As per Relevance of the word reference, we have this rfc below:
Network Working Group D.
Request for Comments: 1368 SynOptics Communications, Inc
K.
Hughes LAN Systems, Inc
October 1992
Definitions of Managed Objects for IEEE 802.3 Repeater
Status of this
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
This memo defines a portion of the Management Information Base (MIB
for use with network management protocols in TCP/IP-based internets
In particular, it defines objects for managing IEEE 802.3 10
Mb/second baseband repeaters, sometimes referred to as "hubs."
Table of
1. Management Framework ........................................ 2
2. Objects ..................................................... 2
2.1 Format of Definitions ...................................... 3
3. Overview .................................................... 3
3.1 Terminology ................................................ 3
3.1.1 Repeaters, Hubs and Concentrators ........................ 3
3.1.2 Repeaters, Ports, and MAUs ............................... 4
3.1.3 Ports and Groups ......................................... 6
3.2 Supporting Functions ....................................... 7
3.3 Structure of MIB ........................................... 9
3.3.1 The Basic Group Definitions .............................. 10
3.3.2 The Monitor Group Definitions ............................ 10
3.3.3 The Address Tracking Group Definitions ................... 10
3.4 Relationship to Other MIBs ................................. 10
3.4.1 Relationship to the 'system' group ....................... 10
3.4.2 Relationship to the 'interfaces' group .................... 10
3.5 Textual Conventions ........................................ 11
4. Definitions ................................................. 11
4.1 MIB Groups in the Repeater MIB ............................. 12
4.2 The Basic Group Definitions ................................ 13
4.3 The Monitor Group Definitions .............................. 23
4.4 The Address Tracking Group Definitions ..................... 33
McMaster & McCloghrie [Page 1]
RFC 1368 802.3 Repeater MIB October 1992
4.5 Traps for use by Repeaters ................................. 35
5. Acknowledgments ............................................. 37
6. References .................................................. 39
7. Security Considerations...................................... 40
8. Authors' Addresses........................................... 40
1. Management
The Internet-standard Network Management Framework consists of
components. They are
STD 16/RFC 1155 [1] which defines the SMI, the mechanisms used
describing and naming objects for the purpose of management.
16/RFC 1212 [7] defines a more concise description mechanism
which is wholly consistent with the SMI
RFC 1156 [2] which defines MIB-I, the core set of managed
for the Internet suite of protocols. STD 17/RFC 1213 [4]
MIB-II, an evolution of MIB-I based on implementation
and new operational requirements
STD 15/RFC 1157 [3] which defines the SNMP, the protocol used
network access to managed objects
The Framework permits new objects to be defined for the purpose
experimentation and evaluation
2.
Managed objects are accessed via a virtual information store,
the Management Information Base or MIB. Objects in the MIB
defined using the subset of Abstract Syntax Notation One (ASN.1) [5]
defined in the SMI. In particular, each object has a name, a syntax
and an encoding. The name is an object identifier,
administratively assigned name, which specifies an object type.
object type together with an object instance serves to
identify a specific instantiation of the object. For
convenience, we often use a textual string, termed the
DESCRIPTOR, to also refer to the object type
The syntax of an object type defines the abstract data
corresponding to that object type. The ASN.1 language is used
this purpose. However, the SMI [1] purposely restricts the ASN.1
constructs which may be used. These restrictions are explicitly
for simplicity
The encoding of an object type is simply how that object type
represented using the object type's syntax. Implicitly tied to
McMaster & McCloghrie [Page 2]
RFC 1368 802.3 Repeater MIB October 1992
notion of an object type's syntax and encoding is how the object
is represented when being transmitted on the network
The SMI specifies the use of the basic encoding rules of ASN.1 [6],
subject to the additional requirements imposed by the SNMP
2.1. Format of
Section 4 contains the specification of all object types contained
this MIB module. The object types are defined using the
defined in the SMI, as amended by the extensions specified in [7,8].
3.
Instances of the object types defined in this memo
attributes of an IEEE 802.3 (Ethernet-like) repeater, as defined
Section 9, "Repeater Unit for 10 Mb/s Baseband Networks" in the
802.3/ISO 8802-3 CSMA/CD standard [9].
These Repeater MIB objects may be used to manage non-
repeater-like devices, but defining objects to
implementation-specific properties of non-standard repeater-
devices is outside the scope of this memo
The definitions presented here are based on the IEEE draft
P802.3K, "Layer Management for 10 Mb/s Baseband Repeaters." [10]
Implementors of these MIB objects should note that [10]
describes when, where, and how various repeater attributes
measured. The IEEE document also describes the effects of
actions that may be invoked by manipulating instances of the
objects defined here
The counters in this document are defined to be the same as
counters in the IEEE 802.3 Repeater Management draft, with
intention that a single instrumentation can be used to implement
the IEEE and IETF management standards
3.1.
3.1.1. Repeaters, Hubs and
In late 1988, the IEEE 802.3 Hub Management task force was
to define managed objects for both 802.3 repeaters and the
10BASE-FA synchronous active stars. The term "hub" was used to
both repeaters and active stars
In March, 1991, the active star proposal was dropped from
10BASE-F draft. Subsequently the 802.3 group changed the name of
McMaster & McCloghrie [Page 3]
RFC 1368 802.3 Repeater MIB October 1992
task force to be the IEEE 802.3 Repeater Management Task Force,
likewise renamed their draft
The use of the term "hub" has led to some confusion, as the
"hub," "intelligent hub," and "concentrator" are often used
indicate a modular chassis with plug-in modules that
generalized LAN/WAN connectivity, often with a mix of 802.3 repeater
token ring, and FDDI connectivity, internetworked by bridges
routers, and terminal servers
To be clear that this work covers the management of IEEE 802.3
repeaters only, the editors of this MIB definitions document chose
call this a "Repeater MIB" instead of a "Hub MIB."
3.1.2. Repeaters, Ports, and
The following text roughly defines the terms "repeater," "port,"
"MAU" as used in the context of this memo. This text is
and omits many technical details. For a more complete and
definition of these terms, refer to Section 9 of [9].
An IEEE 802.3 repeater connects "Ethernet-like" media
together to extend the network length and topology beyond what can
achieved with a single coax segment. It can be pictured as a
structure with two or more input/output ports. The diagram
illustrates a 6-port repeater
^ ^
| |
\ \ / /
\ \ / /
_____\ v /_____
-> ______ ______ ->
/ ^ \
/ / \ \
/ / \ \
| |
v
Figure 1. Repeater
All the stations on the media segments connected to a
repeater's ports participate in a single collision domain. A
transmitted by any of these stations is seen by all of
stations
Data coming in on any port in the repeater is transmitted out
McMaster & McCloghrie [Page 4]
RFC 1368 802.3 Repeater MIB October 1992
each of the remaining n-1 ports. If data comes in to the repeater
two or more ports simultaneously or the repeater detects a
on the incoming port, the repeater transmits a jamming signal out
all ports for the duration of the collision
A repeater is a bit-wise store-and-forward device. It
differentiated from a bridge (a frame store-and-forward device)
that it is primarily concerned with carrier sense and data bits,
does not make data-handling decisions based on the legality
contents of a packet. A repeater retransmits data bits as they
received. Its data FIFO holds only enough bits to make sure that
FIFO does not underflow when the data rate of incoming bits
slightly slower than the repeater's transmission rate
A repeater is not an end-station on the network, and does not
toward the overall limit of 1024 stations. A repeater has no
address associated with it, and therefore packets may not
addressed to the repeater or to its ports. (Packets may be
to the MAC address of a management entity that is monitoring
repeater. This management entity may or may not be connected to
network through one of the repeater's ports. How the
entity obtains information about the activity on the repeater is
implementation issue, and is not discussed in this memo.)
A repeater is connected to the network with Medium Attachment
(MAUs), and sometimes through Attachment Unit Interfaces (AUIs)
well. ("MAUs" are also known as transceivers, and an "AUI" is
same as a 15-pin Ethernet or DIX connector.)
The 802.3 standard defines a "repeater set" as the "repeater unit
plus its associated MAUs (and AUIs if present). The "repeater unit
is defined as the portion of the repeater set that is inboard of
physical media interfaces. The MAUs may be physically separate
the repeater unit, or they may be integrated into the same
package
(MAU) (MAU
\ \ / /
\ \ / /
_____\ v /_____
(MAU) ______ ______ (MAU
/ ^ \
/ / \ \
/ / \ \
(MAU) (MAU
Figure 2. Repeater
McMaster & McCloghrie [Page 5]
RFC 1368 802.3 Repeater MIB October 1992
The most commonly-used MAUs are the 10BASE-5 (AUI to thick "yellow
coax), 10BASE-2 (BNC to thin coax), 10BASE-T (unshielded twisted
pair), and FOIRL (asynchronous fiber optic inter-repeater link,
is being combined into the 10BASE-F standard as 10BASE-FL).
draft 10BASE-F standard also includes the definition for a
synchronous fiber optic attachment, known as 10BASE-FB
It should be stressed that the repeater MIB being defined by the
covers only the repeater unit management - it does not
management of the MAUs that form the repeater set. The
recognizes that MAU management should be the same for MAUs
to end-stations (DTEs) as it is for MAUs connected to repeaters
This memo follows the same strategy; the definition of
information for MAUs is being addressed in a separate memo
3.1.3. Ports and
Repeaters are often implemented in modular "concentrators," where
card cage holds several field-replaceable cards. Several cards
form a single repeater unit, with each card containing one or more
the repeater's ports. Because of this modular architecture,
typically identify these repeater ports with a card number plus
port number relative to the card, e.g., Card 3, Port 11.
To support this modular numbering scheme, this document follows
example of the IEEE Repeater Management draft [10], allowing
implementor to separate the ports in a repeater into "groups",
desired. For example, an implementor might choose to
field-replaceable units as groups of ports so that the port
would match the modular hardware implementation
This group mapping is recommended but optional. An implementor
choose to put all of a modular repeater's ports into a single group
or to divide the ports into groups that do not match
divisions
The object rptrGroupCapacity, which has a maximum value of 1024,
indicates the maximum number of groups that a given repeater
contain. The value of rptrGroupCapacity must remain constant
one management restart to the next
Each group within the repeater is uniquely identified by a
number in the range 1..rptrGroupCapacity. Groups may come and
without causing a management reset, and may be sparsely
within the repeater. For example, in a 12-card cage, cards 3, 5, 6,
and 7 may together form a single repeater, and the implementor
choose to number them as groups 3, 5, 6, and 7, respectively
McMaster & McCloghrie [Page 6]
RFC 1368 802.3 Repeater MIB October 1992
The object rptrGroupPortCapacity, which also has a maximum value
1024, indicates the maximum number of ports that a given group
contain. The value of rptrGroupPortCapacity must not change for
given group. However, a group may be deleted from the repeater
replaced with a group containing a different number of ports.
value of rptrGroupLastOperStatusChange will indicate that a
took place
Each port within the repeater is uniquely identified by a
of group number and port number, where port number is an integer
the range 1..rptrGroupPortCapacity. As with groups within
repeater, ports within a group may be sparsely numbered. Likewise
ports may come and go within a group without causing a
reset
3.2. Supporting
The IEEE 802.3 Hub Management draft [10] defines the following
functions and seven signals used to describe precisely when
counters are incremented. The relationship between the functions
signals is shown in Figure 3.
The CollisionEvent, ActivityDuration, CarrierEvent, FramingError
OctetCount, FCSError, and SourceAddress output signals defined
are not retrievable MIB objects, but rather are concepts used
defining the MIB objects. The inputs are defined in Section 9 of
IEEE 802.3 standard [9].
McMaster & McCloghrie [Page 7]
RFC 1368 802.3 Repeater MIB October 1992
+---------+
|Collision|--------------------->
CollIn(X)+>|Event |
| |Funct | +--------+
| +---------+ |Activity
| +-------+ |Timing |->
+>|Carrier| +---->|Funct |
|Event | | +--------+
DataIn(X)->|Funct |+-----+---------------->
+-------+|
| +-------+
+>|Framing|------------>
|Funct | +-------+
decodedData---------->| |+>|Octet |
+-------+| |Count |->
| |Funct |
| +-------+
| +-------+
Octet | |Cyclic |
Stream +>|Redund.|
| |Check |->
| |Funct |
| +-------+
| +-------+
| |Source |
+>|Address|->
|Funct |
+-------+
Figure 3. Port Functions
Collision Event Function: The collision event function asserts
CollisionEvent signal when the CollIn(X) variable has the value SQE
The CollisionEvent signal remains asserted until the assertion of
CarrierEvent signal due to the reception of the following event
Carrier Event Function: The carrier event function asserts
CarrierEvent signal when the repeater exits the IDLE state, Fig 9-2
[9], and the port has been determined to be port N. It deasserts
CarrierEvent signal when, for a duration of at least Carrier
Time (Ref: 9.5.6.5 [9]), both the DataIn(N) variable has the value
and the CollIn(N) variable has the value -SQE. The value N is
port assigned at the time of transition from the IDLE state
Framing Function: The framing function recognizes the boundaries
an incoming frame by monitoring the CarrierEvent signal and
decoded data stream. Data bits are accepted while the
McMaster & McCloghrie [Page 8]
RFC 1368 802.3 Repeater MIB October 1992
signal is asserted. The framing function strips preamble and
of frame delimiter from the received data stream. The remaining
are aligned along octet boundaries. If there is not an
number of octets, then FramingError shall be asserted.
FramingError signal is cleared upon the assertion of the
signal due to the reception of the following event
Activity Timing Function: The activity timing function measures
duration of the assertion of the CarrierEvent signal. This
value must be adjusted by removing the value of Carrier Recovery
(Ref: 9.5.6.5 [9]) to obtain the true duration of activity on
network. The output of the Activity Timing function is
ActivityDuration value, which represents the duration of
CarrierEvent signal as expressed in units of bit times
Octet Counting Function: The octet counting function counts
number of complete octets received from the output of the
function. The output of the octet counting function is
OctetCount value. The OctetCount value is reset to zero upon
assertion of the CarrierEvent signal due to the reception of
following event
Cyclic Redundancy Check Function: The cyclic redundancy
function verifies that the sequence of octets output by the
function contains a valid frame check sequence field. The
check sequence field is the last four octets received from the
of the framing function. The algorithm for generating an FCS
the octet stream is specified in 3.2.8 [9]. If the FCS
according to this algorithm is not the same as the last four
received from the framing function then the FCSError signal
asserted. The FCSError signal is cleared upon the assertion of
CarrierEvent signal due to the reception of the following event
Source Address Function: The source address function extracts
from the stream output by the framing function. The seventh
twelfth octets shall be extracted from the octet stream and output
the SourceAddress variable. The SourceAddress variable is set to
invalid state upon the assertion of the CarrierEvent signal due
the reception of the following event
3.3. Structure of
Objects in this MIB are arranged into MIB groups. Each MIB group
organized as a set of related objects
McMaster & McCloghrie [Page 9]
RFC 1368 802.3 Repeater MIB October 1992
3.3.1. The Basic Group
This mandatory group contains the objects which are applicable to
repeaters. It contains status, parameter and control objects for
repeater as a whole, the port groups within the repeater, as well
for the individual ports themselves
3.3.2. The Monitor Group
This optional group contains monitoring statistics for the
as a whole and for individual ports
3.3.3. The Address Tracking Group
This optional group contains objects for tracking the MAC
of the DTEs attached to the ports of the repeater
3.4. Relationship to Other
It is assumed that a repeater implementing this MIB will
implement (at least) the 'system' group defined in MIB-II [4].
3.4.1. Relationship to the 'system'
In MIB-II, the 'system' group is defined as being mandatory for
systems such that each managed entity contains one instance of
object in the 'system' group. Thus, those objects apply to
entity even if the entity's sole functionality is management of
repeater
3.4.2. Relationship to the 'interfaces'
In MIB-II, the 'interfaces' group is defined as being mandatory
all systems and contains information on an entity's interfaces,
each interface is thought of as being attached to a 'subnetwork'.
(Note that this term is not to be confused with 'subnet' which
to an addressing partitioning scheme used in the Internet suite
protocols.)
This Repeater MIB uses the notion of ports on a repeater.
concept of a MIB-II interface has NO specific relationship to
repeater's port. Therefore, the 'interfaces' group applies only
the one (or more) network interfaces on which the entity managing
repeater sends and receives management protocol operations, and
not apply to the repeater's ports
This is consistent with the physical-layer nature of a repeater.
repeater is a bitwise store-and-forward device. It
McMaster & McCloghrie [Page 10]
RFC 1368 802.3 Repeater MIB October 1992
activity and bits, but does not process incoming data based on
packet-related information (such as checksum or addresses).
repeater has no MAC address, no MAC implementation, and does not
packets up to higher-level protocol entities for processing
(When a network management entity is observing the repeater, it
appear as though the repeater is passing packets to a higher-
protocol entity. However, this is only a means of
management, and this passing of management information is not part
the repeater functionality.)
3.5. Textual
The datatype MacAddress is used as a textual convention in
document. This textual convention has NO effect on either the
nor the semantics of any managed object. Objects defined using
convention are always encoded by means of the rules that define
primitive type. Hence, no changes to the SMI or the SNMP
necessary to accommodate this textual convention which is
merely for the convenience of readers
4.
SNMP-REPEATER-MIB DEFINITIONS ::=
Counter, TimeTicks,
FROM RFC1155-
mib-2, DisplayString FROM RFC1213-
TRAP-TYPE FROM RFC-1215
OBJECT-TYPE FROM RFC-1212;
snmpDot3RptrMgt OBJECT IDENTIFIER ::= { mib-2 22 }
-- All representations of MAC addresses in this MIB Module use
-- as a textual convention (i.e., this convention does not
-- their encoding), the data type
MacAddress ::= OCTET STRING (SIZE (6)) -- a 6 octet address
-- the "canonical"
-- defined by IEEE 802.1a, i.e., as if it were transmitted
-- significant bit first
McMaster & McCloghrie [Page 11]
RFC 1368 802.3 Repeater MIB October 1992
--
--
-- The following references are used throughout this MIB
--
-- [IEEE 802.3 Std
-- refers to IEEE 802.3/ISO 8802-3 Information
-- systems - Local area networks - Part 3: Carrier
-- multiple access with collision detection (CSMA/CD
-- access method and physical layer
-- (2nd edition, September 21, 1990).
--
-- [IEEE 802.3 Rptr Mgt
-- refers to IEEE P802.3K, 'Layer Management for 10 Mb/
-- Baseband Repeaters, Section 19,' Draft Supplement
-- ANSI/IEEE 802.3, (Draft 8, April 9, 1992)
-- MIB
--
-- The rptrBasicPackage group is mandatory
-- The rptrMonitorPackage and
-- groups are optional
OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 1 }
OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 2 }
OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 3 }
-- object identifiers for organizing the
-- in the groups by repeater, port-group, and
OBJECT IDENTIFIER ::= { rptrBasicPackage 1 }
OBJECT IDENTIFIER ::= { rptrBasicPackage 2 }
OBJECT IDENTIFIER ::= { rptrBasicPackage 3 }
OBJECT IDENTIFIER ::= { rptrMonitorPackage 1 }
OBJECT IDENTIFIER ::= { rptrMonitorPackage 2 }
McMaster & McCloghrie [Page 12]
RFC 1368 802.3 Repeater MIB October 1992
OBJECT IDENTIFIER ::= { rptrMonitorPackage 3 }
rptrAddrTrackRptrInfo -- this subtree is currently
OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 1 }
rptrAddrTrackGroupInfo -- this subtree is currently
OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 2 }
OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 3 }
--
-- The BASIC
--
-- Implementation of the Basic Group is mandatory for
-- managed repeaters
--
-- Basic Repeater
--
-- Configuration, status, and control objects for the
--
--
rptrGroupCapacity OBJECT-
SYNTAX INTEGER (1..1024)
ACCESS read-
STATUS
"The rptrGroupCapacity is the number of
that can be contained within the repeater.
each managed repeater, the groups are
numbered in the range from 1 to rptrGroupCapacity
Some groups may not be present in the repeater,
which case the actual number of groups
will be less than rptrGroupCapacity. The
of groups present will never be greater
rptrGroupCapacity
Note: In practice, this will generally be
number of field-replaceable units (i.e., modules
cards, or boards) that can fit in the
repeater enclosure, and the group numbers
correspond to numbers marked on the
enclosure."
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.2,
aRepeaterGroupCapacity."
McMaster & McCloghrie [Page 13]
RFC 1368 802.3 Repeater MIB October 1992
::= { rptrRptrInfo 1 }
rptrOperStatus OBJECT-
SYNTAX INTEGER {
other(1), -- undefined or unknown
ok(2), -- no known
rptrFailure(3), -- repeater-related
groupFailure(4), -- group-related
portFailure(5), -- port-related
generalFailure(6) -- failure, unspecified
}
ACCESS read-
STATUS
"The rptrOperStatus object indicates
operational state of the repeater.
rptrHealthText object may be consulted for
specific information about the state of
repeater's health
In the case of multiple kinds of failures (e.g.,
repeater failure and port failure), the value
this attribute shall reflect the highest
failure in the following order
rptrFailure(3)
groupFailure(4)
portFailure(5)
generalFailure(6)."
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.2,
aRepeaterHealthState."
::= { rptrRptrInfo 2 }
rptrHealthText OBJECT-
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-
STATUS
"The health text object is a text string
provides information relevant to the
state of the repeater. Agents may use this
to provide detailed information on
failures, including how they were detected, and/
instructions for problem resolution. The
are agent-specific."
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.2,
McMaster & McCloghrie [Page 14]
RFC 1368 802.3 Repeater MIB October 1992
aRepeaterHealthText."
::= { rptrRptrInfo 3 }
rptrReset OBJECT-
SYNTAX INTEGER {
noReset(1),
reset(2)
}
ACCESS read-
STATUS
"Setting this object to reset(2) causes
transition to the START state of Fig 9-2
section 9 [IEEE 802.3 Std].
Setting this object to noReset(1) has no effect
The agent will always return the value noReset(1)
when this object is read
This action does not reset the management
defined in this document nor does it affect
portAdminStatus parameters. Included in
action is the execution of a disruptive Self-
with the following characteristics: a) The
of the tests is not specified. b) The test
the repeater but without affecting
information about the repeater. c) The test
not inject packets onto any segment. d)
received during the test may or may not
transferred. e) The test does not interfere
management functions
As a result of this action a rptrResetEvent
should be sent."
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.3,
acResetRepeater."
::= { rptrRptrInfo 4 }
rptrNonDisruptTest OBJECT-
SYNTAX INTEGER {
noSelfTest(1),
selfTest(2)
}
ACCESS read-
STATUS
"Setting this object to selfTest(2) causes
McMaster & McCloghrie [Page 15]
RFC 1368 802.3 Repeater MIB October 1992
repeater to perform a agent-specific, non
disruptive self-test that has the
characteristics: a) The nature of the tests
not specified. b) The test does not change
state of the repeater or management
about the repeater. c) The test does not
packets onto any segment. d) The test does
prevent the relay of any packets. e) The
does not interfere with management functions
After performing this test the agent will
the repeater health information and send
rptrHealth trap
Setting this object to noSelfTest(1) has
effect. The agent will always return the
noSelfTest(1) when this object is read."
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.3,
acExecuteNonDisruptiveSelfTest."
::= { rptrRptrInfo 5 }
rptrTotalPartitionedPorts OBJECT-
SYNTAX
ACCESS read-
STATUS
"This object returns the total number of ports
the repeater whose current state meets all
of the following criteria:
does not have the value notPresent(3),
rptrPortAdminStatus is enabled(1),
rptrPortAutoPartitionState is autoPartitioned(2)."
::= { rptrRptrInfo 6 }
--
-- The Basic Port Group
--
rptrGroupTable OBJECT-
SYNTAX SEQUENCE OF
ACCESS not-
STATUS
"Table of descriptive and status information
the groups of ports."
::= { rptrGroupInfo 1 }
McMaster & McCloghrie [Page 16]
RFC 1368 802.3 Repeater MIB October 1992
rptrGroupEntry OBJECT-
SYNTAX
ACCESS not-
STATUS
"An entry in the table, containing
about a single group of ports."
INDEX { rptrGroupIndex }
::= { rptrGroupTable 1 }
RptrGroupEntry ::=
SEQUENCE {
INTEGER
DisplayString
OBJECT IDENTIFIER
INTEGER
TimeTicks
}
rptrGroupIndex OBJECT-
SYNTAX INTEGER (1..1024)
ACCESS read-
STATUS
"This object identifies the group within
repeater for which this entry
information. This value is never greater
rptrGroupCapacity."
"Reference IEEE 802.3 Rptr Mgt, 19.2.5.2,
aGroupID."
::= { rptrGroupEntry 1 }
rptrGroupDescr OBJECT-
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-
STATUS
"A textual description of the group. This
should include the full name and
identification of the group's hardware type
McMaster & McCloghrie [Page 17]
RFC 1368 802.3 Repeater MIB October 1992
indicate how the group is differentiated
other groups in the repeater. Plug-in Module,
A' or 'Barney Rubble 10BASE-T 4-port SIMM
Version 2.1' are examples of valid
descriptions
It is mandatory that this only contain
ASCII characters."
::= { rptrGroupEntry 2 }
rptrGroupObjectID OBJECT-
SYNTAX OBJECT
ACCESS read-
STATUS
"The vendor's authoritative identification of
group. This value is allocated within the
enterprises subtree (1.3.6.1.4.1) and provides
straight-forward and unambiguous means
determining what kind of group is being managed
For example, this object could take the
1.3.6.1.4.1.4242.1.2.14 if vendor 'Flintstones
Inc.' was assigned the subtree 1.3.6.1.4.1.4242,
and had assigned the
1.3.6.1.4.1.4242.1.2.14 to its 'Wilma
6-Port FOIRL Plug-in Module.'"
::= { rptrGroupEntry 3 }
rptrGroupOperStatus OBJECT-
SYNTAX INTEGER {
other(1),
operational(2),
malfunctioning(3),
notPresent(4),
underTest(5),
resetInProgress(6)
}
ACCESS read-
STATUS
"An object that indicates the operational
of the group
A status of notPresent(4) indicates that the
is temporarily or permanently physically and/
logically not a part of the repeater. It is
implementation-specific matter as to whether
McMaster & McCloghrie [Page 18]
RFC 1368 802.3 Repeater MIB October 1992
agent effectively removes notPresent entries
the table
A status of operational(2) indicates that
group is functioning, and a status
malfunctioning(3) indicates that the group
malfunctioning in some way."
::= { rptrGroupEntry 4 }
rptrGroupLastOperStatusChange OBJECT-
SYNTAX
ACCESS read-
STATUS
"An object that contains the value of sysUpTime
the time that the value of the
object for this group last changed
A value of zero indicates that the group's
status has not changed since the agent
restarted."
::= { rptrGroupEntry 5 }
rptrGroupPortCapacity OBJECT-
SYNTAX INTEGER (1..1024)
ACCESS read-
STATUS
"The rptrGroupPortCapacity is the number of
that can be contained within the group.
range is 1-1024. Within each group, the ports
uniquely numbered in the range from 1
rptrGroupPortCapacity
Note: In practice, this will generally be
number of ports on a module, card, or board,
the port numbers will correspond to numbers
on the physical embodiment."
"Reference IEEE 802.3 Rptr Mgt, 19.2.5.2,
aGroupPortCapacity."
::= { rptrGroupEntry 6 }
McMaster & McCloghrie [Page 19]
RFC 1368 802.3 Repeater MIB October 1992
--
-- The Basic Port
--
rptrPortTable OBJECT-
SYNTAX SEQUENCE OF
ACCESS not-
STATUS
"Table of descriptive and status information
the ports."
::= { rptrPortInfo 1 }
rptrPortEntry OBJECT-
SYNTAX
ACCESS not-
STATUS
"An entry in the table, containing
about a single port."
INDEX { rptrPortGroupIndex, rptrPortIndex }
::= { rptrPortTable 1 }
RptrPortEntry ::=
SEQUENCE {
INTEGER
INTEGER
INTEGER
INTEGER
}
rptrPortGroupIndex OBJECT-
SYNTAX INTEGER (1..1024)
ACCESS read-
STATUS
"This object identifies the group containing
port for which this entry contains information."
::= { rptrPortEntry 1 }
rptrPortIndex OBJECT-
SYNTAX INTEGER (1..1024)
McMaster & McCloghrie [Page 20]
RFC 1368 802.3 Repeater MIB October 1992
ACCESS read-
STATUS
"This object identifies the port within the
for which this entry contains information.
value can never be greater
rptrGroupPortCapacity for the associated group."
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aPortID."
::= { rptrPortEntry 2 }
rptrPortAdminStatus OBJECT-
SYNTAX INTEGER {
enabled(1),
disabled(2)
}
ACCESS read-
STATUS
"Setting this object to disabled(2) disables
port. A disabled port neither transmits
receives. Once disabled, a port must
explicitly enabled to restore operation. A
which is disabled when power is lost or when
reset is exerted shall remain disabled when
operation resumes
The admin status takes precedence over auto
partition and functionally operates between
auto-partition mechanism and the AUI/PMA
Setting this object to enabled(1) enables the
and exerts a BEGIN on the port's auto-
state machine
(In effect, when a port is disabled, the value
rptrPortAutoPartitionState for that port is
until the port is next enabled. When the
becomes enabled, the
becomes notAutoPartitioned(1), regardless of
pre-disabling state.)"
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aPortAdminState and 19.2.6.3, acPortAdminControl."
::= { rptrPortEntry 3 }
rptrPortAutoPartitionState OBJECT-
SYNTAX INTEGER {
McMaster & McCloghrie [Page 21]
RFC 1368 802.3 Repeater MIB October 1992
notAutoPartitioned(1),
autoPartitioned(2)
}
ACCESS read-
STATUS
"The autoPartitionState flag indicates whether
port is currently partitioned by the repeater'
auto-partition protection
The conditions that cause port partitioning
specified in partition state machine in Section 9
[IEEE 802.3 Std]. They are not
here."
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aAutoPartitionState."
::= { rptrPortEntry 4 }
rptrPortOperStatus OBJECT-
SYNTAX INTEGER {
operational(1),
notOperational(2),
notPresent(3)
}
ACCESS read-
STATUS
"This object indicates the port's
status. The notPresent(3) status indicates
port is physically removed (note this may or
not be possible depending on the type of port.)
The operational(1) status indicates that the
is enabled (see rptrPortAdminStatus) and working
even though it might be auto-partitioned (
rptrPortAutoPartitionState).
If this object has the value operational(1)
rptrPortAdminStatus is set to disabled(2), it
expected that this object's value will change
notOperational(2) soon after."
::= { rptrPortEntry 5 }
McMaster & McCloghrie [Page 22]
RFC 1368 802.3 Repeater MIB October 1992
--
-- The MONITOR
--
-- Implementation of this group is optional, but within
-- group all elements are mandatory. If a managed
-- implements any part of this group, the entire group
-- be implemented
--
-- Repeater Monitor
--
-- Performance monitoring statistics for the
--
rptrMonitorTransmitCollisions OBJECT-
SYNTAX
ACCESS read-
STATUS
"This counter is incremented every time
repeater state machine enters the
COLLISION state from any state other than ONE
LEFT (Ref: Fig 9-2, IEEE 802.3 Std).
The approximate minimum time for rollover of
counter is 16 hours."
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.2,
aTransmitCollisions."
::= { rptrMonitorRptrInfo 1 }
--
-- The Group Monitor
--
rptrMonitorGroupTable OBJECT-
SYNTAX SEQUENCE OF
ACCESS not-
STATUS
"Table of performance and error statistics for
groups."
::= { rptrMonitorGroupInfo 1 }
rptrMonitorGroupEntry OBJECT-
SYNTAX
McMaster & McCloghrie [Page 23]
RFC 1368 802.3 Repeater MIB October 1992
ACCESS not-
STATUS
"An entry in the table, containing
performance and error statistics for a
group. Regular retrieval of the information
this table provides a means of tracking
performance and health of the networked
attached to this group's ports
The counters in this table are redundant in
sense that they are the summations of
already available through other objects. However
these sums provide a considerable optimization
network management traffic over the
necessary retrieval of the individual
included in each sum."
INDEX { rptrMonitorGroupIndex }
::= { rptrMonitorGroupTable 1 }
RptrMonitorGroupEntry ::=
SEQUENCE {
INTEGER
Counter
Counter
}
rptrMonitorGroupIndex OBJECT-
SYNTAX INTEGER (1..1024)
ACCESS read-
STATUS
"This object identifies the group within
repeater for which this entry
information."
::= { rptrMonitorGroupEntry 1 }
rptrMonitorGroupTotalFrames OBJECT-
SYNTAX
ACCESS read-
STATUS
"The total number of frames of valid frame
McMaster & McCloghrie [Page 24]
RFC 1368 802.3 Repeater MIB October 1992
that have been received on the ports in
group. This counter is the summation of
values of the
counters for all of the ports in the group
This statistic provides one of the
necessary for obtaining the packet error rate
The approximate minimum time for rollover of
counter is 80 hours."
::= { rptrMonitorGroupEntry 2 }
rptrMonitorGroupTotalOctets OBJECT-
SYNTAX
ACCESS read-
STATUS
"The total number of octets contained in the
frames that have been received on the ports
this group. This counter is the summation of
values of the
counters for all of the ports in the group
This statistic provides an indicator of the
data transferred. The approximate minimum
for rollover of this counter is 58 minutes."
::= { rptrMonitorGroupEntry 3 }
rptrMonitorGroupTotalErrors OBJECT-
SYNTAX
ACCESS read-
STATUS
"The total number of errors which have occurred
all of the ports in this group. This counter
the summation of the values of
rptrMonitorPortTotalErrors counters for all of
ports in the group."
::= { rptrMonitorGroupEntry 4 }
--
-- The Port Monitor
--
rptrMonitorPortTable OBJECT-
SYNTAX SEQUENCE OF
ACCESS not-
STATUS
McMaster & McCloghrie [Page 25]
RFC 1368 802.3 Repeater MIB October 1992
"Table of performance and error statistics for
ports."
::= { rptrMonitorPortInfo 1 }
rptrMonitorPortEntry OBJECT-
SYNTAX
ACCESS not-
STATUS
"An entry in the table, containing performance
error statistics for a single port."
INDEX { rptrMonitorPortGroupIndex, rptrMonitorPortIndex }
::= { rptrMonitorPortTable 1 }
RptrMonitorPortEntry ::=
SEQUENCE {
INTEGER
INTEGER
Counter
Counter
Counter
Counter
Counter
Counter
Counter
Counter
Counter
Counter
Counter
Counter
}
McMaster & McCloghrie [Page 26]
RFC 1368 802.3 Repeater MIB October 1992
rptrMonitorPortGroupIndex OBJECT-
SYNTAX INTEGER (1..1024)
ACCESS read-
STATUS
"This object identifies the group containing
port for which this entry contains information."
::= { rptrMonitorPortEntry 1 }
rptrMonitorPortIndex OBJECT-
SYNTAX INTEGER (1..1024)
ACCESS read-
STATUS
"This object identifies the port within the
for which this entry contains information."
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aPortID."
::= { rptrMonitorPortEntry 2 }
rptrMonitorPortReadableFrames OBJECT-
SYNTAX
ACCESS read-
STATUS
"This object is the number of frames of
frame length that have been received on this port
This counter is incremented by one for each
received on this port whose OctetCount is
than or equal to minFrameSize and less than
equal to maxFrameSize (Ref: IEEE 802.3 Std
4.4.2.1) and for which the FCSError
CollisionEvent signals are not asserted
This statistic provides one of the
necessary for obtaining the packet error rate
The approximate minimum time for rollover of
counter is 80 hours."
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aReadableFrames."
::= { rptrMonitorPortEntry 3 }
rptrMonitorPortReadableOctets OBJECT-
SYNTAX
ACCESS read-
STATUS
McMaster & McCloghrie [Page 27]
RFC 1368 802.3 Repeater MIB October 1992
"This object is the number of octets contained
valid frames that have been received on this port
This counter is incremented by OctetCount for
frame received on this port which has
determined to be a readable frame
This statistic provides an indicator of the
data transferred. The approximate minimum
for rollover of this counter is 58 minutes."
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aReadableOctets."
::= { rptrMonitorPortEntry 4 }
rptrMonitorPortFCSErrors OBJECT-
SYNTAX
ACCESS read-
STATUS
"This counter is incremented by one for each
received on this port with the FCSError
asserted and the FramingError and
signals deasserted and whose OctetCount is
than or equal to minFrameSize and less than
equal to maxFrameSize (Ref: 4.4.2.1, IEEE 802.3
Std).
The approximate minimum time for rollover of
counter is 80 hours."
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aFrameCheckSequenceErrors."
::= { rptrMonitorPortEntry 5 }
rptrMonitorPortAlignmentErrors OBJECT-
SYNTAX
ACCESS read-
STATUS
"This counter is incremented by one for each
received on this port with the FCSError
FramingError signals asserted and
signal deasserted and whose OctetCount is
than or equal to minFrameSize and less than
equal to maxFrameSize (Ref: IEEE 802.3 Std
4.4.2.1). If rptrMonitorPortAlignmentErrors
incremented then the
McMaster & McCloghrie [Page 28]
RFC 1368 802.3 Repeater MIB October 1992
Counter shall not be incremented for the
frame
The approximate minimum time for rollover of
counter is 80 hours."
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aAlignmentErrors."
::= { rptrMonitorPortEntry 6 }
rptrMonitorPortFrameTooLongs OBJECT-
SYNTAX
ACCESS read-
STATUS
"This counter is incremented by one for each
received on this port whose OctetCount is
than maxFrameSize (Ref: 4.4.2.1, IEEE 802.3 Std).
If rptrMonitorPortFrameTooLongs is
then neither the
nor the rptrMonitorPortFCSErrors counter shall
incremented for the frame
The approximate minimum time for rollover of
counter is 61 days."
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aFramesTooLong."
::= { rptrMonitorPortEntry 7 }
rptrMonitorPortShortEvents OBJECT-
SYNTAX
ACCESS read-
STATUS
"This counter is incremented by one for
CarrierEvent on this port with
less than ShortEventMaxTime. ShortEventMaxTime
greater than 74 bit times and less than 82
times. ShortEventMaxTime has tolerances
to provide for circuit losses between
conformance test point at the AUI and
measurement point within the state machine
Note: shortEvents may indicate
generated noise hits which will cause the
to transmit Runts to its other ports, or
a collision (which may be late) back to
McMaster & McCloghrie [Page 29]
RFC 1368 802.3 Repeater MIB October 1992
transmitting DTE and damaged frames to the rest
the network
Implementors may wish to consider selecting
ShortEventMaxTime towards the lower end of
allowed tolerance range to accommodate bit
suffered through physical channel devices
budgeted for within this standard
The approximate minimum time for rollover of
counter is 16 hours."
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aShortEvents."
::= { rptrMonitorPortEntry 8 }
rptrMonitorPortRunts OBJECT-
SYNTAX
ACCESS read-
STATUS
"This counter is incremented by one for
CarrierEvent on this port that meets one of
following two conditions. Only one test need
made. a) The ActivityDuration is greater
ShortEventMaxTime and less than
and the CollisionEvent signal is deasserted. b
The OctetCount is less than 64,
ActivityDuration is greater than
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
but less than 82 bit times shall increment
the shortEvents counter or the runts counter
not both. A CarrierEvent greater than or equal
552 bit times but less than 565 bit times may
may not be counted as a runt
ValidPacketMinTime has tolerances included
provide for circuit losses between a
test point at the AUI and the measurement
within the state machine
Runts usually indicate collision fragments,
normal network event. In certain
associated with large diameter networks
McMaster & McCloghrie [Page 30]
RFC 1368 802.3 Repeater MIB October 1992
percentage of runts may exceed ValidPacketMinTime
The approximate minimum time for rollover of
counter is 16 hours."
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2, aRunts."
::= { rptrMonitorPortEntry 9 }
rptrMonitorPortCollisions OBJECT-
SYNTAX
ACCESS read-
STATUS
"This counter is incremented by one for
CarrierEvent signal on any port for which
CollisionEvent signal on this port is asserted
The approximate minimum time for rollover of
counter is 16 hours."
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aCollisions."
::= { rptrMonitorPortEntry 10 }
rptrMonitorPortLateEvents OBJECT-
SYNTAX
ACCESS read-
STATUS
"This counter is incremented by one for
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
ActivityDuration is greater than
LateEventThreshold. Such a CarrierEvent
counted twice, as both a collision and as
lateEvent
The LateEventThreshold is greater than 480
times and less than 565 bit times
LateEventThreshold has tolerances included
permit an implementation to build a
threshold to serve as both the
and ValidPacketMinTime threshold
The approximate minimum time for rollover of
counter is 81 hours."
McMaster & McCloghrie [Page 31]
RFC 1368 802.3 Repeater MIB October 1992
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aLateEvents."
::= { rptrMonitorPortEntry 11 }
rptrMonitorPortVeryLongEvents OBJECT-
SYNTAX
ACCESS read-
STATUS
"This counter is incremented by one for
CarrierEvent on this port whose
is greater than the MAU Jabber Lockup
timer TW3 (Ref: 9.6.1 & 9.6.5, IEEE 802.3 Std).
Other counters may be incremented as appropriate."
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aVeryLongEvents."
::= { rptrMonitorPortEntry 12 }
rptrMonitorPortDataRateMismatches OBJECT-
SYNTAX
ACCESS read-
STATUS
"This counter is incremented by one for each
received on this port that meets all of
following conditions: a) The
signal is not asserted. b) The
is greater than ValidPacketMinTime. c)
frequency (data rate) is detectably
from the local transmit frequency. The
degree of mismatch is vendor specific and is to
defined by the vendor for conformance testing
When this event occurs, other counters
increment conditions were satisfied may or may
also be incremented, at the implementor'
discretion. Whether or not the repeater was
to maintain data integrity is beyond the scope
this standard."
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aDataRateMismatches."
::= { rptrMonitorPortEntry 13 }
rptrMonitorPortAutoPartitions OBJECT-
SYNTAX
ACCESS read-
McMaster & McCloghrie [Page 32]
RFC 1368 802.3 Repeater MIB October 1992
STATUS
"This counter is incremented by one for each
the repeater has automatically partitioned
port. The conditions that cause port
are specified in the partition state machine
Section 9 [IEEE 802.3 Std]. They are
differentiated here."
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aAutoPartitions."
::= { rptrMonitorPortEntry 14 }
rptrMonitorPortTotalErrors OBJECT-
SYNTAX
ACCESS read-
STATUS
"The total number of errors which have occurred
this port. This counter is the summation of
values of other error counters (for the
port), namely
rptrMonitorPortFCSErrors
rptrMonitorPortAlignmentErrors
rptrMonitorPortFrameTooLongs
rptrMonitorPortShortEvents
rptrMonitorPortLateEvents
rptrMonitorPortVeryLongEvents,
rptrMonitorPortDataRateMismatches
This counter is redundant in the sense that it
the summation of information already
through other objects. However, it is
specifically because the regular retrieval of
object as a means of tracking the health of a
provides a considerable optimization of
management traffic over the otherwise
retrieval of the summed counters."
::= { rptrMonitorPortEntry 15 }
--
-- The ADDRESS TRACKING
--
-- Implementation of this group is optional; it is
-- for all systems which have the necessary metering. If
-- managed repeater implements any part of this group, the
McMaster & McCloghrie [Page 33]
RFC 1368 802.3 Repeater MIB October 1992
-- group shall be implemented
--
-- The Port Address Tracking
--
rptrAddrTrackTable OBJECT-
SYNTAX SEQUENCE OF
ACCESS not-
STATUS
"Table of address mapping information about
ports."
::= { rptrAddrTrackPortInfo 1 }
rptrAddrTrackEntry OBJECT-
SYNTAX
ACCESS not-
STATUS
"An entry in the table, containing address
information about a single port."
INDEX { rptrAddrTrackGroupIndex, rptrAddrTrackPortIndex }
::= { rptrAddrTrackTable 1 }
RptrAddrTrackEntry ::=
SEQUENCE {
INTEGER
INTEGER
MacAddress
}
rptrAddrTrackGroupIndex OBJECT-
SYNTAX INTEGER (1..1024)
ACCESS read-
STATUS
"This object identifies the group containing
port for which this entry contains information."
::= { rptrAddrTrackEntry 1 }
rptrAddrTrackPortIndex OBJECT-
SYNTAX INTEGER (1..1024)
McMaster & McCloghrie [Page 34]
RFC 1368 802.3 Repeater MIB October 1992
ACCESS read-
STATUS
"This object identifies the port within the
for which this entry contains information."
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aPortID."
::= { rptrAddrTrackEntry 2 }
rptrAddrTrackLastSourceAddress OBJECT-
SYNTAX
ACCESS read-
STATUS
"This object is the SourceAddress of the
readable frame (i.e., counted
rptrMonitorPortReadableFrames) received by
port."
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aLastSourceAddress."
::= { rptrAddrTrackEntry 3 }
rptrAddrTrackSourceAddrChanges OBJECT-
SYNTAX
ACCESS read-
STATUS
"This counter is incremented by one for each
that the rptrAddrTrackLastSourceAddress
for this port has changed
This may indicate whether a link is connected to
single DTE or another multi-user segment
The approximate minimum time for rollover of
counter is 81 hours."
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aSourceAddressChanges."
::= { rptrAddrTrackEntry 4 }
-- Traps for use by
-- Traps are defined using the conventions in RFC 1215 [8].
rptrHealth TRAP-
McMaster & McCloghrie [Page 35]
RFC 1368 802.3 Repeater MIB October 1992
ENTERPRISE snmpDot3
VARIABLES { rptrOperStatus }
"The rptrHealth trap conveys information
to the operational status of the repeater.
trap is sent only when the oper status of
repeater changes
The rptrHealth trap must contain
rptrOperStatus object. The agent may
include the rptrHealthText object in the
list. See the rptrOperStatus and
objects for descriptions of the information
is sent
The agent must throttle the generation
consecutive rptrHealth traps so that there is
least a five-second gap between them."
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4,
hubHealth notification."
::= 1
rptrGroupChange TRAP-
ENTERPRISE snmpDot3
VARIABLES { rptrGroupIndex }
"This trap is sent when a change occurs in
group structure of a repeater. This occurs
when a group is logically or physically
from or added to a repeater. The varBind
contains the identifier of the group that
removed or added
The agent must throttle the generation
consecutive rptrGroupChange traps for the
group so that there is at least a five-second
between them."
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4,
groupMapChange notification."
::= 2
rptrResetEvent TRAP-
ENTERPRISE snmpDot3
VARIABLES { rptrOperStatus }
"The rptrResetEvent trap conveys
McMaster & McCloghrie [Page 36]
RFC 1368 802.3 Repeater MIB October 1992
related to the operational status of the repeater
This trap is sent on completion of a
reset action. A repeater reset action is
as an a transition to the START state of Fig 9-2
in section 9 [IEEE 802.3 Std], when triggered by
management command (e.g., an SNMP Set on
rptrReset object).
The agent must throttle the generation
consecutive rptrResetEvent traps so that there
at least a five-second gap between them
The rptrResetEvent trap is not sent when the
restarts and sends an SNMP coldStart or
trap. However, it is recommended that a
agent send the rptrOperStatus object as
optional object with its coldStart and
trap PDUs
The rptrOperStatus object must be included in
varbind list sent with this trap. The agent
optionally include the rptrHealthText object
well."
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4,
notification."
::= 3
5.
This document is the work of the IETF Hub MIB Working Group. It
based on drafts of the IEEE 802.3 Repeater Management Task Force
Members of the working group included
Karl Auerbach karl@eng.sun.
Jim Barnes barnes@xylogics.
Steve Bostock steveb@novell.
David Bridgham dab@asylum.sf.ca.
Jack Brown jbrown@huahuca-emh8.army.
Howard Brown brown@ctron.
Lida Canin lida@apple.
Jeffrey Case case@cs.utk.
Carson Cheung carson@bnr.com.
James Codespote jpcodes@tycho.ncsc.
John Cook cook@chipcom.
Dave Cullerot cullerot@ctron.
McMaster & McCloghrie [Page 37]
RFC 1368 802.3 Repeater MIB October 1992
James Davin jrd@ptt.lcs.mit.
Gary Ellis garye@hpspd.spd.hp.
David Engel david@cds.
Mike Erlinger mike@mti.
Jeff
Bill Fardy fardy@ctron.
Jeff Fried jmf@relay.proteon.
Bob Friesenhahn pdrusa!bob@uunet.uu.
Shawn Gallagher gallagher@quiver.enet.dec.
Mike Grieves mgrieves@chipcom.
Walter Guilarte 70026.1715@compuserve.
Phillip Hasse phasse@honchuca-emh8.army.
Mark Hoerth mark_hoerth@hp0400.desk.hp.
Greg Hollingsworth gregh@mailer.jhuapl.
Ron Jacoby rj@sgi.
Mike Janson mjanson@mot.
Ken Jones konkord!ksj@uunet.uu.
Satish Joshi sjoshi@synoptics.
Frank Kastenholz kasten@europa.clearpoint.
Manu Kaycee kaycee@trlian.enet.dec.
Mark Kepke mak@cnd.hp.
Mark Kerestes att!alux2!hawk@uunet.uu.
Kenneth Key key@cs.utk.
Yoav Kluger ykluger@fibhaifa.
Cheryl Krupczak cheryl@cc.gatech.
Ron Lau rlau@synoptics.
Chao-Yu Liang cliang@synoptics.
Dave Lindemulder da@mtung.att.
Richie McBride rm@bix.co.
Keith McCloghrie kzm@hls.
Evan McGinnis bem@3com.
Donna McMaster mcmaster@synoptics.
David Minnich dwm@fibercom.
Lynn Monsanto monsanto@sun.
Miriam Nihart miriam@decwet.zso.dec.
Niels Ole Brunsgaard nob@dowtyns.
Edison Paw esp@3com.
David Perkins dperkins@synoptics.
Jason Perreault perreaul@interlan.interlan.
John Pickens jrp@3com.
Jim Reinstedler jimr@sceng.ub.
Anil Rijsinghani anil@levers.enet.dec.
Sam Roberts sroberts@farallon.
Dan Romascanu dan@lannet.
Marshall Rose mrose@dbc.mtview.ca.
Rick Royston rick@lsumus.sncc.lsu.
Michael Sabo sabo@dockmaster.ncsc.
Jonathan Saperia saperia@tcpjon.enet.dec.
McMaster & McCloghrie [Page 38]
RFC 1368 802.3 Repeater MIB October 1992
Mark Schaefer schaefer@davidsys.
Anil Singhal nsinghal@hawk.ulowell.
Timon Sloane peernet!timon@uunet.uu.
Bob Stewart rlstewart@eng.xyplex.
Emil Sturniolo emil@dss.
Bruce Taber taber@interlan.
Iris Tal 437-3580@mcimail.
Mark Therieau markt@python.eng.microcom.
Geoff Thompson thompson@synoptics.
Dean Throop throop@dg-rtp.dg.
Steven Waldbusser waldbusser@andrew.cmu.
Timothy Walden tmwalden@saturn.sys.acc.
Philip Wang watadn!phil@uunet.uu.
Drew Wansley dwansley@secola.columbia.ncr.
David Ward dward@chipcom.
Steve Wong wong@took.enet.dec.
Paul Woodruff paul-woodruff@3com.
Brian Wyld brianw@spider.co.
June-Kang Yang natadm!yang@uunet.uu.
Henry Yip natadm!henry@uunet.uu.
John Ziegler ziegler@artel.
Joseph Zur fibronics!zur@uunet.uu.
6.
[1] Rose M., and K. McCloghrie, "Structure and Identification
Management Information for TCP/IP-based internets", STD 16,
1155, Performance Systems International, Hughes LAN Systems,
1990.
[2] McCloghrie K., and M. Rose, "Management Information Base
Network Management of TCP/IP-based internets", RFC 1156,
LAN Systems, Performance Systems International, May 1990.
[3] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "
Network Management Protocol", STD 15, RFC 1157, SNMP Research
