Minutes of the Remote LAN Monitoring Working Group (RMONMIB)
RMONMIB held an interim meeting in Santa Clara, CA on 21-22 November
1994. The meeting was sponsored by Bay Networks, Inc.
Meeting Materials
o summary.grp -- Latest feature wish list (posted November 20)
o summary.lng -- Latest collection of related e-mail on each feature
listed in summary.grp (posted in 2 parts November 20)
o rmon-mail-agenda -- Meeting agenda (posted November 9)
o robin.txt -- Long list of comments from Robin Iddon on RMON2
features and the AXON ECAM MIB (posted November 15)
o ecammib.my -- AXON ECAM MIB (posted November 15)
o hpaxon.mib -- RMON Probe Configuration MIB (`Aspen MIB') (posted
November 15)
Executive Summary
All potential additions, deletions, and modifications to RMON (made
available to the working group) were discussed. An effort was made to
understand the purpose, merits, and ramifications of each feature.
The three highest priority features were (not in any order):
o Network layer host/matrix tables
o Per-segment protocol distribution
o Packet filtering enhancements
Framework highlights:
o No changes will be made to the RMON MIBs (RFC 1271 and RFC 1513)
that would break existing NMS applications.
o New tables will be added to new groups, not to existing groups in
RFC 1271. (Possibly create new MIB-MODULE?)
o The capture and filter tables may be deprecated as a result of new
work on the filters.
o New objects may be added to existing tables as enhancements
o The rules defining the acceptable use of the dataSource object will
be changed to allow other OIDs than `ifIndex.N'
o EntryStatus will be kept for all existing tables. New tables will
use the RowStatus textual convention.
o The deadline for new problem or feature proposals is January 1,
1995
The agenda posted to the mailing list was observed, with the following
exception: instead of making three passes through the work-item list, a
single pass was made in which discussion on each feature was unlimited.
The interest level described for each feature reflects the opinions of
the meeting attendees and the perceived interest seen on the mailing
list, but it shall be considered the working consensus of the group
unless otherwise altered by consensus gathered via e-mail or at the San
Jose meetings.
Detailed Summary
The following areas were covered:
A) New Monitoring Features
B) Packet Filtering
C) Enhancements
D) Bug Fixes
E) SNMPv2 Alignment
F) Probe Configuration
G) Hardware Considerations
A) New Monitoring Features
A1) Statistical analysis (sampled packet capture w/hardware counters)
[ Sonia Panchen/Hewlett-Packard (presentation/no MIB) ]
Summary:
Sample stream of stats via a post filter (Hewlett-Packard EASE)
Controlled
Sample Rate. Count based sample--not time-based.
Interest:
Strong consensus to add this feature--it was observed that this
addition could be useful for hardware considerations (item G1).
Probable Implementation:
The dataSource objects in existing control tables could be
`pointed to' an ``statControlEntry'' that would indicate the
ifIndex to monitor and the packet skip count.
An additional mode could be provided via filter enhancements
to allow channels to capture sampled packets (see ruled-based
filters). This would allow NMS-based applications to utilize
the raw sampled packet slices.
A2) Duplicate address detection
[ no work done ]
Summary:
Detection of duplicate network layer addresses for the same MAC
address. It was noted that `false' duplicates would exist
under some normal network conditions. If this was added,
it would be limited to a `best effort' by the probe.
Interest:
Moderate consensus to support this. It is hoped that a table
which provided MAC-NET address bindings would be enough to allow
an NMS app to derive this feature.
Probable Implementation:
A table that contained MAC-NET bindings (per interface)
A3) Address change detection
[ MAC changes provided in Repeater MIB, so is this any net addr
or IP only -- no work done ]
Summary:
Detection of MAC-NET address changes. It was determined that
this feature is really part of item (A2).
Interest:
Moderate consensus to support this. This was seen as part of
feature A2.
Probable Implementation:
A table that contained MAC-IP bindings (per interface)
A4) Network layer HostTable
[ Venkat Rangan/Hewlett-Packard (presentation, MIB provided) ]
[ AXON ECAM MIB ]
Summary:
This is viewed as a very key feature of RMON-2. The feature
is assumed to include a matrix table as well. A balance must
be found between hard-wired protocol tables and generic tables.
Implementation proposals from Hewlett-Packard, AXON, TU Delft, and
Tech. Elite were discussed.
The challenge is to provide enough extensibility and flexibility
to support most protocols (layer 3 and above)--without future
MIB changes--and still maintain high inter-operability and
low complexity.
Interest:
Strong consensus to add.
Probable Implementation:
The group seemed to favor a model that used protocol-specific soft
counters (e.g. ECAM MIB). A universal directory of protocol
IDs would be needed, as well as a table of protocol IDs
supported by the probe.
No consensus was reached on the best way to define the soft
counters for a given protocol, or the protocols to be
supported. (This will be a major topic at the San Jose meeting)
A5) Protocol-type distribution through all 7 layers of the ISO model
[ In/Out/Errors or more? Per Host? Per Conversation?
no MIB ]
Summary:
Provide protocol distribution statistics (octets, pkts, errors?)
for the protocols seen on a given interface.
Interest:
Strong consensus to add. No consensus to provide per-host or
per-conversation protocol distribution because of the possible
data table explosion that could occur at this level of
granularity.
Probable Implementation:
No consensus on an implementation
A6) Consider how RMON could benefit network security for example:
Using the RMON History to provide an accountability and audit
trail through the Transport Layer.
[ presentation on auditing was done in Toronto -- no MIB ]
Summary:
Monitor Connections in the Network. Open and Close of connections.
Add a table to just provide the stats.
Connections to/from a resource on the network.
Interest:
Consensus to delete -- feature dropped. Seen to be to expensive to
implement on an RMON probe. Hopefully, data from item A4 can
be used to help in this area.
Probable Implementation:
N/A
A7) More performance metrics in RMON to meet the needs of the
client-server environment.
[ no examples, no MIB ]
Summary:
Monitor transaction response times
Interest:
Consensus to delete -- feature dropped. Seen to be to expensive to
implement on an RMON probe.
Probable Implementation:
N/A
A8) Proposal for host and matrix protocol distribution
[ Richard Kooijman (examples, MIB) ]
[ AXON ECAM MIB ]
Summary:
Per host and per-conversation protocol distribution
Related to the tables in items A4 and A5
Interest:
Consensus to delete -- feature dropped. Seen to be to expensive to
implement on an RMON probe. Concern over data explosion.
Probable Implementation:
N/A
A9) Packet generation
[ Karl Auerbach/Timon Sloane, others (examples, MIBs) ]
[ - range of ideas: ping MIB...send raw MAC frame including CRC ]
Summary:
Allow a mgmt app to specify a raw packet for transmission
by the probe on a specified interface. An alternative would be
to allow the NMS app to specify portions of the packet, or to
retransmit packets from a capture buffer.
Interest:
No consensus to add--group very divided on this issue. Proponents
want the ability to support any protocol, or any protocol
without impact on the probe. Opponents are concerned about
possible misconfiguration, intentional misuse, and security
implications. If the real intent of this feature is to
initiate transactions, then there would be a mechanism needed
to capture, recognize, and report the results.
The group has decided to drop this feature but will allow further
discussion at the San Jose IETF to possibly reverse this decision.
Probable Implementation:
N/A (Timon Sloane's packet generation MIB if revived)
A10) Connectivity Tests
Summary:
Generate `ping' tests to determine addresses and capture the results
Such `Ping MIBs' have already been posted on different occasions.
(Steve will provide a EchoTest MIB example to the working group.)
Packet generation would be controlled by the probe. A mechanism
to trigger generation with events is desired.
Interest:
Strong consensus to add, but some concern that this really
does not belong in RMON, but it is unlikely to be present in any
other standard MIB.
Probable Implementation:
TBD -- want to consider fielded implementations before
writing a new ping MIB.
A11) User-defined history collection
[ Robin Iddon, no MIB ]
[ combine historyControlTable and alarmTable functionality
use historyControlTable plus bucketControlTable?
variable-length buckets or fixed number of objects?
want to fix alarmValue encoding problems and sample
discontinuity problems? ]
Summary:
allow an NMS app to specify objects to be collected in
history buckets.
Interest:
Strong consensus to add
Probable Implementation:
Combination of historyControlTable and alarmControlTable
into a new control table, and a single data table.
A12) Capacity Planning--long term monitoring
[ no consensus, no MIB ]
Summary
probe would provide long-term (i.e., weeks, months) polling
of specified variables such as net utilization.
Interest:
Strong consensus to drop -- feature could be provided by a user
history table (A11) -- feature dropped
Probable implementation:
N/A
B) Packet Filtering
The question was posed if packet filter was really `broken' and the
consensus was that it is sufficient for MAC layer monitoring, but
is difficult (or impossible) to configure higher-layer filters.
The current filter/channel mechanism is not considered
`hardware-friendly,' requiring a software implementation.
B1) Filtering beyond variable-length fields in the packet
[ Karl Auerbach/Timon Sloane -- filter stack
(MIB proposal from Richard Kooijman, filter spec from Karl) ]
Summary:
Rule-based filter mechanism would allow the filters to
be more sophisticated, which should result in less filters needed
to capture a given packet, and allow filters to be
`protocol-aware.'
Make MIB structure flexible to keep performance in check.
Interest:
Strong consensus to add some form of non-proprietary rule-based
filtering.
Probable Implementation:
Consensus to investigate possible use of the Berkeley
packet filter engine.
B2) Change filter mechanism to allow for efficient hardware implementation
[ no examples, no MIB ]
Summary
The current filter/channel mechanism is very difficult
to implement on high speed networks (100 MBit+). Some sort
of `stream-lined' filter should be defined to make
make implementation more likely.
Interest:
Strong interest in supporting high-speed networks
but no consensus on what can be done. Some interest
in allowing filters to be shared more easily.
Probable Implementation:
An `extended-error' eventType with standardized log entries in
the logTable (see item C2).
No consensus on any mechanism to indicate the limits of
`hardware-able' filters with MIB objects.
B3) Pattern matching on sub-string anywhere in pkt (pkt-grep)
[ no MIB ]
Summary
Provide a mechanism to recognize a pattern anywhere in
a packet.
Interest:
Strong interest to drop this feature because it is
too expensive to implement--even on 10 MBit networks
--feature dropped
Probable Implementation:
N/A
B4) New table allowing filters to be shared by different channels
[ Richard Kooijman (examples, MIB) ]
Summary:
Agent implementations can be more efficient if filters
could be shared by different channels.
Need to include all operators (AND/OR) and filter exit.
Problem of sharing ControlTable Entries.
Could register access to ControlTable with renewal from client.
Interest:
Low consensus to fix this in the MIB, but the issue is not
closed if new ideas emerge. There was some desire to create
a `glue-table' that would control the `many-to-many'
filter/channel logic needed to share filters with MIB
objects.
Probable Implementation:
None proposed
B5) Intermediate data table for Karl's filter-stack
[ Karl Auerbach, alternate MIB by Richard Kooijman (MIB) ]
Summary:
Mechanism to make `intermediate-data' gathered while decoding
packets available to management applications. This includes
`interesting' offsets, checksums, etc. within the various
headers in the packet.
Interest:
Strong consensus to delete because it would be too difficult
to define the data semantics and not of enough use to
management applications--feature dropped
Probable Implementation:
N/A
B6) Operator-Based Filtering
[ Richard Kooijman (examples, MIB) ]
Summary:
Channel logic is limited to the implied OR-ing
of all filters associated with the channel. A
mechanism to allow other logical operators
(AND, XOR?) to combine filter results could
be provided.
Interest:
Low interest in implementing this feature with parse-able
text strings. It is hoped that new filtering
changes will be flexible enough to handle this
level of filter logic, without implementing it
in the channel logic--feature dropped
Probable Implementation:
N/A
B7) Filter Enhancements for WAN monitoring
[ Jonathan White (example, MIB) ]
Summary:
(This item should really be in section C.)
Add new status bits to the filterStatus object
to indicate the direction of the packet on a
WAN interface. Also desired general purpose
(non-media specific) error bit definitions.
Interest:
Strong consensus to add a bit for WAN-packet
direction. NMS applications need to check
the monitored interface type (with ifType)
to determine if this bit is relevant.
There was some interest in defining some
general error condition bits.
Probable Implementation:
Add a `WAN packet direction' bit to the
filterStatus object semantics.
C) Enhancements
C1) Packet distribution in the history data tables
[ from charter, no MIB]
[ assumed proposal: add etherHistoryXXtoXXPkts to
etherHistoryTable ]
Summary:
There is no packet-size distribution in the
etherHistoryTable, but there is in the token
ring history tables.
Interest:
Moderate to strong interest in adding this feature.
Probable Implementation:
Add the etherStatXXtoXXPkts objects to the etherHistoryTable
C2) Standardize log table entries
[ trap MIB had trap decode format specified ]
Summary:
The standard event trap types (risingEvent, fallingEvent)
have no standard log entry definition.
Interest:
Strong interest in providing a standard encoding for the
risingEvent and fallingEvent trap types that includes
an ASCII version of the trap.
There was little interest in reviving the packetMatch
trap for this use.
Probable Implementation:
Compressed format of trap-encoding formats as specified
in trap log MIBs previously posted to the mailing list.
C3) Resolution of captureBufferPacketTime timestamp (mSec)
[ scaling factor to get microSec resolution? ]
Summary:
The timestamp resolution of the captureBufferPacketTime
object is in milli-seconds, which inhibits inter-packet
timing information. 10 or 100 micro-second resolution
would be more useful.
Interest:
Moderate interest to consider finer granularity in
this object. There was some concern over the semantics
of this object--whether it was time-stamped as soon as
possible after reception (by hardware?) or when the packet
was added to the capture buffer (consensus was ASAP
after reception).
No consensus to change the semantics of this object
because the added utility was not worth the risk
of breaking applications currently using this
object. No consensus to add a new object
--feature dropped
Probable Implementation:
N/A
C4) Timestamp in MatrixControlTable of last status change
[ some examples, no MIB ]
Summary:
An NMS application has no reliable way of knowing
when data collection was started in certain RMON tables,
A timestamp would make the following situations less
of a problem:
* multi-manager access to a single control table
* interface change in agent causing data to be flushed
Interest:
Moderate consensus to support in the host and matrix groups.
No interest in providing a time-of-day ASCII string.
Probable Implementation:
Add a sysUpTime-based timestamp object to the host and matrix
control tables, indicating the time that data collection
was started (or restarted).
C5) Client/Server Trend Analysis
[ Nevil Brownlee accounting MIB (presentation, no MIB) ]
Summary:
Implement the Accounting `Meter MIB'
(draft-brownlee-acct-meter-mib-01.txt) within RMON.
Interest:
Some interest in the MIB, but not as a part of RMON.
Consensus to follow activity of the Accounting group and
leave this alone for the time--feature dropped
Probable Implementation:
N/A
C6) Host to Physical Port Mapping
[ Dan Romascanu/Lannet, Shay Naeh/ARMON (presentation, MIB)
Summary:
Addition to the hostTable to provide the physical port
from which a packet was received. This feature is very
specific to repeaters and bridges, but can provide
some required data for topology discovery (PHYS-MAC
bindings).
There was considerable discussion on this issue. Some address
tracking is provided in the Repeater MIB (RFC 1516), but
the proposed mechanism provides the last port ID for each SA,
instead of the last SA seen on each port. There was some
concern that a different MIB should address topology discovery
issues instead of using bits and pieces from various sources
(current practice).
(From discussion on RMON for switched VLANs:
Switches - consider a 32 port switch. Need to look at a
single view of all these 32 Collision Domains. How should RMON
look at this implementation. If there is a single backplane which
all the 32 ports move traffic onto, we must be able to view
this information and provide monitoring data.
Could use an `entity MIB' to identify placeholder objects
such as real or virtual backplanes, then point dataSource at
this OID--or the dataSource for this could come from the
connection MIB (if ever completed) to link RMON control tables.)
Interest:
Moderate consensus to add. No consensus on a key implementation
issue: number of identifier components for the physical port.
(proposed # is 2, some want up to 4)
Probable Implementation:
Will be based on the proposed MIB fragment from Lannet and ARMON
C7) EtherStats modifications for traffic characteristics
including NetUtilization added to EtherStats
[ Richard Kooijman (MIB) ]
Summary:
proposed MIB included timing characteristics added to the
ethernet statistics group, and a network utilization object.
A static netUtilization object would allow thresholds
to be based on bandwidth utilization.
Interest:
Low interest in the timing aspect, but strong consensus to add
2 or 3 netUtilization objects to the etherStatsTable.
Need consensus on the intervals: 1 sec, 5 sec, 1 min, 5 min
Probable Implementation:
Objects added to the etherStatsTable with similar semantics
as the etherHistoryNetUtilization object--except the
interval is specified.
C8) Acceptable DataSource values
[ Richard Kooijman (Beholder2) ]
Summary:
The dataSource OID pointer is currently restricted to
a value of `ifIndex.N', where N represents a physical
interface (ethernet or token ring). Proposal to
allow other entities to be used as data sources, such as:
* repeater ports (rptrPortGroupIndex.GROUP.PORT)
The repeater instance is determined by checking
the dataSource
* channel ID (channelIndex.INDEX)
Interest:
Strong interest to expand the dataSource capabilities and
to identify the rules for expansion in order to maintain
inter-operability.
There was strong consensus that SNMPv1 did not provide
enough error codes to help an NMS `debug' resource-related
problems.
Open Issues:
* How does NMS know the configuration capability of the device?
* How does NMS know the resource impact of a specific
configuration?
Probable Implementation:
for table redirection:
* channelIndex.INDEX will be allowed, others are TBD
for resource management issues:
* new MIB objects: 2 gauges indicating percentage of current
memory and CPU usage
* Use the Event/Log mechanism for detailed errors on RMON agent
genError and badValue.
D) Bug Fixes
D1) Align EtherStatsJabbers with IEEE/Repeater MIB definition
Summary:
The RMON definition of a jabber condition is incorrect.
IEEE Jabber is any frame greater than 20ms - 115ms.
RMON Jabber is frame longer than 1518 with bad FCS.
To fix this, etherStatsJabbers could be left alone
or deprecated, and an additional object would provide
a jabber condition counter consistent with the Repeater
MIB definition (rptrMonitorPortVeryLongEvents)
Interest:
No interest in changing because the gain would not be
worth the effort. NMS applications should use the
repeater MIB jabber counter for accuracy--feature dropped
Probable Implementation:
N/A
D2) Separate ethernet-specific tables from `generic-RMON'
Summary:
RFC 1271 contains media-specific (etherStats, etherHistory)
features among the mostly generic control tables. (filterPktStatus
excluded). Proposal to split the ethernet-specific portions
into a different document.
Interest:
No consensus that this is even a bug, bug strong consensus
that it is not worth fixing in any case--feature dropped.
Probable Implementation:
N/A
D3) EtherStatsCollisions inaccurate -- cannot be counted properly with
hardware.
Summary:
Collision counter definition not really an accurate account
of the collisions on a backplane.
Interest:
Moderate consensus that this is a problem.
Strong consensus that it is not worth fixing--feature dropped.
Probable Implementation:
N/A
E) SNMPv2 Alignment
E1) RowStatus versus EntryStatus
[ from charter, consensus to add ]
Summary:
The RowStatus textual convention for managing conceptual
row creation, modification, and deletion is preferred
over the RMON-specific EntryStatus. Proposal is to
use RowStatus instead.
Interest:
Strong interest in using RowStatus for new tables.
Probable Implementation:
The RowStatus TC will be used for new tables.
The objects already defined with the EntryStatus TC
will be unchanged.
E2) Support for SNMPv2 macros
[ which ones? -- is this the same as E4 ]
Summary:
The RMON MIB uses the `old' SMI macros. Proposal to
update the MIB with the appropriate macros from the
SNMPv2 SMI.
Interest:
Mandatory for new MIB objects, but moderate consensus not
to update RFC 1271 and RFC 1513.
Probable Implementation:
New MIB modules (not part of 1271 or 1513) will be
defined with the SNMPv2 SMI macros.
E3) Alarms/Events from M2M MIB
[ from charter, consensus to add ]
Summary:
The Manager To Manager MIB (RFC 1451) provides a more robust
implementation of alarms and events (but no logging) as
defined in the RMON MIB. Proposal to deprecate the existing
alarms and events groups and use the M2M MIB instead.
Interest:
Since the M2M MIB relies on SNMPv2, it cannot replace
alarms and events in existing applications. Strong
consensus not to deprecate the current solution.
Some consensus to add text advising the use of the M2M MIB
in SNMPv2 environments--feature dropped
Probable Implementation:
N/A
E4) Align with SNMPv2 SMI
[ from charter, consensus to add ]
[ DUPLICATE OF E2 -- REMOVED ]
F) Probe Configuration
F1) RMON Probe Configuration including modem configuration
[ AXON/Hewlett-Packard (MIB) -- for consideration as a
separate document from the RMON-2 spec ]
Summary:
Many RMON probes have proprietary configuration MIBs
to configure agent behavior. Proposal to create
separate document or group within RMON MIB to
help standardize agent configuration.
Interest:
* Strong interest in adding a trap destination table to RMON
* No consensus to provide acknowledged traps or modem configuration.
* Consensus not to overlap existing functionality in other
standard MIBs.
Probable Implementation:
Determine interest from the NM area AD in:
* creating a new working group to handle agent configuration,
including out-of-band configuration
* modifying the RS-232 MIB (RFC 1317), MIB-II (RFC 1213),
and the Modem MIB (RFC # ??) to support agent configuration
As a last resort, some probe configuration features will
be developed by the RMONMIB Working Group, derived from the
Hewlett-Packard/AXON MIB.
F2) Probe Resource Capacity Table
Summary:
Many probes can be user-configured to allocate memory resources
to specific tables. A table indicating the ``memory ration''
for each table (specified in KBytes or number of entries)
and memory usage could help NMS apps better utilize RMON
probe resources. Only the probe may create or delete entries
and write access to the ration amount is optional. An additional
gauge indicating total remaining RMON resources may also be useful.
(Also CPU Usage gauge).
Interest:
No consensus that this could be effectively implemented--even
as a read-only table--because of the different ways that
RMON resources are managed in various applications
--feature dropped
Probable Implementation:
N/A
F3) Probe Reset Issues
Summary:
After a probe resets, all the NMS-configured control
entries disappear, and must be re-configured by the NMS.
There is no standard way to configure non-volatile
storage usage of these tables.
Interest:
* Concern over limited NV-storage on a probe--
probe would have to prioritize which control entries
to save or limit control entries to what could fit
in NV-storage.
* NMS may not want all entries restored after a reset.
Moderate interest in adding a storage status object
to each control row, (e.g. xxObject from the Party MIB?)
There was concern over stale entries in the tables,
left behind by sloppy or crashed NMS apps.
Probable Implementation:
* storage status object added to each control row:
- other(1)
- volatile(2) -- RAM
- non-volatile(3) -- NVRAM
- permanent(4) -- ROM
* DEFVAL would be volatile(2).
* Deleting a row via the Entry/Row-Status object deletes
from all storage areas.
G) Hardware Considerations
G1) A concern on the extrapolation of dropped events as the speed of
networks increase, i.e., 100BaseT
[ what can the working group do about this? ]
Summary:
The RMON MIB is difficult to implement on high-speed networks.
The working group needs to explore ways to make high-speed RMON
implementation more cost-effective.
There was concern whether RMON should try to provide
logic-analyzer quality exception handling on high-speed
networks (zero or few droppedEvents).
Some items that may help:
1) statistical sampling to pre-filter data (this is not
useful for exception handling)
2) stream-line packet filter specifications (see item B2)
3) remove packet size distribution counters from the
etherStats group (i.e., keep the counter set limited
to what common hardware can count)
Interest:
Moderate consensus that this is really a problem--line-speed
monitoring (e.g. LA-quality) is not mandatory because networks
rarely run at full utilization. New probe technology will keep up
with increasing line-speeds (specifically 100 MB)
Moderate Interest in suggestions 1 and 2 above.
Strong consensus that high-speed and switched environments
have to be supported.
G2) Concern for distributed RMON
Summary:
RMON is difficult to implement in some `non-standard'
environments, such as:
* multiple sub-agents
* multiple processors
The RMON resources are usually interface-related,
determined by the dataSource object--need to know
the dataSource to pick correct sub-agent.
Some suggestions to help solve this problem:
* possibly add text to enforce dataSource to be set ASAP
* possible DEFVAL for dataSource of ifIndex.1
* RowStatus==createAndGo, dataSource in first PDU ]
Interest:
There was no consensus that this was really a problem.
There was no interest in changing any row creation semantics.
--feature dropped
Probable Implementation:
N/A
Summary of Proposed Changes/Additions to Existing Tables
o Statistics: add network utilization objects to etherStatsTable (C7)
o History: add packet-size distribution counters to
etherHistoryTable (C1)
o Host: add physical-port indication to hostTable (C6) add
data-collection timestamp to hostControlTable (C4)
o Matrix: add data-collection timestamp to matrixControlTable (C4)
o Filter/capture: possibly add channelDescription object to hold
NMS-supplied text string -- the filter group may be deprecated as a
result of new work.
Add a bit to the filterPktStatus to indicate WAN packet direction. (B7)
o Event: define standard logEntry formats for risingEvent and
fallingEvent trap-types. (C2)
