📄 rfc1368.txt
字号:
Network Working Group D. McMaster
Request for Comments: 1368 SynOptics Communications, Inc.
K. McCloghrie
Hughes LAN Systems, Inc.
October 1992
Definitions of Managed Objects for IEEE 802.3 Repeater Devices
Status of this Memo
This RFC specifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements.
Please refer to the current edition of the "IAB Official Protocol
Standards" for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
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 10
Mb/second baseband repeaters, sometimes referred to as "hubs."
Table of Contents
1. Management Framework ........................................ 2
2. Objects ..................................................... 2
2.1 Format of Definitions ...................................... 3
3. Overview .................................................... 3
3.1 Terminology ................................................ 3
3.1.1 Repeaters, Hubs and Concentrators ........................ 3
3.1.2 Repeaters, Ports, and MAUs ............................... 4
3.1.3 Ports and Groups ......................................... 6
3.2 Supporting Functions ....................................... 7
3.3 Structure of MIB ........................................... 9
3.3.1 The Basic Group Definitions .............................. 10
3.3.2 The Monitor Group Definitions ............................ 10
3.3.3 The Address Tracking Group Definitions ................... 10
3.4 Relationship to Other MIBs ................................. 10
3.4.1 Relationship to the 'system' group ....................... 10
3.4.2 Relationship to the 'interfaces' group .................... 10
3.5 Textual Conventions ........................................ 11
4. Definitions ................................................. 11
4.1 MIB Groups in the Repeater MIB ............................. 12
4.2 The Basic Group Definitions ................................ 13
4.3 The Monitor Group Definitions .............................. 23
4.4 The Address Tracking Group Definitions ..................... 33
McMaster & McCloghrie [Page 1]
RFC 1368 802.3 Repeater MIB October 1992
4.5 Traps for use by Repeaters ................................. 35
5. Acknowledgments ............................................. 37
6. References .................................................. 39
7. Security Considerations...................................... 40
8. Authors' Addresses........................................... 40
1. Management Framework
The Internet-standard Network Management Framework consists of three
components. They are:
STD 16/RFC 1155 [1] which defines the SMI, the mechanisms used for
describing and naming objects for the purpose of management. STD
16/RFC 1212 [7] defines a more concise description mechanism,
which is wholly consistent with the SMI.
RFC 1156 [2] which defines MIB-I, the core set of managed objects
for the Internet suite of protocols. STD 17/RFC 1213 [4] defines
MIB-II, an evolution of MIB-I based on implementation experience
and new operational requirements.
STD 15/RFC 1157 [3] 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.
2. 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) [5]
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 [1] 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
McMaster & McCloghrie [Page 2]
RFC 1368 802.3 Repeater MIB October 1992
notion of an object type's syntax and encoding is how the object type
is represented when being transmitted on the network.
The SMI specifies the use of the basic encoding rules of ASN.1 [6],
subject to the additional requirements imposed by the SNMP.
2.1. Format of Definitions
Section 4 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 [7,8].
3. Overview
Instances of the object types defined in this memo represent
attributes of an IEEE 802.3 (Ethernet-like) repeater, as defined by
Section 9, "Repeater Unit for 10 Mb/s Baseband Networks" in the IEEE
802.3/ISO 8802-3 CSMA/CD standard [9].
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." [10]
Implementors of these MIB objects should note that [10] 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.
The counters in this document are defined to be the same as those
counters in the IEEE 802.3 Repeater Management draft, with the
intention that a single instrumentation can be used to implement both
the IEEE and IETF management standards.
3.1. Terminology
3.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. Subsequently the 802.3 group changed the name of the
McMaster & McCloghrie [Page 3]
RFC 1368 802.3 Repeater MIB October 1992
task force to be the IEEE 802.3 Repeater Management Task Force, and
likewise renamed their draft.
The use of the term "hub" has led to some confusion, as the terms
"hub," "intelligent hub," and "concentrator" are often used 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 be clear that this work covers the management of IEEE 802.3
repeaters only, the editors of this MIB definitions document chose to
call this a "Repeater MIB" instead of a "Hub MIB."
3.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 [9].
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
Figure 1. Repeater Unit
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
McMaster & McCloghrie [Page 4]
RFC 1368 802.3 Repeater MIB October 1992
each of the remaining n-1 ports. If data comes in to the repeater 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 integrated into the same physical
package.
(MAU) (MAU)
\ \ / /
\ \ / /
_____\ v /_____
(MAU) ______ ______ (MAU)
/ ^ \
/ / \ \
/ / \ \
(MAU) (MAU)
Figure 2. Repeater Set
McMaster & McCloghrie [Page 5]
RFC 1368 802.3 Repeater MIB October 1992
The most commonly-used MAUs are the 10BASE-5 (AUI to thick "yellow"
coax), 10BASE-2 (BNC to thin coax), 10BASE-T (unshielded twisted-
pair), and FOIRL (asynchronous fiber optic inter-repeater link, 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 repeater 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. The IEEE
recognizes that MAU management should be the same for MAUs connected
to end-stations (DTEs) as it is for MAUs connected to repeaters.
This memo follows the same strategy; the definition of management
information for MAUs is being addressed in a separate memo.
3.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 Management draft [10], allowing an
implementor to separate the ports in a repeater into "groups", if
desired. For example, an implementor might 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, which has a maximum value of 1024,
indicates the maximum number of groups that a given repeater may
contain. The value of rptrGroupCapacity must remain constant from
one management restart to the next.
Each group within the repeater is uniquely identified by a group
number in the range 1..rptrGroupCapacity. Groups may come and go
without causing a management reset, and may be sparsely numbered
within the repeater. For example, in a 12-card cage, cards 3, 5, 6,
and 7 may together form a single repeater, and the implementor may
choose to number them as groups 3, 5, 6, and 7, respectively.
McMaster & McCloghrie [Page 6]
RFC 1368 802.3 Repeater MIB October 1992
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -