RFCs in HTML Format


RFC 1516

                     Definitions of Managed Objects
                    for IEEE 802.3 Repeater Devices

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
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.



Back to RFC index

 

Associates:

 



Sponsered-Sites:

Register domain name and transfer | Cheap webhosting service | Domain name registration

 

 

""