summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1516.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1516.txt')
-rw-r--r--doc/rfc/rfc1516.txt2243
1 files changed, 2243 insertions, 0 deletions
diff --git a/doc/rfc/rfc1516.txt b/doc/rfc/rfc1516.txt
new file mode 100644
index 0000000..f8ec6ad
--- /dev/null
+++ b/doc/rfc/rfc1516.txt
@@ -0,0 +1,2243 @@
+
+
+
+
+
+
+Network Working Group D. McMaster
+Request for Comments: 1516 SynOptics Communications, Inc.
+Obsoletes: 1368 K. McCloghrie
+ Hughes LAN Systems, Inc.
+ September 1993
+
+
+ Definitions of Managed Objects
+ for IEEE 802.3 Repeater Devices
+
+Status of this Memo
+
+ This RFC specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ 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 the Internet community.
+ In particular, it defines objects for managing IEEE 802.3 10
+ Mb/second baseband repeaters, sometimes referred to as "hubs."
+
+Table of Contents
+
+ 1. The Network Management Framework ...................... 2
+ 1.1 Object Definitions ................................... 2
+ 2. Overview .............................................. 2
+ 2.1 Terminology .......................................... 3
+ 2.1.1 Repeaters, Hubs and Concentrators .................. 3
+ 2.1.2 Repeaters, Ports, and MAUs ......................... 3
+ 2.1.3 Ports and Groups ................................... 5
+ 2.1.4 Internal Ports and MAUs ............................ 6
+ 2.2 Supporting Functions ................................. 7
+ 2.3 Structure of MIB ..................................... 9
+ 2.3.1 The Basic Group Definitions ........................ 10
+ 2.3.2 The Monitor Group Definitions ...................... 10
+ 2.3.3 The Address Tracking Group Definitions ............ 10
+ 2.4 Relationship to Other MIBs ........................... 10
+ 2.4.1 Relationship to the 'system' group ................. 10
+ 2.4.2 Relationship to the 'interfaces' group ............. 10
+ 2.5 Textual Conventions .................................. 11
+ 3. Definitions ........................................... 11
+ 3.1 MIB Groups in the Repeater MIB ....................... 12
+ 3.2 The Basic Group Definitions .......................... 13
+ 3.3 The Monitor Group Definitions ........................ 23
+
+
+
+McMaster & McCloghrie [Page 1]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ 3.4 The Address Tracking Group Definitions ............... 34
+ 3.5 Traps for use by Repeaters ........................... 36
+ 4. Changes from RFC 1368 ................................. 38
+ 5. Acknowledgments ....................................... 39
+ 6. References ............................................ 39
+ 7. Security Considerations ............................... 40
+ 8. Authors' Addresses .................................... 40
+
+1. The Network Management Framework
+
+ The Internet-standard Network Management Framework consists of
+ three components. They are:
+
+ o STD 16, RFC 1155 which defines the SMI, the mechanisms used for
+ describing and naming objects for the purpose of management.
+ STD 16, RFC 1212 defines a more concise description mechanism,
+ which is wholly consistent with the SMI.
+
+ o STD 17, RFC 1213 defines MIB-II, the core set of managed objects
+ for the Internet suite of protocols.
+
+ o STD 15, 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.
+
+1.1. Object Definitions
+
+ 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)
+ defined in the SMI. In particular, each object object type is named
+ by an OBJECT IDENTIFIER, an administratively assigned name. 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 descriptor, to
+ refer to the object type.
+
+2. 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 [7].
+
+ These Repeater MIB objects may be used to manage non-standard
+ repeater-like devices, but defining objects to describe
+
+
+
+McMaster & McCloghrie [Page 2]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ 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" [8].
+ Implementors of these MIB objects should note that [8] 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 the same instrumentation can be used to implement both
+ the IEEE and IETF management standards.
+
+2.1. Terminology
+
+2.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
+ 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."
+
+2.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 [7].
+
+
+
+
+McMaster & McCloghrie [Page 3]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ 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
+ 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
+
+
+
+McMaster & McCloghrie [Page 4]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ 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
+
+ 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.
+
+2.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
+
+
+
+McMaster & McCloghrie [Page 5]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ 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 [8], 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.
+
+ The object rptrGroupPortCapacity, which also has a maximum value of
+ 1024, indicates the maximum number of ports that a given group may
+ contain. 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 rptrGroupLastOperStatusChange will indicate that a change
+ took place.
+
+ Each port within the repeater is uniquely identified by a combination
+ of group number and port number, where port number is an integer in
+ the range 1..rptrGroupPortCapacity. As with groups within a
+ repeater, ports within a group may be sparsely numbered. Likewise,
+ ports may come and go within a group without causing a management
+ reset.
+
+2.1.4. Internal Ports and MAUs
+
+ Repeater ports may be thought of as sources of traffic into the
+ repeater. In addition to the externally visible ports mentioned
+ above, such as those with 10BASE-T MAUs, or AUI ports with external
+ transceivers, some implementations may have internal ports that are
+ not obvious to the end-user but are nevertheless sources of traffic
+
+
+
+McMaster & McCloghrie [Page 6]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ into the repeater. Examples include internal management ports,
+ through which an agent communicates, and ports connecting to a
+ backplane internal to the implementation.
+
+ Some implementations may not manage all of a repeater's ports. For
+ managed ports, there must be entries in the port table; unmanaged
+ ports will not show up in the table.
+
+ It is the decision of the implementor to select the appropriate
+ group(s) in which to place internal ports. GroupCapacity for a given
+ group always reflects the number of MANAGED ports in that group.
+
+ If some ports are unmanaged such that not all packet sources are
+ represented by managed ports, then the sum of the input counters for
+ the repeater will not equal the actual output of the repeater.
+
+2.2. Supporting Functions
+
+ The IEEE 802.3 Hub Management draft [8] defines the following seven
+ functions and seven signals used to describe precisely when port
+ counters are incremented. The relationship between the functions and
+ signals is shown in Figure 3.
+
+ The CollisionEvent, ActivityDuration, CarrierEvent, FramingError,
+ OctetCount, FCSError, and SourceAddress output signals defined here
+ are not retrievable MIB objects, but rather are concepts used in
+ defining the MIB objects. The inputs are defined in Section 9 of the
+ IEEE 802.3 standard [7].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McMaster & McCloghrie [Page 7]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ +---------+
+ |Collision|--------------------->CollisionEvent
+ CollIn(X)+>|Event |
+ | |Funct | +--------+
+ | +---------+ |Activity|
+ | +-------+ |Timing |->ActivityDuration
+ +>|Carrier| +---->|Funct |
+ |Event | | +--------+
+ DataIn(X)->|Funct |+-----+---------------->CarrierEvent
+ +-------+|
+ | +-------+
+ +>|Framing|------------>FramingError
+ |Funct | +-------+
+ decodedData---------->| |+>|Octet |
+ +-------+| |Count |->OctetCount
+ | |Funct |
+ | +-------+
+ | +-------+
+ Octet | |Cyclic |
+ Stream +>|Redund.|
+ | |Check |->FCSError
+ | |Funct |
+ | +-------+
+ | +-------+
+ | |Source |
+ +>|Address|->SourceAddress
+ |Funct |
+ +-------+
+
+ Figure 3. Port Functions Relationship
+
+ Collision Event Function: The collision event function asserts the
+ CollisionEvent signal when the CollIn(X) variable has the value
+ SQE. The CollisionEvent signal remains asserted until the assertion
+ of any CarrierEvent signal due to the reception of the following
+ event.
+
+ Carrier Event Function: The carrier event function asserts the
+ CarrierEvent signal when the repeater exits the IDLE state, Fig 9-2
+ [7], and the port has been determined to be port N. It deasserts
+ the CarrierEvent signal when, for a duration of at least Carrier
+ Recovery Time (Ref: 9.5.6.5 [7]), both the DataIn(N) variable has
+ the value II and the CollIn(N) variable has the value -SQE. The
+ value N is the port assigned at the time of transition from the IDLE
+ state.
+
+ Framing Function: The framing function recognizes the boundaries of
+ an incoming frame by monitoring the CarrierEvent signal and the
+
+
+
+McMaster & McCloghrie [Page 8]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ decoded data stream. Data bits are accepted while the CarrierEvent
+ signal is asserted. The framing function strips preamble and start
+ of frame delimiter from the received data stream. The remaining
+ bits are aligned along octet boundaries. If there is not an
+ integral number of octets, then FramingError shall be asserted. The
+ FramingError signal is cleared upon the assertion of the
+ CarrierEvent signal due to the reception of the following event.
+
+ Activity Timing Function: The activity timing function measures the
+ duration of the assertion of the CarrierEvent signal. This duration
+ value must be adjusted by removing the value of Carrier Recovery
+ Time (Ref: 9.5.6.5 [7]) to obtain the true duration of activity on
+ the network. The output of the Activity Timing function is the
+ ActivityDuration value, which represents the duration of the
+ CarrierEvent signal as expressed in units of bit times.
+
+ Octet Counting Function: The octet counting function counts the
+ number of complete octets received from the output of the framing
+ function. The output of the octet counting function is the
+ OctetCount value. The OctetCount value is reset to zero upon the
+ assertion of the CarrierEvent signal due to the reception of the
+ following event.
+
+ 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 [7]. If the FCS
+ generated according to this algorithm is not the same as the last
+ four octets received from the framing function then the FCSError
+ signal is asserted. The FCSError signal is cleared upon the
+ assertion of the CarrierEvent signal due to the reception of the
+ following event.
+
+ 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. The SourceAddress variable is
+ set to an invalid state upon the assertion of the CarrierEvent
+ signal due to the reception of the following event.
+
+2.3. Structure of MIB
+
+ Objects in this MIB are arranged into MIB groups. Each MIB group is
+ organized as a set of related objects.
+
+
+
+
+
+McMaster & McCloghrie [Page 9]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+2.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 the repeater, as
+ well as for the individual ports themselves.
+
+2.3.2. The Monitor Group Definitions
+
+ This optional group contains monitoring statistics for the repeater
+ as a whole and for individual ports.
+
+2.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.
+
+2.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 [3].
+
+2.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.
+
+2.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
+ 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 data based on any
+ packet-related information (such as checksum or addresses). A
+
+
+
+McMaster & McCloghrie [Page 10]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ 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.)
+
+2.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.
+
+3. Definitions
+
+ SNMP-REPEATER-MIB DEFINITIONS ::= BEGIN
+
+ IMPORTS
+ Counter, TimeTicks, Gauge
+ FROM RFC1155-SMI
+ DisplayString FROM RFC1213-MIB
+ TRAP-TYPE FROM RFC-1215
+ OBJECT-TYPE FROM RFC-1212;
+
+
+ snmpDot3RptrMgt OBJECT IDENTIFIER ::= { mib-2 22 }
+
+
+ -- All representations of MAC addresses in this MIB Module use,
+ -- as a textual convention (i.e., this convention does not 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.
+
+
+ -- References
+ --
+ -- The following references are used throughout this MIB:
+ --
+
+
+
+McMaster & McCloghrie [Page 11]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ -- [IEEE 802.3 Std]
+ -- refers to 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, September 21, 1990).
+ --
+ -- [IEEE 802.3 Rptr Mgt]
+ -- refers to IEEE P802.3K, 'Layer Management for 10 Mb/s
+ -- Baseband Repeaters, Section 19,' Draft Supplement to
+ -- ANSI/IEEE 802.3, (Draft 8, April 9, 1992)
+
+
+ -- MIB Groups
+ --
+ -- The rptrBasicPackage group is mandatory.
+ -- The rptrMonitorPackage and rptrAddrTrackPackage
+ -- groups are 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
+ OBJECT IDENTIFIER ::= { rptrBasicPackage 2 }
+ rptrPortInfo
+ OBJECT IDENTIFIER ::= { rptrBasicPackage 3 }
+
+ rptrMonitorRptrInfo
+ OBJECT IDENTIFIER ::= { rptrMonitorPackage 1 }
+ rptrMonitorGroupInfo
+ OBJECT IDENTIFIER ::= { rptrMonitorPackage 2 }
+ rptrMonitorPortInfo
+ OBJECT IDENTIFIER ::= { rptrMonitorPackage 3 }
+
+ rptrAddrTrackRptrInfo -- this subtree is currently unused
+
+
+
+McMaster & McCloghrie [Page 12]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 1 }
+ rptrAddrTrackGroupInfo -- this subtree is currently unused
+ 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 the repeater, 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.
+
+ 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 IEEE 802.3 Rptr Mgt, 19.2.3.2,
+ aRepeaterGroupCapacity."
+ ::= { rptrRptrInfo 1 }
+
+ rptrOperStatus OBJECT-TYPE
+
+
+
+McMaster & McCloghrie [Page 13]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ SYNTAX INTEGER {
+ other(1), -- undefined or unknown status
+ 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 rptrOperStatus 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, listed highest
+ priority first:
+
+ rptrFailure(3)
+ groupFailure(4)
+ portFailure(5)
+ generalFailure(6)."
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.3.2,
+ aRepeaterHealthState."
+ ::= { rptrRptrInfo 2 }
+
+ rptrHealthText OBJECT-TYPE
+ SYNTAX DisplayString (SIZE (0..255))
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "The health text object is a text string that
+ provides information relevant to the operational
+ state of the repeater. Agents may use this string
+ to provide detailed information on current
+ failures, including how they were detected, and/or
+ instructions for problem resolution. The contents
+ are agent-specific."
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.3.2,
+ aRepeaterHealthText."
+ ::= { rptrRptrInfo 3 }
+
+
+
+McMaster & McCloghrie [Page 14]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ rptrReset OBJECT-TYPE
+ SYNTAX INTEGER {
+ noReset(1),
+ reset(2)
+ }
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "Setting this object to reset(2) causes a
+ transition to the START state of Fig 9-2 in
+ section 9 [IEEE 802.3 Std].
+
+ Setting this object to noReset(1) has no effect.
+ The agent will always return the value noReset(1)
+ when this object is read.
+
+ After receiving a request to set this variable to
+ reset(2), the agent is allowed to delay the reset
+ for a short period. For example, the implementor
+ may choose to delay the reset long enough to allow
+ the SNMP response to be transmitted. In any
+ event, the SNMP response must be transmitted.
+
+ This action does not reset the management counters
+ defined in this document nor does it affect the
+ portAdminStatus parameters. Included in this
+ action is the execution of a disruptive Self-Test
+ with the following characteristics: a) The nature
+ of the tests is not specified. b) The test resets
+ the repeater but without affecting management
+ information about the repeater. c) The test does
+ not inject packets onto any segment. d) Packets
+ received during the test may or may not be
+ transferred. e) The test does not interfere with
+ management functions.
+
+ After performing this self-test, the agent will
+ update the repeater health information (including
+ rptrOperStatus and rptrHealthText), and send a
+ rptrHealth trap."
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.3.3,
+ acResetRepeater."
+ ::= { rptrRptrInfo 4 }
+
+ rptrNonDisruptTest OBJECT-TYPE
+ SYNTAX INTEGER {
+ noSelfTest(1),
+
+
+
+McMaster & McCloghrie [Page 15]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ selfTest(2)
+ }
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "Setting this object to selfTest(2) causes the
+ repeater to perform a agent-specific, non-
+ disruptive self-test that has the following
+ characteristics: a) The nature of the tests is
+ not specified. b) The test does not change the
+ state of the repeater or management information
+ about the repeater. c) The test does not inject
+ packets onto any segment. d) The test does not
+ prevent the relay of any packets. e) The test
+ does not interfere with management functions.
+
+ After performing this test, the agent will update
+ the repeater health information (including
+ rptrOperStatus and rptrHealthText) and send a
+ rptrHealth trap.
+
+ Note that this definition allows returning an
+ 'okay' result after doing a trivial test.
+
+ Setting this object to noSelfTest(1) has no
+ effect. The agent will always return the value
+ noSelfTest(1) when this object is read."
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.3.3,
+ acExecuteNonDisruptiveSelfTest."
+ ::= { rptrRptrInfo 5 }
+
+ rptrTotalPartitionedPorts OBJECT-TYPE
+ SYNTAX Gauge
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "This object returns the total number of ports in
+ the repeater whose current state meets all three
+ of the following criteria: rptrPortOperStatus
+ does not have the value notPresent(3),
+ rptrPortAdminStatus is enabled(1), and
+ rptrPortAutoPartitionState is autoPartitioned(2)."
+ ::= { rptrRptrInfo 6 }
+
+
+
+
+
+
+
+McMaster & McCloghrie [Page 16]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ --
+ -- 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."
+ INDEX { rptrGroupIndex }
+ ::= { rptrGroupTable 1 }
+
+ RptrGroupEntry ::=
+ SEQUENCE {
+ rptrGroupIndex
+ INTEGER,
+ rptrGroupDescr
+ DisplayString,
+ rptrGroupObjectID
+ OBJECT IDENTIFIER,
+ rptrGroupOperStatus
+ INTEGER,
+ rptrGroupLastOperStatusChange
+ TimeTicks,
+ rptrGroupPortCapacity
+ INTEGER
+ }
+
+ rptrGroupIndex OBJECT-TYPE
+ SYNTAX INTEGER (1..1024)
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "This object identifies the group within the
+ repeater for which this entry contains
+ information. This value is never greater than
+ rptrGroupCapacity."
+
+
+
+McMaster & McCloghrie [Page 17]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.5.2,
+ aGroupID."
+ ::= { 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 types of groups in the repeater. Plug-in
+ Module, Rev A' or 'Barney Rubble 10BASE-T 4-port
+ SIMM socket Version 2.1' are examples of valid
+ group descriptions.
+
+ It is mandatory that this only contain printable
+ ASCII characters."
+ ::= { rptrGroupEntry 2 }
+
+ rptrGroupObjectID OBJECT-TYPE
+ SYNTAX OBJECT IDENTIFIER
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "The vendor's authoritative identification of the
+ group. This value may be 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 object 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.'"
+ ::= { rptrGroupEntry 3 }
+
+ rptrGroupOperStatus OBJECT-TYPE
+ SYNTAX INTEGER {
+ other(1),
+ operational(2),
+ malfunctioning(3),
+ notPresent(4),
+
+
+
+McMaster & McCloghrie [Page 18]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ 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
+ is temporarily or permanently physically and/or
+ logically not a part of the repeater. It is an
+ implementation-specific matter as to whether the
+ agent effectively removes notPresent entries from
+ the table.
+
+ A status of operational(2) indicates that the
+ group is functioning, and a status of
+ malfunctioning(3) indicates that the group is
+ malfunctioning in some way."
+ ::= { rptrGroupEntry 4 }
+
+ rptrGroupLastOperStatusChange OBJECT-TYPE
+ SYNTAX TimeTicks
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "An object that contains the value of sysUpTime at
+ the time that the value of the rptrGroupOperStatus
+ object for this group last changed.
+
+ A value of zero indicates that the group's
+ operational status has not changed since the agent
+ last restarted."
+ ::= { 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
+
+
+
+McMaster & McCloghrie [Page 19]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ number of ports on a module, card, or board, and
+ the port numbers will correspond to numbers marked
+ on the physical embodiment."
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.5.2,
+ aGroupPortCapacity."
+ ::= { rptrGroupEntry 6 }
+
+
+ --
+ -- 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,
+ rptrPortAdminStatus
+ INTEGER,
+ rptrPortAutoPartitionState
+ INTEGER,
+ rptrPortOperStatus
+ INTEGER
+ }
+
+ rptrPortGroupIndex OBJECT-TYPE
+ SYNTAX INTEGER (1..1024)
+
+
+
+McMaster & McCloghrie [Page 20]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "This object identifies the group containing the
+ port for which this entry contains information."
+ ::= { rptrPortEntry 1 }
+
+ rptrPortIndex OBJECT-TYPE
+ SYNTAX INTEGER (1..1024)
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "This object identifies the port within the group
+ for which this entry contains information. This
+ value can never be greater than
+ rptrGroupPortCapacity for the associated group."
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
+ aPortID."
+ ::= { rptrPortEntry 2 }
+
+ rptrPortAdminStatus OBJECT-TYPE
+ SYNTAX INTEGER {
+ enabled(1),
+ disabled(2)
+ }
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "Setting this object to disabled(2) 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 status takes precedence over auto-
+ partition and functionally operates between the
+ auto-partition mechanism and the AUI/PMA.
+
+ Setting this object to enabled(1) enables the port
+ and exerts a BEGIN on the port's auto-partition
+ state machine.
+
+ (In effect, when a port is disabled, the value of
+ rptrPortAutoPartitionState for that port is frozen
+ until the port is next enabled. When the port
+
+
+
+McMaster & McCloghrie [Page 21]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ becomes enabled, the rptrPortAutoPartitionState
+ becomes notAutoPartitioned(1), regardless of its
+ pre-disabling state.)"
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
+ aPortAdminState and 19.2.6.3, acPortAdminControl."
+ ::= { rptrPortEntry 3 }
+
+ rptrPortAutoPartitionState OBJECT-TYPE
+ SYNTAX INTEGER {
+ notAutoPartitioned(1),
+ autoPartitioned(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 Section 9
+ [IEEE 802.3 Std]. They are not differentiated
+ here."
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
+ aAutoPartitionState."
+ ::= { rptrPortEntry 4 }
+
+ rptrPortOperStatus OBJECT-TYPE
+ SYNTAX INTEGER {
+ operational(1),
+ notOperational(2),
+ notPresent(3)
+ }
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "This object indicates the port's operational
+ status. The notPresent(3) status indicates the
+ port is physically removed (note this may or may
+ not be possible depending on the type of port.)
+ The operational(1) status indicates that the port
+ is enabled (see rptrPortAdminStatus) and working,
+ even though it might be auto-partitioned (see
+ rptrPortAutoPartitionState).
+
+ If this object has the value operational(1) and
+
+
+
+McMaster & McCloghrie [Page 22]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ rptrPortAdminStatus is set to disabled(2), it is
+ expected that this object's value will soon change
+ to notOperational(2)."
+ ::= { rptrPortEntry 5 }
+
+
+ --
+ -- 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, IEEE 802.3 Std).
+
+ The approximate minimum time for rollover of this
+ counter is 16 hours."
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.3.2,
+ aTransmitCollisions."
+ ::= { rptrMonitorRptrInfo 1 }
+
+
+ --
+ -- The Group Monitor Table
+ --
+
+ rptrMonitorGroupTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF RptrMonitorGroupEntry
+ ACCESS not-accessible
+ STATUS mandatory
+ DESCRIPTION
+ "Table of performance and error statistics for the
+
+
+
+McMaster & McCloghrie [Page 23]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ groups."
+ ::= { rptrMonitorGroupInfo 1 }
+
+ rptrMonitorGroupEntry OBJECT-TYPE
+ SYNTAX RptrMonitorGroupEntry
+ ACCESS not-accessible
+ STATUS mandatory
+ DESCRIPTION
+ "An entry in the table, containing total
+ performance and error statistics for a single
+ group. Regular retrieval of the information in
+ this table provides a means of tracking the
+ performance and health of the networked devices
+ attached to this group's ports.
+
+ The counters in this table are redundant in the
+ sense that they are the summations of information
+ already available through other objects. However,
+ these sums provide a considerable optimization of
+ network management traffic over the otherwise
+ necessary retrieval of the individual counters
+ included in each sum."
+ INDEX { rptrMonitorGroupIndex }
+ ::= { rptrMonitorGroupTable 1 }
+
+ RptrMonitorGroupEntry ::=
+ SEQUENCE {
+ rptrMonitorGroupIndex
+ INTEGER,
+ rptrMonitorGroupTotalFrames
+ Counter,
+ rptrMonitorGroupTotalOctets
+ Counter,
+ rptrMonitorGroupTotalErrors
+ Counter
+ }
+
+ rptrMonitorGroupIndex OBJECT-TYPE
+ SYNTAX INTEGER (1..1024)
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "This object identifies the group within the
+ repeater for which this entry contains
+ information."
+ ::= { rptrMonitorGroupEntry 1 }
+
+ rptrMonitorGroupTotalFrames OBJECT-TYPE
+
+
+
+McMaster & McCloghrie [Page 24]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "The total number of frames of valid frame length
+ that have been received on the ports in this group
+ and for which the FCSError and CollisionEvent
+ signals were not asserted. This counter is the
+ summation of the values of the
+ rptrMonitorPortReadableFrames counters for all of
+ the ports in the group.
+
+ This statistic provides one of the parameters
+ necessary for obtaining the packet error rate.
+ The approximate minimum time for rollover of this
+ counter is 80 hours."
+ ::= { rptrMonitorGroupEntry 2 }
+
+ rptrMonitorGroupTotalOctets OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "The total number of octets contained in the valid
+ frames that have been received on the ports in
+ this group. This counter is the summation of the
+ values of the rptrMonitorPortReadableOctets
+ counters for all of the ports in the group.
+
+ This statistic provides an indicator of the total
+ data transferred. The approximate minimum time
+ for rollover of this counter is 58 minutes."
+ ::= { rptrMonitorGroupEntry 3 }
+
+ rptrMonitorGroupTotalErrors OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "The total number of errors which have occurred on
+ all of the ports in this group. This counter is
+ the summation of the values of the
+ rptrMonitorPortTotalErrors counters for all of the
+ ports in the group."
+ ::= { rptrMonitorGroupEntry 4 }
+
+ --
+ -- The Port Monitor Table
+
+
+
+McMaster & McCloghrie [Page 25]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ --
+
+ 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,
+ rptrMonitorPortLateEvents
+ Counter,
+ rptrMonitorPortVeryLongEvents
+ Counter,
+ rptrMonitorPortDataRateMismatches
+
+
+
+McMaster & McCloghrie [Page 26]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ Counter,
+ rptrMonitorPortAutoPartitions
+ Counter,
+ rptrMonitorPortTotalErrors
+ Counter
+ }
+
+ rptrMonitorPortGroupIndex OBJECT-TYPE
+ SYNTAX INTEGER (1..1024)
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "This object identifies the group containing the
+ port for which this entry contains information."
+ ::= { rptrMonitorPortEntry 1 }
+
+ rptrMonitorPortIndex OBJECT-TYPE
+ SYNTAX INTEGER (1..1024)
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "This object identifies the port within the group
+ for which this entry contains information."
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
+ aPortID."
+ ::= { rptrMonitorPortEntry 2 }
+
+ rptrMonitorPortReadableFrames OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "This object is the number of frames of valid
+ frame length that have been received on this port.
+ This counter is incremented by one for each frame
+ received on this port whose OctetCount is greater
+ than or equal to minFrameSize and less than or
+ equal to maxFrameSize (Ref: IEEE 802.3 Std,
+ 4.4.2.1) and for which the FCSError and
+ CollisionEvent signals are not asserted.
+
+ This statistic provides one of the parameters
+ necessary for obtaining the packet error rate.
+ The approximate minimum time for rollover of this
+ counter is 80 hours."
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
+
+
+
+McMaster & McCloghrie [Page 27]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ aReadableFrames."
+ ::= { rptrMonitorPortEntry 3 }
+
+ rptrMonitorPortReadableOctets OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "This object is the number of octets contained in
+ valid frames that have been received on this port.
+ This counter is incremented by OctetCount for each
+ frame received on this port which has been
+ determined to be a readable frame (i.e., including
+ FCS octets but excluding framing bits and dribble
+ bits).
+
+ This statistic provides an indicator of the total
+ data transferred. The approximate minimum time
+ for rollover of this counter is 58 minutes."
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
+ aReadableOctets."
+ ::= { rptrMonitorPortEntry 4 }
+
+ rptrMonitorPortFCSErrors OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "This counter is incremented by one for each frame
+ received on this port with the FCSError signal
+ asserted and the FramingError and CollisionEvent
+ signals deasserted and whose OctetCount is greater
+ than or equal to minFrameSize and less than or
+ equal to maxFrameSize (Ref: 4.4.2.1, IEEE 802.3
+ Std).
+
+ The approximate minimum time for rollover of this
+ counter is 80 hours."
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
+ aFrameCheckSequenceErrors."
+ ::= { rptrMonitorPortEntry 5 }
+
+ rptrMonitorPortAlignmentErrors OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+
+
+
+McMaster & McCloghrie [Page 28]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ DESCRIPTION
+ "This counter is incremented by one for each frame
+ received on this port with the FCSError and
+ FramingError signals asserted and CollisionEvent
+ signal deasserted and whose OctetCount is greater
+ than or equal to minFrameSize and less than or
+ equal to maxFrameSize (Ref: IEEE 802.3 Std,
+ 4.4.2.1). If rptrMonitorPortAlignmentErrors is
+ incremented then the rptrMonitorPortFCSErrors
+ Counter shall not be incremented for the same
+ frame.
+
+ The approximate minimum time for rollover of this
+ counter is 80 hours."
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
+ aAlignmentErrors."
+ ::= { rptrMonitorPortEntry 6 }
+
+ rptrMonitorPortFrameTooLongs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "This counter is incremented by one for each frame
+ received on this port whose OctetCount is greater
+ than maxFrameSize (Ref: 4.4.2.1, IEEE 802.3 Std).
+ If rptrMonitorPortFrameTooLongs is incremented
+ then neither the rptrMonitorPortAlignmentErrors
+ nor the rptrMonitorPortFCSErrors counter shall be
+ incremented for the frame.
+
+ The approximate minimum time for rollover of this
+ counter is 61 days."
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
+ aFramesTooLong."
+ ::= { rptrMonitorPortEntry 7 }
+
+ rptrMonitorPortShortEvents OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "This counter is incremented by one for each
+ CarrierEvent on this port with ActivityDuration
+ less than ShortEventMaxTime. ShortEventMaxTime is
+ greater than 74 bit times and less than 82 bit
+
+
+
+McMaster & McCloghrie [Page 29]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ times. 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 externally
+ generated noise hits which will cause the repeater
+ 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.
+
+ Implementors may wish to consider selecting the
+ ShortEventMaxTime towards the lower end of the
+ allowed tolerance range to accommodate bit losses
+ suffered through physical channel devices not
+ budgeted for within this standard.
+
+ The approximate minimum time for rollover of this
+ counter is 16 hours."
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
+ aShortEvents."
+ ::= { rptrMonitorPortEntry 8 }
+
+ rptrMonitorPortRunts OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "This counter is incremented by one for each
+ CarrierEvent on this port that meets one of the
+ following two conditions. Only one test need be
+ made. a) The ActivityDuration is greater than
+ ShortEventMaxTime and less than ValidPacketMinTime
+ and the CollisionEvent signal is deasserted. b)
+ The OctetCount is less than 64, the
+ ActivityDuration is greater than ShortEventMaxTime
+ and the CollisionEvent signal is deasserted.
+ ValidPacketMinTime is greater than or equal to 552
+ bit times and less than 565 bit times.
+
+ An event whose length is greater than 74 bit times
+ but less than 82 bit times shall increment either
+ the shortEvents counter or the runts counter but
+ not both. A CarrierEvent greater than or equal to
+ 552 bit times but less than 565 bit times may or
+ may not be counted as a runt.
+
+
+
+McMaster & McCloghrie [Page 30]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ ValidPacketMinTime has tolerances included to
+ provide for circuit losses between a conformance
+ test point at the AUI and the measurement point
+ within the state machine.
+
+ Runts usually indicate collision fragments, a
+ normal network event. In certain situations
+ associated with large diameter networks a
+ percentage of collision fragments may exceed
+ ValidPacketMinTime.
+
+ The approximate minimum time for rollover of this
+ counter is 16 hours."
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.6.2, aRunts."
+ ::= { rptrMonitorPortEntry 9 }
+
+ rptrMonitorPortCollisions OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "This counter is incremented by one for any
+ CarrierEvent signal on any port for which the
+ CollisionEvent signal on this port is also
+ asserted.
+
+ The approximate minimum time for rollover of this
+ counter is 16 hours."
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
+ aCollisions."
+ ::= { rptrMonitorPortEntry 10 }
+
+ rptrMonitorPortLateEvents OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "This counter is incremented by one for each
+ CarrierEvent on this port in which the CollIn(X)
+ variable transitions to the value SQE (Ref:
+ 9.6.6.2, IEEE 802.3 Std) while the
+ ActivityDuration is greater than the
+ LateEventThreshold. Such a CarrierEvent is
+ counted twice, as both a collision and as a
+ lateEvent.
+
+
+
+
+McMaster & McCloghrie [Page 31]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ The LateEventThreshold is greater than 480 bit
+ times and less than 565 bit times.
+ LateEventThreshold has tolerances included to
+ permit an implementation to build a single
+ threshold to serve as both the LateEventThreshold
+ and ValidPacketMinTime threshold.
+
+ The approximate minimum time for rollover of this
+ counter is 81 hours."
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
+ aLateEvents."
+ ::= { rptrMonitorPortEntry 11 }
+
+ rptrMonitorPortVeryLongEvents OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "This counter is incremented by one for each
+ CarrierEvent on this port whose ActivityDuration
+ is greater than the MAU Jabber Lockup Protection
+ timer TW3 (Ref: 9.6.1 & 9.6.5, IEEE 802.3 Std).
+ Other counters may be incremented as appropriate."
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
+ aVeryLongEvents."
+ ::= { rptrMonitorPortEntry 12 }
+
+ rptrMonitorPortDataRateMismatches OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "This counter is incremented by one for each frame
+ received on this port that meets all of the
+ following conditions: a) The CollisionEvent
+ signal is not asserted. b) The ActivityDuration
+ is greater than ValidPacketMinTime. c) The
+ frequency (data rate) is detectably mismatched
+ from the local transmit frequency. The exact
+ degree of mismatch is vendor specific and is to be
+ defined by the vendor for conformance testing.
+
+ When this event occurs, other counters whose
+ increment conditions were satisfied may or may not
+ also be incremented, at the implementor's
+ discretion. Whether or not the repeater was able
+
+
+
+McMaster & McCloghrie [Page 32]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ to maintain data integrity is beyond the scope of
+ this standard."
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
+ aDataRateMismatches."
+ ::= { rptrMonitorPortEntry 13 }
+
+ rptrMonitorPortAutoPartitions OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "This counter is incremented by one for each time
+ the repeater has automatically partitioned this
+ port. The conditions that cause port partitioning
+ are specified in the partition state machine in
+ Section 9 [IEEE 802.3 Std]. They are not
+ differentiated here."
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
+ aAutoPartitions."
+ ::= { rptrMonitorPortEntry 14 }
+
+ rptrMonitorPortTotalErrors OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "The total number of errors which have occurred on
+ this port. This counter is the summation of the
+ values of other error counters (for the same
+ port), namely:
+
+ rptrMonitorPortFCSErrors,
+ rptrMonitorPortAlignmentErrors,
+ rptrMonitorPortFrameTooLongs,
+ rptrMonitorPortShortEvents,
+ rptrMonitorPortLateEvents,
+ rptrMonitorPortVeryLongEvents, and
+ rptrMonitorPortDataRateMismatches.
+
+ This counter is redundant in the sense that it is
+ the summation of information already available
+ through other objects. However, it is included
+ specifically because the regular retrieval of this
+ object as a means of tracking the health of a port
+ provides a considerable optimization of network
+ management traffic over the otherwise necessary
+
+
+
+McMaster & McCloghrie [Page 33]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ retrieval of the summed counters."
+ ::= { rptrMonitorPortEntry 15 }
+
+
+ --
+ -- The ADDRESS TRACKING GROUP
+ --
+ -- Implementation of this group is optional; it is appropriate
+ -- for all systems which have the necessary instrumentation. If a
+ -- managed repeater implements any part of this group, the entire
+ -- group shall be implemented.
+
+ --
+ -- The Port Address Tracking Table
+ --
+
+ rptrAddrTrackTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF RptrAddrTrackEntry
+ ACCESS not-accessible
+ STATUS mandatory
+ DESCRIPTION
+ "Table of address mapping information about the
+ ports."
+ ::= { rptrAddrTrackPortInfo 1 }
+
+ rptrAddrTrackEntry OBJECT-TYPE
+ SYNTAX RptrAddrTrackEntry
+ ACCESS not-accessible
+ STATUS mandatory
+ DESCRIPTION
+ "An entry in the table, containing address mapping
+ information about a single port."
+ INDEX { rptrAddrTrackGroupIndex, rptrAddrTrackPortIndex }
+ ::= { rptrAddrTrackTable 1 }
+
+ RptrAddrTrackEntry ::=
+ SEQUENCE {
+ rptrAddrTrackGroupIndex
+ INTEGER,
+ rptrAddrTrackPortIndex
+ INTEGER,
+ rptrAddrTrackLastSourceAddress -- DEPRECATED OBJECT
+ MacAddress,
+ rptrAddrTrackSourceAddrChanges
+ Counter,
+ rptrAddrTrackNewLastSrcAddress
+ OCTET STRING
+ }
+
+
+
+McMaster & McCloghrie [Page 34]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ rptrAddrTrackGroupIndex OBJECT-TYPE
+ SYNTAX INTEGER (1..1024)
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "This object identifies the group containing the
+ port for which this entry contains information."
+ ::= { rptrAddrTrackEntry 1 }
+
+ rptrAddrTrackPortIndex OBJECT-TYPE
+ SYNTAX INTEGER (1..1024)
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "This object identifies the port within the group
+ for which this entry contains information."
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
+ aPortID."
+ ::= { rptrAddrTrackEntry 2 }
+
+ rptrAddrTrackLastSourceAddress OBJECT-TYPE
+ SYNTAX MacAddress
+ ACCESS read-only
+ STATUS deprecated
+ DESCRIPTION
+ "This object is the SourceAddress of the last
+ readable frame (i.e., counted by
+ rptrMonitorPortReadableFrames) received by this
+ port.
+
+ This object has been deprecated because its value
+ is undefined when no frames have been observed on
+ this port. The replacement object is
+ rptrAddrTrackNewLastSrcAddress."
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
+ aLastSourceAddress."
+ ::= { rptrAddrTrackEntry 3 }
+
+ rptrAddrTrackSourceAddrChanges OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "This counter is incremented by one for each time
+ that the rptrAddrTrackLastSourceAddress attribute
+ for this port has changed.
+
+
+
+McMaster & McCloghrie [Page 35]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ This may indicate whether a link is connected to a
+ single DTE or another multi-user segment.
+
+ The approximate minimum time for rollover of this
+ counter is 81 hours."
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
+ aSourceAddressChanges."
+ ::= { rptrAddrTrackEntry 4 }
+
+ rptrAddrTrackNewLastSrcAddress OBJECT-TYPE
+ SYNTAX OCTET STRING (SIZE(0 | 6))
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "This object is the SourceAddress of the last
+ readable frame (i.e., counted by
+ rptrMonitorPortReadableFrames) received by this
+ port. If no frames have been received by this
+ port since the agent began monitoring the port
+ activity, the agent shall return a string of
+ length zero."
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
+ aLastSourceAddress."
+ ::= { rptrAddrTrackEntry 5 }
+
+
+ -- Traps for use by Repeaters
+
+ -- Traps are defined using the conventions in RFC 1215 [6].
+
+ rptrHealth TRAP-TYPE
+ ENTERPRISE snmpDot3RptrMgt
+ VARIABLES { rptrOperStatus }
+ DESCRIPTION
+ "The rptrHealth trap conveys information related
+ to the operational status of the repeater. This
+ trap is sent either when the value of
+ rptrOperStatus changes, or upon completion of a
+ non-disruptive test.
+
+ The rptrHealth trap must contain the
+ rptrOperStatus object. The agent may optionally
+ include the rptrHealthText object in the varBind
+ list. See the rptrOperStatus and rptrHealthText
+ objects for descriptions of the information that
+ is sent.
+
+
+
+McMaster & McCloghrie [Page 36]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ The agent must throttle the generation of
+ consecutive rptrHealth traps so that there is at
+ least a five-second gap between traps of this
+ type. When traps are throttled, they are dropped,
+ not queued for sending at a future time. (Note
+ that 'generating' a trap means sending to all
+ configured recipients.)"
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.3.4,
+ hubHealth notification."
+ ::= 1
+
+ rptrGroupChange TRAP-TYPE
+ ENTERPRISE snmpDot3RptrMgt
+ VARIABLES { rptrGroupIndex }
+ DESCRIPTION
+ "This trap is sent when a change occurs in the
+ group structure of a repeater. This occurs only
+ when a group is logically or physically removed
+ from or added to a repeater. The varBind list
+ contains the identifier of the group that was
+ removed or added.
+
+ The agent must throttle the generation of
+ consecutive rptrGroupChange traps for the same
+ group so that there is at least a five-second gap
+ between traps of this type. When traps are
+ throttled, they are dropped, not queued for
+ sending at a future time. (Note that 'generating'
+ a trap means sending to all configured
+ recipients.)"
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.3.4,
+ groupMapChange notification."
+ ::= 2
+
+ rptrResetEvent TRAP-TYPE
+ ENTERPRISE snmpDot3RptrMgt
+ VARIABLES { rptrOperStatus }
+ DESCRIPTION
+ "The rptrResetEvent trap conveys information
+ related to the operational status of the repeater.
+ This trap is sent on completion of a repeater
+ reset action. A repeater reset action is defined
+ as an a transition to the START state of Fig 9-2
+ in section 9 [IEEE 802.3 Std], when triggered by a
+ management command (e.g., an SNMP Set on the
+ rptrReset object).
+
+
+
+McMaster & McCloghrie [Page 37]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ The agent must throttle the generation of
+ consecutive rptrResetEvent traps so that there is
+ at least a five-second gap between traps of this
+ type. When traps are throttled, they are dropped,
+ not queued for sending at a future time. (Note
+ that 'generating' a trap means sending to all
+ configured recipients.)
+
+ The rptrResetEvent trap is not sent when the agent
+ restarts and sends an SNMP coldStart or warmStart
+ trap. However, it is recommended that a repeater
+ agent send the rptrOperStatus object as an
+ optional object with its coldStart and warmStart
+ trap PDUs.
+
+ The rptrOperStatus object must be included in the
+ varbind list sent with this trap. The agent may
+ optionally include the rptrHealthText object as
+ well."
+ REFERENCE
+ "Reference IEEE 802.3 Rptr Mgt, 19.2.3.4, hubReset
+ notification."
+ ::= 3
+
+ END
+
+
+4. Changes from RFC 1368
+
+ (1) Added section 2.1.4, "Internal Ports and MAUs," that defines
+ internal ports and clarifies how they may or may not be
+ managed.
+
+ (2) Noted that the failure list for rptrOperStatus is ordered
+ highest priority first.
+
+ (3) Clarified rptrReset description to indicate that the agent
+ may briefly delay the reset action.
+
+ (4) For rptrReset, clarified the actions that the agent should
+ take after performing the reset and self-test.
+
+ (5) For rptrNonDisruptTest, similar change to (3).
+
+ (6) Clarified that the rptrNonDisruptTest description allows
+ returning "ok" after doing only a trivial test.
+
+ (7) Deprecated rptrAddrTrackLastSourceAddress and defined a
+
+
+
+McMaster & McCloghrie [Page 38]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ replacement object that has a zero-length value until the
+ first frame is seen on the port.
+
+ (8) Clarified that rptrHealth trap is sent after
+ rptrNonDisruptTest even if repeater health information
+ doesn't change as a result of the test.
+
+ (9) Clarified text on throttling traps.
+
+5. Acknowledgments
+
+ This document is the work of the IETF Hub MIB Working Group. It is
+ based on drafts of the IEEE 802.3 Repeater Management Task Force.
+
+6. References
+
+ [1] Rose M., and K. McCloghrie, "Structure and Identification of
+ Management Information for TCP/IP-based internets", STD 16, RFC
+ 1155, Performance Systems International, Hughes LAN Systems, May
+ 1990.
+
+ [2] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
+ Network Management Protocol", STD 15, RFC 1157, SNMP Research,
+ Performance Systems International, Performance Systems
+ International, MIT Laboratory for Computer Science, May 1990.
+
+ [3] McCloghrie K., and M. Rose, Editors, "Management Information
+ Base for Network Management of TCP/IP-based internets", STD 17,
+ RFC 1213, Performance Systems International, March 1991.
+
+ [4] Information processing systems - Open Systems Interconnection -
+ Specification of Abstract Syntax Notation One (ASN.1),
+ International Organization for Standardization, International
+ Standard 8824, December 1987.
+
+ [5] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
+ STD 16, RFC 1212, Performance Systems International, Hughes LAN
+ Systems, March 1991.
+
+ [6] Rose, M., Editor, "A Convention for Defining Traps for use with
+ the SNMP", RFC 1215, Performance Systems International, March
+ 1991.
+
+ [7] IEEE 802.3/ISO 8802-3 - Information processing systems - Local
+ area networks - Part 3: Carrier sense multiple access with
+ collision detection (CSMA/CD) access method and physical layer
+ specifications, 2nd edition, 21 September 1990.
+
+
+
+
+McMaster & McCloghrie [Page 39]
+
+RFC 1516 802.3 Repeater MIB September 1993
+
+
+ [8] IEEE P802.3K - Layer Management for 10 Mb/s Baseband Repeaters,
+ Section 19, Draft Supplement to ANSI/IEEE 802.3, Draft 8, 9
+ April 1992.
+
+7. Security Considerations
+
+ Security issues are not discussed in this memo.
+
+8. Authors' Addresses
+
+ Donna McMaster
+ SynOptics Communications, Inc.
+ 4401 Great America Parkway
+ P.O. Box 58185
+ Santa Clara, CA 95052-8185
+
+ Phone: (408) 764-1206
+ EMail: mcmaster@synoptics.com
+
+
+ Keith McCloghrie
+ Hughes LAN Systems, Inc.
+ 1225 Charleston Road
+ Mountain View, CA 94043
+
+ Phone: (415) 966-7934
+ EMail: kzm@hls.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McMaster & McCloghrie [Page 40]
+ \ No newline at end of file