2.4.14 Remote Network Monitoring (rmonmib)

NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.

Chair(s):

Andy Bierman <abierman@cisco.com>

Operations and Management Area Director(s):

John Curran <jcurran@bbn.com>
Michael O''Dell <mo@uu.net>

Operations and Management Area Advisor:

John Curran <jcurran@bbn.com>

Technical Advisor(s):

Steven Waldbusser <waldbusser@ins.com>

Mailing Lists:

General Discussion: rmonmib@cisco.com
To Subscribe: rmonmib-request@cisco.com
Archive: ftpeng.cisco.com/ftp/rmonmib/rmonmib

Description of Working Group:

The RMON MIB Working Group is chartered to define a set of managed objects for remote monitoring of networks. These objects will be the minimum necessary to provide the ability to monitor multiple network layers of traffic in remote networks; providing fault, configuration, and performance management, and will be consistent with the SNMP framework and existing SNMP standards.

The working group will consider existing MIB modules that define objects which support similar management, e.g., RFC 1271 and RFC 1513 and efforts in other areas, e.g., the accounting and operational statistics activities. It is possible that this RMON will not be backwards compatible with existing RMON RFCs, but the reasons for any such incompatibility will be well documented.

The following list of features for this RMON has been previously discussed in relation to existing RMON functionality and is included to focus these RMON activities. It is recognized that other issues may be considered and that certain of the following issues may not be part of the final specification:

1) Protocol-type distribution through all seven layers of the ISO model.

2) Address mapping - Network Layer to Data Link (MAC) Layer and vice-versa.

3) Mechanisms that enable the detection of duplicate addresses or address changes.

4) The relationship of the Manager-to-Manager MIB in SNMPv2 and associated RMON alarm related activities.

5) Host Table for the Network Layer and the Transport Layer.

6) Provide a simple mechanism for the specification of event/trap destinations

7) Address the issue of the filter mechanism being constrained by bit-to-bit packet matching, which presents a problem with variable- length packets.

8) Consider how RMON could benefit network security, for example: using the RMON History to provide an accountability and audit trail up to the Transport Layer.

9) Provide performance metrics for the client-server environment.

10) Concerns of hardware implementation should be considered. For example, optimization of the filter and capture group could reduce the cost of the CPU and improve performance.

Goals and Milestones:

Done

  

Activation of working group, call for suggested MIB modules.

Done

  

Submit initial Internet-Draft.

Done

  

Submit RMON-2 MIB Internet-Draft.

Aug 95

  

Submit RMON-2 MIB Internet-Draft to IESG for standards track action.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC1757

DS

Remote Network Monitoring Management Information Base

RFC2021

PS

Remote Network Monitoring Management Information Base Version 2 using SMIv2

RFC2074

PS

Remote Network Monitoring MIB Protocol Identifiers

Current Meeting Report

Minutes of the RMONMIB WG Interim Meeting
Santa Clara, CA - June 25-28, 1997

Reported by Andy Bierman, WG Chair

I. 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.

II. Review Material

(a) RMON Protocol Identifiers Specification

(b) HC-RMON MIB

(c) SMON MIB

III. 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 are 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:

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:

LANE:

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:

Dave Perkins will add elements of syntax from the email proposal.

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:

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:

The HC-MIB additions specify an Integer64 object, which is neither legal nor 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 represents 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 that 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:

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

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:

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)
}

3.2.5) Counter64 Tax

The WG discussed the burden and cluttering effect caused by defining every counter object three times:

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:

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):

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:

[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
rmonHCOutSpeedGauge32, in kBits/sec
rmonHCStatsDropEvents Counter32,
rmonHCStatsDroppedFrames Counter32,
rmonHCStatsOwner OwnerString,
rmonHCStatsStatus RowStatus
}

Table Features:

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 that 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:

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 defined for use 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:

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 that 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:

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 addresses in the index?]

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 that 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 recommended 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

2) smonMibStats

3) portCopy

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.

Slides

None Received

Attendees List

Roster Not Received

Previous PageNext Page