2.4.14 Remote Network Monitoring (rmonmib)

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

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 Remote Network Monitoring (RMONMIB) WG

Chair: Andy Bierman

Reported by: Andy Bierman

Summary

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

Agenda

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:

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

2.9.1) usrHistoryObjectVariable

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.

2.9.2) usrHistoryControlStatus

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.

2.9.3) usrHistoryControlBucketsRequested

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:

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:

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

4) Conclusions

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.

Slides

None Received

Attendees List

go to list

Previous PageNext Page