NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 23-Jul-98
Chair(s):
Andy Bierman <abierman@cisco.com>
Operations and Management Area Director(s):
Harald Alvestrand <Harald.Alvestrand@maxware.no>
Bert Wijnen <wijnen@vnet.ibm.com>
Operations and Management Area Advisor:
Bert Wijnen <wijnen@vnet.ibm.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:
· 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:
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 |
IETF #42 WG Minutes
OPS Area; RMONMIB WG
Chicago, IL August 27, 1998
WG Chair: Andy Bierman (abierman@cisco.com)
Minutes: Andy Bierman and Russell Dietz (rsdietz@tecelite.com)
Review Material:
(Current I-Ds)
[1] RMON Protocol Identifiers (Version 2) <draft-ietf-rmonmib-rmonprot-v2-03.txt>
[2] SMON MIB <draft-ietf-rmonmib-smon-04.txt>
[3] HC-RMON MIB <draft-ietf-rmonmib-hcrmon-03.txt>
(Reviews of Current I-Ds)
[4] ftp://ftp-eng.cisco.com/ftp/rmonmib/review-rmonprot-v2-03.txt
[5] ftp://ftp-eng.cisco.com/ftp/rmonmib/review-smon-04.txt
[6] ftp://ftp-eng.cisco.com/ftp/rmonmib/review-hcrmon-03.txt
Agenda:
1) RMON Protocol Identifiers (Version 2) Discussion
2) SMON MIB Discussion
3) HC-RMON MIB Discussion
4) Interoperability Test Event Planning
5) Standards Track Advancement Planning
6) Application/Service Performance Monitoring
Executive Summary:
The RMONMIB WG is currently working on three different drafts. All of these drafts
have been completed for some time, and peer reviews have recently been completed.
The meeting was used to "review the review comments", and resolve any open issues
with any of the drafts.
The WG resolved almost all known issues with these drafts. The next version of each
will be the "final draft", and will be forwarded to the IESG for RFC publication, by
November 1998.
The WG also discussed plans for an upcoming interoperability test event in January
1998, standards advancement plans for the RMON MIBs, and some ideas for a possible
future WG charter.
1) RMON PIv2 Discussion
The latest PI draft [1] and the associated review comments [4] were discussed by the WG.
1.1) PI document Maintenance
The number of protocols supported by the RMON-2 MIB is growing all the time. This
is an important issue, because RFC 2021 contains normative references to the Protocol
Identifiers document. If the PI document is changing frequently, it will be cycling at
Proposed Standard status. This will cause RFC 2021 to stay at Proposed Standard
status indefinitely.
The WG decided to split the PI document into two pieces. The beginning section,
which defines the PI macro format, will become the "Protocol Identifier Reference"
document and will stay on the standards track (cycle at Proposed). The hundreds of
PI macros will be moved to a new document called the "Protocol Identifier Repository"
document, which will be taken off the standards track and published as an Informational
RFC. Additions to the PI Repository will then be decoupled from the RMON-2 MIB itself.
1.2) PI macro language and terminology
The PI Reference document will be changed to emphasize that the use of "macro" in
the term "PI macro" is historical, since they are not really macros. The document will
also be clarified in several ways, such as: * many of the acronyms will be expanded
at first use * TBDs and editor's notes will be updated and removed * document format
and boilerplate will be updated as per RFCs 2026, 2119, and 2223
1.3) Protocol Verbs
It is possible that support for "sub-protocols" or "verbs" will be added to the PI Reference
and Repository documents in the future. These verbs would allow specific operations
of various terminal protocols to be uniquely identified, for counting and service
monitoring purposes.
1.4) Encapsulation Layer Protocols
The encapsulation layer protocols, such as IEEE 802.1Q, cause the number of
protocolDirectory entries to increase dramatically. The idea of treating such layers as
just another type of "base layer" was discussed. It was decided that although few (if
any) implementations actually model 802.1Q as a specific layer in each protocol identifier,
there is not enough interest to change the encapsulation layer identifiers at this time. It
was noted that specific "VLAN ID" and "user priority" statistics can be obtained with the
SMON MIB. The only potential impact is in the protocolDistStatsTable and the RMON-2
relative-offset filtering mechanism.
1.5) Interoperability Test Issues
Specific interoperability issues related to the PI Reference and (to a lesser degree) the
PI Repository documents were discussed. The following requirements were identified:
* Need to test agents with real traffic (e.g., traffic playback), not simulated and/or partially
constructed application traffic.
* Need to test protocols with specific protocolDirParameters BITS set and cleared (e.g.
NFS fragments, TFTP sessions).
* Need to test IP tunneling and other "multiple L3" protocol encapsulations
* Need to test with some "802.1Q tagged" traffic
1.6) Wildcard Terminal Mechanism
The protocol directory (PD) can contain many different encapsulations of the same
application. It is desirable to create a wildcard mechanism for terminal protocols, similar
to the existing L3 wildcard mechanism. This can reduce the memory used by the agent,
and the polling required by the NMS application.
A proposal for a new "base layer function" to identify wildcard terminals will be sent to
the mailing list by Russell Dietz for the WG to evaluate. The function must allow a
particular terminal PI to be identified as a "wildcard-terminal", and the L3 address type
information must be preserved (for NL and AL counting purposes).
If there are no strong objections posted to the mailing list, the wildcard terminal function
may be altered, and then added to the PI Reference document as an optional feature, (i.e.,
no MIB objects will require that wildcard-terminal encapsulations be present in the PD).
1.6) Protocol Local Index Mapping Table
A proposal for a new mapping feature was discussed, which would provide a simple
mapping from a protocolDirLocalIndex to its associated { protocolDirID,
protocolDirParameters } tuple.
This will be discussed on the mailing list and deferred to future work.
2) SMON MIB Discussion
The latest SMON MIB draft [2] and the associated review comments [5] were discussed
by the WG.
2.1) Garbage Collection Review Comments
A review issue was raised regarding the garbage collection of the smonPrioStatsTable.
These entries are not garbage-collected, but the smonVlanIdStatsTable is (LRU) garbage-
collected. The document will be updated to include the rationale for this decision. An
individual smonPrioStatsTable has a maximum of 8 rows, which is small enough to
expect an agent to account for all 8 possible minor index values, without garbage collection.
2.2) OID Assignment Conflicts
The current HC-RMON and SMON drafts use the same OID assignment in some places.
The SMON MIB will keep its current numbering and the HC-RMON MIB will be
renumbered to fix this problem.
2.3) OwnerString Re-definition Issue
There is a re-definition of the OwnerString TC, which causes popular MIB compilers to
generate error messages when compiling this MIB. The OwnerString TC in RFC 1271
(later 1757) is not exactly the same as the cloned version in the Interfaces MIB (RFC 2233),
partly due to the translation from SMIv1 to SMIv2. SMON imports ifIndex from the
Interfaces MIB, so MIB compilers complain about the "re-definition" of the OwnerString
TC. This problem is avoided in the RMON-2 MIB by importing ifIndex from RFC1213-
MIB, instead of IF-MIB. (Not a great solution either!)
This issue is not likely to be resolved by the RMONMIB WG, but it will be taken to the
mailing list, in the hope someone will propose a solution to this "dependency mess". Perhaps
when RFC 1757 is updated in SMIv2 format (see sec. 5.1) the OwnerString textual convention
can be renamed to RmonOwnerString", and all usage of "OwnerString" in RMON MIBs will
be changed to "RmonOwnerString" as each MIB is updated (e.g., from Proposed to Draft
Standard). Hopefully, a less intrusive solution will be proposed on the mailing list instead.
2.4) SMON dataSourceCapsTable Indirection Issue
The dataSourceCapsTable allows an agent to map Entity MIB physical entities (e.g.,
repeater backplanes) and entire VLANs to ifEntries with ifType "propVirtual(53)". There
is some concern regarding customer confusion and increasing the size of the ifTable.
The SMON editors will add clarifying text regarding this issue to the next SMON draft.
2.5) portCopyTable Bugs
The portCopyTable conformance statement and ASN.1 comments related to the
portCopyTable conformance are inconsistent. The SMON editors will change one of
them to fix the problem. The portCopyIndex range will also be expanded to match the
upper bound used in the InterfaceIndex textual convention.
2.6) New SMON portCopyTable Features
A proposal for adding new features (i.e. columns) to the portCopyTable was discussed by
the WG. There seem to be some common features that have been implemented in
proprietary MIBs, which would be useful in a standard MIB.
New features proposals include:
* portCopyDirection: SYNTAX INTEGER { rx(1), tx(2), both(3) } A parameter to select
traffic by direction.
* portCopyVlanID: SYNTAX Integer32 (0..???) allow for copy of a single configured
VLAN from a ingle dataSource (presumed to carry traffic from multiple VLANs).
* portCopyVlanIdMask: SYNTAX BITS allow for copy of multiple configured VLANs
from a single dataSource (presumed to carry traffic from multiple VLANs).
* Copy only traffic that matches a certain MAC address (SA or DA).
* Control table switch to configure the copying of errored frames.
There seemed to be WG interest for some of the proposals, but not necessarily in the first
version of the SMON MIB. The portCopyDirection object had received the most discussion.
The WG held the following "vote" to gauge consensus:
1) Don't want to do any of this in the SMON MIB
2) Move the portCopyTable forward as-is, with no new features at this time.
3) Add the portCopyDirection object now, and postpone consideration for all other new
features to a future release.
Results:
1) 0
2) 3
3) 8
The WG Chair has posted a proposal for this object to the mailing list. Unless there are
any objections within the next two weeks, the SMON editors will add it to the next
SMON draft (directly to the portCopyTable).
2.7) smonVlanIdStatsId Range
The smonVlanIdStatsId object has a range of 0..4095. Apparently, the new Bridge MIB
has a TC to define a special VLAN index value, such that values for non-802.1Q VLANs
(above 4095) can be supported. A clause in the conformance section would be needed for
this MIB object, so it is clear that only index values 0..4095 are mandatory for MIB
conformance.
The "working proposal" is that the upper bound of this MIB object be increased to match
the Bridge MIB TC. The DESCRIPTION clause will explain the "non-dot1Q" semantics
of VLAN indexes above 4095. Unless there are any objections within the next two weeks,
the SMON editors will make this change to the smonVlanIdStatsId object.
2.8) Interoperability Test Issues
Specific interoperability issues related to the SMON MIB were discussed. The following
requirements were identified:
* Need to use "tagged" test traffic for multiple, specific 802.1Q VLAN IDs.
* Need to use test traffic tagged with multiple, specific 802.1p user priority values.
* Need to test dataSourceCapsTable against real and reported capabilities
* Need to test usage the new SmonDataSource TC options, smonVlanDataSource.<V>
and entPhysicalIndex.<N>.
* Need to test portCopyTable operation and capabilities, compared to those reported in
the dataSourceCapsTable.
3) HC-RMON MIB Discussion
The latest High Capacity RMON draft [3] and the associated review comments [6] were
discussed by the WG.
3.1) Rationale for ZeroBased counters
The ZeroBasedCounter32 and ZeroBasedCounter64 textual conventions do not contain
any rationale for the usage of the TC. The HC-RMON MIB editor will add some clarifying
text as to the expected TC usage, explaining that these counters are found in data tables that
get created by management action. The starting value of zero represents an implied poll,
taken at the moment the table is instantiated.
3.2) mediaIndependentTable Conformance
The mediaIndependentTable is a "stand-alone" feature, yet it is part of the conformance
statement for the RMON-2 HC extensions. The HC-RMON editor will move this table
to its own conformance macro.
3.3) mediaIndependantTable Duplex Changes
The mediaIndepenentTable is defined such that the "out" counters are only instantiated
if the port is operating in full-duplex mode. This causes a problem for NMS applications
if the duplex mode of the port changes while the mediaIndependentEntry is active. There
are no discontinuity indicators for either the "in" or "out" counters in this table, such as
"last-activated-time" or "last-duplex-mode-change-time" Timestamp objects. There is
no explicit indication of the duplex mode, which would be useful for configuring RMON
alarms on duplex-mode changes.
The WG will discuss this issue on the mailing list. There seemed to be WG consensus
that the table is broken as-is, but it is worth fixing, and the solution should not be that difficult.
Three different approaches seem to be popular on this issue:
1) the "minor tweak" solution:
Change the text that says the "out" counters go away to state instead that the "out"
counters never go away, but simply stop incrementing in half-duplex mode.
2) the "80/20 solution":
Make the change in (1), but also add one new read-only MIB object to explicitly
identify the duplex mode * mediaIndependentDuplexMode - enum { half(1), full(2) }
3) the "complete solution":
Make the changes in (1) and (2), but also add some new read-only MIB objects to help
detect duplex mode changes:
* mediaIndependentDuplexChanges - Counter32
* mediaIndependentLastDuplexChangeTime - TimeStamp
The WG will discuss this issue on the mailing list over the next two weeks, and
hopefully a consensus will be reached in that time. The HC-RMON MIB cannot
advance until this issue is resolved, so hopefully the WG will discuss and resolve this
issue quickly.
3.4) ZeroBasedCounter64 TC
This TC uses SYNTAX Counter64, which is not an entirely legal modification to the
Counter64 semantics. The issue is that a counter has special semantics related to its
monotonically increasing behavior. A "snapshot" of a counter does not monotonically
increase, so it should be a gauge instead.
The RMONMIB WG has been waiting for the SNMP WG to add Integer64, Gauge64,
and/or UInteger64 to the SMIv2, but the SNMP WG finally decided not to add any
new 64-bit types to the SMI in the near future.
The RMONMIB WG therefore decided to leave the ZeroBasedCounter64 TC as-is.
There is some field experience already that the Counter64 "wire-encoding" does not
cause interoperability problems between HC-RMON agents and applications.
4) Interoperability Test Event Planning
The WG discussed the possibility of another interoperability test event, to test RMON-2
and the new MIBs.
4.1) Testing Scope and Logistics
The following documents would be tested:
* RMON-2 MIB [RFC 2021]
* RMON-2 PIv2 update to [1]
* SMON MIB update to [2]
* HC-RMON MIB update to [3]
The timeframe for the test event will be mid or late January 1999.
The test event will be hosted by InterWorking Labs, and will be held in (or close to)
San Jose, CA.
The testing requirements mentioned in sections 1.5 and 2.8 will be addressed at the test,
as well as general interoperability of the RMON-2 and HC-RMON MIBs. Test networks
consisting of 10/100 ethernet and gigabit ethernet segments will be used (assuming
vendors will loan equipment and engineers for the test). Further announcements
regarding this test event will be made on the WG mailing list later this year.
5) Standards Track Advancement Planning
The existing RMON MIBs need to progress along the standards track. Each MIB was
discussed by the WG, and The following actions will be taken for each MIB:
5.1) RFC 1513 - Token Ring RMON and RFC 1757 - RMON-1 MIB
The WG Chair will issue a call for interoperability reports on the mailing list.
Implementors will be asked to fill out a survey and email it back to the WG Chair, who
will publish the results.
These MIBs will also be converted to SMIv2 format as they are progressed on the
standards track. The Token Ring RMON MIB is due to move from Proposed Standard
to Draft Standard, and the RMON-1 MIB is due to move from Draft Standard to Full
Standard. The WG Editor will produce converted drafts of these MIBs and the WG
will discuss the conformance sections (and any other details) on the mailing list. No
timeframe has been set for this task, but it is hoped that the reports and drafts will be
ready be the next IETF in December 1998.
5.2) RFC 2021 - RMON-2 MIB
The RMON-2 MIB will not be advanced at this time. The associated Protocol Identifiers
document will cycle at Proposed Standard, and these documents will be advanced
together at a later time.
5.3) RFC 2074 - RMON Protocol Identifiers
This document will be obsoleted by the final, published version of the PIv2 draft [1]. The
document will be split into two RFCs, as described in section 1.1. The standards track
"PI Reference" document will cycle at Proposed Standard. The more dynamic "PI
Repository" document will become an informational RFC, and will be decoupled from
RFC 2021 and the PI Reference.
6) Application/Service Performance Monitoring
The WG discussed some ideas for future work. Ideas for a charter proposal for
Application or Service Level Monitoring were discussed briefly, and will be discussed
further on the mailing list.
The WG Chair and the Area Director want to make sure any proposed work items be
measurable, verifiable and interoperable. The proposed charter should perhaps be
based on metrics defined by the IPPM WG.
There are differing opinions on all the features needed to do Application and/or Service
Level Monitoring, as there is disagreement to what these terms even mean. The proposed
charter should consider precise goals and not be limited in scope to passive protocol
response timing.
The WG also discussed a couple other features that may be considered in the new charter:
* a "username-to-L3-address" mapping function
* distribution counters for DIFFSERV codepoint usage; Augmentation to some RMON-
2 tables (e.g., protocolDistStatsTable and alHostTable)
Ideas and comments on the proposed charter should be sent to the WG mailing list. A
final version is expected to be forwarded to the Area Director before the next IETF in
December 1998.
None received.