IEEE 802.3 Repeater
Technical Manual
A D V A N C E D M I C R O D E V I C E S
1993 Advanced Micro Devices, Inc.
Advanced Micro Devices reserves the right to make changes in its products
without notice in order to improve design or performance characteristics.
This publication neither states nor implies any warranty of any kind, including but not limited to implied warrants of merchantability or fitness
for a particular application. AMD assumes no responsibility for the use of any circuitry other than the circuitry in an AMD product.
The information in this publication is believed to be accurate in all respects at the time of publication, but is subject to change without notice.
AMD assumes no responsibility for any errors or omissions, and disclaims responsibility for any consequences resulting from the use of the
information included herein. Additionally, AMD assumes no responsibility for the functioning of undescribed features or parameters.
Trademarks
AMD is a registered trademarks of Advanced Micro Devices, Inc.
IMR, IMR+, HIMIB, TPEX and TPEX+ are trademarks of Advanced Micro Devices, Inc.
Product names used in this publication are for identification purposes only and may be trademarks of their respective companies.
Table of Contents i
TABLE OF CONTENTS
Section 1 Technology Overview 1-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 Terminology/Definition 1-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Overview of Applications 1-2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Overview of Standards 1-5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Section 2 Repeater Management Standards 2-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 IEEE 802.3 Repeater Management 2-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 IEEE 802.3 MAU Management 2-7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Novell’s Hub Management Interface (HMI) 2-8. . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 IETF Managed Objects for IEEE 802.3 Repeaters 2-13. . . . . . . . . . . . . . . . . . . . .
Section 3 IMR/IMR+ Overview 3-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1 Functional Description 3-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 IMR/IMR+ Based “Velcro Hub” Design 3-2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Port Activity Monitor (PAM) Operation 3-6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Link Test State Machine Description 3-7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5 Receive Polarity Detection/Correction Algorithm 3-8. . . . . . . . . . . . . . . . . . . . . . . .
3.6 Alternate Reconnection Algorithm 3-9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7 Interaction Between Port Disable and Port Autopartition 3-9. . . . . . . . . . . . . . . . . .
3.8 IMR/IMR+ Management Port 3-10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9 IMR+ Device Repeater State Machine Description 3-15. . . . . . . . . . . . . . . . . . . . .
3.10 Response to Preamble Only 3-17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.11 Response to IPG Shrinkage 3-17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.12 Designing Repeaters Using Multiple IMR+ Devices 3-18. . . . . . . . . . . . . . . . . . . .
3.13 Expansion Port 3-19. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.14 External Arbiter 3-20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.15 Reset Circuitry 3-20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.16 Differences Between the IMR and IMR+ Devices 3-22. . . . . . . . . . . . . . . . . . . . . .
3.17 IMR/IMR+ Propagation Delays 3-24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Section 4 HIMIB Overview 4-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1 Architectural Overview 4-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 HIMIB/IMR+ Chip-Set Management Capabilities 4-3. . . . . . . . . . . . . . . . . . . . . . . .
4.3 HIMIB Device Hardware Design Considerations 4-7. . . . . . . . . . . . . . . . . . . . . . . .
4.4 HIMIB Device Software Design Considerations 4-8. . . . . . . . . . . . . . . . . . . . . . . . .
Section 5 Managed Repeater Design 5-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1 High Level Design Considerations for Managed Repeaters 5-1. . . . . . . . . . . . . . .
5.2 Fixed Port Repeater Design 5-4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 IMR+/HIMIB Interface 5-6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4 AUI/MAC Interface 5-6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5 Expansion Bus/MAC Interface 5-7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.6 HIMIB Device Microprocessor Interface 5-11. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.7 Managed Repeater Status Indicators 5-13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.8 Modular Repeater Collision Arbitration 5-14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AMD
Table of Contents
ii
Section 6 Layout Recommendations 6-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1 The Attachment Unit Interface 6-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Decoupling 6-3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Power Planes 6-4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4 Filter Modules 6-5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Section 7 Glossary 7-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Appendix
A 10BASE-T Interface Filter and Transformer Modules A-1. . . . . . . . . . . . . . . . . . . .
B AUI Isolation Transformers B-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1-1
Technology Overview
TECHNOLOGY
OVERVIEW
1
SECTION
1.1 TERMINOLOGY/DEFINITION
Computer networks allow computer systems or stations to share information. The
network consists of the communications medium (typically a cable plant), and network
transmission devices to assist in the communication.
The physical cable plant is generally configured in either a star or a bus topology. In a
bus topology all stations tap into a single cable that runs from one station to the next. In
a star topology the stations are all connected to a central point, where a network hub or
repeater connects the cable segments together.
The star topology offers two major advantages. The first advantage is that the computer
network can now be merged with the existing building telephone network. The telephone
is traditionally configured in a star topology, and a single integrated cable plant results in
lower costs and easier cable management. The second advantage of star networks is
that the repeater is a convenient point for monitoring and managing the network. Some
station failures result in the stations transmitting endlessly on the network. In a bus
topology this would disrupt the entire network. In a star topology, the hub or repeater
unit can detect the fault and isolate that station from the network. The network remains
operational and available for use by the other stations.
The access method is the set of rules that stations use to control when they can access
the network. In Ethernet the access method is Carrier Sense, Multiple Access with
Collision Detect, or CSMA/CD. This means that before a station transmits, it monitors
the network for activity. It waits if it detects that another station is already transmitting.
Once the network is available, the station is free to transmit. While transmitting, stations
monitor the network for collisions with other stations, that is more than one station
transmitting at the same time. When a station detects a collision it ceases to transmit,
then after a variable amount of time it attempts to transmit once again.
To a large degree the access method determines the kind of hub needed in a star
topology cableplant. CSMA/CD is based on the concept that station transmissions are
broadcast on the complete network, and use that fact to determine when there is a
collision. The simplest hub for Ethernet networks could have been a passive star, where
each segment is passively coupled to the rest of the segments. However this would
result in significant loss of signal strength, and high network error rates. For this reason
10BASE-T network hubs are active repeaters. These repeaters regenerate the received
signal and broadcast it on the rest of the network. Additionally, an Ethernet repeater
must perform collision detection for each of its attached links.
Repeaters perform these essential tasks:
■Repeaters regenerate the received signal to comply with IEEE 802.3 specifications
prior to retransmitting it on all links.
■Repeaters detect and propagate collisions to all stations.
■And finally repeaters exclude (partition) stations from the network under certain fault
conditions.
The repeater market can be broken down into four product categories. The
following sections describe the different categories, along with their main functional
characteristics.
AMD
Technology Overview
1-2
1.2 OVERVIEW OF APPLICATIONS
In the few years since the development of the IEEE 802.3 10BASE-T standard,
10BASE-T repeaters have evolved into diverse classes of products. These products are
characterized by different numbers of ports, modularity, reliability, manageability, and
different costs. This section describes four categories of IEEE 802.3 Repeater products,
and their essential characteristics.
1.2.1 Fixed Configuration Unmanaged Repeaters
Unmanaged repeaters perform only the basic IEEE 802.3 functions. These devices vary
in configuration from 8 to 32 ports. They adhere to the strategy of monitor by LED,
manage by disconnect, in that they provide port status and error information through
visual indicators only. They provide no facility for remote monitoring or control, although
they may provide a simple local connection (RS232) to connect a computer terminal for
basic maintenance.
Figure 1-1 Fixed Configuration Unmanaged Repeater
17314A-1
The advantage of these devices has been their low cost. They achieved this low cost by
eliminating two essential capabilities, manageability and modularity. Manageability has
historically been costly to implement, resulting in significantly higher product cost.
Modularity allows repeaters to support variable port configurations. However modular
repeaters require a higher initial cost for the system chassis, which is then amortized
across many more ports.
AMD
1-3
Technology Overview
1.2.2 Fixed Configuration Managed Repeaters
Figure 1-2 shows a network using a managed repeater. This repeater allows a remote
management station to monitor and control its operation.
Figure 1-2 Fixed Configuration Managed Repeater
17314A-2
Management
The term “management” means that the repeater supports access to information
regarding its operation. Managed 10BASE-T repeaters differ in exactly what information
is available, and how that information can be accessed. The recently completed
IEEE 802.3 Repeater Management standard defines common sets of information
required in managed IEEE 802.3 repeaters.
Most managed 10BASE-T repeaters support two modes of remote access. In-band
access allows remote management stations to manage the repeater through the
repeater network. Out-of-band access allows remote management through a separate
interface, such as a serial port. Local management capabilities allow access to manage-
ment information through a local interface, such as front panel switches, LED’s, or an
attached terminal.
Remote management uses a management protocol to transmit management information
between the repeater and a remote management station. This can be as simple as a
serial terminal interface for modem access, to a network management protocol such as
the Simple Network Management Protocol (SNMP).
Fixed configuration managed repeaters have recently been extended to support system
level modularity. Known as “rack and stack” repeaters, these devices combine the
flexibility of the modular repeater with the low cost of a fixed configuration repeater. This
product is essentially a fixed configuration repeater, with an additional external interface
to connect it to other repeaters.
The external interface is used to allow these devices to act in concert as a single
repeater. Some of these products allow a single “master” unit to manage other “slave”
units through a management interface, resulting in additional cost savings.
AMD
Technology Overview
1-4
1.2.3 Modular (Enterprise) Repeaters
Modular repeaters are used in environments where the potential need exists for a large
number of ports. By combining the repeaters into a single system chassis, modular
repeaters take advantage of shared costs such as the power supply and network
management module. These systems have a high initial cost due to the increased size
and power requirements, however they offer easy expansion by installing additional
port modules.
Figure 1-3 Modular Repeaters
17314A-3
Management
These systems also support enhanced capabilities, such as redundant power supplies
and support for multiple LAN segments. Multiple LAN segment support allows card by
card segmentation of the network in busy networks. These modular hubs often provide
bridging and routing between the segments, as well as support for different media
access protocols (Token Ring, FDDI etc.), and different media types (STP, UTP, Coax,
Fiber Optics).
This class of system is generally deployed in large building and campus networks. In
these environments network reliability is a major concern. For that reason this class of
repeater almost always includes network management capabilities. That capability is
reflected in the higher initial cost for these systems.
1.2.4 Server Based Repeaters
Server based repeaters are a new class of 10BASE-T product. These repeaters consist
of one or more hub cards designed to be installed in the file server itself. In many cases,
file servers are located near 10BASE-T repeaters. File servers already have a chassis,
power supply, and processor capable of managing the repeater. In these environments,
where the file server has slots available for use by one or more repeater cards, this
provides a low cost option.
AMD
1-5
Technology Overview
Figure 1-4 Unmanaged Server-Based Repeaters
17314A-4
Initially server based repeaters provided only unmanaged capabilities. These products
are the equivalent of a fixed configuration dumb repeater. Newer server based repeaters
use the capabilities of the server processor to add management support for these
products. Novell, Inc. recently introduced the Hub Management Interface (HMI) specifi-
cation. This specification provides a hardware independent interface between the Novell
Netware server management software and the repeater (hub) card.
Figure 1-5 Managed Server-Based Repeaters
Management
17314A-5
AMD
Technology Overview
1-6
The AMD HIMIB and IMR+ repeater chipset directly supports the additional manage-
ment requirements for server based repeaters. AMD offers a design kit called the
ISA-HUBTM-KT for managed server applications. This design kit provides a complete
hardware and software solution for server based managed repeater applications.
A complete user manual for the ISA-HUB is available from AMD (PID #17642A).
1.3 OVERVIEW OF STANDARDS
Computer networking standards are developed by several different standards bodies
with overlapping jurisdiction. Ethernet repeaters are defined in the standards of three
different organizations. The three organizations are the Institute of Electrical and
Electronic Engineers (IEEE), the International Standards Organization (ISO), and the
Internet Engineering Task Force (IETF).
The IEEE 802.3 committee defined the core Ethernet standard. This work involved the
original coax and repeater specifications, the newer 10BASE-T specification, and
various IEEE 802.3 management specifications. The IEEE standards are ultimately
submitted to the International Standards Organization (ISO) for final approval as an
international standard.
This was a straight forward process for the basic physical layer and media access
specifications. However the network management specification is split between ISO and
IEEE. ISO has developed standards for the specification of management information.
The IEEE 802.3 committee used this as the basis for their work in the specification of
repeater management. Additionally the IEEE 802.1 committee specified management
information required for all repeaters in the IEEE 802 protocol suite.
These standards work together to specify the requirements for IEEE 802.3 Repeater
Management. What is not specified in these standards is the protocol to transport
network management information over a network. The most widely supported network
management protocol is the Simple Network Management Protocol (SNMP). The
Internet Engineering Task Force (IETF), an organization responsible for the develop-
ment of guidelines for the administration of the U.S. based Internet, specified the SNMP.
The IETF as a organization ties into the world standards organization through the US
Department of Defense, as an entity separate from the IEEE or ANSI. What is important
is that the IETF specifies how management information will be represented when
transmitted over the network. Specifically the IETF has defined an IEEE 802.3 Repeater
Management Information Base (MIB) that is used to transmit repeater information
through the network. This MIB was based on the work of the IEEE 802.3 Repeater
Management task group.
A final specification of interest is the Hub Management Interface specification developed
by Novell, Inc. This is an interface specification that describes what management
information must be supported by IEEE 802.3 hub cards in Novell file servers, and how
that information is passed to the Novell management protocol stack. This specification is
based on an early draft version of the IEEE 802.3 Repeater Management standard, and
has additional requirements beyond the published IEEE 802.3 specification.
1.3.1 IEEE 802.3 Repeater Standard
The original IEEE 802.3 standards defined the use of coax cable for the transmission of
network information between many stations on a single network segment. The distance
of the network and the maximum number of stations attached to the network were
limited by signal loss on the coax cable.
IEEE 802.3 then developed Section 9 of the standard, detailing the use of a repeater to
extend the distance and number of stations that could be attached to a single
IEEE 802.3 network. The repeater regenerated the electrical signal and retimed the
transmitted bits, connecting one coax segment to another. The standard supports an
extended network topology where stations can be separated by as many as 4 repeaters.
AMD
1-7
Technology Overview
All of the segments attached by repeaters are part of the same collision domain,
meaning that the CSMA/CD access method extends through the repeaters over the
entire network. The round trip delay time must be limited to the maximum collision
window defined by the core IEEE 802.3 standard. The total size of this network is limited
by the need to sense collisions between stations on opposite ends of the network.
Where the IEEE 802.3 coax repeater standard allows connection of multiple stations
through a coax segment, the IEEE 802.3 10BASE-T standard for transmission of
Ethernet over Unshielded Twisted Pair (UTP) cable requires that a repeater port be
attached to each individual 10BASE-T station. An effective way of implementing this is
with a multiport 10BASE-T repeater, which provides multiple 10BASE-T station ports.
Each 10BASE-T link can be up to 100 meters long, and consists of two twisted pairs
(4 conductors total) of UTP cable. One pair is used for transmit, and one for receive.
The use of 10BASE-T repeaters in an 802.3 network is still constrained by the
IEEE 802.3 limitation of at most 4 repeaters between any two end stations.
Where coax based IEEE 802.3 stations are physically attached to the same cable,
10BASE-T stations are physically attached to individual cables called “link segments”.
However the 10BASE-T repeater makes them appear to be connected to a single cable.
It does this by propagating the incoming frames from any station to all other stations in
the network, as well as detecting and signaling when a collision condition is detected.
The repeater receives frames from any attached station, and propagates it to the rest of
the attached stations. During the propagation of the frame, the repeater regenerates the
signal, and retimes the bits. Each repeater has a clock recovery circuit that enables it to
receive and decode (separate clock from data) the incoming bit stream. When the
repeater detects an incoming frame on any port, it connects that port to the clock
recovery circuit where the frame is then decoded. The decoded bits are passed into a
small FIFO, from which they are retransmitted on all ports using the repeater’s locally
generated clock.
This process removes the clock jitter and restores the signal level of the incoming frame.
A few of the initial bits in the frame can be lost in this process because the clock
recovery circuit requires a few bit times to synchronize with the incoming data. Subse-
quent frames can come from different stations, each with a different clock source. This
means that the repeater clock recovery circuit must be able to synchronize to a different
clock source on each frame.
The repeater also plays a central role in collision detection and propagation. Collision is
detected by monitoring activity on all ports. When two or more incoming ports go active
simultaneously, or when the repeater detects a receive mode collision on any port, it
signals a collision condition by transmitting a Jam signal to all ports. This is logically
identical to the collision behavior of a coax based IEEE 802.3 network, with the excep-
tion that collision detection by the repeater is quicker and easier than the DC collision
detection method used by stations on coax IEEE 802.3 networks.
1.3.2 IEEE 802.3 Repeater Management
The IEEE 802.3 committee is working to define the management requirements for
IEEE 802.3 networks. This work initially resulted in the Section 5 “Layer Management”
standard, and more recently the Section 19 “Layer Management for 10Mb/s Baseband
Repeaters” standard. The IEEE 802.3 Repeater Management specification defines what
is managed inside a repeater, not how a repeater is managed by a network manager.
The individual entities inside a repeater that can be managed are referred to as the
management objects. These objects fall into three basic classes.
Attributes
Attributes are the accessible pieces of information in the repeater. They provide status
information about the operational state of the repeater and the network, such as the
AMD
Technology Overview
1-8
health of the repeater, the number of collisions, the total number of received bytes, etc.
Attributes can be readable, writable, or both. In the case of the IEEE 802.3 Repeater
Management standard, all attributes are read only.
Actions
Actions are commands that the network manager can direct the repeater to execute.
They allow the manager to alter the state or value of a management object, such as
resetting the repeater, enabling or disabling ports, etc.
Notifications
Notifications are the messages the repeater is required to send to a network manager
when a significant event occurs. Unlike the attributes and actions that originate at the
network manager, notifications originate at the repeater itself. Because of their potential
impact on the available network bandwidth, these messages are only used to report
significant events.
IEEE 802.3 management objects relate to the repeater in a hierarchical manner. Some
of the objects support management of the overall repeater. Others are used to manage
the individual ports in the repeater. An 8 port repeater would then require one of these
objects for each port. Individual groups of ports are also assigned several objects to
support management of a cluster of ports as a single entity. A single repeater could then
have 4 groups, each consisting of 24 ports for a total of 96 ports.
The IEEE 802.3 management objects are grouped into three sets, or packages.
Packages can each consist of any number of attributes, actions and notifications.
The three packages defined for IEEE 802.3 Repeater Management are Basic Control,
Performance Monitoring, and Address Tracking.
Basic Control is the required minimum set of objects that must be supported by man-
aged IEEE repeaters. Performance Monitoring is the optional set of management
objects necessary to monitor the performance of IEEE 802.3 repeaters. These objects
consist of many real-time port and repeater statistics. Support for these objects is
provided by the AMD HIMIB chip. Address tracking provides port level detection of
attached station addresses. Like the Performance Monitoring package, the Address
Tracking package requires statistics supported by the HIMIB device.
1.3.3 IEEE 802.3 MAU Management
The most recent element in the IEEE 802.3 architecture to undergo management
standardization is the Media Attachment Unit (MAU). The IEEE 802.3 MAU is the actual
physical line interface. Using MAU management, the network manager can determine
status information and initiate control actions on the MAU.
Each port in a managed repeater is subject to support of the IEEE 802.3 MAU Manage-
ment requirements. Like the IEEE 802.3 Repeater Management suite, the IEEE 802.3
MAU Management standard is organized in several packages. Basic Control provides
the minimum mandantory requirements for managed MAUs. MAU Control enables the
network manager to control as well as monitor the MAU operation. Media Loss is a
conditional attribute that provides optional support for AUI attachments. Broadband
DTE MAU is the final conditional package, providing optional support for broadband
network management.
1.3.4 Simple Network Management Protocol
The IEEE 802.3 suite of management standards specifies the management objects
required to support standard interoperable management of IEEE 802.3 systems. It does
not address the issue of how this information is communicated to a remote manager.
The Simple Network Management Protocol (SNMP) is one of many network manage-
AMD
1-9
Technology Overview
ment protocols. Because of its origins in the TCP/IP networking community the SNMP is
widely used in complex heterogeneous corporate networks.
The basic function of the SNMP is to provide a protocol to “get” and “set” management
information base (MIB) attributes in remote stations, and for the remote station to signal
an “alarm” condition to the network manager. Using this capability network managers
can monitor (get) and control (set) remote station operation. The IEEE 802.3 notification
is supported by the SNMP alarm message.
In an IEEE 802.3 Repeater, SNMP allows network managers to enable and disable
ports, as well as to acquire frame error and performance statistics. The SNMP protocol
is specified in Request for Comments (RFC) 1157.
1.3.5 MIB-I, MIB-II, Repeater MIB and RMON MIB
Along with a network management protocol (SNMP), network management requires a
standard way of addressing specific MIB attributes. This structure of network objects is
referred to as the containment tree, and consists of a hierarchy of management object
classes. The IEEE 802.3 repeater ports can be addressed individually or as part of a
group. The groups are combined into a repeater, which in turn is part of a station. The
station could in turn contain additional repeaters and other manageable objects.
The IETF defined MIB-I (RFC 1156) as the original specification of management objects
for stations in an SNMP network. These objects dealt primarily with network interfaces
and elements of the protocol stack. MIB-II (RFC 1213) modified these object definitions,
extending them to cover other related objects. Neither MIB-I nor MIB-II defined support
for repeater management objects.
The IETF Repeater MIB (RFC 1368) was developed based on the IEEE 802.3 Repeater
Management standard. It describes the SNMP based management attributes required in
repeater management objects.
These MIBs are generally oriented toward management by network management
stations within the local campus network. The amount of traffic to actively monitor station
operation is not excessive by LAN standards, however because of bandwidth limitations
remote monitoring is more difficult. Because of this a specification for remote manage-
ment over a wide area network was defined. This allows a remote network monitoring
station to report general network information back to a central management station.
Only when requested by the central management station would detailed traffic informa-
tion be transmitted between the remote monitor and the central manager.
The specification for a remote network monitoring management information base is
referred to as the RMON MIB. This MIB specifies a broad selection of optional manage-
ment and monitoring capabilities, allowing vendors to craft RMON products which span
a broad range of applications and cost.
While not directly related to IEEE 802.3 Repeater Management, many of the RMON MIB
(RFC 1271) attributes mimic those defined in the IEEE 802.3 management suite.
10BASE-T repeaters are often appropriate devices to host the remote management
engine, and could have RMON MIB capabilities installed as an option.
AMD
Technology Overview
1-10
2-1
Repeater Management Standards
REPEATER MANAGEMENT
STANDARDS
2
SECTION
2.1 IEEE 802.3 REPEATER MANAGEMENT
This section describes the IEEE 802.3 Repeater Management Information Base (MIB).
The IEEE 802.3 repeater MIB consists of several different object types. From an
implementation point of view the important ones are the attributes, actions, and notifica-
tions. Attributes are used to monitor and control device operation. Actions force the
repeater to execute a management command, while notifications are used by the
repeater to signal the network manager that a significant event has occurred. The
following sections list the three management packages, and their management objects.
The IEEE 802.3 MIB objects are grouped into three packages, known as the Basic
Control package, the Performance Monitoring package, and the Address Tracking
package. Repeater management objects fall into one of three main classes. The
“repeater” object class contains those objects necessary for overall repeater manage-
ment. The “group” object class contains objects necessary to manage collections of
ports. Ports can be clustered into groups for easier manageability, and the “group” MIB
attributes provide observability into those groups. A group is frequently used to denote
the characteristics of a physical implementation, such as a 12 or 16 port card which fits
into a modular chassis. The “port” object class contains objects that are used to manage
the operation of individual ports in the repeater group.
2.1.1 Basic Control Package (Mandatory)
Table 2-1 lists the attribute, action, and notification management objects in the
IEEE 802.3 Repeater Management Basic Control package. These management objects
are primarily concerned with repeater configuration information and repeater status
(health). Following the table is a brief description of the management object. Because
the Basic Control package objects do not require high speed event tracking, they are
typically implemented in software. For the exact specification of these and other objects
refer to the actual standard documents.
AMD
Repeater Management Standards
2-2
Table 2-1 IEEE 802.3 Repeater Basic Capabilities Package
Repeater Class Object Name Object Type Ref. Para
Repeater repeaterID Attribute Get 19.2.3.2
Repeater repeaterGroupCapacity Attribute Get 19.2.3.2
Repeater groupMap Attribute Get 19.2.3.2
Repeater repeaterHealthState Attribute Get 19.2.3.2
Repeater repeaterHealthText Attribute Get 19.2.3.2
Repeater repeaterHealthData Attribute Get 19.2.3.2
Repeater resetRepeater Action 19.2.3.3
Repeater executeNonDisruptiveSelfTest Action 19.2.3.3
Repeater repeaterHealth Notification 19.2.3.4
Repeater repeaterReset Notification 19.2.3.4
Repeater groupMapChange Notification 19.2.3.4
ResourceTypeID resourceTypeIDName Attribute Get N/A
ResourceTypeID resourceInfo Attribute Get N/A
Group groupID Attribute Get 19.2.5.2
Group groupPortCapacity Attribute Get 19.2.5.2
Group portMap Attribute Get 19.2.5.2
Group portMapChange Notification 19.2.5.2
Port portID Attribute Get 19.2.6.2
Port portAdminState Attribute Get 19.2.6.2
Port autoPartitionState Attribute Get 19.2.6.2
Port portAdminControl Action 19.2.6.3
repeaterID
“repeaterID” is a read-only attribute used to identify the specific instance of the repeater
in the system. It consists of an integer value between 1 and 1024.
repeaterGroupCapacity
“repeaterGroupCapacity” is a read-only attribute used to identify the maximum number
of groups supported by this repeater. It consists of an integer value between 1 and
1024. “repeaterGroupCapacity” can be larger than the actual number of installed
groups.
groupMap
“groupMap” is a read-only attribute used to identify the actual installed groups in this
repeater. It consists of a-bit string “repeaterGroupCapacity” bits in length. Each-bit signals
the absence (“0”) or presence (“1”) of the group, numbered from lowest to highest.
repeaterHealthState
“repeaterHealthState” is a read-only attribute used to indicate the general health of the
repeater. It consists of a numeric value. The possible values are:
1 other undefined or unknown
2 OK no known failures
3 repeaterFailure known to have a repeater-related failure
4 groupFailure known to have a group-related failure
5 portFailure known to have a port-related failure
6 generalFailure has an unspecified failure type
In the event that multiple failures are present, the highest priority failure (lowest num-
bered failure) should be reported.
AMD
2-3
Repeater Management Standards
repeaterHealthText
“repeaterHealthText” is a read-only attribute, consisting of a text string that provides
relevant information about the operational state of the repeater to a network manager.
The contents of this attribute are vendor specific, and can be used to provide detailed
failure information or problem resolution instructions. The string must be printable text
no longer than 255 characters in length.
repeaterHealthData
“repeaterHealthData” is a read-only attribute consisting of a block of information related
to the operational state of the repeater. The encoding of the information is vendor
specific, and must not exceed 255 bytes in length.
resetRepeater
“resetRepeater” is an action. When received, the repeater state is reset to “Start” state
as defined in the IEEE 802.3 Section 9 standard. This forces the repeater to execute a
disruptive self-test. The exact requirements of the self test are unspecified. The repeater
maintains management information throughout the execution of this action, and
transmits a “repeaterReset” notification in response to this action request. During this
action the repeater must not inject any packets onto any segment. Received packets
may or may not be transferred at the implementors discretion.
executeNonDisruptiveSelfTest
“executeNonDisruptiveSelfTest” is an action. When received, the repeater executes a
vendor specific test. During the test the state of the repeater is unchanged, and the
management information remains intact. This test must not inject any packets onto any
segment attached to the repeater. This test does not interfere with the transfer of any
packets through the repeater. Completion of this test results in a “repeaterHealth”
notification.
repeaterHealth
“repeaterHealth” is a notification. It is sent when the health state of a repeater changes,
not including initial powering up of the repeater. At a minimum the repeaterHealth
notification consists of the “repeaterHealthState” attribute. It optionally includes the
“repeaterHealthText” and “repeaterHealthData” attributes.
repeaterReset
“repeaterReset” is a notification. It is sent when the repeater is reset at power-up, or
upon completion of the resetRepeater action. repeaterReset notification contains
repeaterHealthState, and optionally repeaterHealthText and repeaterHealthData
attributes.
groupMapChange
“groupMapChange” is a notification that a group has been logically inserted or removed
from the repeater. This notification is not sent during repeater power up. This notification
consists of the new groupMap attribute.
resourceTypeIDName
“resourceTypeIDName” is a read-only attribute. It is used to contain the name of the
resourceTypeID managed object, a fixed value of “RTID”. See 802.1F Common
Definitions and Procedures for IEEE 802 Management Information (Draft) for additional
details.
resourceInfo
“resourceInfo” is a read-only attribute provided by repeater manufacturer. It is used to
describe the resource. The attribute contains the ManufacturerOUI (Organizational Unit
Identifier), ManufacturerName, ManufacturerProductName, and ManufacturerProduct-
Version. See 802.1F Common Definitions and Procedures for IEEE 802 Management
Information (Draft) for additional details.
AMD
Repeater Management Standards
2-4
groupID
“groupID” is a read-only attribute used to identify a specific instance of a group class in
the repeater. It is an integer value in the range of 1 to 1024. This value cannot exceed
“repeaterGroupCapacity”.
groupPortCapacity
“groupPortCapacity” is a read-only attribute used to identify the number of potential
ports in this instance of a group. It is an integer value in the range of 1 to 1024. The
number of actual ports present may be less than or equal to the groupPortCapacity.
portMap
“portMap” is a read-only attribute used to identify the actual installed ports in this group.
It consists of a-bit string “groupPortCapacity” bits in length. Each-bit signals the absence
(“0”) or presence (“1”) of the port, numbered from lowest to highest.
portMapChange
“portMapChange” is a notification that a port has been logically inserted or removed
from the group. This notification is not sent during repeater power up. This notification
consists of the new portMap attribute.
portID
“portID” is a read-only attribute used to identify the specific instance of the port in the
group. It consists of an integer value between 1 and 1024.
portAdminState
“portAdminState” is a read-only attribute used to indicate whether the port is currently
enabled or disabled. A disabled port does not transmit or receive. This attribute is
preserved across repeater reset and loss of power. This attribute is not writable,
however it is controlled through the portAdminControl action. This attribute takes
precedence over the auto-partition mechanism. A value of ‘1’ means the port is
disabled, a value of ‘2’ means it is enabled.
autoPartitionState
“autoPartitionState” is a read-only attribute indicating the state of the port autoPartition
state machine. A value of a 1 means that the port is currently auto partitioned, a value
of 2 means that the port is currently not auto partitioned.
portAdminControl
“portAdminControl” is an action. When received it modifies the “portAdminState”
attribute. A ‘1’ is used to enable the port, while a ‘0’ is used to disable the port. A
disabled port does not transmit or receive any information. A transition from disabled to
enabled in the “portAdminState” causes the auto partition state machine to return to the
‘BEGIN’ state, as defined in Section 9 of the IEEE 802.3 standard.
2.1.2 Performance Monitoring Package (Optional)
The performance monitoring package provides additional statistics beyond those
provided by the basic control capabilities package. These statistics consist of multiple
32-bit counters on each port, all of which are fully supported by the AMD HIMIB. Prior to
the introduction of the AMD HIMIB these management objects required extensive
hardware and software support.
AMD
2-5
Repeater Management Standards
Table 2-2 IEEE 802.3 Performance Monitoring Package
Repeater Class Object Name Object Type Ref. Para.
Repeater transmitCollisions Attribute Get 19.2.3.2
Port readableFrames Attribute Get 19.2.6.2
Port readableOctets Attribute Get 19.2.6.2
Port frameCheckSequenceErrors Attribute Get 19.2.6.2
Port alignmentErrors Attribute Get 19.2.6.2
Port framesTooLong Attribute Get 19.2.6.2
Port shortEvents Attribute Get 19.2.6.2
Port runts Attribute Get 19.2.6.2
Port collisions Attribute Get 19.2.6.2
Port lateEvents Attribute Get 19.2.6.2
Port veryLongEvents Attribute Get 19.2.6.2
Port dataRateMismatches Attribute Get 19.2.6.2
Port autoPartitions Attribute Get 19.2.6.2
transmitCollisions
”transmitCollisions” is a read-only attribute that counts the number of transmit collisions
this repeater has detected. The value of the transmitCollisions attribute is a 32-bit
counter with a minimum rollover time of 16 hours.
readableFrames
“readableFrames” is a read-only attribute that counts the number of valid frames
detected by the port. Valid frames are from 64 bytes to 1518 bytes in length, have a
valid frame CRC and are received without a collision. This attribute is a 32-bit counter
with a minimum rollover time of 80 hours.
readableOctets
“readableOctets” is a read-only attribute that counts the number of total octets received
on each port. This number is determined by adding the frame length to this register at
the completion of every valid frame. This attribute is a 32-bit counter with a minimum
rollover time of 58 minutes.
frameCheckSequenceErrors
“frameCheckSequenceErrors” is a read-only attribute that counts the number of frames
detected on each port with an invalid frame check sequence. This counter is incre-
mented on each frame of valid length (64 bytes to 1518 bytes) that does not suffer a
collision during the frame. This counter is incremented on each invalid frame, however it
is not incremented for frames with both framing errors and frame check sequence
errors. This attribute is a 32-bit counter with a minimum rollover time of 80 hours.
alignmentErrors
“alignmentErrors” is a read-only attribute that counts the number of frames detected on
each port with an FCS error and a framing error. Frames that have both framing errors
and FCS errors are counted by this attribute, but not by the frameCheckSequenceErrors
attribute. This attribute is a 32-bit counter with a minimum rollover time of 80 hours.
framesTooLong
“framesTooLong” is a read-only attribute that counts the number of frames that exceed
the 1518 byte maximum frame size. This attribute is a 32-bit counter with a minimum
rollover time of 61 days.
AMD
Repeater Management Standards
2-6
shortEvents
“shortEvents” is a read-only attribute that counts the number of instances where activity
is detected with a duration less than the “ShortEventMaxTime” (74–82-bit times). This
attribute is a 32-bit counter with a minimum rollover time of 16 hours.
runts
“runts” is a read-only attribute that counts the number of instances where activity is
detected with a duration greater than the “ShortEventMaxTime” (74–82-bit times), but
less than the minimum valid frame time (512-bit times, 64 bytes). This attribute is a
32-bit counter with a minimum rollover time of 16 hours.
collisions
“collisions” is a read-only attribute that counts the number of instances where a carrier is
detected on the port, and a collision is detected. This attribute is a 32-bit counter with a
minimum rollover time of 16 hours.
lateEvents
“lateEvents” is a read-only attribute that counts the number of instances where a
collision is detected after the LateEventThreshold (480–565-bit times) in the frame. This
event will be counted both by the “lateEvents” attribute, as well as the “collisions”
attribute. This attribute is a 32-bit counter with a minimum rollover time of 81 hours.
veryLongEvents
“veryLongEvents” is a read-only attribute that counts the number of times the transmitter
is active for greater than the MAU Jabber Lockup Protection Timer allows
(4 ms–7.5 ms). This attribute is a 32-bit counter with a minimum rollover time of
198 days.
dataRateMismatches
“dataRateMismatches” is a read-only attribute that counts the number of occurrences
where the frequency, or data rate of the incoming signal is detectably different from the
local transmit frequency. This attribute is a 32-bit counter that is incremented on each
such event.
autoPartitions
“autoPartitions” is a read-only attribute that counts the number of instances where the
repeater has partitioned this port from the network. This attribute is a 32-bit counter that
is incremented on each such event.
2.1.3 Address Tracking Package (Optional)
The address tracking package provides optional information related to the MAC address
of frames received on each port. This information can be used to monitor attached
station addresses on a port by port basis. All objects in the Address Tracking package
are directly supported by the AMD HIMIB.
Table 2-3 IEEE 802.3 Address Tracking Package
Repeater Class Object Name Object Type Ref. Para.
Port lastSourceAddress Attribute Get 19.2.6.2
Port sourceAddressChanges Attribute Get 19.2.6.2
lastSourceAddress
“lastSourceAddress” is a read-only attribute that saves the value of the Source Address
field in the last frame it received. This attribute is a 6-byte field.
AMD
2-7
Repeater Management Standards
sourceAddressChanges
“sourceAddressChanges” is a read-only attribute that counts the number of times the
source address field of received frames changes. This attribute is a 32-bit counter with a
minimum rollover of 81 hours.
2.2 IEEE 802.3 MAU MANAGEMENT
Section 20 of the IEEE 802.3 standard defines the management requirements of a
Media Attachment Unit (MAU). Table 2-4 defines the management objects specified in
IEEE 802.3 Section 20. This standard was in draft form at the time this document was
written, so the objects may change. The objects had not yet been assigned numbers at
the time this was written. Refer to the draft document for detailed descriptions of the
MAU object definitions.
Like the IEEE 802.3 Repeater Management Standard, the IEEE 802.3 MAU Manage-
ment Draft consists of several packages. The Basic package is the minimum subset
required for a managed MAU. The MAU Control package is an optional package that
provides management control of MAU operation. The Media Loss Tracking package
(actually one attribute) is a mandatory package for AUI’s that keeps statistics on the
media availability. The Media Loss Tracking package is optional for other MAU’s.
Finally, the Broadband DTE MAU package is a required set of management objects in
broadband MAU’s.
Table 2-4 IEEE 802.3 MAU Management
Package Object Name Object Type Reference
Basic mauID attribute 20.2.3.2
Basic mauType attribute 20.2.3.2
Basic mauMediaAvailable attribute 20.2.3.2
Basic jabber attribute 20.2.3.2
Basic mauAdminState attribute 20.2.3.2
Basic jabber notification 20.2.3.4
MAU Control resetMAU action 20.2.3.3
MAU Control mauAdminCtrl action 20.2.3.3
Media Loss Tracking mauLoseMediaCounter attribute 20.2.3.2
Broadband DTE MAU bBandSplitType attribute 20.2.3.2
Broadband DTE MAU bBandFrequencies attribute 20.2.3.2
mauID
“mauID” is a read-only attribute used to identify the specific instance of the MAU on the
port. It consists of an integer value.
mauType
“mauType” is a read-only attribute used to identify the IEEE 802.3 MAU type. This
consists of an integer value, that is the section number where the specific type of MAU
is specified.
mauMediaAvailable
“mauMediaAvailable” is a read-only attribute used to signal the status of the media link.
For link based MAU’s such as 10BASE-T this is the link test fail state. For other MAU’s
such as the basic AUI interface this is the loopback detection status.
mauLoseMediaCounter
“mauLoseMediaCounter” is a read-only attribute used to count the number of times the
mauMediaAvailable attribute has gone from‘available’ to any other state. This counter
must not be allowed to increment at a rate greater than 10 times per second.
AMD
Repeater Management Standards
2-8
jabber
“jabber” is a two part attribute consisting of a jabberFlag, and a jabberCounter. Both
parts of the attribute are read-only.
The jabber Counter attribute counts the number of times the jabberFlag enters the ‘fault’
state. This counter must not be allowed to increment at a rate greater than 40 times per
second.
mauAdminState
“mauAdminState” is a read-only attribute used to indicate the current control status of
the MAU, that is what state the manager previously commanded the MAU to assume.
Refer to mauAdminCtrl for the state definitions.
bBandSplitType
“bBandSplitType” is a read-only attribute used to monitor the configuration of a broad-
band IEEE 802.3 MAU. This attribute indicates whether the broadband cabling system is
a single cable system or a dual cable system.
bBandFrequencies
“bBandFrequencies” is a two part integer used for a broadband IEEE 802.3 MAU
consisting of the Transmitter Carrier Frequency and the Translation Offset Frequency.
The Transmitter Carrier Frequency part of the attribute is the actual transmitter carrier
frequency divided by 250 KHz. Likewise the Translation Offset Frequency part of the
attribute is the translation offset frequency divided by 250 KHz.
resetMAU
“resetMAU” is an action that results in the MAU performing a reset. This reset must be at
least 1/2 second in length, during which the AUI DI, DO, and CI should be idle. This
reset should operate the same as a power on reset.
mauAdminCtrl
“mauAdminCtrl” is an action that controls the operational state of the MAU.
jabber
“jabber” is a notification that the MAU has detected a jabber fault. This is the same
condition that determines the state of the jabber attribute (jabberFlag).
2.3 NOVELL’S HUB MANAGEMENT INTERFACE (HMI)
Novell Inc. has defined the Hub Management Interface (HMI) specification. Supporting
IEEE 802.3 or hub cards in Novell file servers, this specification defines the hardware
independent driver requirements for managed third party hub card vendors. This
document specifically focuses on support for 10BASE-T repeaters, rather than support-
ing IEEE 802.3 repeaters in general.
The interface consists of two components. The first is a definition of objects accessible
through “get” and “set” commands from the hub management protocol layers. The
second is a specification of the memory structure used to communicate between the
hub driver and the hub protocol stack. Two different memory structures are defined, the
Hub Interface Table (HIT), and the Group Interface Table (GIT).
The IEEE 802.3 managed objects are split into two groups. Part of the objects are
managed using the Get and Set capabilities of HMI. Others are accessed through
variables in the HIT and GIT. The HMI specification was developed during the draft
stages of the IEEE 802.3 Repeater Management specification, and differs in the number
of managed objects.
Note that the following IEEE 802.3 Repeater Management objects have no HMI
equivalence: repeaterID, resourceInfo, groupID, portMap, portMapChange, and portID.
Additionally HMI offers only very limited support for the newly developed MAU Manage-
ment specification.
AMD
2-9
Repeater Management Standards
2.3.1 Novell HMI/IEEE 802.3 Repeater MIB Mapping
Table 2-5 provides a summary of the HMI management objects, and their IEEE 802.3
equivalents. The text following the table provides an overview of the objects not
previously described in the 802.3 Repeater Management section. For more detailed
information refer to the Novell HMI specification.
The Novell management attributes are divided into four classes. The first three mimic
the IEEE 802.3 Repeater Management definitions, with Basic Control, Performance
Monitoring, and Address Tracking packages. The fourth is called Novell Extensions, and
includes additional management attributes.
Table 2-5 HMI to IEEE 802.3 Management Object Equivalencies
Object Package HMI Object Name HMI # IEEE Object Name
Basic InfoTablePointer 0
Basic ResetHubAction 1 resetRepeater
Basic ExecutesSelfTest1Action 2 executeNonDisruptive
SelfTestAction
Basic ExecutesSelfTest2Action 3
Basic PortAdminState 4 portAdminState
Basic AutoPartitionState 5 autoPartitionState
Performance TransmitCollisions 6 transmitCollisions
Performance RepeaterVeryLongEvents 7
Performance PortVeryLongEvents 8 veryLongEvents
Performance ReadableFrames 9 readableFrames
Performance ReadableOctets 10 readableOctets
Performance FrameCheckSequenceErrors 11 frameCheckSequenceErrors
Performance AlignmentErrors 12 alignmentErrors
Performance FramesTooLong 13 framesTooLong
Performance ShortEvents 14 shortEvents
Performance Runts 15 runts
Performance Collisions 16 collisions
Performance LateEvents 17 lateEvents
Performance DataRateMismatches 18 dataRateMismatches
Performance AutoPartitions 19 autoPartitions
Address LastSourceAddress 20 lastSourceAddress
Address SourceAddressChanges 21 sourceAddressChanges
Novell PortLinkState 22 aMediaAvailable
(MAU Mgmt)
Novell RepeaterTotalOctets 23
Novell PortType 24
InfoTablePointer
“InfoTablePointer” is a pointer to the Hub Information Table (HIT). This pointer is used
to access other Hub management information.
ExecuteSelfTest1Action
“ExecuteSelfTest1Action” is equivalent to the 802.3 Repeater Management
“executeNonDisruptiveSelfTest” action.
AMD
Repeater Management Standards
2-10
ExecuteSelfTest2Action
“ExecuteSelfTest2Action” is an action that causes the repeater to perform a disruptive
self test. This test may interfere with the transfer of packets through the repeater.
PortAdminState
This HMI management object consists of two IEEE 802.3 objects. Both Set and Get
operations are available for this object. The Set operation corresponds to the
IEEE 802.3 portAdminControl action, while the get operation corresponds to the IEEE
802.3 portAdminState management attribute.
RepeaterVeryLongEvents
This management attribute tracks the number of VeryLongEvents the repeater has seen
on all ports. This attribute is the sum of the IEEE 802.3 veryLongEvents attribute across
all ports in the repeater.
PortLinkState
This management attribute is a Novell vendor specific extension to the basic IEEE 802.3
management attributes. It’s purpose is to track on a port by port basis whether the port
is receiving link status pulses. This attribute consists of an integer value from 1 to 3, with
the following meaning:
1 Link Up
2 Link Down
3 Not Applicable – The port is not a 10BASE-T port.
RepeaterTotalOctets
This management attribute is a Novell vendor specific extension to the basic IEEE
management attributes. This attribute counts the total number of bytes repeated by the
hub, whether the frame had a valid FCS or not. This counter adds 8 bytes per frame for
the preamble.
PortType
This management attribute is a Novell vendor specific extension to the basic IEEE
management attributes. This attribute is a number from 1 to 4, with the following
meanings: 1 Other port type
2 Normal port type
3 Local host port
4 AUI port
2.3.2 Hub Information Table (HIT)
Table 2-6 describes the structure of the Hub Information Table (HIT). Several of the
variables in the table represent IEEE 802.3 repeater management attributes, and are
passed through the table instead of through managed object requests.
AMD
2-11
Repeater Management Standards
Table 2-6 HMI Hub Information Table
HMI Object Name HIT Table Offset (hex bytes) IEEE Object Name
Reserved 00
HubType 10
Reserved1 11
MajorVersion 12
MinorVersion 13
ManufacturerID 14 resourceTypeIDName
Reserved2 17
HubDescriptionPointer 18
HubVersionPointer 1C
HealthState 20 repeaterHealthState
HealthTextPointer 24 repeaterHealthText
HealthDataPointer 28 repeaterHealthData
HealthDataLength 2C
GroupsSupported 2E repeaterGroupCapacity
GroupInfoTablePointer 30
CapabilitiesBitMap 34
Most of the entries in this table do not have IEEE 802.3 equivalents. The following is a
brief description of these parameters. Refer to the HMI specification for more details.
Reserved
This is a 16-byte reserved field.
HubType
This 1-byte field is set to a ‘1’ to signify that this Hub is a 10BASE-T hub.
Reserved1
This is a 1-byte reserved field.
MajorVersion
This field is a HIT major version number. The version number of this table is ‘1’.
MinorVersion
This field is a HIT minor version number. The current number of this table is ‘0’.
ManufacturerID
This is a 3-byte manufacturer’s ID field, as specified in the IEEE 802.1F Recommended
Practice draft document. The IEEE 802.1F equivalent attribute is the resourceInfo and is
typically the three leading bytes of the manufacturer’s MAC address.
Reserved2
This is a 1-byte reserved field.
HubDescriptionPointer
This field points to a text string describing this hub.
HubVersionPointer
This field points to a text string that describes the hub’s version number.
HealthDataLength
This is the length in bytes of the preceding HealthDataPointer. Because the HealthData
string contains binary information, it cannot be terminated by a ‘0’.
AMD
Repeater Management Standards
2-12
GroupInfoTablePointer
This is a 4-byte pointer to the Group Information Table (GIT).
CapabilitiesBitMap
This field is a 1-byte value indicating the level of management capabilities present in this
HMI managed HUB. These numbers can be in the range from 0 to 3, with the following
meanings: 0 Basic Control
1 Performance Monitoring
2 Address Tracking
3 Novell Extensions
2.3.3 Group Information Table (GIT)
Table 2-7 is the group information table. It is used to provide information related to
specific groups of ports in the Repeater. Several of the IEEE 802.3 MIB attributes are
passed through the Group Information Table instead of being transferred as managed
objects.
Table 2-7 HMI Group Information Table
GIT # GIT Object Name IEEE Object Name
00 Installed groupMap
01 Slot
02 Ports groupPortCapacity
04 Description
08 ObjectIDPointer
0C ObjectIDLength
0E InstalledTime
12 DriverWorkspace
Slot
This is an optional 1-byte field to indicate the slot number of the selected Hub Group.
Description
This is a 4-byte pointer to a text string indicating information about this group.
ObjectIDPointer
This is a 4-byte pointer to the array of 16-bit words, that provides the manufacturer’s
group identification information. The format for this information is documented in the
“Structure and Identification of Management Information for TCP/IP based Internets”
enterprise subtree. This provides an exact specification of the class of group being
managed.
ObjectIDLength
This 2-byte value is the length of the Object ID array in bytes.
InstalledTime
This 4-byte field is the system time when the group was last installed in the hub.
DriverWorkspace
This 10-byte field is available for the driver to use as temporary storage during it’s
execution.
AMD
2-13
Repeater Management Standards
2.3.4 HMI Notifications
In addition to HMI managed objects, and attributes passed through the HIT and GIT, the
Novell HMI document specifies how various events in the Repeater can cause a
notification message to be passed to the Hub manager. Table 2-8 lists the notification
messages required by the HMI specification. These notifications correspond to their
IEEE 802.3 equivalents.
Table 2-8 HMI Notifications
HMI Object Name HMI # IEEE 802.3 Object Name
HealthChange 1 repeaterHealth
GroupChange 2 groupMapChange
HubReset 3 repeaterReset
2.4 IETF MANAGED OBJECTS FOR IEEE 802.3 REPEATERS
As the IEEE 802.3 committee defined the repeater management objects, the IETF
extended the definition to specify a protocol and encoding to use in the remote manage-
ment of these objects. The IETF also defined additional objects for use in managing
repeaters. The actual definition and syntax of these objects is defined in RFC 1368,
“Definitions of Managed Objects for IEEE 802.3 Repeater Devices”.
Table 2-9 lists the IETF 802.3 Repeater MIB ‘get’ and ‘set’ attributes, and cross
references it to the IEEE 802.3 Repeater Management attributes and actions. Refer to
RFC 1368 for a detailed description of each management object. Many of the SNMP
managed objects have no corresponding analog in the IEEE 802.3 repeater MIB.
Table 2-9 SNMP to IEEE 802.3 Attribute Cross-reference
IETF 802.3 Repeater IEEE 802.3 Repeater
IETF Identification Code MIB Reference MIB Reference
snmpDot3RptrMgt.1.1.1 rptrGroupCapacity repeaterGroupCapacity
snmpDot3RptrMgt.1.1.2 rptrOperStatus repeaterHealthState
snmpDot3RptrMgt.1.1.3 rptrHealthText repeaterHealthText
snmpDot3RptrMgt.1.1.4 rptrReset resetRepeater
snmpDot3RptrMgt.1.1.5 rptrNonDisruptTest executeNonDisruptiveSelf
TestAction
snmpDot3RptrMgt.1.1.6 rptrTotalPartitionedPorts
snmpDot3RptrMgt.1.2.1.1.1 rptrGroupIndex groupID
snmpDot3RptrMgt.1.2.1.1.2 rptrGroupDescr
snmpDot3RptrMgt.1.2.1.1.3 rptrGroupEntry
snmpDot3RptrMgt.1.2.1.1.4 rptrGroupOperStatus
snmpDot3RptrMgt.1.2.1.1.5 rptrGroupLastOperStatusChange
snmpDot3RptrMgt.1.2.1.1.6 rptrGroupPortCapacity groupPortCapacity
snmpDot3RptrMgt.1.3.1.1.1 rptrPortGroupIndex
snmpDot3RptrMgt.1.3.1.1.2 rptrPortIndex portID
snmpDot3RptrMgt.1.3.1.1.3 rptrPortAdminStatus portAdminState
portAdminControl
snmpDot3RptrMgt.1.3.1.1.4 rptrPortAutoPartitionState autoPartitionState
snmpDot3RptrMgt.1.3.1.1.5 rptrPortOperStatus
AMD
Repeater Management Standards
2-14
Table 2-9 SNMP to IEEE 802.3 Attribute Cross-reference (continued)
IETF 802.3 Repeater IEEE 802.3 Repeater
IETF Identification Code MIB Reference MIB Reference
snmpDot3RptrMgt.2.1.1 rptrMonitorTransmitCollisions transmitCollisions
snmpDot3RptrMgt.2.2.1.1.1 rptrMonitorGroupIndex
snmpDot3RptrMgt.2.2.1.1.2 rptrMonitorGroupTotalFrames
snmpDot3RptrMgt.2.2.1.1.3 rptrMonitorGroupTotalOctets
snmpDot3RptrMgt.2.2.1.1.4 rptrMonitorGroupTotalErrors
snmpDot3RptrMgt.2.3.1.1.1 rptrMonitorPortGroupIndex
snmpDot3RptrMgt.2.3.1.1.2 rptrMonitorPortIndex portID
snmpDot3RptrMgt.2.3.1.1.3 rptrMonitorPortReadableFrames readableFrames
snmpDot3RptrMgt.2.3.1.1.4 rptrMonitorPortReadableOctets readableOctets
snmpDot3RptrMgt.2.3.1.1.5 rptrMonitorPortFCSErrors frameCheckSequenceErrors
snmpDot3RptrMgt.2.3.1.1.6 rptrMonitorPortAlignmentErrors alignmentErrors
snmpDot3RptrMgt.2.3.1.1.7 rptrMonitorPortFrameTooLongs framesTooLong
snmpDot3RptrMgt.2.3.1.1.8 rptrMonitorPortShortEvents shortEvents
snmpDot3RptrMgt.2.3.1.1.9 rptrMonitorPortRunts runts
snmpDot3RptrMgt.2.3.1.1.10 rptrMonitorPortCollisions collisions
snmpDot3RptrMgt.2.3.1.1.11 rptrMonitorPortLateEvents lateEvents
snmpDot3RptrMgt.2.3.1.1.12 rptrMonitorPortVeryLongEvents veryLongEvents
snmpDot3RptrMgt.2.3.1.1.13 rptrMonitorPortDataRate dataRateMismatches
Mismatches
snmpDot3RptrMgt.2.3.1.1.14 rptrMonitorPortAutoPartitions autoPartitions
snmpDot3RptrMgt.2.3.1.1.15 rptrMonitorPortTotalErrors
snmpDot3RptrMgt.3.1.1.1.1 rptrAddrTrackGroupIndex
snmpDot3RptrMgt.3.1.1.1.2 rptrAddrTrackPortIndex portID
snmpDot3RptrMgt.3.1.1.1.3 rptrAddrTrackLastSourceAddress lastSourceAddress
snmpDot3RptrMgt.3.1.1.1.4 rptrAddrTrackSourceAddrChanges sourceAddressChanges
snmpDot3RptrMgt.3.2 rptrAddrTrackGroupInfo
snmpDot3RptrMgt.3.3 rptrAddrTrackPortInfo
Table 2-10 lists the IETF traps, which correspond to the IEEE management notifications
objects.
Table 2-10 SNMP Trap to IEEE 802.3 Notification Cross-Reference
IETF 802.3 Repeater IEEE 802.3 Repeater
IETF Identification Code MIB Reference MIB Reference
snmpDot3RptrMgt.1 rptrHealth repeaterHealth
snmpDot3RptrMgt.2 rptrGroupChange groupMapChange
snmpDot3RptrMgt.3 rptrResetEvent repeaterReset
3-1
IMR/IMR+ Overview
IMR/IMR+
OVERVIEW
3
SECTION
3.1 FUNCTIONAL DESCRIPTION
The Am79C981 Integrated Multiport Repeater Plus device is a single chip implementa-
tion of an IEEE 802.3/Ethernet repeater (or hub). In addition to the eight integral
10BASE-T ports plus one AUI port comprising the basic repeater, the IMR+ chip also
provides the hooks necessary for complex network management and diagnostics.
The IMR+ device is also expandable, enabling the implementation of high port count
repeaters based on several IMR+ devices.
The IMR+ device interfaces directly with AMD’s Am79C987 Hardware Implemented
Management Information Base (HIMIB) device to allow a fully managed multiport
repeater to be implemented as specified by the IEEE 802.3 Layer Management for
10 Mb/s Baseband Repeaters Standard. When the IMR+ and HIMIB devices are used
as a chip set, the HIMIB device maintains complete repeater and per port statistics
which can be accessed on demand by a microprocessor through a simple 8-bit
parallel port.
Figure 3-1 IMR+ Block Diagram
AUI
Management
Port Expansion
Port
Twisted Pair
Port 0 Twisted Pair
Port 7
Repeater
State
Machine
17314A-6
The IMR+ device differs from the original IMR chip in only a few minor internal details.
The IMR+ device is pin, software and timing compatible with the IMR device, and may
be used as a direct replacement in an existing IMR-based design. Most of the enhance-
ments in the IMR+ device relate to the provision of additional internal status information,
which is primarily included for use by the companion HIMIB device. The HIMIB device
requires this enhanced status information in order to allow implementation of a fully
managed repeater, compliant to the IEEE 802.3 Layer Management for 10 Mb/s
Baseband Repeaters Standard. The implementation of managed repeaters is covered in
detail in Section 5 of this manual, and the complete definition of all changes between the
AMD
IMR/IMR+ Overview
3-2
IMR and IMR+ devices is contained in this section under “Differences Between the
IMR and IMR+ Devices”.
From the perspective of a simple low cost, unmanaged repeater application, the primary
additional feature offered by the IMR+ device over and above that of the original IMR
device, is the provision of a “Minimum Mode”, designed to minimize the external support
logic to provide simple diagnostic and status related indicators (LEDs). The Minimum
Mode is explained in more detail in this section under “Minimum Mode Operation”.
3.2 IMR/IMR+ BASED “VELCROTM HUB” DESIGN
For low end systems, the IMR combined with a power supply, crystal and EMI/RFI
filter/transformer modules, effectively produces a fully operational 10BASE-T repeater,
with an AUI port to allow connection to an existing 10BASE2/5 coax backbone.
Figure 3-2 Simple “VelcroTM Hub” Example
Power
Supply Regulator
Quad Filter/
Transformer
Module
IMR/IMR+
AUI
Isolation
Quad Filter/
Transformer
Module
17314A-7
Status
LEDs
3.2.1 IMR-Based “VelcroTM Hub” Design
A “Velcro Hub” application example is shown in Figure 3-3. The external PAL connects
to the Management Port of the IMR device, and implements a simple state machine.
This is used to configure the programmable options of the IMR device at power up (if the
default options need to be changed), and then continuously clocks in Management Port
“Get” requests on the SI pin. It also clocks out the results on the SO pin to obtain
internal status information (such as the Link Status, Partitioning or Polarity). The result
of the “Get” request, output on the SO pin by the IMR device, is shifted into the external
serial-to-parallel converter, and used to drive LED status indicators, using a simple
pulse stretch and driver circuit.
The state machine can be enhanced to allow external selection (through a front panel
mounted switch or other selection mechanism) of different Management Port “Get”
requests, such that the same LEDs can be used to display various status information.
The “IMR VelcroTM Hub Board” is available from AMD as an example design kit, which
details these concepts.
AMD
3-3
IMR/IMR+ Overview
Figure 3-3 “Velcro Hub” Design Using the IMR Device
ACK REQ
JAM
SI
SO
SCLKX1
Am79C980
IMR TP Port 0
AUI Port
TP Port 7
VDD
VDD
8 Link Test Status LEDs
20 MHz
+ 0.01%
X2
State
Machine
(PAL)
8-Bit SIPO Shift
Register and
LED Driver
SHIFT
CLK
SERIN
COL
DAT
10 K 10 K
Note:
Unused receiver pairs (DI +/-, CI +/-, RXDn +/-)
should be shorted together.
100 pF 100 pF
17314A-8
3.2.2 IMR+ Based “Velcro Hub” Design
The design of a simple repeater using the IMR+ device is simplified by use of the
“Minimum Mode”, which allows status information to be continuously output from the
Management Port of the IMR+ device, without the need for an external state machine.
Figure 3-4 shows an application example employing the IMR+ device in Minimum Mode.
Figure 3-4 “Velcro” Hub Design Using the IMR+ Device
Am79C981
IMR+ Chip
XTAL
OSC
CK
D
Q
ASYNC
RESET
X1
X2
RST STR
SO
CLR
CK Q
QD
1/2 ’74
TCK
CK
SI SIPO
CK
T
P
7
T
P
6
T
P
5
T
P
0
A
U
I
1/2 ’74
TCK
SCLK SI
Register
TEST
17314A-9
AMD
IMR/IMR+ Overview
3-4
In this configuration, the IMR+ device will continuously output one of four status
conditions on the SO pin, dependent on the programming of the TEST and SI pins. The
programming of SI and TEST allows any one of the following status indications to be
reported on SO:
AUI Port Loop Back Status (1-bit) and Twisted Pair Port Link Status (8-bits)
AUI/Twisted Pair Port Partitioning Status (9-bits)
AUI Port SQE Test Error Status (1-bit) and Twisted Pair Polarity Status (8-bits)
AUI/Twisted Pair Port Bit Rate Error Status (9-bits)
The state of the SI and TEST pins can be changed at any time to select alternative
status of the SO pin.
The data on the SO pin is output as a 10-bit serial stream (AUI status first, followed by
TP0 status, TP1 status, etc.). A blank period of 100 ns will occur after the 9 status bits
have been output, during which time the STR pin will be active, delineating the start/end
of each “status window”. The SO output stream can be directly input to a serial-to-
parallel convertor, and used to drive LED status indicators using appropriate latches and
drivers. The details of the programming and timing of Minimum Mode are covered in the
following section.
Since the data presented on the SO pin may be valid for only one “status window”
(so an individual bit, such as the AUI Loop Back Error, may be active for only 100 ns),
external pulse stretch circuitry should be included to ensure that the LED indicators
are visible.
Note that the normal “Get” and “Set” capabilities of the IMR+ Management Port are
unavailable when Minimum Mode is selected.
3.2.3 Minimum Mode Operation
The IMR+ Minimum Mode supports designs of low end, unmanaged repeaters. This
mode uses minimal additional support logic to display the following status indicators:
■AUI Port Loop Back Status and Twisted Pair Port Link Status
■AUI/Twisted Pair Port Partitioning Status
■AUI Port SQE Test Error Status and Twisted Pair Port Receiver Polarity Status
■AUI/Twisted Pair Port Bit Rate Error Status
Additionally the Minimum Mode of the IMR+ chip supports automatic receive polarity
detection/correction without the addition of external logic.
The IMR+ device determines that Minimum Mode is selected by monitoring the state of
the TEST pin while RST is asserted. If TEST is HIGH (asserted), while reset is active
(RST LOW) it enters Minimum Mode. Additionally the state of the SI pin during reset
determines if the IMR+ device is to be programmed for Automatic Polarity Detection/
Correction.
The TEST input must be deasserted on the rising edge of reset. A maximum delay of
100 ns is allowed to account for propagation delay.
TEST SI Function
0 0 Normal Management Mode
0 1 Normal Management Mode
1 0 Minimum Mode, Receive Polarity Detection/Correction disabled.
1 1 Minimum Mode, Receive Polarity Detection/Correction enabled.
AMD
3-5
IMR/IMR+ Overview
In Minimum Mode, the SO pin is used to serially output the IMR+ chip’s status informa-
tion based on the state of the SI and SCLK pins:
SCLK SI SO Output
0 0 AUI Port SQE Test Error Status + TP Port Receive Polarity Status
0 1 Bit Rate Error Status (All ports)
1 0 AUI Port Loop Back Status + TP Ports Link Status
1 1 Partitioning Status (All ports)
The output format and timing is identical to that of the CRS and STR when the IMR+
device is used in the stand alone mode (see Figure 3-5).
Figure 3-5 Management Port Minimum Mode and Port Activity Monitor Signal Relationship
X1
CRS
(Note 2)
STR
CRS
AUI CRS
TP0 CRS
TP1 CRS
TP2 CRS
TP3 CRS
TP4 CRS
TP5 CRS
TP6 CRS
TP7 CRS
AUI
TCK
(Note 1)
SO
(Note 3) SO
AUI SO
TP0 SO
TP1 SO
TP2 SO
TP3 SO
TP4 SO
TP5 SO
TP6 SO
TP7 SO
AUI
Notes:
1. Externally generated signal illustrates internal IMR+ chip clock phase relationship.
2. CRS timing with the C-bit cleared (IMR+ Chip Programmable Options)
3. For Minimum Mode
17314A-10
When SI = 0, SO outputs the related AUI status bits (Loop Back Error or SQE Test
Error, depending on the value of SCLK), followed by the 8 TP status bits (receive
polarity or Link Status, depending on the value of SCLK). The TP status bits are output
in order from port 0 to port 7.
When SI = 1, the Port Partitioning Status or Port Bit Rate Error Status indicators are
output (depending on the value of SCLK). The AUI is output first, followed by the TP port
indicators starting with port 0.
The timing of the SO output matches that of the Port Activity Monitor (PAM). The state of
the SI and SCLK pins is checked at the end of every cycle after all port status indicators
have been output. The rising edge of the X1 clock, occurring before falling edge of STR,
is used to strobe in the state of the SI and SCLK pins.
The IMR+ device may be programmed into Minimum Mode only at reset, and cannot be
modified until a subsequent reset.
AMD
IMR/IMR+ Overview
3-6
3.3 PORT ACTIVITY MONITOR (PAM) OPERATION
Two IMR+ device pins, CRS and STR, are used to serially output the state of the
internal Carrier Sense signals from the AUI and the eight twisted pair ports. This
function together with external hardware or software can be used to monitor repeater
receive and collision activity. The accuracy of the CRS signals is 10 Bit Times (BT)
(1 µs). A transition to active state by any of the internal carrier sense bits that lasts for
less than 10BT is latched internally and is used to set the appropriate bit during the next
sample period. See Figure 3-5 for an illustration of the timing of the port activity monitor.
3.3.1 Stand-Alone IMR/IMR+ Device (With STR Output)
Figure 3-6 shows how external hardware can be employed to convert the serial CRS bit
stream into a parallel format suitable for a “receive activity” display. Note that since the
data presented on the CRS pin may be valid for only a single 100 ns period, and the fact
that a maximum Ethernet packet length is only ~1.2 ms in duration, external pulse
stretch circuitry should be included to ensure that the LED indicators are visible.
Figure 3-6 Port Activity Monitor
IMR/IMR+
XTAL
OSC
CK
D
Q
ASYNC
RESET
X1
X2
RST STR
CRS
CLR
CK Q
QD
1/2 ’74
TCK
CK
SI SIPO
CK Register
T
P
7
T
P
6
T
P
5
T
P
0
A
U
I
Shift Register
Carrier Sense Outputs
1/2 ’74
TCK
17314A-11