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
[email protected]
Russell Dietz
[email protected]
John Flick
[email protected]
Manjiri Gadagbar
[email protected]
Robin Iddon
[email protected]
Barry Kesner
[email protected]
Bill Lahaye
[email protected]
Tam Nguyen
[email protected]
David Perkins
[email protected]
Dan Romascanu
[email protected]
Rajeev Seth
[email protected]
Steve Waldbusser
[email protected]
Rich Waterman
[email protected]
Hong Xiao
[email protected]
--------------1809D9A521D4F0B6E61169FA--
