NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 24-Nov-97
Andy Bierman <email@example.com>
Operations and Management Area Director(s):
John Curran <firstname.lastname@example.org>
Michael O'Dell <email@example.com>
Operations and Management Area Advisor:
John Curran <firstname.lastname@example.org>
Steven Waldbusser <email@example.com>
To Subscribe: firstname.lastname@example.org
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:
Activation of working group, call for suggested MIB modules.
Submit initial Internet-Draft.
Submit RMON-2 MIB Internet-Draft.
Submit RMON-2 MIB Internet-Draft to IESG for standards track action.
· Remote Network Monitoring MIB Extensions for Switch Networks Version 1.0
· Remote Network Monitoring MIB Protocol Identifiers (Version 2)
· Remote Network Monitoring Management Information Base for High Capacity Networks
Request For Comments:
Remote Network Monitoring Management Information Base
Remote Network Monitoring Management Information Base Version 2 using SMIv2
Remote Network Monitoring MIB Protocol Identifiers
Minutes of the Remote Network Monitoring (RMONMIB) WG
Chair: Andy Bierman
Reported by: Andy Bierman
The RMONMIB MIB WG met to discuss RMON interoperability issues. Many issues were identified and clarified. As a result, some editorial changes will be made to the documents recently submitted to the IESG for review (PI Spec. v2, HC-RMON, and SMON).
1) Agenda Bashing
2) Working Group Status
3) RMON Interoperability Discussion
4) Future RMON Projects Discussion
Detailed Account of Agenda Items
1) WG Status
The 'final' versions of all work in progress were sent to the Area Director on 12nov97. This included the following documents:
draft-ietf-rmonmib-rmonprot-v2-03.txt (RMON Protocol Identifiers v2)
draft-ietf-rmonmib-smon-04.txt (SMON MIB)
draft-ietf-rmonmib-hcrmon-03.txt (HC-RMON MIB)
There will be some clarifying changes made to these documents, which will be reflected in the version published after the first round of reviews.
2) RMON Interoperability Discussion
All RMON MIBs were discussed, focusing on (real or potential) implementation differences, caused by ambiguities or errors in the RMON documents.
2.1) TimeFilter MIB walk
The RMON-2 MIB clearly states that the TimeMark index should be incremented in a MIB walk of a time-filtered table. Some implementations do not increment the TimeMark, but rather jump to the next table instead of the next TimeMark value for the current table. This is non-compliant, but it allows a simple MIB walk to finish. This is important in some situations, such as during development testing.
It was decided that no new MIB object will be added to identify a 'TimeFilter mode'. It was noted that some implementations may provide this capability in a proprietary manner, but the compliant behavior, as specified in the document, will not be changed.
2.2) Gauge64 vs. Counter64
The RMON MIBs define some TCs:
ZeroBasedCounter32 (based on Gauge32, defined in RMON-2)
ZeroBasedCounter64 (based on Counter64, defined in HC-RMON)
ZeroBasedGauge64 (based on Counter64, defined in HC-RMON)
The use of Counter64 for the base type is not correct. The correct approach for the HC-RMON MIB is to add an unsigned 64-bit data type to the SNMP SMI. This issue has been deferred to the SNMPv3 WG.
2.3) SmonDataSource Syntax
The SMON MIB defines three variants of the SmonDataSource TC. The Entity MIB variant is inconsistent with other sources, such as the Interfaces MIB.
Resolution: The reference to entPhysicalEntry.<N> will be changed to entPhysicalIndex.<N>.
2.4) Bit Encoding
There are some differences in the way bits are encoded in the protocolDirParameters OCTET STRING. There is no confusion related to MIB objects declared as BITS, but this MIB object is only encoded as OCTET STRING INDEX components.
The RMON Protocol Identifiers document states that the protocolDirParameter OCTET should be encoded the same as a BIT is encoded (i.e., Least Significant Bit (LSB) on the left). However, the HTTP example shows this OCTET encoded with the (intuitive) LSB on the right (e.g., bit 0 = 0x01, not 0x80). All implementations of this object followed this intuitive approach.
Resolution: The 'LSB on the right' encoding will be used Sec. 4.2.6, paragraphs 3 and 4 contradict this, and will be removed.
2.5) Row Creation
Many aspects of row creation for specific RMON tables were discussed, as well as proper interpretation of the RowStatus TC defined in RFC 1903. The following is a summary of the issues discussed:
2.5.1) Setting columns in the first PDU without RowStatus
NMS apps should be aware that an agent may accept or reject SetPDUs which do not contain a RowStatus varbind for the row (i.e., fooRowStatus = 'createAndGo' or 'createAndWait').
2.5.2) Creating an Existing Row
If an agent receives a SetPDU containing a RowStatus varbind equal to 'createAndGo' or 'createAndWait', for an existing row, the agent must reject the request.
2.5.3) Common Practices
It was noted that all probes seem to support multiple step row creation, and that the safest NMS algorithm is the '3 step' approach:
PDU 1: Set rowStatus='createAndWait' and ownerString='<me>'
PDU 2: Set rest of r/c columns to appropriate values.
Do not assume DEFVALs are applied.
PDU 3: Set rowStatus to active
It is suggested that an agent support row creation which takes an arbitrary number of Set and Get PDU transactions.
2.5.4) notInService vs. notReady
Some ambiguity exists in the event an agent does not retain all required resources for a given function.
Resolution: RFC 1903 does not mandate that resources must be held by the agent for a row with RowStatus = 'notInService', i.e., the agent may change the RowStatus to 'notReady' at some point after the row was taken out of service by an NMS. Therefore, an RMON probe is not required to honor a Set request to change a given RowStatus value to 'active' at all times, although support for this feature is encouraged.
2.6) ProbeReset Behavior
An agent is encouraged to send an SNMP Response, before executing a system reboot, when processing a RMON-2 'probeReset' varbind. If the agent does not respond, the NMS may repeatedly retransmit the request, possibly causing further reboots.
An NMS is encouraged to check for coldstart or warmstart traps from the probe, as well as an SNMP Response, when using this reboot feature.
2.7) nlMaxDesired/alMaxDesired Quota
Some aspects of the separate 'maxDesired' objects for the network and application layers were clarified:
· Each entry in the NL table must be duplicated in the AL table
· If an entry isn't in the NL table, it can't be in the AL table
· The duplicated AL entries (e.g., alHostInPkts.IP.<ip_addr>.IP) count towards the alMaxDesired quota
· The agent should not reject configurations which cause zero or a seemingly inappropriate number of NL and AL entries to be collected. (Garbage in, Garbage out).
· The inserts and deletes counters should be incremented each time a 'maxDesired' quota is enforced, rather than incrementing the associated 'droppedFrames' counter. This should be done even if the 'maxDesired' quota for the table is zero.
2.8) Clearing inserts/deletes counters
The 'inserts' and 'deletes' counters within a given control row should not be reset to zero when the associated RowStatus is set to 'notInService'. Instead, the 'deletes' counter should be incremented as all the data entries are removed, so that 'inserts = deletes'. These counters should only be set to zero when the control row is first created.
2.9) UsrHistory Issues
The RMON-2 MIB states that this MIB object must point at a 32-bit INTEGER-based object instance. The UsrHistory extensions in the HC-RMON MIB state that the usrHistoryObjectVariable should be pointed at Counter64 instances to cause rows in the 'HC' usrHistoryTable to be created. The RMON-2 text needs to be changed somehow, to lift the 32-bit restriction on INTEGER-based objects, and allow usrHistoryObjectVariable to point at 64-bit MIB objects if the HC-RMON UsrHistory group is supported.
The MIB text is ambiguous with respect to the conditions places on allowing this object to be set to 'active'.
Resolution: This object can be set to 'active' as soon as all columns in the usrHistoryControlEntry are valid. None of the entries in the associated usrHistoryObjectTable need to be valid before the usrHistoryControlEntry can be activated.
The RMON-2 MIB states that this object may be changed while the collection is active, causing the usrHistory buffer to be dynamically resized. The WG agreed to remove this feature, since it was not used in the RMON-1 etherHistory feature.
Resolution: The RMON-2 MIB needs to be changed to clarify that this object cannot be changed if the associated usrHistoryControlRowStatus is 'active', and all references to dynamic buffer resizing should be removed.
2.10) Protocol Directory Issues
Some aspects of prtocolDirTable were clarified:
· A probe must count past 'supportedOff' inner nodes, e.g., If ether2.ip.udp.snmp is configured to be counted, then it must be counted, even if ether2.ip.udp is 'supportedOff' for a given function.
· When a 'protocolDirConfig' object is set to 'supportedOff', the probe should delete all NL, AL, and/or addressMap data entries. Do not delete any AL entries for child protocols.
· A protocolDirEntry for an inner node cannot be deleted if any child entries for that protocol exist in the protocolDirTable.
· If an NL protocol is deleted, than all data collection for that protocol and its children is disabled. This only applies to NL protocols, since an NL protocolDirLocalIndex is required to represent any child in an AL table.
2.11) ProtocolDir Wildcarding
Network protocols not identified with an EtherType (or LLC/SNAP value), must not be identified as 'wildcard-ether2' when representing the wildcarded version of the protocol. The RMON PI Spec could be more clear on this issue, e.g. NL protocols only encapsulated over LLC should be wildcarded with a base layer value for 'wildcard-llc'.
2.12) ProtocolDirDescr Parsing
NMS applications should not parse the protocol description string to identify a given application or inner node, instead of parsing the protocolDirId string. The syntax of this string is not strictly defined, in a manner suitable for parsing.
Resolution: The WG may pursue development of some function to make it easy for an NMS to identify any encapsulation of a given application, such as a 'wildcard-terminal' function or an 'application mapping function', from ASCII string to list of protocolDirLocalIndex values, representing the specified application.
2.13) Multiple Network Layers (IP Tunneling)
There is some ambiguity regarding the detection and representation of encapsulated network layers, such as 'ipip'. The RMON-2 MIB is not very specific regarding the counting of such packets in the addressMap, NL, and AL tables. An agent may make one of several implementation decisions:
· count the innermost NL protocol only
· count the outermost NL protocol only
· count both the innermost and outermost NL protocols only
· count all the NL encapsulations
An NMS can detect encapsulations by examining addressMapPhysicalAddress and addressMapNetworkAddress pairs, to detect layering 'upwards' from the MAC address through the highest NL layer.
It was noted that an NMS has no way to differentiate between counter increments (or addressMapTable changes) due to tunneled traffic and normal traffic (e.g., A.X sends to B.Y, or X sends to Y). Note also that tunneled network encapsulations can only be counted if such an encapsulation is active in the protocolDirTable (e.g., ether2.ip.ipip or wildcard-ether2.ip.ipip.udp.snmp).
2.14) ProtocolDirTable Auto-Population
An agent may add protocol encapsulations as detected on the wire, or it may populate the protocolDirTable with 'everything it knows' upon startup.
If an NMS deletes a protocolDirEntry, the probe should not add it back, due to the auto-learning feature. Note that not all WG members feel that auto-learning is a feature, since it causes everything to be counted by default, and forces an NMS to explicitly disable or delete a protocol, for every encapsulation of that protocol, and for every possible encapsulation of all children of that protocol, in order to counteract the auto-learn 'feature'.
2.15) AddressMapTable Configuration
When an addressMapControlEntry is deleted, the associated addressMapEntries are not deleted. No new entries or entry updates will be done for the associated value of addressMapSource, and existing adderssMapEntries with that addressMapSource value are untouched until they are removed (because the NL address was detected on a different source port, or the entry is aged out).
An agent may disallow multiple addressMapControlEntries with the same value of addressMapControlDataSource, since more than one of such a control entry does not affect the addressMapTable behavior for that data source.
An agent must keep only the 'newest' source port mapping for a given network address, even if that network address is detected on multiple source ports. Only one entry per network address is maintained, even though the addressMapSource object appears in the addressMapEntry INDEX.
3) Future RMON Work
The remaining meeting time was spent discussing ideas for future development by the RMONMIB WG. Note that there are no plans to recharter the WG after the current RFCs are published, and this discussion was held only to gauge working group interest in various features.
3.1) Application Response Measurement (ARM)
Although an effort exists for application-based ARM calculation, a probe-based ARM feature is also desirable. Some RMON vendors have discovered that the RMON-2 Protocol Directory can be used to identify applications to be 'timed', and the existing 'alMatrix' functions can be augmented to convey such information.
There is some concern about how to implement this feature in a scalable way, especially for high speed switches, but there is also a great deal of interest in this feature.
3.2) Wildcarded Terminals
A protocolDirTable enhancement to allow applications (terminals) to be wildcarded has been suggested. It was rejected at the last interim meeting as a 'base layer extension', as being too disruptive a change. This feature would allow an NMS to count any encapsulation of an application by knowing at least one encapsulation of that application, and would allow an agent to conserve memory by not counting separate encapsulations (above the network layer) for the same application.
3.3) RMON for WAN interfaces
This feature is almost completely supported by the new mediaIndependentStatsTable in the HC-RMON MIB, which supports high speed full-duplex interfaces. The RMON MIBs do not support specific WAN media errors or conditions (ala etherStats or tokenRingPStats), but this incremental improvement over a single 'errorInPkts' or 'errorOutPkts' counter is not seen to be worth the effort of developing a WAN_RMON MIB.
3.4) DISMAN-like Extensions for RMON-2
The ability to execute user-defined scripts upon receipt of certain packet types (e.g., via the alMatrixSDTable or the channelTable) can be quite useful. This type of feature has been developed by at least one RMON vendor.
The WG agreed that this complicated feature should wait until (at least) the DISMAN solution for notification dispatching is completed, which may not be for a long time.
3.4) FDDI-RMON MIB
A suggestion was made to develop media-specific RMON functions for FDDI interfaces. The WG has declined to develop a FDDI-RMON MIB in the past, and nothing has changed to alter that sentiment.
3.5) Username to Address Mapping Table
A suggestion was made to augment the existing address mapping function with a 'username to address' mapping function. This may be a mapping between various types of usernames and either a network address or a MAC address.
There was a great deal of interest in this feature, although the details are not well understood at this time.
3.6) portCopyTable for full-duplex ports
The SMON MIB does not allow an NMS to specify which traffic should be copied from a full-duplex source port, in a portCopyEntry. A future augmentation of this table may be developed to allow the traffic direction to be specified by an NMS for full-duplex source ports (i.e., rx-only, tx-only, or both).
The WG will remain active under the current charter until the current drafts are published as RFCs. The document changes agreed upon at this meeting will be added to the next release of each draft.
After the three documents are published as RFCs, the WG will remain inactive until the Area Director determines there is sufficient need to recharter the RMONMIB WG.
go to list