Minutes - IETF #40 Washington, D.C.
------------------------------------
WG: RMONMIB
Area: OPS
Meeting: 08dec97 1930-2200
WG Chair: Andy Bierman
Minutes: 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
------
- Agenda Bashing
- Working Group Status
- RMON Interoperability Discussion
- 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 3 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
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:
* 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).
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.