the network.
Implementors may wish to consider selecting the
ShortEventMaxTime towards the lower end of the
allowed tolerance range to accommodate bit losses
suffered through physical channel devices not
budgeted for within this standard.
The approximate minimum time for rollover of this
counter is 16 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aShortEvents."
::= { rptrMonitorPortEntry 8 }
rptrMonitorPortRunts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each
CarrierEvent on this port that meets one of the
following two conditions. Only one test need be
made. a) The ActivityDuration is greater than
ShortEventMaxTime and less than ValidPacketMinTime
and the CollisionEvent signal is deasserted. b)
The OctetCount is less than 64, the
ActivityDuration is greater than ShortEventMaxTime
and the CollisionEvent signal is deasserted.
ValidPacketMinTime is greater than or equal to 552
bit times and less than 565 bit times.
An event whose length is greater than 74 bit times
but less than 82 bit times shall increment either
the shortEvents counter or the runts counter but
not both. A CarrierEvent greater than or equal to
552 bit times but less than 565 bit times may or
may not be counted as a runt.
ValidPacketMinTime has tolerances included to
provide for circuit losses between a conformance
test point at the AUI and the measurement point
within the state machine.
Runts usually indicate collision fragments, a
normal network event. In certain situations
associated with large diameter networks a
percentage of collision fragments may exceed
ValidPacketMinTime.
The approximate minimum time for rollover of this
counter is 16 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2, aRunts."
::= { rptrMonitorPortEntry 9 }
rptrMonitorPortCollisions OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for any
CarrierEvent signal on any port for which the
CollisionEvent signal on this port is also
asserted.
The approximate minimum time for rollover of this
counter is 16 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aCollisions."
::= { rptrMonitorPortEntry 10 }
rptrMonitorPortLateEvents OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each
CarrierEvent on this port in which the CollIn(X)
variable transitions to the value SQE (Ref:
9.6.6.2, IEEE 802.3 Std) while the
ActivityDuration is greater than the
LateEventThreshold. Such a CarrierEvent is
counted twice, as both a collision and as a
lateEvent.
The LateEventThreshold is greater than 480 bit
times and less than 565 bit times.
LateEventThreshold has tolerances included to
permit an implementation to build a single
threshold to serve as both the LateEventThreshold
and ValidPacketMinTime threshold.
The approximate minimum time for rollover of this
counter is 81 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aLateEvents."
::= { rptrMonitorPortEntry 11 }
rptrMonitorPortVeryLongEvents OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each
CarrierEvent on this port whose ActivityDuration
is greater than the MAU Jabber Lockup Protection
timer TW3 (Ref: 9.6.1 & 9.6.5, IEEE 802.3 Std).
Other counters may be incremented as appropriate."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aVeryLongEvents."
::= { rptrMonitorPortEntry 12 }
rptrMonitorPortDataRateMismatches OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each frame
received on this port that meets all of the
following conditions: a) The CollisionEvent
signal is not asserted. b) The ActivityDuration
is greater than ValidPacketMinTime. c) The
frequency (data rate) is detectably mismatched
from the local transmit frequency. The exact
degree of mismatch is vendor specific and is to be
defined by the vendor for conformance testing.
When this event occurs, other counters whose
increment conditions were satisfied may or may not
also be incremented, at the implementor's
discretion. Whether or not the repeater was able
to maintain data integrity is beyond the scope of
this standard."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aDataRateMismatches."
::= { rptrMonitorPortEntry 13 }
rptrMonitorPortAutoPartitions OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each time
the repeater has automatically partitioned this
port. The conditions that cause port partitioning
are specified in the partition state machine in
Section 9 [IEEE 802.3 Std]. They are not
differentiated here."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aAutoPartitions."
::= { rptrMonitorPortEntry 14 }
rptrMonitorPortTotalErrors OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of errors which have occurred on
this port. This counter is the summation of the
values of other error counters (for the same
port), namely:
rptrMonitorPortFCSErrors,
rptrMonitorPortAlignmentErrors,
rptrMonitorPortFrameTooLongs,
rptrMonitorPortShortEvents,
rptrMonitorPortLateEvents,
rptrMonitorPortVeryLongEvents, and
rptrMonitorPortDataRateMismatches.
This counter is redundant in the sense that it is
the summation of information already available
through other objects. However, it is included
specifically because the regular retrieval of this
object as a means of tracking the health of a port
provides a considerable optimization of network
management traffic over the otherwise necessary
retrieval of the summed counters."
::= { rptrMonitorPortEntry 15 }
--
-- The ADDRESS TRACKING GROUP
--
-- Implementation of this group is optional; it is appropriate
-- for all systems which have the necessary instrumentation. If a
-- managed repeater implements any part of this group, the entire
-- group shall be implemented.
--
-- The Port Address Tracking Table
--
rptrAddrTrackTable OBJECT-TYPE
SYNTAX SEQUENCE OF RptrAddrTrackEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Table of address mapping information about the
ports."
::= { rptrAddrTrackPortInfo 1 }
rptrAddrTrackEntry OBJECT-TYPE
SYNTAX RptrAddrTrackEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the table, containing address mapping
information about a single port."
INDEX { rptrAddrTrackGroupIndex, rptrAddrTrackPortIndex }
::= { rptrAddrTrackTable 1 }
RptrAddrTrackEntry ::=
SEQUENCE {
rptrAddrTrackGroupIndex
INTEGER,
rptrAddrTrackPortIndex
INTEGER,
rptrAddrTrackLastSourceAddress -- DEPRECATED OBJECT
MacAddress,
rptrAddrTrackSourceAddrChanges
Counter,
rptrAddrTrackNewLastSrcAddress
OCTET STRING
}
rptrAddrTrackGroupIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the group containing the
port for which this entry contains information."
::= { rptrAddrTrackEntry 1 }
rptrAddrTrackPortIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the port within the group
for which this entry contains information."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aPortID."
::= { rptrAddrTrackEntry 2 }
rptrAddrTrackLastSourceAddress OBJECT-TYPE
SYNTAX MacAddress
ACCESS read-only
STATUS deprecated
DESCRIPTION
"This object is the SourceAddress of the last
readable frame (i.e., counted by
rptrMonitorPortReadableFrames) received by this
port.
This object has been deprecated because its value
is undefined when no frames have been observed on
this port. The replacement object is
rptrAddrTrackNewLastSrcAddress."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aLastSourceAddress."
::= { rptrAddrTrackEntry 3 }
rptrAddrTrackSourceAddrChanges OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each time
that the rptrAddrTrackLastSourceAddress attribute
for this port has changed.
This may indicate whether a link is connected to a
single DTE or another multi-user segment.
The approximate minimum time for rollover of this
counter is 81 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aSourceAddressChanges."
::= { rptrAddrTrackEntry 4 }
rptrAddrTrackNewLastSrcAddress OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0 | 6))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object is the SourceAddress of the last
readable frame (i.e., counted by
rptrMonitorPortReadableFrames) received by this
port. If no frames have been received by this
port since the agent began monitoring the port
activity, the agent shall return a string of
length zero."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aLastSourceAddress."
::= { rptrAddrTrackEntry 5 }
-- Traps for use by Repeaters
-- Traps are defined using the conventions in RFC1215 [6].
rptrHealth TRAP-TYPE
ENTERPRISE snmpDot3RptrMgt
VARIABLES { rptrOperStatus }
DESCRIPTION
"The rptrHealth trap conveys information related
to the operational status of the repeater. This
trap is sent either when the value of
rptrOperStatus changes, or upon completion of a
non-disruptive test.
The rptrHealth trap 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
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4,
hubHealth notification."
::= 1
rptrGroupChange TRAP-TYPE
ENTERPRISE snmpDot3RptrMgt
VARIABLES { rptrGroupIndex }
DESCRIPTION
"This trap is sent when a change occurs in the
group structure of a 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
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4,
groupMapChange notification."
::= 2
rptrResetEvent TRAP-TYPE
ENTERPRISE snmpDot3RptrMgt
VARIABLES { rptrOperStatus }
DESCRIPTION
"The rptrResetEvent trap 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
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4, hubReset
notification."
::= 3
END
4. Changes from RFC1368
(1) Added section 2.1.4, "Internal Ports and MAUs," that defines
internal ports and clarifies how they may or may not be
managed.
(2) Noted that the failure list for rptrOperStatus is ordered
highest priority first.
(3) Clarified rptrReset description to indicate that the agent
may briefly delay the reset action.
(4) For rptrReset, clarified the actions that the agent should
take after performing the reset and self-test.
(5) For rptrNonDisruptTest, similar change to (3).
(6) Clarified that the rptrNonDisruptTest description allows
returning "ok" after doing only a trivial test.
(7) Deprecated rptrAddrTrackLastSourceAddress and defined a
replacement object that has a zero-length value until the
first frame is seen on the port.
(8) Clarified that rptrHealth trap is sent after
rptrNonDisruptTest even if repeater health information
doesn't change as a result of the test.
(9) Clarified text on throttling traps.
5. Acknowledgments
This document is the work of the IETF Hub MIB Working Group. It is
based on drafts of the IEEE 802.3 Repeater Management Task Force.
6. References
[1] Rose M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based internets", STD 16, RFC
1155, Performance Systems International, Hughes LAN Systems, May
1990.
[2] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Network Management Protocol", STD 15, RFC1157, SNMP Research,
Performance Systems International, Performance Systems
International, MIT Laboratory for Computer Science, May 1990.
[3] McCloghrie K., and M. Rose, Editors, "Management Information
Base for Network Management of TCP/IP-based internets", STD 17,
RFC1213, Performance Systems International, March 1991.
[4] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization, International
Standard 8824, December 1987.
[5] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
STD 16, RFC1212, Performance Systems International, Hughes LAN
Systems, March 1991.
[6] Rose, M., Editor, "A Convention for Defining Traps for use with
the SNMP", RFC1215, Performance Systems International, March
1991.
[7] 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, 2nd edition, 21 September 1990.
[8] IEEE P802.3K - Layer Management for 10 Mb/s Baseband Repeaters,
Section 19, Draft Supplement to ANSI/IEEE 802.3, Draft 8, 9
April 1992.
7. Security Considerations
Security issues are not discussed in this memo.
8. Authors' Addresses
Donna McMaster
SynOptics Communications, Inc.
4401 Great America Parkway
P.O. Box 58185
Santa Clara, CA 95052-8185
Phone: (408) 764-1206
EMail: mcmaster@synoptics.com
Keith McCloghrie
Hughes LAN Systems, Inc.
1225 Charleston Road
Mountain View, CA 94043
Phone: (415) 966-7934
EMail: kzm@hls.com