until index N is assigned to the entry with the
lowest value of rptrTopNPortRate or there are no
more rptrTopNPortEntries.
No ports are included in a report where their
value of rptrTopNPortRate would be zero."
::= { rptrTopNPortEntry 1 }
rptrTopNPortGroupIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object identifes the group containing
the port for this entry. (See also object
type rptrGroupIndex.)"
::= { rptrTopNPortEntry 2 }
rptrTopNPortPortIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The index of the repeater port.
(See object type rptrPortIndex.)"
::= { rptrTopNPortEntry 3 }
rptrTopNPortRate OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The amount of change in the selected variable
during this sampling interval for the identified
port. The selected variable is that port's
instance of the object selected by
rptrTopNPortRateBase."
::= { rptrTopNPortEntry 4 }
-- Notifications for use by Repeaters
rptrHealth NOTIFICATION-TYPE
OBJECTS { rptrOperStatus }
STATUS deprecated
DESCRIPTION
"********* THIS OBJECT IS DEPRECATED **********
In a system containing a single managed repeater,
the rptrHealth notification conveys information
related to the operational status of the repeater.
It is sent either when the value of
rptrOperStatus changes, or upon completion of a
non-disruptive test.
The rptrHealth notification must contain the
rptrOperStatus object. The agent may optionally
include the rptrHealthText object in the varBind
list. See the rptrOperStatus and rptrHealthText
objects for descriptions of the information that
is sent.
The agent must throttle the generation of
consecutive rptrHealth traps so that there is at
least a five-second gap between traps of this
type. When traps are throttled, they are dropped,
not queued for sending at a future time. (Note
that 'generating' a trap means sending to all
configured recipients.)"
REFERENCE
"[IEEE 802.3 Mgt], 30.4.1.3.1, nRepeaterHealth
notification."
::= { snmpDot3RptrMgt 0 1 }
rptrGroupChange NOTIFICATION-TYPE
OBJECTS { rptrGroupIndex }
STATUS deprecated
DESCRIPTION
"********* THIS OBJECT IS DEPRECATED **********
In a system containing a single managed repeater,
this notification is sent when a change occurs in the
group structure of the repeater. This occurs only
when a group is logically or physically removed
from or added to a repeater. The varBind list
contains the identifier of the group that was
removed or added.
The agent must throttle the generation of
consecutive rptrGroupChange traps for the same
group so that there is at least a five-second gap
between traps of this type. When traps are
throttled, they are dropped, not queued for
sending at a future time. (Note that 'generating'
a trap means sending to all configured
recipients.)"
REFERENCE
"[IEEE 802.3 Mgt], 30.4.1.3.3, nGroupMapChange
notification."
::= { snmpDot3RptrMgt 0 2 }
rptrResetEvent NOTIFICATION-TYPE
OBJECTS { rptrOperStatus }
STATUS deprecated
DESCRIPTION
"********* THIS OBJECT IS DEPRECATED **********
In a system containing a single managed repeater-unit,
the rptrResetEvent notification conveys information
related to the operational status of the repeater.
This trap is sent on completion of a repeater
reset action. A repeater reset action is defined
as an a transition to the START state of Fig 9-2
in section 9 [IEEE 802.3 Std], when triggered by a
management command (e.g., an SNMP Set on the
rptrReset object).
The agent must throttle the generation of
consecutive rptrResetEvent traps so that there is
at least a five-second gap between traps of this
type. When traps are throttled, they are dropped,
not queued for sending at a future time. (Note
that 'generating' a trap means sending to all
configured recipients.)
The rptrResetEvent trap is not sent when the agent
restarts and sends an SNMP coldStart or warmStart
trap. However, it is recommended that a repeater
agent send the rptrOperStatus object as an
optional object with its coldStart and warmStart
trap PDUs.
The rptrOperStatus object must be included in the
varbind list sent with this trap. The agent may
optionally include the rptrHealthText object as
well."
REFERENCE
"[IEEE 802.3 Mgt], 30.4.1.3.2, nRepeaterReset
notification."
::= { snmpDot3RptrMgt 0 3 }
-- Notifications for repeaters in a multiple-repeater implementation.
-- An implementation may send either the single-repeater OR
-- multiple-repeater version of these notifications (1 or 4; 2 or 5)
-- but not both.
rptrInfoHealth NOTIFICATION-TYPE
OBJECTS { rptrInfoOperStatus }
STATUS current
DESCRIPTION
"In a system containing multiple managed repeaters,
the rptrInfoHealth notification conveys information
related to the operational status of a repeater.
It is sent either when the value of rptrInfoOperStatus
changes, or upon completion of a non-disruptive test.
The agent must throttle the generation of
consecutive rptrInfoHealth notifications for
the same repeater so that there is at least
a five-second gap between notifications of this type.
When notifications are throttled, they are dropped,
not queued for sending at a future time. (Note
that 'generating' a notification means sending
to all configured recipients.)"
REFERENCE
"[IEEE 802.3 Mgt], 30.4.1.3.1, nRepeaterHealth
notification."
::= { snmpDot3RptrMgt 0 4 }
rptrInfoResetEvent NOTIFICATION-TYPE
OBJECTS { rptrInfoOperStatus }
STATUS current
DESCRIPTION
"In a system containing multiple managed
repeaters, the rptrInfoResetEvent notification
conveys information related to the operational
status of a repeater. This notification is sent
on completion of a repeater reset action. A
repeater reset action is defined as a transition
to the START state of Fig 9-2 in section 9 of
[IEEE 802.3 Std], when triggered by a management
command (e.g., an SNMP Set on the rptrInfoReset
object).
The agent must throttle the generation of
consecutive rptrInfoResetEvent notifications for
a single repeater so that there is at least
a five-second gap between notifications of
this type. When notifications are throttled,
they are dropped, not queued for sending at
a future time. (Note that 'generating' a
notification means sending to all configured
recipients.)
The rptrInfoResetEvent is not sent when the
agent restarts and sends an SNMP coldStart or
warmStart trap. However, it is recommended that
a repeater agent send the rptrInfoOperStatus
object as an optional object with its coldStart
and warmStart trap PDUs."
REFERENCE
"[IEEE 802.3 Mgt], 30.4.1.3.2, nRepeaterReset
notification."
::= { snmpDot3RptrMgt 0 5 }
-- Conformance information
snmpRptrModConf
OBJECT IDENTIFIER ::= { snmpRptrMod 1 }
snmpRptrModCompls
OBJECT IDENTIFIER ::= { snmpRptrModConf 1 }
snmpRptrModObjGrps
OBJECT IDENTIFIER ::= { snmpRptrModConf 2 }
snmpRptrModNotGrps
OBJECT IDENTIFIER ::= { snmpRptrModConf 3 }
-- Object groups
snmpRptrGrpBasic1516 OBJECT-GROUP
OBJECTS { rptrGroupCapacity,
rptrOperStatus,
rptrHealthText,
rptrReset,
rptrNonDisruptTest,
rptrTotalPartitionedPorts,
rptrGroupIndex,
rptrGroupDescr,
rptrGroupObjectID,
rptrGroupOperStatus,
rptrGroupLastOperStatusChange,
rptrGroupPortCapacity,
rptrPortGroupIndex,
rptrPortIndex,
rptrPortAdminStatus,
rptrPortAutoPartitionState,
rptrPortOperStatus }
STATUS deprecated
DESCRIPTION
"********* THIS GROUP IS DEPRECATED **********
Basic group from RFCs 1368 and 1516.
NOTE: this object group is DEPRECATED and replaced
with snmpRptrGrpBasic."
::= { snmpRptrModObjGrps 1 }
snmpRptrGrpMonitor1516 OBJECT-GROUP
OBJECTS { rptrMonitorTransmitCollisions,
rptrMonitorGroupIndex,
rptrMonitorGroupTotalFrames,
rptrMonitorGroupTotalOctets,
rptrMonitorGroupTotalErrors,
rptrMonitorPortGroupIndex,
rptrMonitorPortIndex,
rptrMonitorPortReadableFrames,
rptrMonitorPortReadableOctets,
rptrMonitorPortFCSErrors,
rptrMonitorPortAlignmentErrors,
rptrMonitorPortFrameTooLongs,
rptrMonitorPortShortEvents,
rptrMonitorPortRunts,
rptrMonitorPortCollisions,
rptrMonitorPortLateEvents,
rptrMonitorPortVeryLongEvents,
rptrMonitorPortDataRateMismatches,
rptrMonitorPortAutoPartitions,
rptrMonitorPortTotalErrors }
STATUS deprecated
DESCRIPTION
"********* THIS GROUP IS DEPRECATED **********
Monitor group from RFCs 1368 and 1516.
NOTE: this object group is DEPRECATED and replaced
with snmpRptrGrpMonitor."
::= { snmpRptrModObjGrps 2 }
snmpRptrGrpAddrTrack1368 OBJECT-GROUP
OBJECTS { rptrAddrTrackGroupIndex,
rptrAddrTrackPortIndex,
rptrAddrTrackLastSourceAddress,
rptrAddrTrackSourceAddrChanges }
STATUS obsolete
DESCRIPTION
"Address tracking group from RFC1368.
NOTE: this object group is OBSOLETE and replaced
with snmpRptrGrpAddrTrack1516."
::= { snmpRptrModObjGrps 3 }
snmpRptrGrpAddrTrack1516 OBJECT-GROUP
OBJECTS { rptrAddrTrackGroupIndex,
rptrAddrTrackPortIndex,
rptrAddrTrackLastSourceAddress,
rptrAddrTrackSourceAddrChanges,
rptrAddrTrackNewLastSrcAddress }
STATUS deprecated
DESCRIPTION
"********* THIS GROUP IS DEPRECATED **********
Address tracking group from RFC1516.
NOTE: this object group is DEPRECATED and
replaced with snmpRptrGrpAddrTrack."
::= { snmpRptrModObjGrps 4 }
snmpRptrGrpBasic OBJECT-GROUP
OBJECTS { rptrGroupIndex,
rptrGroupObjectID,
rptrGroupOperStatus,
rptrGroupPortCapacity,
rptrPortGroupIndex,
rptrPortIndex,
rptrPortAdminStatus,
rptrPortAutoPartitionState,
rptrPortOperStatus,
rptrPortRptrId,
rptrInfoId,
rptrInfoRptrType,
rptrInfoOperStatus,
rptrInfoReset,
rptrInfoPartitionedPorts,
rptrInfoLastChange }
STATUS current
DESCRIPTION
"Basic group for a system with one or more
repeater-units in multi-segment (post-RFC1516)
version of the MIB module."
::= { snmpRptrModObjGrps 5 }
snmpRptrGrpMonitor OBJECT-GROUP
OBJECTS { rptrMonitorPortGroupIndex,
rptrMonitorPortIndex,
rptrMonitorPortReadableFrames,
rptrMonitorPortReadableOctets,
rptrMonitorPortFCSErrors,
rptrMonitorPortAlignmentErrors,
rptrMonitorPortFrameTooLongs,
rptrMonitorPortShortEvents,
rptrMonitorPortRunts,
rptrMonitorPortCollisions,
rptrMonitorPortLateEvents,
rptrMonitorPortVeryLongEvents,
rptrMonitorPortDataRateMismatches,
rptrMonitorPortAutoPartitions,
rptrMonitorPortTotalErrors,
rptrMonitorPortLastChange,
rptrMonTxCollisions,
rptrMonTotalFrames,
rptrMonTotalErrors,
rptrMonTotalOctets }
STATUS current
DESCRIPTION
"Monitor group for a system with one or more
repeater-units in multi-segment (post-RFC1516)
version of the MIB module."
::= { snmpRptrModObjGrps 6 }
snmpRptrGrpMonitor100 OBJECT-GROUP
OBJECTS { rptrMonitorPortIsolates,
rptrMonitorPortSymbolErrors,
rptrMonitorPortUpper32Octets,
rptrMonUpper32TotalOctets }
STATUS current
DESCRIPTION
"Monitor group for 100Mb/s ports and repeaters
in a system with one or more repeater-units in
multi-segment (post-RFC1516) version of the MIB
module. Systems which support Counter64 should
also implement snmpRptrGrpMonitor100w64."
::= { snmpRptrModObjGrps 7 }
snmpRptrGrpMonitor100w64 OBJECT-GROUP
OBJECTS { rptrMonitorPortHCReadableOctets,
rptrMonHCTotalOctets }
STATUS current
DESCRIPTION
"Monitor group for 100Mb/s ports and repeaters in a
system with one or more repeater-units and support
for Counter64."
::= { snmpRptrModObjGrps 8 }
snmpRptrGrpAddrTrack OBJECT-GROUP
OBJECTS { rptrAddrTrackGroupIndex,
rptrAddrTrackPortIndex,
rptrAddrTrackSourceAddrChanges,
rptrAddrTrackNewLastSrcAddress,
rptrAddrTrackCapacity }
STATUS current
DESCRIPTION
"Passive address tracking group for post-RFC1516
version of the MIB module."
::= { snmpRptrModObjGrps 9 }
snmpRptrGrpExtAddrTrack OBJECT-GROUP
OBJECTS { rptrExtAddrTrackMacIndex,
rptrExtAddrTrackSourceAddress }
STATUS current
DESCRIPTION
"Extended passive address tracking group for
a system with one or more repeater-units in
post-RFC1516 version of the MIB module."
::= { snmpRptrModObjGrps 10 }
snmpRptrGrpRptrAddrSearch OBJECT-GROUP
OBJECTS { rptrAddrSearchLock,
rptrAddrSearchStatus,
rptrAddrSearchAddress,
rptrAddrSearchState,
rptrAddrSearchGroup,
rptrAddrSearchPort,
rptrAddrSearchOwner }
STATUS current
DESCRIPTION
"Active MAC address search group and topology
mapping support for repeaters."
::= { snmpRptrModObjGrps 11 }
snmpRptrGrpTopNPort OBJECT-GROUP
OBJECTS { rptrTopNPortControlIndex,
rptrTopNPortRepeaterId,
rptrTopNPortRateBase,
rptrTopNPortTimeRemaining,
rptrTopNPortDuration,
rptrTopNPortRequestedSize,
rptrTopNPortGrantedSize,
rptrTopNPortStartTime,
rptrTopNPortOwner,
rptrTopNPortRowStatus,
rptrTopNPortIndex,
rptrTopNPortGroupIndex,
rptrTopNPortPortIndex,
rptrTopNPortRate }
STATUS current
DESCRIPTION
"Top `N' group for repeater ports."
::= { snmpRptrModObjGrps 12 }
-- Compliances
snmpRptrModComplRFC1368 MODULE-COMPLIANCE
STATUS obsolete
DESCRIPTION
"Compliance for RFC1368.
NOTE: this module compliance is OBSOLETE and
replaced by snmpRptrModComplRFC1516."
MODULE -- this module
MANDATORY-GROUPS { snmpRptrGrpBasic1516 }
GROUP snmpRptrGrpMonitor1516
DESCRIPTION
"Implementation of this optional group is
recommended for systems which have the
instrumentation to do performance monitoring."
GROUP snmpRptrGrpAddrTrack1368
DESCRIPTION
"Implementation of this group is
recommended for systems which have
the necessary instrumentation."
::= { snmpRptrModCompls 1 }
snmpRptrModComplRFC1516 MODULE-COMPLIANCE
STATUS deprecated
DESCRIPTION
"********* THIS COMPLIANCE IS DEPRECATED **********
Compliance for RFC1516 and for backwards
compatibility with single-repeater,
10Mb/s-only implementations."
MODULE -- this module
MANDATORY-GROUPS { snmpRptrGrpBasic1516 }
GROUP snmpRptrGrpMonitor1516
DESCRIPTION
"Implementation of this optional group is
recommended for systems which have the
instrumentation to do performance monitoring."
GROUP snmpRptrGrpAddrTrack1516
DESCRIPTION
"Implementation of this group is
recommended for systems which have
the necessary instrumentation."
::= { snmpRptrModCompls 2 }
snmpRptrModCompl MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Compliance for the multi-segment version of the
MIB module for a system with one or more
repeater-units."
MODULE -- this module
MANDATORY-GROUPS { snmpRptrGrpBasic,
snmpRptrGrpMonitor,
snmpRptrGrpAddrTrack }
GROUP snmpRptrGrpMonitor100
DESCRIPTION
"Implementation of this group is
mandatory for managed systems which
contain 100Mb/s repeaters."
GROUP snmpRptrGrpMonitor100w64
DESCRIPTION
"Implementation of this group is
mandatory for managed systems which
contain 100Mb/s repeaters and which
can support Counter64."
GROUP snmpRptrGrpExtAddrTrack
DESCRIPTION
"Implementation of this group is
recommended for systems which have
the necessary instrumentation to track
MAC addresses of multiple DTEs attached
to a single repeater port."
GROUP snmpRptrGrpRptrAddrSearch
DESCRIPTION
"Implementation of this group is
recommended for systems which allow
read-write access and which have
the necessary instrumentation to
search all incoming data streams
for a particular MAC address."
GROUP snmpRptrGrpTopNPort
DESCRIPTION
"Implementation of this group is
recommended for systems which have
the necessary resources to support
TopN statistics reporting."
::= { snmpRptrModCompls 3 }
END
4. Topology Mapping
The network mapping algorithm presented below takes information
available from network devices such as repeaters, bridges, and
switches, and creates a representation of the physical topology of
the network.
Networking devices connect to the network via one or more ports.
Through these ports, the device is capable of hearing network packets
sent by other devices. By looking the source address in the packet,
and identifying which port the packet was heard on, the device can
provide information to a Network Management System about the location
of an address in the network, relative to that device. For devices
such as bridges and switches, the association of address to port can
be retrieved via the forwarding data base part of the Bridge MIB.
For repeaters, the rptrAddrSearchTable may be used to perform the
association.
Given this information, it would be possible for the NMS to create a
topology of the network which represents the physical relationships
of the devices in the networks. The following is an example of how
this might be done:
Assume the network:
=============================
| | |
| | |
d1 d4 d7
/ \ |
/ \ |
d2 d3 d5
|
|
d6
The discovery process would first determine the existence of the
network devices and nodes in the network. In the above example, the
network devices discovered would be:
d1,d2,d3,d4,d5,d6,d7
From this list of discovered devices, select (arbitrarily or via some
heuristic) a device as the starting point. From that device,
determine where all other devices are located in the network with
respect to the selected device.
For example, if d1 is the selected device, the network in relation to
d1 would look like:
d1
/ | \
/ | \
d2 d3 d4,d5,d6,d7
So d1 sees d2 on one port, d3 on another port, and d4, d5, and d6 on
the third port. In other words, using the rptrAddrSearchTable (if d1
is a repeater) or the Forwarding Database (if it is a bridge or a
switch), d1 has located d2 on one port, d1 has located d3 on another
port, and finally, d1 has located d4, d5, d6, and d7 on yet another
port.
After the first step of the algorithm is accomplished, the next and
final step is a recursive one. Go to each of these temporary
'segments' (e.g., the segment connecting d1 and d2, or the segment
connecting d1 and d3, or the segment connecting d1, d4, d5, d6, and
d7) and determine which of these devices really belongs in that
segment.
As new segments are created due to this process, the recursive
algorithm visits them, and performs the exact same process.
In the example, the segments connecting d1 and d2, and connecting d1
and d3, require no further scrutiny, since there are only two nodes
in those segments. However, the segment connecting d1, d4, d5, d6,
and d7 may prove to be one or more segments, so we will investigate
it.
The purpose of this step is to determine which devices are really
connected to this segment, and which are actually connected
downstream. This is done by giving each of the child devices in the
segment (d4, d5, d6, and d7) a chance to eliminate each of the others
from the segment.
A device eliminates another device by showing that it hears the
parent device (in this case, d1) on one port, and the other device on
another port (different from the port on which it heard the parent).
If this is true, then it must mean that that device is _between_ the
parent device and the device which is being eliminated.
In the example, we can see that device d4 can eliminate both d5 and
d6, , but nobody can eliminate d4 and d7, because everybody hears
them on the same port that they hear the parent device (d1). So the
resulting topology looks like:
d1
/ | \
/ | \
d2 d3 d4,d7
|
|
d5,d6
Next the algorithm visits the next segment, which is the one
connecting d4, d5, and d6. Using the process stated above, d5 can
eliminate d6, since it hears d4 on a different port from where it
hears d6. Finally, the topology looks like:
d1
/ | \
/ | \
d2 d3 d4,d7
|
|
d5
|
|
d6
This is actually the topology shown at the beginning of the
description.
With this information about how the network devices are connected, it
is a relatively simple extension to then place nodes such as
workstations and PCs in the network. This can be done by placing the
node into a segment, then allowing the network devices to show that
the node is really not part of that segment.
This elimination can be done because the devices know what port
connects them to the segment on which the node is temporarily placed.
If they actually hear the node on a different port than that which
connects the device to the segment, then the node must be downstream,
and so it is moved onto the downstream segment. Then that segment is
evaluated, and so forth. Eventually, no device can show that the
node is connected downstream, and so it must be attached to that
segment.
For example, assume the network:
=============================
| | |
| | |
d1 d4 d7
/ \ |
/ \ |
d2 d3 d5
| |
| |
e1 d6
In this network, we are trying to place e1 where it belongs. We
begin by placing it arbitrarily into a segment:
==================================
| | | |
| | | |
e1 d1 d4 d7
/ \ |
/ \ |
d2 d3 d5
|
|
d6
In the above case, we would give d1, d4, and d7 a chance to show that
e1 is not really on that segment. d4 and d7 hear e1 on the same port
which connects them to that segment, so they cannot eliminate e1 from
the segment. However, d1 will hear e1 on a different port, so we
move e1 down onto the segment which is connected by that port. This
yields the following:
=============================
| | |
| | |
d1 d4 d7
/ \ |
/ \ |
d2 d3,e1 d5
|
|
d6
Now we give everyone in that segment (besides that parent device, d1)
a chance to eliminate e1. Only d3 can try, and it succeeds, so we
place e1 on segment which is connected by the port on which d3 heard
e1. There is no segment there (yet), so we create one, and end up
with the following:
=============================
| | |
| | |
d1 d4 d7
/ \ |
/ \ |
d2 d3 d5
| |
| |
e1 d6
which is the correct position.
5. Acknowledgements
This document was produced by the IETF Hub MIB Working Group, whose
efforts were greatly advanced by the contributions of the following
people:
Chuck Black
John Flick
Jeff Johnson
Leon Leong
Mike Lui
Dave Perkins
Geoff Thompson
Maurice Turcotte
Paul Woodruff
6. References
[1] IEEE 802.3/ISO 8802-3 Information processing systems -
Local area networks - Part 3: Carrier sense multiple
access with collision detection (CSMA/CD) access method
and physical layer specifications, 1993.
[2] IEEE 802.3u-1995, "MAC Parameters, Physical Layer, Medium
Attachment Units and Repeater for 100 Mb/s Operation,
Type 100BASE-T," Sections 21 through 29, Supplement to
IEEE Std 802.3, October 26, 1995.
[3] IEEE 802.3u-1995, "10 & 100 Mb/s Management," Section 30,
Supplement to IEEE Std 802.3, October 26, 1995.
[4] de Graaf, K., D. Romascanu, D. McMaster, K. McCloghrie,
and S. Roberts, "Definitions of Managed Objects for IEEE
802.3 Medium Attachment Units (MAUs)", Work in Progress.
[5] McCloghrie, K., and M. Rose, Editors, "Management
Information Base for Network Management of TCP/IP-based
internets: MIB-II", STD 17, RFC1213, Hughes LAN Systems,
Performance Systems International, March 1991.
[6] SNMPv2 Working Group, J. Case, K. McCloghrie, M. Rose,
and S. Waldbusser, "Structure of Management Information
for version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC1902, January 1996.
[7] SNMPv2 Working Group, J. Case, K. McCloghrie, M. Rose,
and S. Waldbusser, "Textual Conventions for version 2 of
the Simple Network Management Protocol (SNMPv2)", RFC
1903, January 1996.
[8] SNMPv2 Working Group, J. Case, K. McCloghrie, M. Rose,
and S. Waldbusser, "Conformance Statements for version 2
of the Simple Network Management Protocol (SNMPv2)", RFC
1904, January 1996.
[9] SNMPv2 Working Group, J. Case, K. McCloghrie, M. Rose,
and S. Waldbusser, "Protocol Operations for version 2 of
the Simple Network Management Protocol (SNMPv2)", RFC
1905, January 1996.
[10] Case, J., M. Fedor, M. Schoffstall, and J. Davin, "Simple
Network Management Protocol", STD 15, RFC1157, SNMP
Research, Performance Systems International, MIT Laboratory
for Computer Science, May 1990.
[11] McMaster, D., and K. McCloghrie, "Definitions of Managed
Objects for IEEE 802.3 Repeater Devices", RFC1516,
September 1993.
[12] McAnally, G., D. Gilbert, and J. Flick, "Conditional
Grant of Rights to Specific Hewlett-Packard Patents In
Conjunction With the Internet Engineering Task Force's
Internet-Standard Network Management Framework", RFC1988,
August 1996.
[13] Hewlett-Packard Company, US Patents 5,293,635 and
5,421,024.
[14] McCloghrie, K., and F. Kastenholz, "Evolution of the
Interfaces Group of MIB-II", RFC1573, January 1994.
7. Security Considerations
Security issues are not discussed in this memo.
8. Authors' Addresses
Kathryn de Graaf
3Com Corporation
118 Turnpike Rd.
Southborough, MA 01772 USA
Phone: (508)229-1627
Fax: (508)490-5882
EMail: kdegraaf@isd.3com.com
Dan Romascanu
Madge Networks (Israel) Ltd.
Atidim Technology Park, Bldg. 3
Tel Aviv 61131, Israel
Phone: 972-3-6458414, 6458458
Fax: 972-3-6487146
EMail: dromasca@madge.com
Donna McMaster
Cisco Systems Inc.
170 West Tasman Drive
San Jose, CA 95134
Phone: (408) 526-5260
EMail: mcmaster@cisco.com
Keith McCloghrie
Cisco Systems Inc.
170 West Tasman Drive
San Jose, CA 95134
Phone: (408) 526-5260
EMail: kzm@cisco.com