From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1515.txt | 1403 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1403 insertions(+) create mode 100644 doc/rfc/rfc1515.txt (limited to 'doc/rfc/rfc1515.txt') diff --git a/doc/rfc/rfc1515.txt b/doc/rfc/rfc1515.txt new file mode 100644 index 0000000..2322ded --- /dev/null +++ b/doc/rfc/rfc1515.txt @@ -0,0 +1,1403 @@ + + + + + + +Network Working Group D. McMaster +Request for Comments: 1515 SynOptics Communications, Inc. + K. McCloghrie + Hughes LAN Systems, Inc. + S. Roberts + Farallon Computing, Inc. + September 1993 + + + Definitions of Managed Objects + for IEEE 802.3 Medium Attachment Units (MAUs) + +Status of this Memo + + This RFC specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" for the standardization state and status + of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document 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 + Medium Attachment Units (MAUs). + +Table of Contents + + 1. The Network Management Framework ...................... 2 + 2. Objects ............................................... 2 + 3. Overview .............................................. 2 + 3.1 Terminology .......................................... 3 + 3.2 Structure of MIB ..................................... 3 + 3.2.1 The Repeater MAU Basic Group Definitions ........... 3 + 3.2.2 The Interface MAU Basic Group Definitions .......... 3 + 3.2.3 The Broadband MAU Basic Group Definitions .......... 3 + 3.3 Relationship to Other MIBs ........................... 3 + 3.3.1 Relationship to the 'system' group ................. 3 + 3.3.2 Relationship to the 'interfaces' group ............. 4 + 3.3.3 Relationship to the 802.3 Repeater MIB ............. 4 + 3.4 Management of Internal MAUs .......................... 4 + 4. Definitions ........................................... 5 + 4.1 Groups in the Repeater MAU MIB ....................... 5 + 4.1.1 The Repeater MAU Basic Group Definitions ........... 6 + 4.1.2 The Interface MAU Basic Group Definitions .......... 12 + 4.1.3 The Broadband MAU Basic Group Definitions .......... 18 + 4.2 Traps for use by 802.3 MAUs .......................... 20 + + + +McMaster, McCloghrie & Roberts [Page 1] + +RFC 1515 802.3 MAU MIB September 1993 + + + 5. Acknowledgments ....................................... 21 + 6. References ............................................ 23 + 7. Security Considerations ............................... 24 + 8. Authors' Addresses .................................... 25 + +1. The Network Management Framework + + The Internet-standard Network Management Framework consists of three + components. They are: + + STD 16, RFC 1155 [1] which defines the SMI, the mechanisms used + for describing and naming objects for the purpose of management. + STD 16, RFC 1212 [7] defines a more concise description mechanism, + which is wholly consistent with the SMI. + + STD 17, RFC 1213 [4] which defines MIB-II, the core set of managed + objects for the Internet suite of protocols. + + STD 15, RFC 1157 [3] which defines the SNMP, the protocol used for + network access to managed objects. + + The Framework permits new objects to be defined for the purpose of + experimentation and evaluation. + +2. 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. + +3. Overview + + Instances of the object types defined in this document represent + attributes of an IEEE 802.3 MAU. Several types of MAUs are defined + in the IEEE 802.3/ISO 8802-3 CSMA/CD standard [9]. + + These MAUs may be connected to IEEE 802.3 repeaters or to 802.3 + (Ethernet-like) interfaces. For convenience this document refers to + these devices as "repeater MAUs" and "interface MAUs." + + The definitions presented here are based on Draft 5 of Section 20 of + IEEE P802.3p, "Layer Management for 10 Mb/s Medium Attachment Units + + + +McMaster, McCloghrie & Roberts [Page 2] + +RFC 1515 802.3 MAU MIB September 1993 + + + (MAUs), Section 20" [10] dated 11 July 1992. + +3.1. Terminology + + Refer to Section 3.1.2 of [13] for simple definitions of the terms + "repeater," "port," and "MAU" as used in the context of this + document. For a more complete and precise definition of these terms, + refer to Section 9 of [9]. + +3.2. Structure of MIB + + Objects in this MIB are arranged into MIB groups. Each MIB group is + organized as a set of related objects. + +3.2.1. The Repeater MAU Basic Group Definitions + + This group contains all repeater MAU-related configuration, status, + and control objects. Implementation of the dot3RpMauBasicGroup is + mandatory for MAUs attached to repeaters. + +3.2.2. The Interface MAU Basic Group Definitions + + This group contains all interface MAU-related configuration, status, + and control objects. Implementation of the dot3IfMauBasicGroup is + mandatory for MAUs attached to interfaces. + +3.2.3. The Broadband MAU Basic Group Definitions + + This group contains all broadband-specific MAU-related configuration + objects. Implementation of the dot3BroadMauBasicGroup is mandatory + for 10BROAD36 MAUs, and is not appropriate for other types of MAUs. + +3.3. Relationship to Other MIBs + + It is assumed that an agent implementing this MIB will also implement + (at least) the 'system' group defined in MIB-II [4]. The following + sections identify other MIBs that such an agent should implement. + +3.3.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 + MAU. + + + + + + +McMaster, McCloghrie & Roberts [Page 3] + +RFC 1515 802.3 MAU MIB September 1993 + + +3.3.2. Relationship to the 'interfaces' group + + The sections of this document that define interface MAU-related + objects specify an extension to the 'interfaces' group of MIB-II [4]. + An agent implementing these interface-MAU related objects must also + implement the 'interfaces' group of MIB-II. The value of the same as + the value of 'ifIndex' used to instantiate the interface to which the + given MAU is connected. + + It is expected that an agent implementing the interface-MAU related + objects in this MIB will also implement the Ethernet-like Interfaces + MIB [11]. + + (Note that repeater ports are not represented as interfaces in the + sense of MIB-II's 'interfaces' group. See section 3.4.2 of the + repeater MIB [12] for more details.) + +3.3.3. Relationship to the 802.3 Repeater MIB + + The section of this document that defines repeater MAU-related + objects specifies an extension to the 802.3 Repeater MIB defined in + [13]. An agent implementing these repeater-MAU related objects must + also implement the 802.3 Repeater MIB. + + The values of 'rpMauGroupIndex' and 'rpMauPortIndex' used to + instantiate a repeater MAU variable shall be the same as the values + of 'rptrPortGroupIndex' and 'rptrPortIndex' used to instantiate the + port to which the given MAU is connected. + +3.4. Management of Internal MAUs + + In some situations, a MAU can be "internal" -- i.e., its + functionality is implemented entirely within a device. For example, + a managed repeater may contain an internal repeater- MAU and/or an + internal interface-MAU through which management communications + originating on one of the repeater's external ports pass in order to + reach the management agent associated with the repeater. Such + internal MAUs may or may not be managed. If they are managed, + objects describing their attributes should appear in the appropriate + MIB group -- dot3RpMauBasicGroup for internal repeater-MAUs and + dot3IfMauBasicGroup for internal interface-MAUs. + + + + + + + + + + +McMaster, McCloghrie & Roberts [Page 4] + +RFC 1515 802.3 MAU MIB September 1993 + + +4. Definitions + + MAU-MIB DEFINITIONS ::= BEGIN + + + IMPORTS + Counter FROM RFC1155-SMI + OBJECT-TYPE FROM RFC-1212 + TRAP-TYPE FROM RFC-1215; + + + snmpDot3MauMgt OBJECT IDENTIFIER ::= { mib-2 26 } + + + -- References + -- + -- The following references are used throughout this MIB: + -- + -- [RFC 1213] + -- refers to McCloghrie, K., and M. Rose, Editors, + -- Management Information Base for Network Management + -- of TCP/IP-based internets: MIB-II, STD 17, RFC 1213, + -- Hughes LAN Systems, Performance Systems International, + -- March 1991. + -- + -- [RFC 1368] + -- refers to McMaster, D., and K. McCloghrie, Editors, + -- Definitions of Managed Objects for IEEE 802.3 Repeater + -- Devices, RFC 1368, SynOptics Communications, Hughes + -- LAN Systems, October 1992. + -- + -- [IEEE 802.3 MAU Mgt] + -- refers to IEEE P802.3p, 'Layer Management for 10 Mb/s + -- Medium Access Unit (MAUs), Section 20,' Draft Supplement + -- to ANSI/IEEE 802.3, Draft 5, 11 July 1992. + + + -- MIB Groups + -- + -- The dot3RpMauBasicGroup is mandatory for MAUs attached to + -- repeaters. + -- The dot3IfMauBasicGroup is mandatory for MAUs attached to + -- DTEs (interfaces). + -- The dot3BroadMauBasicGroup is mandatory for broadband MAUs + -- attached to DTEs. + + + dot3RpMauBasicGroup + + + +McMaster, McCloghrie & Roberts [Page 5] + +RFC 1515 802.3 MAU MIB September 1993 + + + OBJECT IDENTIFIER ::= { snmpDot3MauMgt 1 } + dot3IfMauBasicGroup + OBJECT IDENTIFIER ::= { snmpDot3MauMgt 2 } + dot3BroadMauBasicGroup + OBJECT IDENTIFIER ::= { snmpDot3MauMgt 3 } + + + -- object identifiers for MAU types + -- (see rpMauType and ifMauType for usage) + dot3MauType + OBJECT IDENTIFIER ::= { snmpDot3MauMgt 4 } + dot3MauTypeAUI -- no internal MAU, view from AUI + OBJECT IDENTIFIER ::= { dot3MauType 1 } + dot3MauType10Base5 -- thick coax MAU (per 802.3 section 8) + OBJECT IDENTIFIER ::= { dot3MauType 2 } + dot3MauTypeFoirl -- FOIRL MAU (per 802.3 section 9.9) + OBJECT IDENTIFIER ::= { dot3MauType 3 } + dot3MauType10Base2 -- thin coax MAU (per 802.3 section 10) + OBJECT IDENTIFIER ::= { dot3MauType 4 } + dot3MauType10BaseT -- UTP MAU (per 802.3 section 14) + OBJECT IDENTIFIER ::= { dot3MauType 5 } + dot3MauType10BaseFP -- passive fiber MAU (per 802.3 section 16) + OBJECT IDENTIFIER ::= { dot3MauType 6 } + dot3MauType10BaseFB -- sync fiber MAU (per 802.3 section 17) + OBJECT IDENTIFIER ::= { dot3MauType 7 } + dot3MauType10BaseFL -- async fiber MAU (per 802.3 section 18) + OBJECT IDENTIFIER ::= { dot3MauType 8 } + dot3MauType10Broad36 -- broadband DTE MAU (per 802.3 section 11) + -- note that 10BROAD36 MAUs can be attached to interfaces but + -- not to repeaters + OBJECT IDENTIFIER ::= { dot3MauType 9 } + + + -- + -- The Repeater MAU Basic Group + -- + -- Implementation of the Repeater MAU Basic Group is mandatory + -- for MAUs attached to repeaters. + + -- + -- The Basic Repeater MAU Table + -- + + rpMauTable OBJECT-TYPE + SYNTAX SEQUENCE OF RpMauEntry + ACCESS not-accessible + STATUS mandatory + DESCRIPTION + + + +McMaster, McCloghrie & Roberts [Page 6] + +RFC 1515 802.3 MAU MIB September 1993 + + + "Table of descriptive and status information about + the MAU(s) attached to the ports of a repeater." + ::= { dot3RpMauBasicGroup 1 } + + rpMauEntry OBJECT-TYPE + SYNTAX RpMauEntry + ACCESS not-accessible + STATUS mandatory + DESCRIPTION + "An entry in the table, containing information + about a single MAU." + INDEX { rpMauGroupIndex, rpMauPortIndex, rpMauIndex } + ::= { rpMauTable 1 } + + RpMauEntry ::= + SEQUENCE { + rpMauGroupIndex + INTEGER, + rpMauPortIndex + INTEGER, + rpMauIndex + INTEGER, + rpMauType + OBJECT IDENTIFIER, + rpMauStatus + INTEGER, + rpMauMediaAvailable + INTEGER, + rpMauMediaAvailableStateExits + Counter, + rpMauJabberState + INTEGER, + rpMauJabberingStateEnters + Counter + } + + rpMauGroupIndex OBJECT-TYPE + SYNTAX INTEGER (1..1024) + ACCESS read-only + STATUS mandatory + DESCRIPTION + "This variable uniquely identifies the repeater + group containing the port to which the MAU + described by this entry is connected." + REFERENCE + "Reference RFC1368, rptrGroupIndex." + ::= { rpMauEntry 1 } + + + + +McMaster, McCloghrie & Roberts [Page 7] + +RFC 1515 802.3 MAU MIB September 1993 + + + rpMauPortIndex OBJECT-TYPE + SYNTAX INTEGER (1..1024) + ACCESS read-only + STATUS mandatory + DESCRIPTION + "This variable uniquely identifies the repeater + port within group rpMauGroupIndex to which the MAU + described by this entry is connected." + REFERENCE + "Reference RFC 1368, rptrPortIndex." + ::= { rpMauEntry 2 } + + rpMauIndex OBJECT-TYPE + SYNTAX INTEGER (1..9) + ACCESS read-only + STATUS mandatory + DESCRIPTION + "This variable uniquely identifies the MAU + connected to port rpMauPortIndex within group + rpMauGroupIndex that is described by this entry." + REFERENCE + "Reference IEEE 802.3 MAU Mgt, 20.2.3.2, aMAUID." + ::= { rpMauEntry 3 } + + rpMauType OBJECT-TYPE + SYNTAX OBJECT IDENTIFIER + ACCESS read-only + STATUS mandatory + DESCRIPTION + "This object identifies the 10 Mb/s baseband MAU + type. An initial set of MAU types are defined + above. The assignment of OBJECT IDENTIFIERs to + new types of MAUs is managed by the IANA. If the + MAU type is unknown, the object identifier + + unknownMauType OBJECT IDENTIFIER ::= { 0 0 } + + is returned. Note that unknownMauType is a + syntactically valid object identifier, and any + conformant implementation of ASN.1 and the BER + must be able to generate and recognize this + value." + REFERENCE + "Reference IEEE 802.3 MAU Mgt, 20.2.3.2, + aMAUType." + ::= { rpMauEntry 4 } + + rpMauStatus OBJECT-TYPE + + + +McMaster, McCloghrie & Roberts [Page 8] + +RFC 1515 802.3 MAU MIB September 1993 + + + SYNTAX INTEGER { + other(1), + unknown(2), + operational(3), + standby(4), + shutdown(5), + reset(6) + } + ACCESS read-write + STATUS mandatory + DESCRIPTION + "The current state of the MAU. This object may be + implemented as a read-only object by those agents + and MAUs that do not implement software control of + the MAU state. Some agents may not support + setting the value of this object to some of the + enumerated values. + + The value other(1) is returned if the MAU is in a + state other than one of the states 2 through 6. + + The value unknown(2) is returned when the MAU's + true state is unknown; for example, when it is + being initialized. + + A MAU in the operational(3) state is fully + functional, operates, and passes signals to its + attached DTE or repeater port in accordance to its + specification. + + A MAU in standby(4) state forces DI and CI and the + media transmitter to idle. Standby(4) mode only + applies to link type MAUs. The state of + rpMauMediaAvailable is unaffected. + + A MAU in shutdown(5) state assumes the same + condition on DI, CI, and the media transmitter as + though it were powered down. The MAU may return + other(1) value for the mauJabber and + rpMauMediaAvailable objects when it is in this + state. For an AUI, this state will remove power + from the AUI. + + Setting this variable to the value reset(6) resets + the MAU in the same manner as a power-off, power- + on cycle of at least one-half second would. The + agent is not required to return the value reset + (6). + + + +McMaster, McCloghrie & Roberts [Page 9] + +RFC 1515 802.3 MAU MIB September 1993 + + + Setting this variable to the value operational(3), + standby(4), or shutdown(5) causes the MAU to + assume the respective state except that setting a + mixing-type MAU or an AUI to standby(4) will cause + the MAU to enter the shutdown state." + REFERENCE + "Reference IEEE 802.3 MAU Mgt, 20.2.3.2, + aMAUAdminState, and 20.2.3.3, acMAUAdminControl + and acResetMAUAction." + ::= { rpMauEntry 5 } + + rpMauMediaAvailable OBJECT-TYPE + SYNTAX INTEGER { + other(1), + unknown(2), + available(3), + notAvailable(4), + remoteFault(5), + invalidSignal(6) + } + ACCESS read-only + STATUS mandatory + DESCRIPTION + "If the MAU is a link or fiber type (FOIRL, + 10BASE-T, 10BASE-F) then this is equivalent to the + link test fail state/low light function. For an + AUI or a coax (including broadband) MAU this + indicates whether or not loopback is detected on + the DI circuit. The value of this attribute + persists between packets for MAU types AUI, + 10BASE5, 10BASE2, 10BROAD36, and 10BASE-FP. + + The value other(1) is returned if the + mediaAvailable state is not one of 2 through 6. + + The value unknown(2) is returned when the MAU's + true state is unknown; for example, when it is + being initialized. At power-up or following a + reset, the value of this attribute will be unknown + for AUI, coax, and 10BASE-FP MAUs. For these MAUs + loopback will be tested on each transmission + during which no collision is detected. If DI is + receiving input when DO returns to IDL after a + transmission and there has been no collision + during the transmission then loopback will be + detected. The value of this attribute will only + change during non-collided transmissions for AUI, + coax, and 10BASE-FP MAUs. + + + +McMaster, McCloghrie & Roberts [Page 10] + +RFC 1515 802.3 MAU MIB September 1993 + + + The value available(3) indicates that the link, + light, or loopback is normal. The value + notAvailable(4) indicates link loss, low light, or + no loopback. + + The value remoteFault(5) indicates that a fault + has been detected at the remote end of the link. + The value invalidSignal(6) indicates that an + invalid signal has been received from the other + end of the link. Both remoteFault(5) and + invalidSignal(6) apply only to MAUs of type + 10BASE-FB." + REFERENCE + "Reference IEEE 802.3 MAU Mgt, 20.2.3.2, + aMediaAvailable." + ::= { rpMauEntry 6 } + + rpMauMediaAvailableStateExits OBJECT-TYPE + SYNTAX Counter + ACCESS read-only + STATUS mandatory + DESCRIPTION + "A count of the number of times that + rpMauMediaAvailable for this MAU instance leaves + the state available(3)." + REFERENCE + "Reference IEEE 802.3 MAU Mgt, 20.2.3.2, + lostMediaCount." + ::= { rpMauEntry 7 } + + rpMauJabberState OBJECT-TYPE + SYNTAX INTEGER { + other(1), + unknown(2), + noJabber(3), + jabbering(4) + } + ACCESS read-only + STATUS mandatory + DESCRIPTION + "The value other(1) is returned if the jabber + state is not 2, 3, or 4. The agent must always + return other(1) for MAU type dot3MauTypeAUI. + + The value unknown(2) is returned when the MAU's + true state is unknown; for example, when it is + being initialized. + + + + +McMaster, McCloghrie & Roberts [Page 11] + +RFC 1515 802.3 MAU MIB September 1993 + + + If the MAU is not jabbering the agent returns + noJabber(3). This is the 'normal' state. + + If the MAU is in jabber state the agent returns + the jabbering(4) value." + REFERENCE + "Reference IEEE 802.3 MAU Mgt, 20.2.3.2, + aJabber.jabberFlag." + ::= { rpMauEntry 8 } + + rpMauJabberingStateEnters OBJECT-TYPE + SYNTAX Counter + ACCESS read-only + STATUS mandatory + DESCRIPTION + "A count of the number of times that + rpMauJabberState for this MAU instance enters the + state jabbering(4). For a MAU of type + dot3MauTypeAUI, this counter will always indicate + zero." + REFERENCE + "Reference IEEE 802.3 MAU Mgt, 20.2.3.2, + aJabber.jabberCounter." + ::= { rpMauEntry 9 } + + + -- + -- The Interface MAU Basic Group + -- + -- Implementation of the Interface MAU Basic Group is mandatory + -- for MAUs attached to DTEs (interfaces). + + -- + -- The Basic Interface MAU Table + -- + + ifMauTable OBJECT-TYPE + SYNTAX SEQUENCE OF IfMauEntry + ACCESS not-accessible + STATUS mandatory + DESCRIPTION + "Table of descriptive and status information about + the MAU(s) attached to an interface." + ::= { dot3IfMauBasicGroup 1 } + + ifMauEntry OBJECT-TYPE + SYNTAX IfMauEntry + ACCESS not-accessible + + + +McMaster, McCloghrie & Roberts [Page 12] + +RFC 1515 802.3 MAU MIB September 1993 + + + STATUS mandatory + DESCRIPTION + "An entry in the table, containing information + about a single MAU." + INDEX { ifMauIfIndex, ifMauIndex } + ::= { ifMauTable 1 } + + IfMauEntry ::= + SEQUENCE { + ifMauIfIndex + INTEGER, + ifMauIndex + INTEGER, + ifMauType + OBJECT IDENTIFIER, + ifMauStatus + INTEGER, + ifMauMediaAvailable + INTEGER, + ifMauMediaAvailableStateExits + Counter, + ifMauJabberState + INTEGER, + ifMauJabberingStateEnters + Counter + } + + ifMauIfIndex OBJECT-TYPE + SYNTAX INTEGER + ACCESS read-only + STATUS mandatory + DESCRIPTION + "This variable uniquely identifies the interface + to which the MAU described by this entry is + connected." + REFERENCE + "Reference RFC 1213, ifIndex." + ::= { ifMauEntry 1 } + + ifMauIndex OBJECT-TYPE + SYNTAX INTEGER (1..9) + ACCESS read-only + STATUS mandatory + DESCRIPTION + "This variable uniquely identifies the MAU + connected to interface ifMauIfIndex that is + described by this entry." + REFERENCE + + + +McMaster, McCloghrie & Roberts [Page 13] + +RFC 1515 802.3 MAU MIB September 1993 + + + "Reference IEEE 802.3 MAU Mgt, 20.2.3.2, aMAUID." + ::= { ifMauEntry 2 } + + ifMauType OBJECT-TYPE + SYNTAX OBJECT IDENTIFIER + ACCESS read-only + STATUS mandatory + DESCRIPTION + "This object identifies the 10 Mb/s baseband or + broadband MAU type. An initial set of MAU types + are defined above. The assignment of OBJECT + IDENTIFIERs to new types of MAUs is managed by the + IANA. If the MAU type is unknown, the object + identifier + + unknownMauType OBJECT IDENTIFIER ::= { 0 0 } + + is returned. Note that unknownMauType is a + syntactically valid object identifier, and any + conformant implementation of ASN.1 and the BER + must be able to generate and recognize this + value." + REFERENCE + "Reference IEEE 802.3 MAU Mgt, 20.2.3.2, + aMAUType." + ::= { ifMauEntry 3 } + + ifMauStatus OBJECT-TYPE + SYNTAX INTEGER { + other(1), + unknown(2), + operational(3), + standby(4), + shutdown(5), + reset(6) + } + ACCESS read-write + STATUS mandatory + DESCRIPTION + "The current state of the MAU. This object may be + implemented as a read-only object by those agents + and MAUs that do not implement software control of + the MAU state. Some agents may not support + setting the value of this object to some of the + enumerated values. + + The value other(1) is returned if the MAU is in a + state other than one of the states 2 through 6. + + + +McMaster, McCloghrie & Roberts [Page 14] + +RFC 1515 802.3 MAU MIB September 1993 + + + The value unknown(2) is returned when the MAU's + true state is unknown; for example, when it is + being initialized. + + A MAU in the operational(3) state is fully + functional, operates, and passes signals to its + attached DTE or repeater port in accordance to its + specification. + + A MAU in standby(4) state forces DI and CI and the + media transmitter to idle. Standby(4) mode only + applies to link type MAUs. The state of + ifMauMediaAvailable is unaffected. + + A MAU in shutdown(5) state assumes the same + condition on DI, CI, and the media transmitter as + though it were powered down. The MAU may return + other(1) value for the mauJabber and + ifMauMediaAvailable objects when it is in this + state. For an AUI, this state will remove power + from the AUI. + + Setting this variable to the value reset(6) resets + the MAU in the same manner as a power-off, power- + on cycle of at least one-half second would. The + agent is not required to return the value reset + (6). + + Setting this variable to the value operational(3), + standby(4), or shutdown(5) causes the MAU to + assume the respective state except that setting a + mixing-type MAU or an AUI to standby(4) will cause + the MAU to enter the shutdown state." + REFERENCE + "Reference IEEE 802.3 MAU Mgt, 20.2.3.2, + aMAUAdminState, and 20.2.3.3, acMAUAdminControl + and acResetMAUAction." + ::= { ifMauEntry 4 } + + ifMauMediaAvailable OBJECT-TYPE + SYNTAX INTEGER { + other(1), + unknown(2), + available(3), + notAvailable(4), + remoteFault(5), + invalidSignal(6) + } + + + +McMaster, McCloghrie & Roberts [Page 15] + +RFC 1515 802.3 MAU MIB September 1993 + + + ACCESS read-only + STATUS mandatory + DESCRIPTION + "If the MAU is a link or fiber type (FOIRL, + 10BASE-T, 10BASE-F) then this is equivalent to the + link test fail state/low light function. For an + AUI or a coax (including broadband) MAU this + indicates whether or not loopback is detected on + the DI circuit. The value of this attribute + persists between packets for MAU types AUI, + 10BASE5, 10BASE2, 10BROAD36, and 10BASE-FP. + + The value other(1) is returned if the + mediaAvailable state is not one of 2 through 6. + + The value unknown(2) is returned when the MAU's + true state is unknown; for example, when it is + being initialized. At power-up or following a + reset, the value of this attribute will be unknown + for AUI, coax, and 10BASE-FP MAUs. For these MAUs + loopback will be tested on each transmission + during which no collision is detected. If DI is + receiving input when DO returns to IDL after a + transmission and there has been no collision + during the transmission then loopback will be + detected. The value of this attribute will only + change during non-collided transmissions for AUI, + coax, and 10BASE-FP MAUs. + + The value available(3) indicates that the link, + light, or loopback is normal. The value + notAvailable(4) indicates link loss, low light, or + no loopback. + + The value remoteFault(5) indicates that a fault + has been detected at the remote end of the link. + The value invalidSignal(6) indicates that an + invalid signal has been received from the other + end of the link. Both remoteFault(5) and + invalidSignal(6) apply only to MAUs of type + 10BASE-FB." + REFERENCE + "Reference IEEE 802.3 MAU Mgt, 20.2.3.2, + aMediaAvailable." + ::= { ifMauEntry 5 } + + ifMauMediaAvailableStateExits OBJECT-TYPE + SYNTAX Counter + + + +McMaster, McCloghrie & Roberts [Page 16] + +RFC 1515 802.3 MAU MIB September 1993 + + + ACCESS read-only + STATUS mandatory + DESCRIPTION + "A count of the number of times that + ifMauMediaAvailable for this MAU instance leaves + the state available(3)." + REFERENCE + "Reference IEEE 802.3 MAU Mgt, 20.2.3.2, + lostMediaCount." + ::= { ifMauEntry 6 } + + ifMauJabberState OBJECT-TYPE + SYNTAX INTEGER { + other(1), + unknown(2), + noJabber(3), + jabbering(4) + } + ACCESS read-only + STATUS mandatory + DESCRIPTION + "The value other(1) is returned if the jabber + state is not 2, 3, or 4. The agent must always + return other(1) for MAU type dot3MauTypeAUI. + + The value unknown(2) is returned when the MAU's + true state is unknown; for example, when it is + being initialized. + + If the MAU is not jabbering the agent returns + noJabber(3). This is the 'normal' state. + + If the MAU is in jabber state the agent returns + the jabbering(4) value." + REFERENCE + "Reference IEEE 802.3 MAU Mgt, 20.2.3.2, + aJabber.jabberFlag." + ::= { ifMauEntry 7 } + + ifMauJabberingStateEnters OBJECT-TYPE + SYNTAX Counter + ACCESS read-only + STATUS mandatory + DESCRIPTION + "A count of the number of times that + ifMauJabberState for this MAU instance enters the + state jabbering(4). For a MAU of type + dot3MauTypeAUI, this counter will always indicate + + + +McMaster, McCloghrie & Roberts [Page 17] + +RFC 1515 802.3 MAU MIB September 1993 + + + zero." + REFERENCE + "Reference IEEE 802.3 MAU Mgt, 20.2.3.2, + aJabber.jabberCounter." + ::= { ifMauEntry 8 } + + + -- + -- The Broadband MAU Basic Group + -- + -- Implementation of the Broadband MAU Basic Group is mandatory + -- for broadband MAUs attached to DTEs. + + -- + -- The Basic Broadband MAU Table + -- + + broadMauBasicTable OBJECT-TYPE + SYNTAX SEQUENCE OF BroadMauBasicEntry + ACCESS not-accessible + STATUS mandatory + DESCRIPTION + "Table of descriptive and status information about + the broadband MAUs connected to interfaces." + ::= { dot3BroadMauBasicGroup 1 } + + broadMauBasicEntry OBJECT-TYPE + SYNTAX BroadMauBasicEntry + ACCESS not-accessible + STATUS mandatory + DESCRIPTION + "An entry in the table, containing information + about a single broadband MAU." + INDEX { broadMauIfIndex, broadMauIndex } + ::= { broadMauBasicTable 1 } + + BroadMauBasicEntry ::= + SEQUENCE { + broadMauIfIndex + INTEGER, + broadMauIndex + INTEGER, + broadMauXmtRcvSplitType + INTEGER, + broadMauXmtCarrierFreq + INTEGER, + broadMauTranslationFreq + INTEGER + + + +McMaster, McCloghrie & Roberts [Page 18] + +RFC 1515 802.3 MAU MIB September 1993 + + + } + + broadMauIfIndex OBJECT-TYPE + SYNTAX INTEGER + ACCESS read-only + STATUS mandatory + DESCRIPTION + "This variable uniquely identifies the interface + to which the MAU described by this entry is + connected." + REFERENCE + "Reference RFC 1213, ifIndex." + ::= { broadMauBasicEntry 1 } + + broadMauIndex OBJECT-TYPE + SYNTAX INTEGER (1..9) + ACCESS read-only + STATUS mandatory + DESCRIPTION + "This variable uniquely identifies the MAU + connected to interface broadMauIfIndex that is + described by this entry." + REFERENCE + "Reference IEEE 802.3 MAU Mgt, 20.2.3.2, aMAUID." + ::= { broadMauBasicEntry 2 } + + broadMauXmtRcvSplitType OBJECT-TYPE + SYNTAX INTEGER { + other(1), + single(2), + dual(3) + } + ACCESS read-only + STATUS mandatory + DESCRIPTION + "This object indicates the type of frequency + multiplexing/cabling system used to separate the + transmit and receive paths for the 10BROAD36 MAU. + + The value other(1) is returned if the split type + is not either single or dual. + + The value single(2) indicates a single cable + system. The value dual(3) indicates a dual cable + system, offset normally zero." + REFERENCE + "Reference IEEE 802.3 MAU Mgt, 20.2.3.2, + aBbMAUXmitRcvSplitType." + + + +McMaster, McCloghrie & Roberts [Page 19] + +RFC 1515 802.3 MAU MIB September 1993 + + + ::= { broadMauBasicEntry 3 } + + broadMauXmtCarrierFreq OBJECT-TYPE + SYNTAX INTEGER + ACCESS read-only + STATUS mandatory + DESCRIPTION + "This variable indicates the transmit carrier + frequency of the 10BROAD36 MAU in MHz/4; that is, + in units of 250 kHz." + REFERENCE + "Reference IEEE 802.3 MAU Mgt, 20.2.3.2, + aBroadbandFrequencies.xmitCarrierFrequency." + ::= { broadMauBasicEntry 4 } + + broadMauTranslationFreq OBJECT-TYPE + SYNTAX INTEGER + ACCESS read-only + STATUS mandatory + DESCRIPTION + "This variable indicates the translation offset + frequency of the 10BROAD36 MAU in MHz/4; that is, + in units of 250 kHz." + REFERENCE + "Reference IEEE 802.3 MAU Mgt, 20.2.3.2, + aBroadbandFrequencies.translationFrequency." + ::= { broadMauBasicEntry 5 } + + + -- Traps for use by 802.3 MAUs + + -- Traps are defined using the conventions in RFC 1215 [8]. + + rpMauJabberTrap TRAP-TYPE + ENTERPRISE snmpDot3MauMgt + VARIABLES { rpMauJabberState } + DESCRIPTION + "This trap is sent whenever a managed repeater MAU + enters the jabber state. + + The agent must throttle the generation of + consecutive rpMauJabberTraps so that there is at + least a five-second gap between them." + REFERENCE + "Reference IEEE 802.3 MAU Mgt, 20.2.3.4, + nJabberNotification." + ::= 1 + + + + +McMaster, McCloghrie & Roberts [Page 20] + +RFC 1515 802.3 MAU MIB September 1993 + + + ifMauJabberTrap TRAP-TYPE + ENTERPRISE snmpDot3MauMgt + VARIABLES { ifMauJabberState } + DESCRIPTION + "This trap is sent whenever a managed interface + MAU enters the jabber state. + + The agent must throttle the generation of + consecutive ifMauJabberTraps so that there is at + least a five-second gap between them." + REFERENCE + "Reference IEEE 802.3 MAU Mgt, 20.2.3.4, + nJabberNotification." + ::= 2 + + END + + +5. Acknowledgments + + This document is the work of the IETF Hub MIB Working Group. It is + based on a proposal written by Geoff Thompson and modified by the + IEEE 802.3 Repeater Management Task Force. Paul Woodruff provided + valuable corrections and suggestions for improvement. + + Members of the IETF Hub MIB Working Group included: + + Karl Auerbach karl@eng.sun.com + Jim Barnes barnes@xylogics.com + Steve Bostock steveb@novell.com + David Bridgham dab@asylum.sf.ca.us + Jack Brown jbrown@huahuca-emh8.army.mil + Howard Brown brown@ctron.com + Lida Canin lida@apple.com + Jeffrey Case case@cs.utk.edu + Carson Cheung carson@bnr.com.ca + James Codespote jpcodes@tycho.ncsc.mil + John Cook cook@chipcom.com + Dave Cullerot cullerot@ctron.com + James Davin jrd@ptt.lcs.mit.edu + Gary Ellis garye@hpspd.spd.hp.com + David Engel david@cds.com + Mike Erlinger mike@mti.com + Jeff Erwin + Bill Fardy fardy@ctron.com + Jeff Fried jmf@relay.proteon.com + Bob Friesenhahn pdrusa!bob@uunet.uu.net + Shawn Gallagher gallagher@quiver.enet.dec.com + + + +McMaster, McCloghrie & Roberts [Page 21] + +RFC 1515 802.3 MAU MIB September 1993 + + + Mike Grieves mgrieves@chipcom.com + Walter Guilarte 70026.1715@compuserve.com + Phillip Hasse phasse@honchuca-emh8.army.mil + Mark Hoerth mark_hoerth@hp0400.desk.hp.com + Greg Hollingsworth gregh@mailer.jhuapl.edu + Ron Jacoby rj@sgi.com + Mike Janson mjanson@mot.com + Ken Jones konkord!ksj@uunet.uu.net + Satish Joshi sjoshi@synoptics.com + Frank Kastenholz kasten@europa.clearpoint.com + Manu Kaycee kaycee@trlian.enet.dec.com + Mark Kepke mak@cnd.hp.com + Mark Kerestes att!alux2!hawk@uunet.uu.net + Kenneth Key key@cs.utk.edu + Yoav Kluger ykluger@fibhaifa.com + Cheryl Krupczak cheryl@cc.gatech.edu + Ron Lau rlau@synoptics.com + Chao-Yu Liang cliang@synoptics.com + Dave Lindemulder da@mtung.att.com + Richie McBride rm@bix.co.uk + Keith McCloghrie kzm@hls.com + Evan McGinnis bem@3com.com + Donna McMaster mcmaster@synoptics.com + David Minnich dwm@fibercom.com + Lynn Monsanto monsanto@sun.com + Miriam Nihart miriam@decwet.zso.dec.com + Niels Ole Brunsgaard nob@dowtyns.dk + Edison Paw esp@3com.com + David Perkins dperkins@synoptics.com + Jason Perreault perreaul@interlan.interlan.com + John Pickens jrp@3com.com + Jim Reinstedler jimr@sceng.ub.com + Anil Rijsinghani anil@levers.enet.dec.com + Sam Roberts sroberts@farallon.com + Dan Romascanu dan@lannet.com + Marshall Rose mrose@dbc.mtview.ca.us + Rick Royston rick@lsumus.sncc.lsu.edu + Michael Sabo sabo@dockmaster.ncsc.mil + Jonathan Saperia saperia@tcpjon.enet.dec.com + Mark Schaefer schaefer@davidsys.com + Anil Singhal nsinghal@hawk.ulowell.edu + Timon Sloane peernet!timon@uunet.uu.net + Bob Stewart rlstewart@eng.xyplex.com + Emil Sturniolo emil@dss.com + Bruce Taber taber@interlan.com + Iris Tal 437-3580@mcimail.com + Mark Therieau markt@python.eng.microcom.com + Geoff Thompson thompson@synoptics.com + + + +McMaster, McCloghrie & Roberts [Page 22] + +RFC 1515 802.3 MAU MIB September 1993 + + + Dean Throop throop@dg-rtp.dg.com + Steven Waldbusser waldbusser@andrew.cmu.edu + Timothy Walden tmwalden@saturn.sys.acc.com + Philip Wang watadn!phil@uunet.uu.net + Drew Wansley dwansley@secola.columbia.ncr.com + David Ward dward@chipcom.com + Steve Wong wong@took.enet.dec.com + Paul Woodruff paul-woodruff@3com.com + Brian Wyld brianw@spider.co.uk + June-Kang Yang natadm!yang@uunet.uu.net + Henry Yip natadm!henry@uunet.uu.net + John Ziegler ziegler@artel.com + Joseph Zur zur@fibhaifa.com + +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] McCloghrie, K., and M. Rose, "Management Information Base for + Network Management of TCP/IP-based internets", RFC 1156, Hughes + LAN Systems, Performance Systems International, May 1990. + + [3] 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. + + [4] McCloghrie, K., and M. Rose, Editors, "Management Information + Base for Network Management of TCP/IP-based internets: MIB-II", + STD 17, RFC 1213, Hughes LAN Systems, Performance Systems + International, March 1991. + + [5] Information processing systems - Open Systems Interconnection - + Specification of Abstract Syntax Notation One (ASN.1), + International Organization for Standardization, International + Standard 8824, December 1987. + + [6] Information processing systems - Open Systems Interconnection - + Specification of Basic Encoding Rules for Abstract Notation One + (ASN.1), International Organization for Standardization, + International Standard 8825, December 1987. + + [7] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", + STD 16, RFC 1212, Performance Systems International, Hughes LAN + Systems, March 1991. + + + +McMaster, McCloghrie & Roberts [Page 23] + +RFC 1515 802.3 MAU MIB September 1993 + + + [8] Rose, M., Editor, "A Convention for Defining Traps for use with + the SNMP", RFC 1215, Performance Systems International, March + 1991. + + [9] 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. + + [10] IEEE P802.3p, "Layer Management for 10 Mb/s Medium Access Unit + (MAUs), Section 20", Draft Supplement to ANSI/IEEE 802.3, Draft + 5, July 11, 1992. + + [11] Kastenholz, F., "Definitions of Managed Objects for the + Ethernet-like Interface Types", RFC 1398, FTP Software, Inc., + January 1993. + + [12] McMaster, D., and K. McCloghrie, Editors, "Definitions of + Managed Objects for IEEE 802.3 Repeater Devices", RFC 1368, + SynOptics Communications, Hughes LAN Systems, October 1992. + +7. Security Considerations + + Security issues are not discussed in this memo. + + + + + + + + + + + + + + + + + + + + + + + + + + + +McMaster, McCloghrie & Roberts [Page 24] + +RFC 1515 802.3 MAU MIB September 1993 + + +8. Authors' Addresses + + Donna McMaster + SynOptics Communications, Inc. + 4401 Great America Parkway + P.O. Box 58185 + Santa Clara, CA 95052-8185 + + Phone: (408) 764-1206 + EMail: mcmaster@synoptics.com + + + Keith McCloghrie + Hughes LAN Systems, Inc. + 1225 Charleston Road + Mountain View, CA 94043 + + Phone: (415) 966-7934 + EMail: kzm@hls.com + + + Sam Roberts + Farallon Computing, Inc. + 2470 Mariner Square Loop + Alameda, CA 94501-1010 + + Phone: (510) 814-5215 + EMail: sroberts@farallon.com + + + + + + + + + + + + + + + + + + + + + + + +McMaster, McCloghrie & Roberts [Page 25] + \ No newline at end of file -- cgit v1.2.3