Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/rmonmib/rmonmib-interim-minutes-97jun.txt

Text File | 1997-10-13 | 40KB | 1,018 lines

OPS Area
RMONMIB WG Interim Meeting Minutes
Santa Clara, CA
June 25-28, 1997
Minutes by Andy Bierman - WG Chair

1) Summary
----------

The RMONMIB WG met to advance progress on all I-Ds under development:

  - RMON Protocol Identifiers
  - High Capacity RMON (HC-RMON)
  - RMON Extensions for Switched Networks (SMON)

All features were either accepted, modified, or rejected.
New I-Ds will be generated, which will be subject to
WG Last Call upon publication.

2) Review Material
------------------

 (1) RMON Protocol Identifiers Specification
     - pre-draft-ietf-rmonmib-rmonprot-v2-01.txt  (posted 13jun97)

 (2) HC-RMON MIB
     - draft-ietf-rmonmib-hcrmon-00.txt
     - email-robin_iddon-hcrmon.txt               (posted 28feb97)

 (3) SMON MIB
     - pre-draft-ietf-rmonmib-smon-00.txt         (posted 14jun97)

3) Minutes
----------

The following minutes do not contain a temporal account of
discussions, but rather a summary of all issues and resolutions.
Detailed rationale for decisions made is not always presented.

3.1) RMON Protocol Identifiers

3.1.1) Leaf protocols

Many leaf PI macros have been added to the document in the
TCP/IP suite.  Additional text will be added to emphasize:

   - actual PD implementations can contain protocolDirTable
     INDEX values not represented in this document

   - the PI document will never contain all leaf protocols.
     Given that the textual identifier (protocolDirDescr)
     is not authoritative whatsoever, and the protocolDirID
     encoding for a leaf is actually defined in the PI macro(s) of
     its parent(s), this is not considered a problem.

   - actual PD implementations may identify children of tcp or udp
     under either or both transports, even though the PI document
     may identify a leaf as rooted under tcp or udp specifically.


3.1.2) PI Support for AAL-5 Based Encapsulations

The WG will partially support AAL-5 encapsulations, however
no special identifiers will be added to the PI document.
Instead, RFC 1483 encaps will be mapped to the appropriate
existing  base layer identifier that follows the RFC 1483 header.
The dataSource for a collection monitoring AAL-5 traffic
must reference an ifEntry with an associated ifType of one
of these values:

 RFC 1483:
   - aal5(49)    (preferred, but ifStack required)
   - atm(37)     (should use only when no ifStack)
 LANE:
   - aflane8023(59)    (ifStack required)
   - aflane8025(60)    (ifStack required)

It is understood that not all possible attributes of RFC 1483
or LANE encapsulations can be identified with this approach,
and that this approach may rely on proper ifStack representation
of these logical interfaces.  An NMS will have to use more
ATM-specific MIBs to monitor such statistics.

3.1.3) PI Support for IEEE 802.1Q Encapsulations

The WG will support the emerging VLAN encapsulation standard
by adding a PI macro for dot1Q, which will be positioned as
a 'shim' layer, between the ether2 base layer and the network layer.
This approach can support the ether2 and SNAP child protocol encoding
rules, but not LLC without SNAP. Also, LLC-N and LLC-TR encoding cannot
be distinguished.

3.1.4) Document Edits

In section 4., Fig. 1c, Fig. 1d:

Remove special case descriptions for vsnap base layer encoding.

In section 4.2:

Elements of syntax will be added from the email proposal by Dave Perkins.

The syntax for the vsnap base layer encoding will be changed.
The basic syntax will be simplified and made more extensible.
The numbering specification for vsnap will change to a series
of quad-words, separated by colons (e.g. 0x0011 : 0x2233 : 0x4455).
[ed. - how is a 3-byte OUI represented?]

The vnap encapsulation itself will be encoded exactly as the other
base layers, value = [0.0.0.4]. The OUI field will move to a new
protocol macro, for each vsnap OUI needed. E.g.,

 OLD WAY:

   atalk PROTOCOL-IDENTIFIER
     ...
   ::= { vsnap(0x080007) 0x809b }

 NEW WAY:

   apple-oui PROTOCOL-IDENTIFIER
     ...
   ::=  { vsnap 0x080007 }


   atalk PROTOCOL-IDENTIFIER
     ...
   :== { apple-oui 0x809b }

In section 4.2.1:

New text will be added to document protocol names as they appear
in RFC 1700, by allowing a more flexible syntax. Proposal
by Dave Perkins, and modifications by Skip Koppenhaver will
be used to replace the text in this section.

In section 5:

Typos identified in emails from Skip Koppenhaver and Dave Perkins
will be corrected.

Reference section will be completed.

In section 5.1.1.2:

Text will be added to emphasize proper usage of the wildcard function.
Clarifications regarding default encoding choices will also be added:

  - always use the lowest possible valued base layer for the
    wildcard encoding when a network layer can be encoded
    more than one way (e.g., choose ether2 over snap).

  - choose ether2 over snap even if the probe contains only
    token ring interfaces

  - wildcard-<base-layer> (e.g., wildcard-ether2 == 4.1.0.0.1.1.0)
    is not allowed. Wildcarding applies to the network layer,
    not the base layer.  "Wildcard-ether2" is supposed to represent
    all MAC frames, which can be counted with RMON1.

3.2) HC-RMON MIB

The HC-RMON MIB additions (email-robin_iddon-hcrmon.txt) were discussed
at length.

3.2.1) 48 bit vs. 64 bit Counters

A proposal was debated to redefine the HC counters to Counter48, in order to
allow easy conversion to floating point format, for the purpose of data
archival. The HC counters will remain as Counter64, since there is not
sufficient interest in defining new ASN.1 data types at this time.

3.2.2) Table Additions

The following tables will be added to support high capacity history and TopN
collections:

  - etherHistoryHighCapacityTable
  - hostTopNHighCapacityTable
  - nlMatrixTopNHighCapacityTable
  - alMatrixTopNHighCapacityTable
  - usrHistoryHighCapacityTable

The HC-MIB additions specify an Integer64 object, which is neither legal or
necessary, since the pkt or octetRate objects can only have non-negative
values.  Therefore, all such objects will have a syntax of Gauge64
(sec. 3.2.3).

3.2.3) New Data Type Definition

A proposal will be written specifying a textual convention for a data type
called Gauge64, derived from Counter64. It will have the same semantics as
Gauge32, except extended to 64 bit precision.  The HC-RMON MIB needs this data
type to snapshot Counter64 values and represent non-negative deltas  between
two Counter64 values.

3.2.4)  TopN RateBase Additions

The TopNControl tables associated with the data tables listed in sec. 3.2.2
contain 'rateBase' objects which enumerate and identify the counter used to
sort the data table.

The WG agreed on a proposal to duplicate some or all of these control tables,
by adding enumerations to the end of the following objects:

  -  hostTopNRateBase
  -  nlMatrixTopNControlRateBase
  -  alMatrixTopNControlRateBase

These enumerations would replicate the existing versions, and allow 2 new
modes of rate selection:

  - Counter64 versions of the rateBase
  - Counter32 & Overflow Counter32 pair version of rateBase

For example, the hostTopNRateBaseObject would be extended:

 SYNTAX INTEGER {
                      hostTopNInPkts(1),
                      hostTopNOutPkts(2),
                      hostTopNInOctets(3),
                      hostTopNOutOctets(4),
                      hostTopNOutErrors(5),
                      hostTopNOutBroadcastPkts(6),
                      hostTopNOutMulticastPkts(7),
                      hostTopNHCInPkts(8),
                      hostTopNHCOutPkts(9),
                      hostTopNHCInOctets(10),
                      hostTopNHCOutOctets(11),
                      hostTopNHCOutErrors(12),
                      hostTopNHCOutBroadcastPkts(13),
                      hostTopNHCOutMulticastPkts(14),
                      hostTopNOvflInPkts(15),
                      hostTopNOvflOutPkts(16),
                      hostTopNOvflInOctets(17),
                      hostTopNOvflOutOctets(18),
                      hostTopNOvflOutErrors(19),
                      hostTopNOvflOutBroadcastPkts(20),
                      hostTopNOvflOutMulticastPkts(21)
              }

Upon further review, the Chair is asking the WG to consider a simpler
approach. In the event an agent has implemented any or all of the tables
listed in sec. 3.2.2:

  - there should be no difference in the sort order between the Counter64
    and Ovfl-Counter32/Counter32 pair rateBase objects

  - there should be no reason the agent can implement Counter64, but not
    the Ovfl-Counter32 object

  - there should be no reason an NMS programmed to use the new mechanism
    can't check for both Counter64 and Ovfl-Counter32, for collections
    with a hostTopNRateBase == [8..14].

Simplification example:

 SYNTAX INTEGER {
                      hostTopNInPkts(1),
                      hostTopNOutPkts(2),
                      hostTopNInOctets(3),
                      hostTopNOutOctets(4),
                      hostTopNOutErrors(5),
                      hostTopNOutBroadcastPkts(6),
                      hostTopNOutMulticastPkts(7),
                      hostTopNHCInPkts(8),
                      hostTopNHCOutPkts(9),
                      hostTopNHCInOctets(10),
                      hostTopNHCOutOctets(11),
                      hostTopNHCOutErrors(12),
                      hostTopNHCOutBroadcastPkts(13),
                      hostTopNHCOutMulticastPkts(14)
              }

  - if agent allows 8-14, then it MUST populate both Counter64 and
    Ovfl-Counter32 HC objects for the selected rateBase.

  - if the NMS sets 8-14 on such an agent, it will retrieve the
    HC version that it wants; this doesn't affect topN function

  - if the NMS sets a rateBase == [1..7], then the agent must not
    sort by the HC version of the rateBase counter, should it exist.

3.2.5) Counter64 Tax

The WG discussed the burden and cluttering effect caused by defining
every counter object 3 times:
    { fooBars, fooBarOvfls, fooBar64s }.

The WG's intent is to support a single version of a counter, e.g.,
    { fooBars } OR { fooBar64s }
based on 1573 rules, at some time in the future when Counter64
support is in wide deployment.

3.2.6) UsrHistory Clarification

RFC 2021 does not contain text that explicitly states how 'absolute'
type usrHistory objects should be collected when 'delta' objects
are present in the same usrHistory bucket. An 'absolute' object
requires one poll at T0, and a 'delta' object requires 2 polls,
at T0 and T1 (i.e., val(T1) - val(T0) is stored at T1).  When both
poll types are combined, 'absolute' objects are polled at T1.

3.2.7) Full Duplex Ports

The monitoring and representation of full-duplex ports was
discussed at length.  The following conclusions were reached:

   - full duplex ports must be represented as a single dataSource,
     the same as a half-duplex port.

   - a probe located inside a switch will be able to properly
     distinguish 'in' pkts from 'out' pkts, but stand-alone probes
     would arbitrarily label one direction 'in', and the other direction
     'out', for RMON counting purposes.

   - the rpMauType object in the latest HUB-MAU MIB
     (draft-ietf-hubmib-mau-mib-04.txt) can be used to distinguish
     the actual state (10/100, half-duplex/full-duplex)
     of a full duplex Ethernet port.  However, this MIB is not
     widely implemented [ed. - or even RFC 1515?].

   - the HC-RMON MIB will support 100 MB and Gigabit Ethernet
     statistics with a new media-independent rmonHCStatsTable (sec. 3.2.9).

   - an agent may use the existing etherStats and etherHistory
     tables defined in RFC 1757 for such interfaces, but the WG will not
     modify the etherHistoryTable.

   - the ifSpeed for full-duplex ports should be twice the half-duplex speed,
     for RMON netUtilization calculation.


3.2.8) CaptureBufferPacketTime Granularity Extension

The packet-timestamp in the RMON-1 MIB has milli-second granularity,
which is not sufficient for 100MB and Gigabit Ethernet packet capture.
The following object will be added (in a table augmenting the
captureBufferEntry):

captureBufferPacketHCTime  OBJECT-TYPE
  SYNTAX      Integer32 (0..999999)
  UNITS       "nano-seconds"
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "...  use this object in conjunction with existing timestamp
      object; return number of nano-seconds to be added to to number
      of milli-seconds obtained from the captureBufferPacketTime
      object, to obtain true inter-pkt arrival time."
  ::= { captureBufferHCEntry 1 }

3.2.9) Media Independent HC StatsTable

A new group with a single table will be added to the HC-RMON MIB
to provide generic statistics support for any RMON dataSource.

rmonHCStats Counter Matrix:
      [in, out] *
      [totalPkts, totalOctets, nuCastPkts, nuCastOctets, totalErrPkts+] *
      [Counter32, Ovfl-Counter32, Counter64]
  + == except no 64-bit support for totalErrPkts or 'out' version


[ed. - I don't have detailed notes on this table; Steve will
add to HC-MIB from his notes. This MIB entry is from memory;
actual I-D may be different.]

  rmonHCStatsEntry
    INDEX { rmonHCStatsIndex }

    RmonHCStatsEntry ::= SEQUENCE {
        rmonHCStatsIndex                    Integer32, -- (1..65535)
        rmonHCStatsDataSource               DataSource,
        rmonHCStatsTotalInPkts              Counter32,
        rmonHCStatsTotalInOvflPkts          Counter32,
        rmonHCStatsTotalInHCPkts            Counter64,
        rmonHCStatsTotalInOctets            Counter32,
        rmonHCStatsTotalInOvflOctets        Counter32,
        rmonHCStatsTotalInHCOctets          Counter64,
        rmonHCStatsTotalInErrPkts           Counter32,
        rmonHCStatsTotalInErrOvflPkts       Counter32,
        rmonHCStatsTotalInErrHCPkts         Counter64,
        rmonHCStatsNuInPkts                 Counter32,
        rmonHCStatsNuInOvflPkts             Counter32,
        rmonHCStatsNuInHCPkts               Counter64,
        rmonHCStatsNuInOctets               Counter32,
        rmonHCStatsNuInOvflOctets           Counter32,
        rmonHCStatsNuInHCOctets             Counter64,
        rmonHCStatsTotalOutPkts             Counter32,
        rmonHCStatsTotalOutOvflPkts         Counter32,
        rmonHCStatsTotalOutHCPkts           Counter64,
        rmonHCStatsTotalOutOctets           Counter32,
        rmonHCStatsTotalOutOvflOctets       Counter32,
        rmonHCStatsTotalOutHCOctets         Counter64,
        rmonHCStatsOutNuPkts                Counter32,
        rmonHCStatsOutNuOvflPkts            Counter32,
        rmonHCStatsOutNuHCPkts              Counter64,
        rmonHCStatsOutNuOctets              Counter32,
        rmonHCStatsOutNuOvflOctets          Counter32,
        rmonHCStatsOutNuHCOctets            Counter64,
        rmonHCInSpeed                       Gauge32,   -- in kBits/sec
        rmonHCOutSpeed                      Gauge32,   -- in kBits/sec
        rmonHCStatsDropEvents               Counter32,
        rmonHCStatsDroppedFrames            Counter32,
        rmonHCStatsOwner                    OwnerString,
        rmonHCStatsStatus                   RowStatus
    }

Table Features:

  - combined control & data table, like etherStats
  - arbitrary integer RMON control index
  - regular RMON DataSource (OID) driven
  - for half-duplex ports. only the 'in' set of counters are used
  - counts good and bad frames.

3.2.10) HC-MIB Conformance Statements

The WG did not discuss conformance statements for the HC-RMON MIB
at this meeting. Previously, the WG agreed to several points:

   a) RFC 1573 instantiation rules could be applied with dataSource
      granularity.

   b) dynamically sparse instantiation of Counter64 objects
      is not desirable, so the Counter64 version of an RMON counter
      should be instantiated if a given dataSource can possibly
      cross the thresholds defined in RFC 1573.

There is still some confusion as to which Counter64 instances must
be created when not all dataSources available for RMON collection
are the same speed. It is likely a monitored device will have far
more low-speed then high-speed interfaces, so instantiating all
HC counters would cause the agent to double the counter memory
required for interfaces, just to implement an HC collection on
one interface.

The HC-MIB tables will therefore be conditionally mandatory, based
on the maximum possible speed of a given dataSource.

3.3) SMON MIB

The SMON was discussed for two days, and significantly modified.
The tables are presented in the order found in the MIB.

3.3.1)  SmonDataSource TC

This TC will be changed to support the following dataSource types:

  - ifIndex.<I>
    DataSources of this traditional form are called 'port-based',
    but only if ifType.<I> is not equal to 'propVirtual(53)'.

  - rmonVlanDataSource.<V>
    A dataSource of this form refers to a 'Packet-based VLAN' and
    is called a 'VLAN-based' dataSource.

  - entPhysicalEntry.<N>
    A dataSource of this form refers to a physical entity within
    the agent (e.g. entPhysicalClass = backplane) and os called
    an 'entity-based' dataSource.

Repeater ports will not be explicitly modeled as RMON dataSources,
due to side effects associated with the new dataSource implementation
requirements (sec. 3.3.3).  Repeater backplanes can be represented
as entity-based dataSources.

3.3.2) rmonVlanDataSource OID Registration Point

An OBJECT IDENTIFIER for registration purposes only will be
defines for uses as an SmonDataSource. A single integer parameter
is appended to the end of this OID when actually encountered in
the dataSourceCapsTable, which represents a positive, non-zero VLAN
identifier value.

3.3.3) DataSourceCapsTable

A new group called 'dataSourceCaps' will be added, containing one
table, the dataSourceCapsTable.  An RMON agent populates this
table will all supported dataSources.  An NMS may use this table to
discover the identity and attributes of the dataSources on
a given agent implementation.  Similar to the probeCapabilities object,
actual row-creation operations will succeed or fail based on the
resources available and parameter values used in each row-creation
operation.

The new read-only table can be summarized as follows:

  dataSourceCapsTable
  - INDEX { IMPLIED dataSourceCapsObject }

    DataSourceCapsEntry ::= SEQUENCE {
        dataSourceCapsObject          SmonDataSource,
        dataSourceRmonCaps            BITS,
        dataSourceCopyCaps            BITS,
        dataSourceCapsIfIndex         InterfaceIndex
    }

  - dataSourceCapsObject               SmonDataSource
    Identifies the true dataSource to the NMS.

  - dataSourceRmonCaps                BITS
    General attributes of the specified dataSource.
    Note that these are static attributes, which should not
    be adjusted because of current resources or configuration.

      - countErrFrames(0)
        The agent sets this bit for the dataSource if errored frames
        received on this dataSource can actually be monitored by the agent.
        The agent clears this bit is any errored frames are not visible to
        the RMON data collector.

      - countAllGoodFrames(1)
        The agent sets this bit for the dataSource if all good frames received
        on this dataSource can actually be monitored by the agent.
        The agent clears this bit if any good frames are not visible for RMON
        collection, e.g., the dataSource is a non-promiscuous interface or an
        internal switch interface which may not receives frames which were
        switched in hardware or dropped by the bridge forwarding function.

      - countAnyRmonTables(2)
        The agent sets this bit if this dataSource can actually be used in
        any implemented RMON tables, resources notwithstanding.
        The agent clears this bit if this dataSourceCapsEntry is present
        simply to identify a dataSource that may only be used as
        portCopySource and/or a portCopyDest, but not the source of an
        actual RMON data collection.

  - dataSourceCopyCaps                     BITS
    PortCopy function capabilities of the specified dataSource.
    Note that these are static capabilities, which should not be adjusted
    because of current resources or configuration.

      - copySourcePort(0)
        The agent sets this bit if this dataSource is capable of acting
        as a source of a portCopy operation. The agent clears this bit
        otherwise.

      - copyDestPort(1)
        The agent sets this bit if this dataSource is capable of acting as
        a destination of a portCopy operation. The agent clears this bit
        otherwise.

      - copySrcTxTraffic(2)
        If the copySourcePort BIT is set:
          The agent sets this bit if this dataSource is capable of
          copying frames transmitted out this portCopy source.
          The agent clears this bit otherwise.  This function is
          needed to support full-duplex ports.
        Else this BIT should be cleared.

      - copySrcRxTraffic(3)
        If the copySourcePort BIT is set:
          The agent sets this bit if this dataSource is capable of
          copying frames received on this portCopy source.
          The agent clears this bit otherwise. This function is
          needed to support full-duplex ports.
        Else this BIT should be cleared.

      - countDstDropEvents(4)
        If the copyDestPort BIT is set:
          The agent sets this bit if it is capable of incrementing the
          portCopyDstDroppedFrames object (sec. 3.3.11), when this
          dataSource is the target of a portCopy operation and a
          frame destined to this dataSource is dropped (for RMON
          counting purposes). The agent clears this bit otherwise.
        Else this BIT should be cleared.

      - copyErrFrames(5)
        If the copySourcePort BIT is set:
          The agent sets this bit if it is capable of copying all errored
          frames from this portCopy source-port, for errored frames
          received on this dataSource. The agent clears this bit otherwise.
        Else this BIT should be cleared.

      - copyUnalteredFrames(6)
        If the copySourcePort BIT is set:
          The agent sets this bit if it is capable of copying all frames
          from this portCopy source-port without alteration in any way;
          including, but not limited to:
             - truncation (with or without CRC regeneration)
             - proprietary header insertion
             - MAC header rewrite
             - VLAN retagging
          The agent clears this bit otherwise.
        Else this BIT should be cleared.

      - copyAllGoodFrames(7)
        If the copySourcePort BIT is set:
          The agent sets this bit for the dataSource if all good frames
          received on this dataSource are normally capable of being copied
          by the agent. The agent clears this bit if any good frames are
          not visible for the RMON portCopy operation, e.g., the dataSource
          is a non-promiscuous interface or an internal switch interface
          which may not receive frames which were switched in hardware or
          dropped by the bridge forwarding function.
        Else this BIT should be cleared.

  - dataSourceCapsIfIndex       InterfaceIndex
    This object contains the ifIndex value of the ifEntry associated with
    this dataSource.


3.3.4)  DataSource Agent Implementation Requirements

Upon restart of the RMON agent, the dataSourceTable, ifTable, and perhaps
entPhysicalTable are initialized for the available dataSources.

For each dataSourceCapsEntry representing a VLAN or entPhysicalEntry,
the agent must create an associated ifEntry with a ifType value
of 'propVirtual(53)'.  This ifEntry will be used as the actual value
in RMON control table dataSource objects.  The assigned ifIndex value
is copied into the associated dataSourceCapsIfIndex object.

It is understood that dataSources representing VLANs may not always
be instantiated immediately upon restart, but rather as VLAN usage
is detected by the agent.  The agent should attempt to create
dataSource and interface entries for all dataSources as soon as possible.

3.3.5) Arbitrary DataSource Aggregation

The WG decided to support specific dataSource aggregation functions,
instead of generic functions, such as the arbitrary combination
of dataSources provided in the SMON MIB.  The motivation for
grouping dataSources together is the reduction in agent resources
and NMS polling required to provide the equivalent data-set.
However, some vendors said they would not reduce agent resource
usage with such a mechanism.

Arbitrary combination of dataSources can be useful for collections
of ports grouped for administrative reasons
(e.g. ports 1-8 == ISP_customer_1) or agent resource restrictions
(e.g. agent can only monitor ports in groups of 4).

However, this approach was rejected for two reasons:

  1) the agent requirement to count a single packet once in a
     port aggregation is perceived as too difficult to enforce in
     an interoperable manner because packet counting within a
     switch is too architecture-dependent.

  2) an arbitrary NMS has no way of knowing which permutations
     of dataSources the agent will allow to be configured.
     The WG could not think of a way to properly define MIB objects
     for such aggregation rules that didn't require brute force
     listing of all permutations.

Therefore the SMON Port Aggregation group will be removed, which
includes the following tables:

  - aggregCollTable
  - aggregSelTable
  - aggregControlTable
  - aggregStatsTable

3.3.6) VLAN Statistics Collection by DataSource

In this mode. an agent must monitor all frames on all ingress ports,
and attribute them to the correct VLAN.

Statistics will be gathered on packet-based VLANs, and it is
an implementation-specific matter as to how the agent determines
the proper default-VLAN for untagged, or priority-tagged frames
(PVID) for each frame.  RMON VLAN data collection is done after
the VLAN Ingress Rules have been applied for each frame.

The RMON agent must identify the VLAN ID and user_priority
values associated with frames received at each ingress point on
the switch.  Frames are counted once at each ingress point only,
regardless of the number of egress ports to which the frame
will be forwarded.

It is an implementation-specific manner as to how many collections of
this type the agent may allow concurrently.

[Ed. - Do we need to add a requirement that the RMON agent converts
LLC-TR encoded frames to LLC-N format for RMON counting purposes,
to avoid confusion in the RMON tables that use MAC addesses in the
indes?]

3.3.7) PropVirtualTable Removed

The propVirtualTable was going to be used to allow an NMS to direct
the agent to perform the procedure described in sec. 3.3.4.  Since
arbitrary port aggregation (sec. 3.3.5) will not be supported,
there is no need for the NMS to create dataSources.

3.3.8) IfStackTable Usage Removed

Since the rmonVlanDataSource registration OID will be used to identify
VLAN collections, and only packet-based VLANs can be collected for
more than a single dataSource (per collection), the ifStackTable is
no longer needed.

It is possible that implementations may choose to create ifStackEntries
when instantiating the rmonDataSourceEntry for a packet-based VLAN
dataSource, but this is not required or utilized by the standard.

3.3.9) SmonStatsDataSource TC Removed

This TC allowed an smonDataSource to be filtered by VLAN ID and/or VLAN
user priority by appending parameters to an smonDataSource value.
This would allow collection of a single VLAN on a single port, but the
group felt the feature was not worth the extra complexity.

3.3.10) SMON VLAN Statistics

The SMON MIB will support aggregated statistics for IEEE 802.1Q VLAN
environments.

VLAN statistics can be gathered in two different ways; either by using a
dataSource referencing a VLAN (sec. 3.3.6) or by configuring
smonVlanIdStats and/or smonVlanPrioStats collections. These functions allow
a VLAN-ID or user priority distributions per dataSource, auto-populated by
the agent in a manner similar to the RMON1 hostTable.

Only good frames are counted in the tables described in this section.

3.3.10.1) VLAN ID Stats

The smonVlanStatsControlTable allows configuration of VLAN-ID collections.

  smonVlanStatsControlEntry
    INDEX { smonStatsControlIndex }

    SmonVlanStatsControlEntry ::= SEQUENCE {
        smonVlanStatsControlIndex         Integer32,
        smonVlanStatsControlDataSource    SmonDataSource,
        smonVlanStatsControlCreateTime    LastCreateTime,
        smonVlanStatsControlOwner         OwnerString,
        smonVlanStatsControlStatus        RowStatus
    }

The smonVlanIdStatsTable provides a distribution based on the IEEE 802.1Q
VLAN-ID (VID), for each frame attributed to the data source for the
collection.

This function applies the same rules for attributing frames to VLAN-based
collections. RMON VLAN statistics are collected after the Ingress Rules
defined in section 3.13 of the VLAN Specification (P802.1Q/D4)
are applied. [ed. maybe not, see below]

The main motivation for this table is to provide a high-level view of
total VLAN usage, and relative non-unicast traffic usage.  To differentiate
between multicast and broadcast traffic for a given VLAN,
a VLAN-based hostTable collection should be used.

Counter Matrix == [total, NUcast] * [pkts, octets] *
                  [Counter32, Ovfl-Counter32, Counter64]

  smonVlanStatsIdEntry
    INDEX { smonStatsControlIndex, smonVlanIdStatsId }

    SmonVlanStatsIdEntry ::= SEQUENCE {
        smonVlanIdStatsId                   Integer32,
        smonVlanIdStatsTotalPkts            Counter32,
        smonVlanIdStatsTotalOvflPkts        Counter32,
        smonVlanIdStatsTotalHCPkts          Counter64,
        smonVlanIdStatsTotalOctets          Counter32,
        smonVlanIdStatsTotalOvflOctets      Counter32,
        smonVlanIdStatsTotalHCOctets        Counter64,
        smonVlanIdStatsNUcastPkts           Counter32,
        smonVlanIdStatsNUcastOvflPkts       Counter32,
        smonVlanIdStatsNUcastHCPkts         Counter64,
        smonVlanIdStatsNUcastOctets         Counter32,
        smonVlanIdStatsNUcastOvflOctets     Counter32,
        smonVlanIdStatsNUcastHCOctets       Counter64
    }

 -  smonVlanIdStatsId             Integer32 (0..4095)
    VLAN Tag ID
    Note that index 0 is supposed to be converted to a valid VID, based on
    the associated PVID.    [ed. - What does INDEX[0] count? ]

3.3.10.2) SmonVlanIdStatsTable Garbage Collection

It is possible that entries in this table will be LRU garbage-collected
based on agent resources, and VLAN configuration.  Agents are encouraged
to support all 4096 index values and not garbage collect this table.

[ed. Given that these can be removed and recreated, just like an
nlHostEntry, shouldn't there be a LastCreateTime object in the table?]


3.3.10.3) VLAN Priority Stats

The smonPrioStatsControlTable allows configuration of VLAN collections,
based on the value of the 3-bit user_priority field encoded in the TCI.
Note that this table merely reports priority as encoded in VLAN headers,
not the priority (if any) given the frame for actual switching purposes.

  smonPrioStatsControlEntry
    INDEX { smonPrioControlIndex }

    SmonPrioStatsControlEntry ::= SEQUENCE {
        smonPrioStatsControlIndex         Integer32,
        smonPrioStatsControlDataSource    SmonDataSource,
        smonPrioStatsControlCreateTime    LastCreateTime,
        smonPrioStatsControlOwner         OwnerString,
        smonPrioStatsControlStatus        RowStatus
    }

The smonPrioStatsTable provides a distribution based on the user_priority
field in the VLAN header.

Counter Matrix == [total] * [pkts, octets] *
                  [Counter32, Ovfl-Counter32, Counter64]

  smonPrioStatsEntry
    INDEX { smonPrioControlIndex, smonPrioStatsId }

    SmonPrioStatsEntry ::= SEQUENCE {
        smonPrioStatsId                 Integer32,
        smonPrioStatsPkts               Counter32,
        smonPrioStatsOvflPkts           Counter32,
        smonPrioStatsHCPkts             Counter64,
        smonPrioStatsOctets             Counter32,
        smonPrioStatsOvflOctets         Counter32,
        smonPrioStatsHCOctets           Counter64
    }

 -  smonPrioStatsId             Integer32 (0..7)
    VLAN Tag User Priority value

 - Entries in this table may not be garbage-collected.

 - NUcast counters were removed because only the packet and octet
   priority totals were deemed to be interesting.

3.3.11) PortCopyTable

The portCopyTable is used along with the dataSourceCopyCaps object in
the dataSourceCapsTable to configure traffic steering functions within
a switch.  Note that this table manages no RMON data collection in itself,
and a probe may possibly implement no other RMON objects except the
probeCapabilities scalar, the dataSourceCapsTable, and this table.

   portCopyTable
   INDEX [ portCopySource, portCopyDest]

   PortCopyEntry ::=  SEQUENCE {
        portCopySource            InterfaceIndex,
        portCopyDest              InterfaceIndex,
        portCopyDstDroppedFrames  Counter32,
        portCopyStatus            RowStatus
   }

The portCopySource and portCopyDest values must represent ifEntries
which have corresponding entries in the dataSourceCapsTable.

It is an implementation specific matter as to whether an agent
will allow an interface to act as a portCopySource and a portCopyDest
at the same time, or allow an interface to be used for RMON collection
and portCopy operation(s) at the same time.  An agent may allow any or
all of the portCopy modes described below.

The standard does not place a limit on the mode by which this copy function
may be used:

 Mode 1 --  1:1 Copy
   Single dataSource copied to a single destination dataSource.
   Agent may limit configuration based on ifTypes, ifSpeeds,
   half-duplex/full-duplex, or agent resources.
   In this mode the single instance of the portCopyDstDroppedFrames
   object refers to dropped frames on the portCopyDest interface.

 Mode 2 --  N:1 Copy
   Multiple dataSources copied to a single destination dataSource.
   Agent may limit configuration based on ifTypes, ifSpeeds,
   half-duplex/full-duplex, portCopyDest over-subscription,
   or agent resources.
   In this mode all N instances of the portCopyDstDroppedFrames
   object should contain the same value, and refer to dropped frames
   on the portCopyDest interface.

 Mode 3 --  N:M Copy
   Multiple dataSources copied to multiple destination dataSources.
   Agent may limit configuration based on ifTypes, ifSpeeds,
   half-duplex/full-duplex, portCopyDest over-subscription, or agent
   resources.
   In this mode all N instances of the portCopyDstDroppedFrames
   object should the droppedFrames counter associated with the
   portCopyDest INDEX value for the specific entry, and refer to the
   total dropped frames on that portCopyDest interface (i.e., a single
   droppedFrames counter is maintained for each value of M).

The rows do not have an OwnerString, since multiple rows may be part
of the same portCopy operation. The agent is expected to activate or
deactivate entries one at a time, based on the rowStatus for the given row.
This can lead to unpredictable results in Modes 2 and 3 in applications
utilizing the portCopy target traffic, if multiple PDUs are used to
fully configure the operation.  It is reccomended that an entire
portCopy operation be configured in one SetRequest PDU if possible.

The portCopyDest object may not reference an interface associated with
a packet-based VLAN (rmonVlanDataSource.V), but this dataSource type may be
used as a portCopySource.

3.3.12) SMON Conformance Statements and Groups

There are 4 groups in the SMON MIB:
  1) smonVlanStats
  2) smonPrioStats
  3) dataSource
  4) portCopy

There are 3 conformance groups:
  1) smonMIBGroup
     - all 4 groups mandatory

  2) smonMibStats
     - dataSource mandatory
     - smonVlanStats mandatory if IEEE 802.1Q bridging implemented
     - smonPrioStats mandatory if IEEE 802.1p priority-switching implemented
     - portCopy optional

  3) portCopy
     - dataSource mandatory
     - smonVlanStats optional
     - smonPrioStats optional
     - portCopy mandatory


3.4) ProbeCapabilities Additions

The probeCapabilities bitmask needs to be republished with some new
BIT definitions for the HC-RMON and SMON MIBs:

 HC-RMON MIB:

    - HCStats(27)
      The probe supports at least one of the HC statistics collection
      types.

    - HCHistory(28)
      The probe supports at least one of the HC history collection types.

    - HCHost(29)
      The probe supports at least one of the HC host collection types.

    - HCMatrix(30)
      The probe supports at least one of the HC matrix collection types.

    - HCTopN(31)
      The probe supports at least one of the HC topN collection types.

    - HCCapture(32)
      The probe supports the captureBufferHCPacket group.

SMON MIB:

    - smonVlanStats(33)
      The probe supports the smonVlanStats object group.

    - smonPrioStats(34)
      The probe supports the smonPrioStats object group.

    - dataSource(35)
      The probe supports the dataSource object group.

    - portCopy(36)
      The probe supports the portCopy object group.

It hasn't been determined which new document will contain the updated
probeCapabilities object.  [ed. - Steve?]

4) Meeting Resolutions
----------------------

The functional attributes of each feature have been specified by the WG.
The WG Editors will now rewrite the drafts, and the final WG review
cycle can then begin.

4.1) Meeting Action Items

Each of the I-Ds in progress need to be updated by the WG Editors.

An I-D proposal for the Gauge64 TC needs to be written by the WG Chair.

4.2) Near-Term Timetable

      June 27   -- Interim meeting ends
      July 21   -- I-D updates published; upon publication give
                   3 week WG Last Call on all I-Ds
      August 11 -- Re-publish I-Ds if needed, and submit them to IESG,
                   to begin NM Directorate Review process

4.3) Upcoming RMONMIB WG Meetings

There will not be an RMONMIB WG meeting at the Munich IETF.
The WG plans to be completed before the meeting begins, and the
upcoming I-Ds are not expected to generate any controversy.
The current set of drafts have undergone three rounds of WG review,
and all unresolvable features have been removed from the documents.


5) Attendees
------------

  Andy Bierman                   [e-mail]
  Russell Dietz                  [e-mail]
  John Flick                     [e-mail]
  Manjiri Gadagbar               [e-mail]
  Robin Iddon                    [e-mail]
  Barry Kesner                   [e-mail]
  Bill Lahaye                    [e-mail]
  Tam Nguyen                     [e-mail]
  David Perkins                  [e-mail]
  Dan Romascanu                  [e-mail]
  Rajeev Seth                    [e-mail]
  Steve Waldbusser               [e-mail]
  Rich Waterman                  [e-mail]
  Hong Xiao                      [e-mail]

--------------1809D9A521D4F0B6E61169FA--