Internet Draft 802.3 Repeater MIB 9 February 1992
Definitions of Managed Objects
for IEEE 802.3 Repeater Devices
9 February 1992
Donna McMaster
SynOptics Communications, Inc.
mcmaster@synoptics.com
Keith McCloghrie
Hughes LAN Systems, Inc.
kzm@hls.com
1. Abstract
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 repeaters, sometimes referred
to as "hubs."
2. Status of this Memo
This draft document will be submitted to the RFC editor as an
experimental extension to the SNMP MIB. Distribution of this
memo is unlimited. Please send comments to Donna McMaster
(mcmaster@synoptics.com) and Keith McCloghrie (kzm@hls.com).
McMaster/McCloghrie (editors) [Page 1]
Internet Draft 802.3 Repeater MIB 9 February 1992
3. Management Framework
The Internet-standard Network Management Framework consists of
three components. They are:
RFC 1155 which defines the SMI, the mechanisms used for
describing and naming objects for the purpose of management.
RFC 1212 defines a more concise description mechanism, which
is wholly consistent with the SMI.
RFC 1156 which defines MIB-I, the core set of managed objects
for the Internet suite of protocols. RFC 1213, defines MIB-II,
an evolution of MIB-I based on implementation experience and
new operational requirements.
RFC 1157 which defines the SNMP, the protocol used for network
access to managed objects.
The Framework permits new objects to be defined for the
purpose of experimentation and evaluation.
McMaster/McCloghrie (editors) [Page 2]
Internet Draft 802.3 Repeater MIB 9 February 1992
4. Objects
Managed objects are accessed via a virtual information store,
termed the Management Information Base or MIB. Objects in the
MIB are defined using the subset of Abstract Syntax Notation
One (ASN.1) [7] defined in the SMI. In particular, each object
has a name, a syntax, and an encoding. The name is an object
identifier, an administratively assigned name, which specifies
an object type. The object type together with an object
instance serves to uniquely identify a specific instantiation
of the object. For human convenience, we often use a textual
string, termed the OBJECT DESCRIPTOR, to also refer to the
object type.
The syntax of an object type defines the abstract data
structure corresponding to that object type. The ASN.1
language is used for this purpose. However, the SMI [3]
purposely restricts the ASN.1 constructs which may be used.
These restrictions are explicitly made for simplicity.
The encoding of an object type is simply how that object type
is represented using the object type's syntax. Implicitly tied
to the notion of an object type's syntax and encoding is how
the object type is represented when being transmitted on the
network.
The SMI specifies the use of the basic encoding rules of ASN.1
[8], subject to the additional requirements imposed by the
SNMP.
4.1. Format of Definitions
Section 6 contains the specification of all object types
contained in this MIB module. The object types are defined
using the conventions defined in the SMI, as amended by the
extensions specified in [9,10].
McMaster/McCloghrie (editors) [Page 3]
Internet Draft 802.3 Repeater MIB 9 February 1992
5. Overview
Instances of the object types defined in this memo represent
attributes of an IEEE 802.3 (Ethernet-like) repeater. This
type of repeater is defined by Section 9, "Repeater Unit for
10 Mb/s Baseband Networks" in the IEEE 802.3/ISO 8802-3
CSMA/CD standard [11].
These Repeater MIB objects may be used to manage non-standard
repeater-like devices, but defining objects to describe
implementation-specific properties of non-standard repeater-
like devices is outside the scope of this memo.
The definitions presented here are based on the IEEE draft
standard P802.3K, "Layer Management for 10 Mb/s Baseband
Repeaters." [13] It was originally based on Draft 3 [12],
which was the input to the July 1991 IEEE 802 plenary meeting,
and was modified to pick up a few minor technical
clarifications made during that meeting. Of particular
interest is Appendix B of that specification, which provides
an example of how the main body of the standard could be
translated to meet the requirements of the SNMP SMI.
Since that time both IEEE and IETF drafts has been modified.
See Section 7, IEEE Convergence, for details of similarities
and differences between this work and the latest IEEE draft.
Implementors of these MIB objects should note that the IEEE
document [13] explicitly describes when, where, and how
various repeater attributes are measured. The IEEE document
also describes the effects of repeater actions that may be
invoked by manipulating instances of the MIB objects defined
here.
5.1. Terminology
5.1.1. Repeaters, Hubs and Concentrators
In late 1988, the IEEE 802.3 Hub Management task force was
chartered to define managed objects for both 802.3 repeaters
and the proposed 10BASE-FA synchronous active stars. The term
"hub" was used to cover both repeaters and active stars. In
March, 1991, the active star proposal was dropped from the
10BASE-F draft, and now the 802.3 Hub Mgmt work covers only
repeaters.
McMaster/McCloghrie (editors) [Page 4]
Internet Draft 802.3 Repeater MIB 9 February 1992
The use of the term "hub" led to some confusion, as the terms
"hub," "intelligent hub," and "concentrator" are used in other
contexts to indicate a modular chassis with plug-in modules
that provide 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 avoid this naming confusion, the editors of this MIB
definitions document chose to call this a "Repeater MIB"
instead of a "Hub MIB."
Likewise, in November, 1991, the 802.3 Hub Mgt task force
voted to replace the term "hub" with "repeater" in their
proposed standard. In addition, they agreed to change the name
of their task force and standard to match. (There are
currently no plans to change the name of the IETF Hub MIB
Working Group or mailing list.)
5.1.2. Repeaters, Ports, and MAUs
The following text roughly defines the terms "repeater,"
"port," and "MAU" as used in the context of this memo. This
text is imprecise and omits many technical details. For a more
complete and precise definition of these terms, refer to
Section 9 of [11].
An IEEE 802.3 repeater connects "Ethernet-like" media segments
together to extend the network length and topology beyond what
can be achieved with a single coax segment. It can be pictured
as a star structure with two or more input/output ports. The
diagram below illustrates a 6-port repeater:
^ ^
| |
\ \ / /
\ \ / /
_____\ v /_____
-> ______ ______ ->
/ ^ \
/ / \ \
/ / \ \
| |
v v
Repeater Unit
McMaster/McCloghrie (editors) [Page 5]
Internet Draft 802.3 Repeater MIB 9 February 1992
All the stations on the media segments connected to a given
repeater's ports participate in a single collision domain. A
packet transmitted by any of these stations is seen by all of
these stations.
Data coming in on any port in the repeater is transmitted out
through each of the remaining n-1 ports. If data comes in to
the repeater on two or more ports simultaneously or the
repeater detects a collision on the incoming port, the
repeater transmits a jamming signal out on all ports for the
duration of the collision.
A repeater is a bit-wise store-and-forward device. It is
differentiated from a bridge (a frame store-and-forward
device) in that it is primarily concerned with carrier sense
and data bits, and does not make data-handling decisions based
on the legality or contents of a packet. A repeater
retransmits data bits as they are received. Its data FIFO
holds only enough bits to make sure that the FIFO does not
underflow when the data rate of incoming bits is slightly
slower than the repeater's transmission rate.
A repeater is not an end-station on the network, and does not
count toward the overall limit of 1024 stations. A repeater
has no MAC address associated with it, and therefore packets
may not be addressed to the repeater or to its ports. (Packets
may be addressed to the MAC address of a management entity
that is monitoring a repeater. This management entity may or
may not be connected to the network through one of the
repeater's ports. How the management entity obtains
information about the activity on the repeater is an
implementation issue, and is not discussed in this memo.)
A repeater is connected to the network with Medium Attachment
Units (MAUs), and sometimes through Attachment Unit Interfaces
(AUIs) as well. ("MAUs" are also known as transceivers, and an
"AUI" is the 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 the physical media interfaces. The MAUs may
be physically separate from the repeater unit, or they may be
McMaster/McCloghrie (editors) [Page 6]
Internet Draft 802.3 Repeater MIB 9 February 1992
integrated into the same physical package.
(MAU) (MAU)
\ \ / /
\ \ / /
_____\ v /_____
(MAU) ______ ______ (MAU)
/ ^ \
/ / \ \
/ / \ \
(MAU) (MAU)
Repeater Set
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, which is being combined into the 10BASE-F
standard as 10BASE-FL). The draft 10BASE-F standard also
includes the definition for a new synchronous fiber optic
attachment, known as 10BASE-FB.
It should be stressed that the hub MIB being defined by the
IEEE covers only the repeater unit management - it does not
include management of the MAUs that form the repeater set.
This memo follows the same strategy. The IEEE recognizes that
MAU management should be the same for MAUs connected to
stations (DTEs) as it is for MAUs connected to repeaters.
Defining management information for MAUs has been discussed in
IEEE 802.3, and is on the agenda for the next meeting.
5.1.3. Ports and Groups
Repeaters are often implemented in modular "concentrators,"
where a card cage holds several field-replaceable cards.
Several cards may form a single repeater unit, with each card
containing one or more of the repeater's ports. Because of
this modular architecture, users typically identify these
repeater ports with a card number plus the port number
relative to the card, e.g., Card 3, Port 11.
To support this modular numbering scheme, this document
follows the example of the IEEE Repeater Mgmt drafts [12,13],
allowing an implementor to separate the ports in a repeater
into "groups", if desired. For example, an implementor might
McMaster/McCloghrie (editors) [Page 7]
Internet Draft 802.3 Repeater MIB 9 February 1992
choose to represent field-replaceable units as groups of ports
so that the port numbering would match the modular hardware
implementation.
This group mapping is recommended but optional. An implementor
may 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 physical divisions.
The object rptrGroupCapacity indicates the maximum number of
groups that a given repeater may contain, and no group number
shall exceed the value of rptrGroupCapacity for its repeater.
Groups within a repeater may be sparsely numbered. For
example, in a 12-card cage, cards 3, 5, 6, and 7 may together
form a single repeater, and the implementor may choose to
number them as groups 3, 5, 6, and 7, respectively.
The value of rptrGroupCapacity must remain constant from one
management restart to the next.
The object rptrGroupPortCapacity indicates the maximum number
of ports that a given group may contain, and no port number
shall exceed the value of rptrGroupPortCapacity for its group.
As with groups within a repeater, ports within a group may be
sparsely numbered.
Groups may come and go without causing a management reset. The
value of rptrGroupPortCapacity must not change for a given
group. However, a group may be deleted from the repeater and
replaced with a group containing a different number of ports.
The value of rptrGroupUpTime will indicate that a change took
place.
Likewise, ports may come and go within a group without causing
a management reset.
In summary, each group within the repeater is uniquely
identified by a group number. Group numbers are in the range
1..rptrGroupCapacity, which has a maximum value of 1024. Each
port within the repeater is uniquely identified by a
combination of group number and port number. Ports in a group
are numbered from 1 to rptrGroupPortCapacity, which also has a
McMaster/McCloghrie (editors) [Page 8]
Internet Draft 802.3 Repeater MIB 9 February 1992
maximum value of 1024.
5.2. Supporting Functions
The IEEE 802.3 Hub Management draft [12] defines the following
five functions that are used in describing precisely when port
counters are incremented. The figure below illustrates the
relationships between the five functions.
Note: The IEEE group has modified this section of their
document. This text will be similarly updated after their
confirmation ballot has been resolved.
Note that the FramingError, ActivityDuration, OctetCount,
FCSError, and SourceAddress variables defined here are not
directly available in the MIB definitions that follow, but
rather are concepts used in defining the MIB objects.
+--------------------> FramingError
| +-----------+
| | Cyclic |
| | Redundancy|
| +->| Check |-> FCSError
| | | Function |
| | +-----------+
decoded +----------+ | | +-----------+
data --->| Framing |--+ | | Octet |
+->| Function |------+->| Counting |-> OctetCount
| +----------+octet | | Function |
| stream | +-----------+
| | +-----------+
| | | Source |
| +->| Address |-> SourceAddress
| | Function |
| +-----------+
| +-----------+
carrier| | Activity |
sense -+---------------------->| Timing |-> ActivityDuration
| Function |
+-----------+
Framing Function: The framing function recognizes the
boundaries of an incoming frame by monitoring the carrier
sense signal and the decoded data stream. Data bits are
accepted while the carrier sense signal is asserted. The
McMaster/McCloghrie (editors) [Page 9]
Internet Draft 802.3 Repeater MIB 9 February 1992
framing function strips preamble and start of frame fields
from the received data stream. The remaining bits are aligned
along octet boundaries. If there are not an integral number of
octets, then FramingError shall be asserted.
Activity Timing Function: The activity timing function
measures the duration of the assertion of the carrier sense
variable. The output of the timing function is expressed in
units of time with the ActivityDuration value.
Octet Counting Function: The octet counting function counts
the number of octets received from the output of the framing
function. The output of the octet counting function is the
OctetCount value.
Cyclic Redundancy Check Function: The cyclic redundancy check
function verifies that the sequence of octets output by the
framing function contains a valid frame check sequence field.
The frame check sequence field is the last four octets
received from the output of the framing function. The
algorithm for generating an FCS from the octet stream is
specified in 3.2.8 [11]. If the FCS generated according to
this algorithm is not the same as the last four octets
received from the framing function then FCSError is asserted.
Source Address Function: The source address function extracts
octets from the stream output by the framing function. The
seventh through twelfth octets shall be extracted from the
octet stream and output as the SourceAddress variable.
5.3. Structure of MIB
Objects in this MIB are arranged into MIB groups. Each MIB
group is organized as a set of related objects.
5.3.1. The Basic Group Definitions
This mandatory group contains the objects which are applicable
to all repeaters. It contains status, parameter and control
objects for the repeater as a whole, the port groups within
McMaster/McCloghrie (editors) [Page 10]
Internet Draft 802.3 Repeater MIB 9 February 1992
the repeater, as well as for the individual ports themselves.
5.3.2. The Monitor Group Definitions
This optional group contains monitoring statistics for the
repeater as a whole and for individual ports.
5.3.3. The Address Tracking Group Definitions
This optional group contains objects for tracking the MAC
addresses of the DTEs attached to the ports of the repeater.
5.4. Relationship to Other MIBs
It is assumed that a repeater implementing this MIB will also
implement (at least) the 'system' group defined in MIB-II [6].
5.4.1. Relationship to the 'system' group
In MIB-II, the 'system' group is defined as being mandatory
for all systems such that each managed entity contains one
instance of each object in the 'system' group. Thus, those
objects apply to the entity even if the entity's sole
functionality is management of a repeater.
5.4.2. Relationship to the 'interfaces' group
In MIB-II, the 'interfaces' group is defined as being
mandatory for all systems and contains information on an
entity's interfaces, where each interface is thought of as
being attached to a 'subnetwork'. (Note that this term is not
to be confused with 'subnet' which refers to an addressing
partitioning scheme used in the Internet suite of protocols.)
This Repeater MIB uses the notion of ports on a repeater. The
concept of a MIB-II interface has NO specific relationship to
a repeater's port. Therefore, the 'interfaces' group applies
only to the one (or more) network interfaces on which the
entity managing the repeater sends and receives management
protocol operations, and does not apply to the repeater's
ports.
This is consistent with the physical-layer nature of a
repeater. A repeater is a bitwise store-and-forward device. It
recognizes activity and bits, but does not process incoming
McMaster/McCloghrie (editors) [Page 11]
Internet Draft 802.3 Repeater MIB 9 February 1992
data based on any packet-related information (such as checksum
or addresses). A repeater has no MAC address, no MAC
implementation, and does not pass packets up to higher-level
protocol entities for processing.
(When a network management entity is observing the repeater,
it may appear as though the repeater is passing packets to a
higher-level protocol entity. However, this is only a means of
implementing management, and this passing of management
information is not part of the repeater functionality.)
5.5. Textual Conventions
The datatype MacAddress is used as a textual convention in
this document. This textual convention has NO effect on either
the syntax nor the semantics of any managed object. Objects
defined using this convention are always encoded by means of
the rules that define their primitive type. Hence, no changes
to the SMI or the SNMP are necessary to accommodate this
textual convention which is adopted merely for the convenience
of readers.
McMaster/McCloghrie (editors) [Page 12]
Internet Draft 802.3 Repeater MIB 9 February 1992
6. Definitions
SNMP-REPEATER-MIB DEFINITIONS ::= BEGIN
IMPORTS
experimental, Counter, TimeTicks FROM RFC1155-SMI
DisplayString FROM RFC1213-MIB
OBJECT-TYPE FROM RFC-1212;
-- All representations of MAC addresses in this MIB Module use,
-- as a textual convention (i.e. this convention does not affect
-- their encoding), the data type:
MacAddress ::= OCTET STRING (SIZE (6)) -- a 6 octet address in
-- the "canonical" order
-- defined by IEEE 802.1a, i.e., as if it were transmitted least
-- significant bit first.
--
-- 16-bit addresses, if needed, are represented by setting their
-- upper 4 octets to all 0's, i.e., AAFF would be represented
-- as 00000000AAFF.
snmpDot3RptrMgt OBJECT IDENTIFIER ::= { experimental 29 }
-- groups in the SNMP Repeater Mib
-- the rptrBasicPackage group is mandatory,
-- the others optional
rptrBasicPackage
OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 1 }
rptrMonitorPackage
OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 2 }
rptrAddrTrackPackage
OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 3 }
-- object identifiers for organizing the information
-- in the groups by repeater, port-group, and port
rptrRptrInfo
OBJECT IDENTIFIER ::= { rptrBasicPackage 1 }
rptrGroupInfo
McMaster/McCloghrie (editors) [Page 13]
Internet Draft 802.3 Repeater MIB 9 February 1992
OBJECT IDENTIFIER ::= { rptrBasicPackage 2 }
rptrPortInfo
OBJECT IDENTIFIER ::= { rptrBasicPackage 3 }
rptrMonitorRptrInfo
OBJECT IDENTIFIER ::= { rptrMonitorPackage 1 }
rptrMonitorGroupInfo -- this subtree is not currently used
OBJECT IDENTIFIER ::= { rptrMonitorPackage 2 }
rptrMonitorPortInfo
OBJECT IDENTIFIER ::= { rptrMonitorPackage 3 }
rptrAddrTrackRptrInfo -- this subtree is not currently used
OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 1 }
rptrAddrTrackGroupInfo -- this subtree is not currently used
OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 2 }
rptrAddrTrackPortInfo
OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 3 }
-- The Basic Group
-- Implementation of the Basic Group is mandatory for all
-- managed repeaters.
--
-- Basic Repeater Information
--
-- Configuration, status, and control objects for the overall
-- repeater
rptrGroupCapacity OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The rptrGroupCapacity is the number of groups
that can be contained within the repeater. Within
each managed repeater, the groups are uniquely
numbered in the range from 1 to rptrGroupCapacity.
Some groups may not be present in a given repeater
instance, in which case the actual number of
groups present will be less than
rptrGroupCapacity. The number of groups present
will never be greater than rptrGroupCapacity.
McMaster/McCloghrie (editors) [Page 14]
Internet Draft 802.3 Repeater MIB 9 February 1992
Note: In practice, this will generally be the
number of field-replaceable units (i.e., modules,
cards, or boards) that can fit in the physical
repeater enclosure, and the group numbers will
correspond to numbers marked on the physical
enclosure."
REFERENCE
"Reference [12] 19.2.3.2, hubGroupCapacity."
::= { rptrRptrInfo 1 }
rptrOperState OBJECT-TYPE
SYNTAX INTEGER {
other(1), -- undefined or unknown state
ok(2), -- no known failures
rptrFailure(3), -- repeater-related failure
groupFailure(4), -- group-related failure
portFailure(5), -- port-related failure
generalFailure(6) -- failure, unspecified type
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The rptrOperState object indicates the
operational state of the repeater. The
rptrHealthText object may be consulted for more
specific information about the state of the
repeater's health.
In the case of multiple kinds of failures (e.g.,
repeater failure and port failure), the value of
this attribute shall reflect the highest priority
failure in the following order:
rptrFailure(3)
groupFailure(4)
portFailure(5)
generalFailure(6)"
REFERENCE
"Reference [12] 19.2.3.2, hubHealthState."
::= { rptrRptrInfo 2 }
rptrHealthText OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-only
STATUS mandatory
DESCRIPTION
McMaster/McCloghrie (editors) [Page 15]
Internet Draft 802.3 Repeater MIB 9 February 1992
"The health text object is a text string that
provides information relevant to the operational
state of the repeater. Agents may use this
mechanism to provide detailed failure information
or instructions for problem resolution. The
contents are agent-specific."
REFERENCE
"Reference [12] 19.2.3.2, hubHealthText."
::= { rptrRptrInfo 3 }
rptrReset OBJECT-TYPE
SYNTAX INTEGER {
noReset(1),
reset(2)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Setting this variable to reset(2) causes a
transition to the START state of Fig 9-2 in
section 9 [11].
Setting this variable to noReset(1) has no effect.
The agent will always return the value noReset(1)
when this variable is read.
This action does not reset the management counters
defined in this document nor does it affect the
portAdminState parameters. Included in this action
is the execution of a disruptive Self-Test. As a
result of this action a rptrReset trap may be
sent.
Note: This action may result in the loss of
packets."
REFERENCE
"Reference [12] 19.2.3.3, resetHubAction."
::= { rptrRptrInfo 4 }
rptrNonDisruptTest OBJECT-TYPE
SYNTAX INTEGER {
noSelfTest(1),
selfTest(2)
}
ACCESS read-write
McMaster/McCloghrie (editors) [Page 16]
Internet Draft 802.3 Repeater MIB 9 February 1992
STATUS mandatory
DESCRIPTION
"Setting this variable to selfTest(2) causes the
repeater to perform a agent-specific, non-
disruptive self-test that has the following
characteristics: (1) The nature of the tests is
not specified. (2) The test does not change the
state of the repeater or management information
about the repeater. (3) The test does not inject
packets onto any segment. (4) The test does not
prevent the relay of any packets. (5) The test
does not interfere with management functions.
After performing this test the agent will update
the repeater health information. If a change in
the repeater health has occurred, the agent will
send a rptrHealth trap.
Setting this variable to noSelfTest(1) has no
effect. The agent will always return the value
noSelfTest(1) when this variable is read."
REFERENCE
"Reference [12] 19.2.3.3, executeSelfTest1Action."
::= { rptrRptrInfo 5 }
--
-- The Basic Port Group Table
--
rptrGroupTable OBJECT-TYPE
SYNTAX SEQUENCE OF RptrGroupEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Table of descriptive and status information about
the groups of ports."
::= { rptrGroupInfo 1 }
rptrGroupEntry OBJECT-TYPE
SYNTAX RptrGroupEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the table, containing information
about a single group of ports."
McMaster/McCloghrie (editors) [Page 17]
Internet Draft 802.3 Repeater MIB 9 February 1992
INDEX { rptrGroupIndex }
::= { rptrGroupTable 1 }
RptrGroupEntry ::=
SEQUENCE {
rptrGroupIndex
INTEGER,
rptrGroupDescr
DisplayString,
rptrGroupObjectID
OBJECT IDENTIFIER,
rptrGroupOperState
INTEGER,
rptrGroupUpTime
TimeTicks,
rptrGroupPortCapacity
INTEGER
}
rptrGroupIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This variable identifies the group within the
repeater for which this entry contains
information. This value is never greater than
rptrGroupCapacity."
REFERENCE
"Reference [12] 19.2.5.2, groupID."
::= { rptrGroupEntry 1 }
rptrGroupDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"A textual description of the group. This value
should include the full name and version
identification of the group's hardware type and
indicate how the group is differentiated from
other groups in the repeater. 'Wilma Flintstone
6-Port FOIRL Plug-in Module, Rev A' or 'Barney
Rubble 10BASE-T 4-port SIMM socket V. 2.1' are
examples of valid group descriptions.
McMaster/McCloghrie (editors) [Page 18]
Internet Draft 802.3 Repeater MIB 9 February 1992
It is mandatory that this only contain printable
ASCII characters."
REFERENCE
"No reference (new object)."
::= { rptrGroupEntry 2 }
rptrGroupObjectID OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The vendor's authoritative identification of the
group. This value is allocated within the SMI
enterprises subtree (1.3.6.1.4.1) and provides a
straight-forward and unambiguous means for
determining what kind of group is being managed.
For example, this variable could take the value
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 identifier
1.3.6.1.4.1.4242.1.2.14 to its 'Wilma Flintstone
6-Port FOIRL Plug-in Module.'"
REFERENCE
"No reference (new object)."
::= { rptrGroupEntry 3 }
rptrGroupOperState OBJECT-TYPE
SYNTAX INTEGER {
other(1),
operational(2),
malFunctioning(3),
notPresent(4),
underTest(5),
resetInProgress(6)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"An object that indicates the operational status
of the group.
A status of notPresent(4) indicates that the group
has been physically removed from the repeater. A
status of operational(2) indicates that the group
McMaster/McCloghrie (editors) [Page 19]
Internet Draft 802.3 Repeater MIB 9 February 1992
is functioning, and a status of malFunctioning(3)
indicates that the group is malfunctioning in some
way."
REFERENCE
"No reference (new object)."
::= { rptrGroupEntry 4 }
rptrGroupUpTime OBJECT-TYPE
SYNTAX TimeTicks
ACCESS read-only
STATUS mandatory
DESCRIPTION
"An object that contains the value of sysUpTime at
the time that the management information relating
to this group was last reset.
A value of zero would indicate that the group was
present when the agent last restarted. A non-zero
value would indicate that the group had been added
to the repeater after the agent last restarted."
REFERENCE
"No reference (new object)."
::= { rptrGroupEntry 5 }
rptrGroupPortCapacity OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The rptrGroupPortCapacity is the number of ports
that can be contained within the group. Valid
range is 1-1024. Within each group, the ports are
uniquely numbered in the range from 1 to
rptrGroupPortCapacity.
Note: In practice, this will generally be the
number of ports on a module, card, or board, and
the port numbers will correspond to numbers marked
on the physical embodiment."
REFERENCE
"Reference [12] 19.2.5.2, numberOfPorts."
::= { rptrGroupEntry 6 }
McMaster/McCloghrie (editors) [Page 20]
Internet Draft 802.3 Repeater MIB 9 February 1992
--
-- The Basic Port Table
--
rptrPortTable OBJECT-TYPE
SYNTAX SEQUENCE OF RptrPortEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Table of descriptive and status information about
the ports."
::= { rptrPortInfo 1 }
rptrPortEntry OBJECT-TYPE
SYNTAX RptrPortEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the table, containing information
about a single port."
INDEX { rptrPortGroupIndex, rptrPortIndex }
::= { rptrPortTable 1 }
RptrPortEntry ::=
SEQUENCE {
rptrPortGroupIndex
INTEGER,
rptrPortIndex
INTEGER,
rptrPortAdminState
INTEGER,
rptrPortAutoPartitionState
INTEGER,
rptrPortOperState
INTEGER
}
rptrPortGroupIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This variable identifies the group containing the
port for which this entry contains information."
::= { rptrPortEntry 1 }
McMaster/McCloghrie (editors) [Page 21]
Internet Draft 802.3 Repeater MIB 9 February 1992
rptrPortIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This variable identifies the port within the
group within the repeater for which this entry
contains management information. This value can
never be greater than rptrGroupPortCapacity for
the associated group."
REFERENCE
"Reference [12] 19.2.6.2, portID."
::= { rptrPortEntry 2 }
rptrPortAdminState OBJECT-TYPE
SYNTAX INTEGER {
disabled(1),
enabled(2)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Setting this variable to disabled(1) disables the
port. A disabled port neither transmits nor
receives. Once disabled, a port must be
explicitly enabled to restore operation. A port
which is disabled when power is lost or when a
reset is exerted shall remain disabled when normal
operation resumes.
The admin state takes precedence over auto-
partition and functionally operates between the
auto-partition mechanism and the AUI/PMA.
Setting this variable to enabled(2) enables the
port and exerts a BEGIN on the port's auto-
partition state machine.
Note: What the above means is that when a port
becomes disabled, its current auto-partition state
is frozen until the port is next enabled. When the
port becomes enabled, the auto-partition state
becomes notAutoPartitioned, regardless of its
pre-disabling state. This text will be clarified
in the next draft."
McMaster/McCloghrie (editors) [Page 22]
Internet Draft 802.3 Repeater MIB 9 February 1992
REFERENCE
"Reference [12] 19.2.6.2, portAdminState and [12]
19.2.6.3, portAdminControl."
::= { rptrPortEntry 3 }
rptrPortAutoPartitionState OBJECT-TYPE
SYNTAX INTEGER {
autoPartitioned(1),
notAutoPartitioned(2)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The autoPartitionState flag indicates whether the
port is currently partitioned by the repeater's
auto-partition protection.
The conditions that cause port partitioning are
specified in partition state machine in Sect. 9
[11]. They are not differentiated here."
REFERENCE
"Reference [12] 19.2.6.2, autoPartitionState."
::= { rptrPortEntry 4 }
rptrPortOperState OBJECT-TYPE
SYNTAX INTEGER {
operational(1),
notOperational(2),
notPresent(3)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object indicates the port's operational
state. The notPresent(3) state indicates the port
is physically removed (note this may or may not be
possible depending on the type of port.) The
operational(1) state indicates that the port is
enabled (see rptrPortAdminState) and working, even
though it might be auto-partitioned (see
rptrPortAutoPartitionState)."
REFERENCE
"No reference (new object)."
::= { rptrPortEntry 5 }
McMaster/McCloghrie (editors) [Page 23]
Internet Draft 802.3 Repeater MIB 9 February 1992
--
-- The MONITOR GROUP
--
-- Implementation of this group is optional, but within the
-- group all elements are mandatory. If a managed repeater
-- implements any part of this group, the entire group shall
-- be implemented.
--
-- Repeater Monitor Information
--
-- Performance monitoring statistics for the repeater
--
rptrMonitorTransmitCollisions OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented every time the
repeater state machine enters the TRANSMIT
COLLISION state from any state other than ONE PORT
LEFT (Ref: Fig 9-2) [11].
Note: The approximate minimum time for counter
rollover is 16 hours."
REFERENCE
"Reference [12] 19.2.3.2, transmitCollisions."
::= { rptrMonitorRptrInfo 1 }
rptrMonitorMJLPs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The repeater MJLPs object counts the number of
times the repeater enters the DISABLE OUTPUT state
in the MAU Jabber Lockup Protection state diagram
(Fig. 9-5) [11].
Note: The approximate minimum time for counter
rollover is 200 days."
REFERENCE
"Reference [12] 19.2.3.2, repeaterMJLPs."
::= { rptrMonitorRptrInfo 2 }
McMaster/McCloghrie (editors) [Page 24]
Internet Draft 802.3 Repeater MIB 9 February 1992
--
-- The Port Monitor Table
--
rptrMonitorPortTable OBJECT-TYPE
SYNTAX SEQUENCE OF RptrMonitorPortEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Table of performance and error statistics for the
ports."
::= { rptrMonitorPortInfo 1 }
rptrMonitorPortEntry OBJECT-TYPE
SYNTAX RptrMonitorPortEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the table, containing performance and
error statistics for a single port."
INDEX { rptrMonitorPortGroupIndex, rptrMonitorPortIndex }
::= { rptrMonitorPortTable 1 }
RptrMonitorPortEntry ::=
SEQUENCE {
rptrMonitorPortGroupIndex
INTEGER,
rptrMonitorPortIndex
INTEGER,
rptrMonitorPortReadableFrames
Counter,
rptrMonitorPortReadableOctets
Counter,
rptrMonitorPortFCSErrors
Counter,
rptrMonitorPortAlignmentErrors
Counter,
rptrMonitorPortFrameTooLongs
Counter,
rptrMonitorPortShortEvents
Counter,
rptrMonitorPortRunts
Counter,
rptrMonitorPortCollisions
Counter,
McMaster/McCloghrie (editors) [Page 25]
Internet Draft 802.3 Repeater MIB 9 February 1992
rptrMonitorPortLateCollisions
Counter,
rptrMonitorPortDataRateMismatches
Counter,
rptrMonitorPortAutoPartitions
Counter,
rptrMonitorPortTotalErrors
Counter
}
rptrMonitorPortGroupIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Group Index for identifying the port."
::= { rptrMonitorPortEntry 1 }
rptrMonitorPortIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Port Index for identifying the port."
REFERENCE
"Reference [12] 19.2.6.2, portID."
::= { rptrMonitorPortEntry 2 }
rptrMonitorPortReadableFrames OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"A representation of the total frames of valid
frame length. This counter is incremented by one
for each frame whose OctetCount is greater than or
equal to minFrameSize and less than or equal to
maxFrameSize (Ref: 4.4.2.1 [11]) and for which
FCSError is not asserted.
Note: The approximate minimum time between
counter rollovers is 81 hours."
REFERENCE
"Reference [12] 19.2.6.2, readableFrames."
::= { rptrMonitorPortEntry 3 }
McMaster/McCloghrie (editors) [Page 26]
Internet Draft 802.3 Repeater MIB 9 February 1992
rptrMonitorPortReadableOctets OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Increment counter by OctetCount for each frame
which which has been determined to be a readable
frame.
Note: The approximate minimum time between
counter rollovers is 58 minutes."
REFERENCE
"Reference [12] 19.2.6.2, readableOctets."
::= { rptrMonitorPortEntry 4 }
rptrMonitorPortFCSErrors OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Increment counter by one for each frame with
FCSError and without FramingError and whose
OctetCount is greater than or equal to
minFrameSize and less than or equal to
maxFrameSize (Ref: 4.4.2.1 [11]).
Note: The approximate minimum time between
counter rollovers is 81 hours."
REFERENCE
"Reference [12] 19.2.6.2,
frameCheckSequenceErrors."
::= { rptrMonitorPortEntry 5 }
rptrMonitorPortAlignmentErrors OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Increment counter by one for each frame with
FCSError and FramingError and whose octetCount is
greater than or equal to minFrameSize and less
than or equal to maxFrameSize (Ref: 4.4.2.1 [11]).
Note: The approximate minimum time between
counter rollovers is 81 hours."
McMaster/McCloghrie (editors) [Page 27]
Internet Draft 802.3 Repeater MIB 9 February 1992
REFERENCE
"Reference [12] 19.2.6.2, alignmentErrors."
::= { rptrMonitorPortEntry 6 }
rptrMonitorPortFrameTooLongs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Increment counter by one for each frame whose
OctetCount is greater than maxFrameSize (Ref:
4.4.2.1 [11]).
Note: The approximate minimum time between
counter rollovers is 61 days."
REFERENCE
"Reference [12] 19.2.6.2, framesTooLong."
::= { rptrMonitorPortEntry 7 }
rptrMonitorPortShortEvents OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Increment counter by one for each carrier event
whose ActivityDuration is greater than
ShortEventMinTime and less than ShortEventMaxTime.
ShortEventMinTime represents any event of
sufficient duration to initiate transmission by a
repeater. ShortEventMaxTime is greater than 7.4uS
and less than 8.2uS. ShortEventMaxTime has
tolerances included to provide for circuit losses
between a conformance test point at the AUI and
the measurement point within the state machine.
Note: shortEvents may indicate an externally
generated noise hit which will cause the relay to
transmit Runts to its other ports, or propagate a
collision (which may be late) back to the
transmitting DTE and damaged frames to the rest of
the network. Such shortEvents are not a feature of
normal network activity. Also it should be noted
that a MAU that is attached to a coax segment may
have several carrier dropouts on the DI circuit
before the CI circuit is active and stable. Such
McMaster/McCloghrie (editors) [Page 28]
Internet Draft 802.3 Repeater MIB 9 February 1992
dropouts will increment the shortEvent counter but
are considered normal for a coax segment."
REFERENCE
"Reference [12] 19.2.6.2, shortEvents."
::= { rptrMonitorPortEntry 8 }
rptrMonitorPortRunts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Increment counter by one for each carrier event
whose ActivityDuration is greater than
ShortEventMaxTime and less than RuntMaxTime.
RuntMaxTime is greater than 53.2uS and less than
56.0uS.
An event whose length is greater than 7.4uS but
less than 8.2uS shall increment either the
ShortEvent object or the runts object but not
both.
A non-collision event greater than 53.2uS but less
than 56.0uS may or may not be counted as a runt.
A non-collision event greater than or equal to
56.0uS shall not be counted as a Runt.
RuntMaxTime has tolerances included to provide for
circuit losses between a conformance test point at
the AUI and the measurement point within the state
machine.
Note: Runts do not indicate a problem in the
network. The approximate minimum time for counter
rollover is 16 hours."
REFERENCE
"Reference [12] 19.2.6.2, runts."
::= { rptrMonitorPortEntry 9 }
rptrMonitorPortCollisions OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Increment counter by one for each carrier event
in which the CIPresent(X) variable has the value
McMaster/McCloghrie (editors) [Page 29]
Internet Draft 802.3 Repeater MIB 9 February 1992
SQE (see 9.6.6.2 [11]).
Note: The approximate minimum time for counter
rollover is 16 hours."
REFERENCE
"Reference [12] 19.2.6.2, collisions."
::= { rptrMonitorPortEntry 10 }
rptrMonitorPortLateCollisions OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Increment counter by one for each carrier event
in which the CIPresent(X) variable has the value
SQE (see 9.6.6.2 [11]) at any time when the
ActivityDuration is greater than the RuntMaxTime.
A late collision is counted twice, as both a
collision and as a late collision.
LateCollisionThreshold has tolerances included to
provide for circuit losses between a conformance
test point at the AUI and the measurement point
within the state machine.
Note: The approximate minimum time between
counter rollovers is 81 hours."
REFERENCE
"Reference [12] 19.2.6.2, lateCollisions."
::= { rptrMonitorPortEntry 11 }
rptrMonitorPortDataRateMismatches OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The dataRateMismatches object counts the number
of times that a packet has been received by this
port with the transmission frequency (data rate)
detectably mismatched from the local transmit
frequency. The exact degree is implementation-
specific and is to be defined by the implementor
for conformance testing.
Note: Whether or not the repeater was able to
McMaster/McCloghrie (editors) [Page 30]
Internet Draft 802.3 Repeater MIB 9 February 1992
maintain data integrity is beyond the scope of
this standard."
REFERENCE
"Reference [12] 19.2.6.2, dataRateMismatches."
::= { rptrMonitorPortEntry 12 }
rptrMonitorPortAutoPartitions OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The autoPartitions object counts the number of
times that the repeater has automatically
partitioned this port. The conditions that cause
port partitioning are specified in partition state
machine in Sect. 9 [11]. They are not
differentiated here.
Note: The approximate minimum time between
counter rollovers is 20 days."
REFERENCE
"Reference [12] 19.2.6.2, autoPartitions."
::= { rptrMonitorPortEntry 13 }
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 counters (for the same port),
namely:
To be determined.
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."
REFERENCE
McMaster/McCloghrie (editors) [Page 31]
Internet Draft 802.3 Repeater MIB 9 February 1992
"No reference (new object)."
::= { rptrMonitorPortEntry 14 }
McMaster/McCloghrie (editors) [Page 32]
Internet Draft 802.3 Repeater MIB 9 February 1992
--
-- The ADDRESS TRACKING GROUP
--
-- Implementation of this group is optional; it is appropriate
-- for all systems which have the necessary metering. 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
MacAddress,
rptrAddrTrackSourceAddrChanges
Counter
}
rptrAddrTrackGroupIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
McMaster/McCloghrie (editors) [Page 33]
Internet Draft 802.3 Repeater MIB 9 February 1992
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Group Index for identifying the port."
::= { rptrAddrTrackEntry 1 }
rptrAddrTrackPortIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Port index for identifying the port."
REFERENCE
"Reference [12] 19.2.6.2, portID."
::= { rptrAddrTrackEntry 2 }
rptrAddrTrackLastSourceAddress OBJECT-TYPE
SYNTAX MacAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The lastSourceAddress object is the source
address of the last readable frame (i.e., counted
by rptrMonitorPortReadableFrames) received by this
port."
REFERENCE
"Reference [12] 19.2.6.2, lastSourceAddress."
::= { rptrAddrTrackEntry 3 }
rptrAddrTrackSourceAddrChanges OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The rptrAddrTrackSourceAddressChanges object
counts the number of the times that the
rptrAddrTrackLastSourceAddress for this port has
changed.
Note: This may indicate whether a link is
connected to a single DTE or another multi-user
segment. The approximate minimum time for counter
rollover is 81 hours."
REFERENCE
"Reference [12] 19.2.6.2, sourceAddressChanges."
McMaster/McCloghrie (editors) [Page 34]
Internet Draft 802.3 Repeater MIB 9 February 1992
::= { rptrAddrTrackEntry 4 }
McMaster/McCloghrie (editors) [Page 35]
Internet Draft 802.3 Repeater MIB 9 February 1992
-- Traps for use by Repeaters
-- Traps are defined using the conventions in RFC 1215 [10].
rptrHealth TRAP-TYPE
ENTERPRISE snmpDot3RptrMgt
VARIABLES { rptrOperState }
DESCRIPTION
"The rptrHealth trap conveys information related
to the operational state of the repeater. This
trap is sent only when the oper status of the
repeater changes.
The rptrHealth trap must contain the rptrOperState
variable. The agent may optionally include the
rptrHealthText variable in the varBind list. See
the rptrOperState 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 them."
REFERENCE
"Reference [12] 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 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 them."
REFERENCE
"Reference [12] 19.2.3.4, groupMapChange
notification."
::= 2
McMaster/McCloghrie (editors) [Page 36]
Internet Draft 802.3 Repeater MIB 9 February 1992
rptrReset TRAP-TYPE
ENTERPRISE snmpDot3RptrMgt
VARIABLES { rptrOperState }
DESCRIPTION
"The rptrReset trap conveys information related to
the operational state 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 [11], when triggered by a management
command (e.g., an SNMP Set on the rptrReset
object).
The agent must throttle the generation of
consecutive rptrReset traps so that there is at
least a five-second gap between them.
The rptrReset 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 rptrHealth variables as optional
variables with its coldStart and warmStart trap
PDUs.
The rptrOperState variable must be included in the
varbind list sent with this trap. The agent may
optionally include the rptrHealthText variable as
well."
REFERENCE
"Reference [12] 19.2.3.4, hubReset notification."
::= 3
END
McMaster/McCloghrie (editors) [Page 37]
Internet Draft 802.3 Repeater MIB 9 February 1992
7. Convergence with IEEE
The main body of the drafts output by the IEEE 802.3 Repeater
Management Task Force [12,13] follows the ISO and 802.1
network management guidelines. The first draft of this
document was a faithful translation of [12] into the SNMP SMI
format.
In the process of translating the IEEE definitions into the
SNMP SMI, the editors of this document and members of the
hubmib working group identified some areas in which the ISO
management framework differs from the IETF/SNMP management
framework, implying additional changes needed in the SNMP
Repeater MIB structure.
It should be noted that the IETF SNMP Hub MIB Working Group
has consistently agreed that the technical counter definitions
in the SNMP MIB must follow those in the IEEE document, so
that vendor instrumentation need not be different.
The IEEE has just closed a confirmation ballot, and will be
meeting soon to resolve technical issues raised in the
balloting process. When these issues have been resolved, the
resulting counter definitions will be incorporated into this
IETF SNMP MIB.
7.1. Basic Repeater Information
The IETF SNMP Hub MIB Working Group omitted the following IEEE
objects from the basic repeater information:
groupMap: The group map information typically changes
infrequently, and can be obtained in a single powerful GetNext
PDU. Therefore, this object was deemed redundant and
unnecessary in the SNMP management framework.
rptrHealthData: The working group decided that this object
should be in vendor-specific MIBs, not in a standard, since it
McMaster/McCloghrie (editors) [Page 38]
Internet Draft 802.3 Repeater MIB 9 February 1992
cannot be decoded in a standard way.
7.2. Port Group Table
The working group omitted the following IEEE object from the
rptrGroupTable:
portMap: As with groupMap, above, the port map information
typically changes infrequently, and can be obtained in a
single powerful GetNext PDU. Therefore, this object was
deemed redundant and unnecessary in the SNMP management
framework.
The working group added the following objects to the
rptrGroupTable:
rptrGroupDescr: a DisplayString to describe the nature of the
port group.
rptrGroupObjectId: an OBJECT IDENTIFIER, allocated from the
vendor's enterprises subtree, to uniquely identify the port
group.
rptrGroupUpTime: a TimeTicks-valued object containing the
value of sysUpTime at the time that the management information
relating to this group was last reset. A non-zero value would
indicate that the group had been added to the repeater after
the agent last restarted.
rptrGroupOperState: an enumerated integer, indicating the
operational state of the group.
7.3. Port Table
The working group added the following object to the
rptrPortTable:
rptrPortOperState: an enumerated integer, indicating the
McMaster/McCloghrie (editors) [Page 39]
Internet Draft 802.3 Repeater MIB 9 February 1992
operational state of the port.
7.4. Traps
The overlap between the rptrReset trap and the SNMP standard
cold start and warm start traps was examined and clarified.
Because the rptrReset trap refers only to the reset of the
repeater state machine, it does not imply that management was
reset. The rptrReset trap can be sent independently of cold
start or warm start traps. However, the editors agreed that
repeater agents should not send the rptrReset trap at the same
time as the cold start or warm start traps are sent. The
repeater health parameters can be included in the cold start
or warm start trap, making the rptrReset trap unnecessary
and/or redundant.
The frequency at which all of the traps could be generated was
examined as well, and the description text for these traps was
modified to specify a minimum time interval between generation
of two traps of the same type.
McMaster/McCloghrie (editors) [Page 40]
Internet Draft 802.3 Repeater MIB 9 February 1992
8. Open Issues
This document has been updated in accordance with the
decisions made at the November meeting of the Hub MIB working
group in Santa Fe. On several issues, the meeting agreed to
general guidelines, rather than detailed direction. This
section details those issues for which the editors either made
detailed decisions, or are still looking for feedback from the
working group before making detailed decisions.
The editors encourage the Hub MIB working group to discuss
these issues on the mailing list, so that they can be resolved
before the next working group meeting. When this section is
empty, it will be time to forward this document.
8.1. rptrGroupOperState
Additional enumerated values have been added to the
rptrGroupOperState object. The editors believe these are in
accordance with the discussion at the Santa Fe meeting.
8.2. rptrPortOperState
The rptrPortOperState object has been added. The editors
believe the enumerated values are in accordance with the
discussion at the Santa Fe meeting.
8.3. Total Counters
The Santa Fe meeting agreed that the addition of total
counters is appropriate for some information. The example
cited was error counters which need to be collected frequently
in order to track the health of the network, especially
considering it is not unusual for a single repeater to have
over 100 ports, causing high collection overhead.
One such counter, rptrMonitorPortTotalErrors, has been added.
The specific errors which are included in this counter are yet
to be determined.
McMaster/McCloghrie (editors) [Page 41]
Internet Draft 802.3 Repeater MIB 9 February 1992
9. 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.
McMaster/McCloghrie (editors) [Page 42]
Internet Draft 802.3 Repeater MIB 9 February 1992
10. References
[1] V. Cerf, IAB Recommendations for the Development of
Internet Network Management Standards. Internet Working
Group Request for Comments 1052. Network Information
Center, SRI International, Menlo Park, California,
(April, 1988).
[2] V. Cerf, Report of the Second Ad Hoc Network Management
Review Group, Internet Working Group Request for Comments
1109. Network Information Center, SRI International,
Menlo Park, California, (August, 1989).
[3] M.T. Rose and K. McCloghrie, Structure and Identification
of Management Information for TCP/IP-based internets,
Internet Working Group Request for Comments 1155.
Network Information Center, SRI International, Menlo
Park, California, (May, 1990).
[4] K. McCloghrie and M.T. Rose, Management Information Base
for Network Management of TCP/IP-based internets,
Internet Working Group Request for Comments 1156.
Network Information Center, SRI International, Menlo
Park, California, (May, 1990).
[5] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin,
Simple Network Management Protocol, Internet Working
Group Request for Comments 1157. Network Information
Center, SRI International, Menlo Park, California, (May,
1990).
[6] K. McCloghrie and M.T. Rose (editors), Management
Information Base for Network Management of TCP/IP-based
internets: MIB-II, Internet Working Group Request for
Comments 1213. Network Information Center, SRI
International, Menlo Park, California, (March, 1991).
[7] Information processing systems - Open Systems
Interconnection - Specification of Abstract Syntax
Notation One (ASN.1), International Organization for
Standardization. International Standard 8824, (December,
1987).
[8] Information processing systems - Open Systems
Interconnection - Specification of Basic Encoding Rules
McMaster/McCloghrie (editors) [Page 43]
Internet Draft 802.3 Repeater MIB 9 February 1992
for Abstract Notation One (ASN.1), International
Organization for Standardization. International Standard
8825, (December, 1987).
[9] M.T. Rose, K. McCloghrie (editors), Concise MIB
Definitions, Internet Working Group Request for Comments
1212. Network Information Center, SRI International,
Menlo Park, California, (March, 1991).
[10] M.T. Rose (editor), A Convention for Defining Traps for
use with the SNMP, Internet Working Group Request for
Comments 1215. Network Information Center, SRI
International, Menlo Park, California, (March, 1991).
[11] 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, Sept. 21,
1990).
[12] IEEE P802.3K, "Layer Management for Hub Devices", Draft
Supplement to ANSI/IEEE 802.3, (Draft 3, May 30, 1991).
[13] IEEE P802.3K, "Layer Management for 10 Mb/s Baseband
Repeaters, Section 19," Draft Supplement to ANSI/IEEE
802.3, (Draft 5, December 22, 1991).
McMaster/McCloghrie (editors) [Page 44]
Internet Draft 802.3 Repeater MIB 9 February 1992
Table of Contents
1 Abstract .............................................. 1
2 Status of this Memo ................................... 1
3 Management Framework .................................. 2
4 Objects ............................................... 3
4.1 Format of Definitions ............................... 3
5 Overview .............................................. 4
5.1 Terminology ......................................... 4
5.1.1 Repeaters, Hubs and Concentrators ................. 4
5.1.2 Repeaters, Ports, and MAUs ........................ 5
5.1.3 Ports and Groups .................................. 7
5.2 Supporting Functions ................................ 9
5.3 Structure of MIB .................................... 10
5.3.1 The Basic Group Definitions ....................... 10
5.3.2 The Monitor Group Definitions ..................... 11
5.3.3 The Address Tracking Group Definitions ............ 11
5.4 Relationship to Other MIBs .......................... 11
5.4.1 Relationship to the 'system' group ................ 11
5.4.2 Relationship to the 'interfaces' group ............ 11
5.5 Textual Conventions ................................. 12
6 Definitions ........................................... 13
6.1 Groups in the Repeater MIB .......................... 13
6.2 The Basic Group Definitions ......................... 14
6.3 The Monitor Group Definitions ....................... 24
6.4 The Address Tracking Group Definitions .............. 33
6.5 Traps for use by Repeaters .......................... 36
7 Convergence with IEEE ................................. 38
7.1 Basic Repeater Information .......................... 38
7.2 Port Group Table .................................... 39
7.3 Port Table .......................................... 39
7.4 Traps ............................................... 40
8 Open Issues ........................................... 41
8.1 rptrGroupOperState .................................. 41
8.2 rptrPortOperState ................................... 41
8.3 Total Counters ...................................... 41
9 Acknowledgments ....................................... 42
10 References ........................................... 43
McMaster/McCloghrie (editors) [Page 45]
