Remote Network Monitoring (rmonmib) Charter

NOTE: This charter is accurate as of the 31st IETF Meeting in San Jose. It may now be out-of-date. (Consider this a "snapshot" of the working group from that meeting.) Up-to-date charters for all active working groups can be found elsewhere in this Web server.


Network Management Area Director(s):

Area Advisor

Mailing List Information

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.
May 95
Submit recommendation for Proposed Standard.

No Current Internet-Drafts

Request for Comments