Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

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

Wrap

Text File | 1997-10-13 | 38.8 KB | 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 abierman@cisco.com Russell Dietz rsdietz@techelite.com John Flick johnf@hprnd.rose.hp.com Manjiri Gadagbar manjiri@baynetworks.com Robin Iddon robin_iddon@3mail.3com.com Barry Kesner bkesner@raleigh.ibm.com Bill Lahaye lahaye@ctron.com Tam Nguyen tgnguyen@baynetworks.com David Perkins dperkins@scruznet.com Dan Romascanu dromasca@madge.com Rajeev Seth rseth@enetman.com Steve Waldbusser waldbusser@ins.com Rich Waterman rwaterma@msn.com Hong Xiao hong@shomiti.com --------------1809D9A521D4F0B6E61169FA--