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