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/rfc2358.txt | 2187 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2187 insertions(+) create mode 100644 doc/rfc/rfc2358.txt (limited to 'doc/rfc/rfc2358.txt') diff --git a/doc/rfc/rfc2358.txt b/doc/rfc/rfc2358.txt new file mode 100644 index 0000000..78ff776 --- /dev/null +++ b/doc/rfc/rfc2358.txt @@ -0,0 +1,2187 @@ + + + + + + +Network Working Group J. Flick +Request for Comments: 2358 Hewlett-Packard Company +Obsoletes: 1650 J. Johnson +Category: Standards Track RedBack Networks + June 1998 + + + Definitions of Managed Objects for + the Ethernet-like Interface Types + +Status of this Memo + + This document 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" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +Abstract + + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols in the Internet community. + This memo obsoletes RFC 1650 "Definitions of Managed Objects for the + Ethernet-like Interface Types using SMIv2". This memo extends that + specification by including management information useful for the + management of 100 Mb/s Ethernet interfaces. + + Ethernet technology, as defined by the 802.3 Working Group of the + IEEE, continues to evolve, with scalable increases in speed, new + types of cabling and interfaces, and new features. This evolution + may require changes in the managed objects in order to reflect this + new functionality. This document, as with other documents issued by + this working group, reflect a certain stage in the evolution of + Ethernet technology. In the future, this document might be revised, + or new documents might be issued by the Ethernet Interfaces and Hub + MIB Working Group, in order to reflect the evolution of Ethernet + technology. + + + + + + + + + + +Flick & Johnson Standards Track [Page 1] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + +Table of Contents + + 1. Introduction ................................................ 2 + 2. The SNMP Network Management Framework ...................... 2 + 2.1. Object Definitions ....................................... 3 + 3. Overview ................................................... 3 + 3.1. Relation to MIB-2 ........................................ 4 + 3.2. Relation to the Interfaces MIB ........................... 4 + 3.2.1. Layering Model ......................................... 4 + 3.2.2. Virtual Circuits ....................................... 4 + 3.2.3. ifTestTable ............................................ 5 + 3.2.4. ifRcvAddressTable ...................................... 5 + 3.2.5. ifPhysAddress .......................................... 5 + 3.2.6. ifType ................................................. 6 + 3.2.7. Specific Interface MIB Objects ......................... 7 + 3.3. Relation to the 802.3 MAU MIB ............................ 10 + 3.4. Mapping of IEEE 802.3 Managed Objects .................... 10 + 4. Definitions ................................................ 11 + 5. Intellectual Property ...................................... 34 + 6. Acknowledgements ........................................... 34 + 7. References ................................................. 35 + 8. Security Considerations .................................... 36 + 9. Authors' Addresses ......................................... 37 + A. Change Log ................................................. 38 + B. Full Copyright Statement ................................... 39 + +1. Introduction + + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols in the Internet community. + In particular, it defines objects for managing ethernet-like + interfaces. + + This memo also includes a MIB module. This MIB module extends the + list of managed objects specified in the earlier version of this MIB: + RFC1650 [11]. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [13]. + +2. The SNMP Network Management Framework + + The SNMP Network Management Framework consists of several components. + For the purpose of this specification, the applicable components of + the Framework are the SMI and related documents [2, 3, 4], which + define the mechanisms used for describing and naming objects for the + purpose of management. + + + +Flick & Johnson Standards Track [Page 2] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + The Framework permits new objects to be defined for the purpose of + experimentation and evaluation. + +2.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) [1] + defined in the SMI [2]. 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 these object types represent attributes of an interface + to an ethernet-like communications medium. At present, ethernet-like + media are identified by the following values of the ifType object in + the Interfaces MIB [12]: + + ethernetCsmacd(6) + iso88023Csmacd(7) + starLan(11) + + The definitions presented here are based on the IEEE 802.3 Layer + Management Specification [5], as originally interpreted by Frank + Kastenholz then of Interlan in [7]. Implementors of these MIB + objects should note that the IEEE document explicitly describes (in + the form of Pascal pseudocode) when, where, and how various MAC + attributes are measured. The IEEE document also describes the + effects of MAC actions that may be invoked by manipulating instances + of the MIB objects defined here. + + To the extent that some of the attributes defined in [5] are + represented by previously defined objects in MIB-2 [16] or in the + Interfaces MIB [12], such attributes are not redundantly represented + by objects defined in this memo. Among the attributes represented by + objects defined in other memos are the number of octets transmitted + or received on a particular interface, the number of frames + transmitted or received on a particular interface, the promiscuous + status of an interface, the MAC address of an interface, and + multicast information associated with an interface. + + + + + + + +Flick & Johnson Standards Track [Page 3] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + +3.1. Relation to MIB-2 + + This section applies only when this MIB is used in conjunction with + the "old" (RFC 1213) [16] interface group. + + The relationship between an ethernet-like interface and an interface + in the context of the Internet-standard MIB is one-to-one. As such, + the value of an ifIndex object instance can be directly used to + identify corresponding instances of the objects defined herein. + + For agents which implement the (now deprecated) ifSpecific object, an + instance of that object that is associated with an ethernet-like + interface has the OBJECT IDENTIFIER value: + + dot3 OBJECT IDENTIFER ::= { transmission 7 } + +3.2. Relation to the Interfaces MIB + + The Interface MIB [12] requires that any MIB which is an adjunct of + the Interface MIB clarify specific areas within the Interface MIB. + These areas were intentionally left vague in the Interface MIB to + avoid over constraining the MIB, thereby precluding management of + certain media-types. + + Section 3.3 of [12] enumerates several areas which a media-specific + MIB must clarify. Each of these areas is addressed in a following + subsection. The implementor is referred to [12] in order to + understand the general intent of these areas. + +3.2.1. Layering Model + + This MIB does not provide for layering. There are no sublayers. + + EDITOR'S NOTE: + + One could foresee the development of an 802.2 and enet-transceiver + MIB. They could be higher and lower sublayers, respectively. All + that THIS document should do is allude to the possibilities and urge + the implementor to be aware of the possibility and that they may have + requirements which supersede the requirements in this document. + +3.2.2. Virtual Circuits + + This medium does not support virtual circuits and this area is not + applicable to this MIB. + + + + + + +Flick & Johnson Standards Track [Page 4] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + +3.2.3. ifTestTable + + This MIB defines two tests for media which are instrumented with this + MIB; TDR and Loopback. Implementation of these tests is not + required. Many common interface chips do not support one or both of + these tests. + + These two tests are provided as a convenience, allowing a common + method to invoke the test. + + Standard MIBs do not include objects in which to return the results + of the TDR test. Any needed objects MUST be provided in the vendor + specific MIB. + + Note that the ifTestTable is now deprecated. Work is underway to + define a replacement MIB for system and interface testing. It is + expected that the tests defined in this document will be usable in + this replacement MIB. + +3.2.4. ifRcvAddressTable + + This table contains all IEEE 802.3 addresses, unicast, multicast, and + broadcast, for which this interface will receive packets and forward + them up to a higher layer entity for local consumption. The format + of the address, contained in ifRcvAddressAddress, is the same as for + ifPhysAddress. + + In the event that the interface is part of a MAC bridge, this table + does not include unicast addresses which are accepted for possible + forwarding out some other port. This table is explicitly not + intended to provide a bridge address filtering mechanism. + +3.2.5. ifPhysAddress + + This object contains the IEEE 802.3 address which is placed in the + source-address field of any Ethernet, Starlan, or IEEE 802.3 frames + that originate at this interface. Usually this will be kept in ROM + on the interface hardware. Some systems may set this address via + software. + + In a system where there are several such addresses the designer has a + tougher choice. The address chosen should be the one most likely to + be of use to network management (e.g. the address placed in ARP + responses for systems which are primarily IP systems). + + If the designer truly can not chose, use of the factory- provided ROM + address is suggested. + + + + +Flick & Johnson Standards Track [Page 5] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + If the address can not be determined, an octet string of zero length + should be returned. + + The address is stored in binary in this object. The address is + stored in "canonical" bit order, that is, the Group Bit is positioned + as the low-order bit of the first octet. Thus, the first byte of a + multicast address would have the bit 0x01 set. + +3.2.6. ifType + + This MIB applies to interfaces which have any of the following ifType + values: + + ethernetCsmacd(6) + iso88023Csmacd(7) + starLan(11) + + It is RECOMMENDED that all Ethernet-like interfaces use an ifType of + ethernetCsmacd(6) regardless of the speed that the interface is + running or the link-layer encapsulation in use. iso88023Csmacd(7) + and starLan(11) are supported for backwards compatability. + + There are two other interface types defined in the IANAifType-MIB for + 100 Mbit Ethernet. They are fastEther(62), and fastEtherFX(69). + This document takes the position that an Ethernet is an Ethernet, and + Ethernet interfaces SHOULD always have the same value of ifType. + Information on the particular flavor of Ethernet that an interface is + running is available from ifSpeed in the Interfaces MIB, and + ifMauType in the 802.3 MAU MIB. An Ethernet-like interface SHOULD + NOT use the fastEther(62) or fastEtherFX(69) ifTypes. + + Interfaces with any of the supported ifType values map to the + EtherLike-MIB in the same manner. Which compliance statement an + interface should implement is dependent on the maximum speed + supported on the interface. The EtherLike-MIB etherCompliance + compliance statement applies to all Ethernet-like interfaces whose + maximum supported speed is 10 Mbit/sec or less. There are no + implementation differences. Similarly, the EtherLike-MIB + ether100MbsCompliance compliance statement applies to all Ethernet- + like interfaces whose maximum supported speed is 100Mbit/sec. + + An interface that is capable of operating at 100Mbit/sec MUST + implement the ether100MbsCompliance compliance statement, even if it + is currently operating at a lower speed. Counters in the + ether100MbsCompliance compliance statement that only apply to 100 + Mbit interfaces would simply not increment when the interface is + operating at a lower speed. + + + + +Flick & Johnson Standards Track [Page 6] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + +3.2.7. Specific Interface MIB Objects + + The following table provides specific implementation guidelines for + applying the interface group objects to ethernet-like media. + + Object + + ifIndex Each ethernet-like interface is + represented by an ifEntry. The + dot3StatsTable in this MIB module is + indexed by dot3StatsIndex. The interface + identified by a particular value of + dot3StatsIndex is the same interface as + identified by the same value of ifIndex. + + ifDescr Refer to [12]. + + ifType Refer to section 3.2.6. + + ifMtu 1500 octets. + + ifSpeed The current operational speed of the + interface in bits per second. For + current ethernet-like interfaces, this + will be equal to 1,000,000 (1 million), + 10,000,000 (10 million), or 100,000,000 + (100 million). If the interface + implements auto-negotiation, + auto-negotiation is enabled for this + interface, and the interface has not yet + negotiated to an operational speed, this + object SHOULD reflect the maximum speed + supported by the interface. Note that + this object MUST NOT indicate a doubled + value when operating in full-duplex + mode. It MUST indicate the correct + line speed regardless of the current + duplex mode. The correct object to use + to determine the duplex mode of the + interface is the ifMauType object in the + 802.3 MAU MIB. + + ifPhysAddress Refer to section 3.2.5. + + ifAdminStatus Write access is not required. Support + for 'testing' is not required. + + + + + +Flick & Johnson Standards Track [Page 7] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + ifOperStatus The operational state of the interface. + Support for 'testing' is not required. + The value 'dormant' has no meaning for + an ethernet-like interface. + + ifLastChange Refer to [12]. + + ifInOctets The number of octets in valid MAC frames + received on this interface, including + the MAC header and FCS. + + ifInUcastPkts Refer to [12]. + + ifInDiscards Refer to [12]. + + ifInErrors The sum for this interface of + dot3StatsAlignmentErrors, + dot3StatsFCSErrors, + dot3StatsFrameTooLongs, + dot3StatsInternalMacReceiveErrors and + dot3StatsSymbolErrors. + + ifInUnknownProtos Refer to [12]. + + ifOutOctets The number of octets transmitted in + valid MAC frames on this interface, + including the MAC header and FCS. + + ifOutUcastPkts Refer to [12]. + + ifOutDiscards Refer to [12]. + + ifOutErrors The sum for this interface of: + dot3StatsSQETestErrors, + dot3StatsLateCollisions, + dot3StatsExcessiveCollisions, + dot3StatsInternalMacTransmitErrors and + dot3StatsCarrierSenseErrors. + + ifName Locally-significant textual name for the + interface (e.g. lan0). + + ifInMulticastPkts Refer to [12]. + + ifInBroadcastPkts Refer to [12]. + + ifOutMulticastPkts Refer to [12]. + + + + +Flick & Johnson Standards Track [Page 8] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + ifOutBroadcastPkts Refer to [12]. + + ifHCInOctets 64-bit versions of counters. Required + ifHCOutOctets for ethernet-like interfaces that are + capable of operating at 20Mbit/sec or + faster, even if the interface is + currently operating at less than + 20Mbit/sec. + + ifHCInUcastPkts 64-bit versions of packet counters. + ifHCInMulticastPkts Support for these counters is not + ifHCInBroadcastPkts required for the interface types + ifHCOutUcastPkts supported by this MIB. They are only + ifHCOutMulticastPkts required for interfaces capable of + ifHCOutBroadcastPkts operating at 640Mbit/sec or faster. + Note that a future revision of this + document may support faster interfaces, + and therefore may require support for + these counters. + + ifLinkUpDownTrapEnable Refer to [12]. Default is 'enabled' + + ifHighSpeed The current operational speed of the + interface in millions of bits per + second. For current ethernet-like + interfaces, this will be equal to 1, 10, + or 100. If the interface implements + auto-negotiation, auto-negotiation is + enabled for this interface, and the + interface has not yet negotiated to an + operational speed, this object SHOULD + reflect the maximum speed supported by + the interface. Note that this object + MUST NOT indicate a doubled value when + operating in full-duplex mode. It MUST + indicate the correct line speed + regardless of the current duplex mode. + The correct object to use to determine + the duplex mode of the interface is the + ifMauType object in the 802.3 MAU MIB. + + ifPromiscuousMode Refer to [12]. + + ifConnectorPresent This will normally be 'true'. + + ifAlias Refer to [12]. + + ifCounterDiscontinuityTime Refer to [12]. + + + +Flick & Johnson Standards Track [Page 9] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + ifStackHigherLayer Refer to section 3.2.1. + ifStackLowerLayer + ifStackStatus + + ifRcvAddressAddress Refer to section 3.2.4. + ifRcvAddressStatus + ifRcvAddressType + +3.3. Relation to the 802.3 MAU MIB + + Support for the mauModIfCompl compliance statement of the MAU-MIB + [14] is REQUIRED for Ethernet-like interfaces. This MIB is needed in + order to allow applications to determine the current MAU type in use + by the interface. The MAU type indicates not only the media type in + use, but also indicates whether the interface is operating in half- + duplex or full-duplex mode. Implementing this MIB module without + implementing the MAU-MIB would leave applications with no standard + way to determine the duplex mode of the interface. + +3.4. Mapping of IEEE 802.3 Managed Objects + + IEEE 802.3 Managed Object Corresponding SNMP Object + + oMacEntity + .aMACID dot3StatsIndex or + IF-MIB - ifIndex + .aFramesTransmittedOK IF-MIB - ifOutUCastPkts + + ifOutMulticastPkts + + ifOutBroadcastPkts + .aSingleCollisionFrames dot3StatsSingleCollisionFrames + .aMultipleCollisionFrames dot3StatsMultipleCollisionFrames + .aFramesReceivedOK IF-MIB - ifInUcastPkts + + ifInMulticastPkts + + ifInBroadcastPkts + .aFrameCheckSequenceErrors dot3StatsFCSErrors + .aAlignmentErrors dot3StatsAlignmentErrors + .aOctetsTransmittedOK IF-MIB - ifOutOctets + .aFramesWithDeferredXmissions dot3StatsDeferredTransmissions + .aLateCollisions dot3StatsLateCollisions + .aFramesAbortedDueToXSColls dot3StatsExcessiveCollisions + .aFramesLostDueToIntMACXmitError dot3StatsInternalMacTransmitErrors + .aCarrierSenseErrors dot3StatsCarrierSenseErrors + .aOctetsReceivedOK IF-MIB - ifInOctets + .aFramesLostDueToIntMACRcvError dot3StatsInternalMacReceiveErrors + .aPromiscuousStatus IF-MIB - ifPromiscuousMode + .aReadMulticastAddressList IF-MIB - ifRcvAddressTable + .aMulticastFramesXmittedOK IF-MIB - ifOutMulticastPkts + .aBroadcastFramesXmittedOK IF-MIB - ifOutBroadcastPkts + + + +Flick & Johnson Standards Track [Page 10] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + .aMulticastFramesReceivedOK IF-MIB - ifInMulticastPkts + .aBroadcastFramesReceivedOK IF-MIB - ifInBroadcastPkts + .aFrameTooLongErrors dot3StatsFrameTooLongs + .aReadWriteMACAddress IF-MIB - ifPhysAddress + .aCollisionFrames dot3CollFrequencies + .acAddGroupAddress IF-MIB - ifRcvAddressTable + .acDeleteGroupAddress IF-MIB - ifRcvAddressTable + .acExecuteSelfTest dot3TestLoopBack + + oPHYEntity + .aSQETestErrors dot3StatsSQETestErrors + .aSymbolErrorDuringCarrier dot3StatsSymbolErrors + + + The following IEEE 802.3 managed objects have been removed from this + MIB module as a result of implementation feedback: + + oMacEntity + .aFramesWithExcessiveDeferral + .aInRangeLengthErrors + .aOutOfRangeLengthField + .aMACEnableStatus + .aTransmitEnableStatus + .aMulticastReceiveStatus + .acInitializeMAC + + Please see [15] for the detailed reasoning on why these objects were + removed. + +4. Definitions + + EtherLike-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, + Counter32, mib-2, transmission + FROM SNMPv2-SMI + MODULE-COMPLIANCE, OBJECT-GROUP + FROM SNMPv2-CONF + ifIndex, InterfaceIndex + FROM IF-MIB; + + etherMIB MODULE-IDENTITY + LAST-UPDATED "9806032150Z" -- June 3, 1998 + ORGANIZATION "IETF 802.3 Hub MIB Working Group" + CONTACT-INFO + "WG E-mail: hubmib@hprnd.rose.hp.com + To subscribe: hubmib-request@hprnd.rose.hp.com + + + +Flick & Johnson Standards Track [Page 11] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + Chair: Dan Romascanu + Postal: LANNET Ltd. + Atidum Technology Park, Bldg. 3 + Tel Aviv 61131 + Israel + Tel: +972 3 645 8414 + E-mail: dromasca@lannet.com + + Editor: John Flick + Postal: Hewlett-Packard Company + 8000 Foothills Blvd. M/S 5556 + Roseville, CA 95747-5556 + USA + Tel: +1 916 785 4018 + Fax: +1 916 785 3583 + E-mail: johnf@hprnd.rose.hp.com + + Editor: Jeffrey Johnson + Postal: RedBack Networks + 2570 North First Street, Suite 410 + San Jose, CA, 95131 + USA + Tel: +1 408 571 2699 + Fax: +1 408 571 2698 + E-Mail: jeff@redbacknetworks.com" + + DESCRIPTION "The MIB module to describe generic objects for + Ethernet-like network interfaces. This MIB is an + updated version of the Ethernet-like MIB in RFC + 1650." + + REVISION "9806032150Z" + DESCRIPTION "Updated to include support for 100 Mb/sec + interfaces." + + REVISION "9402030400Z" + DESCRIPTION "Version published as RFC 1650." + ::= { mib-2 35 } + + etherMIBObjects OBJECT IDENTIFIER ::= { etherMIB 1 } + + dot3 OBJECT IDENTIFIER ::= { transmission 7 } + + -- the Ethernet-like Statistics group + + dot3StatsTable OBJECT-TYPE + SYNTAX SEQUENCE OF Dot3StatsEntry + MAX-ACCESS not-accessible + + + +Flick & Johnson Standards Track [Page 12] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + STATUS current + DESCRIPTION "Statistics for a collection of ethernet-like + interfaces attached to a particular system." + ::= { dot3 2 } + + dot3StatsEntry OBJECT-TYPE + SYNTAX Dot3StatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION "Statistics for a particular interface to an + ethernet-like medium." + INDEX { dot3StatsIndex } + ::= { dot3StatsTable 1 } + + Dot3StatsEntry ::= + SEQUENCE { + dot3StatsIndex InterfaceIndex, + dot3StatsAlignmentErrors Counter32, + dot3StatsFCSErrors Counter32, + dot3StatsSingleCollisionFrames Counter32, + dot3StatsMultipleCollisionFrames Counter32, + dot3StatsSQETestErrors Counter32, + dot3StatsDeferredTransmissions Counter32, + dot3StatsLateCollisions Counter32, + dot3StatsExcessiveCollisions Counter32, + dot3StatsInternalMacTransmitErrors Counter32, + dot3StatsCarrierSenseErrors Counter32, + dot3StatsFrameTooLongs Counter32, + dot3StatsInternalMacReceiveErrors Counter32, + dot3StatsEtherChipSet OBJECT IDENTIFIER, + dot3StatsSymbolErrors Counter32 + } + + dot3StatsIndex OBJECT-TYPE + SYNTAX InterfaceIndex + MAX-ACCESS read-only + STATUS current + DESCRIPTION "An index value that uniquely identifies an + interface to an ethernet-like medium. The + interface identified by a particular value of + this index is the same interface as identified + by the same value of ifIndex." + ::= { dot3StatsEntry 1 } + + dot3StatsAlignmentErrors OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + + + +Flick & Johnson Standards Track [Page 13] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + DESCRIPTION "A count of frames received on a particular + interface that are not an integral number of + octets in length and do not pass the FCS check. + + The count represented by an instance of this + object is incremented when the alignmentError + status is returned by the MAC service to the + LLC (or other MAC user). Received frames for + which multiple error conditions obtain are, + according to the conventions of IEEE 802.3 + Layer Management, counted exclusively according + to the error status presented to the LLC." + REFERENCE "IEEE 802.3 Layer Management" + ::= { dot3StatsEntry 2 } + + dot3StatsFCSErrors OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "A count of frames received on a particular + interface that are an integral number of octets + in length but do not pass the FCS check. + + The count represented by an instance of this + object is incremented when the frameCheckError + status is returned by the MAC service to the + LLC (or other MAC user). Received frames for + which multiple error conditions obtain are, + according to the conventions of IEEE 802.3 + Layer Management, counted exclusively according + to the error status presented to the LLC." + REFERENCE "IEEE 802.3 Layer Management" + ::= { dot3StatsEntry 3 } + + dot3StatsSingleCollisionFrames OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "A count of successfully transmitted frames on + a particular interface for which transmission + is inhibited by exactly one collision. + + A frame that is counted by an instance of this + object is also counted by the corresponding + instance of either the ifOutUcastPkts, + ifOutMulticastPkts, or ifOutBroadcastPkts, + and is not counted by the corresponding + instance of the dot3StatsMultipleCollisionFrames + + + +Flick & Johnson Standards Track [Page 14] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + object." + REFERENCE "IEEE 802.3 Layer Management" + ::= { dot3StatsEntry 4 } + + + dot3StatsMultipleCollisionFrames OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "A count of successfully transmitted frames on + a particular interface for which transmission + is inhibited by more than one collision. + + A frame that is counted by an instance of this + object is also counted by the corresponding + instance of either the ifOutUcastPkts, + ifOutMulticastPkts, or ifOutBroadcastPkts, + and is not counted by the corresponding + instance of the dot3StatsSingleCollisionFrames + object." + REFERENCE "IEEE 802.3 Layer Management" + ::= { dot3StatsEntry 5 } + + + dot3StatsSQETestErrors OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "A count of times that the SQE TEST ERROR + message is generated by the PLS sublayer for a + particular interface. The SQE TEST ERROR + message is defined in section 7.2.2.2.4 of + ANSI/IEEE 802.3-1985 and its generation is + described in section 7.2.4.6 of the same + document." + REFERENCE "ANSI/IEEE Std 802.3-1985 Carrier Sense + Multiple Access with Collision Detection Access + Method and Physical Layer Specifications" + ::= { dot3StatsEntry 6 } + + dot3StatsDeferredTransmissions OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "A count of frames for which the first + transmission attempt on a particular interface + is delayed because the medium is busy. + + + + +Flick & Johnson Standards Track [Page 15] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + The count represented by an instance of this + object does not include frames involved in + collisions." + REFERENCE "IEEE 802.3 Layer Management" + ::= { dot3StatsEntry 7 } + + dot3StatsLateCollisions OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The number of times that a collision is + detected on a particular interface later than + 512 bit-times into the transmission of a + packet. + + Five hundred and twelve bit-times corresponds + to 51.2 microseconds on a 10 Mbit/s system. A + (late) collision included in a count + represented by an instance of this object is + also considered as a (generic) collision for + purposes of other collision-related + statistics." + REFERENCE "IEEE 802.3 Layer Management" + ::= { dot3StatsEntry 8 } + + dot3StatsExcessiveCollisions OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "A count of frames for which transmission on a + particular interface fails due to excessive + collisions." + REFERENCE "IEEE 802.3 Layer Management" + ::= { dot3StatsEntry 9 } + + dot3StatsInternalMacTransmitErrors OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "A count of frames for which transmission on a + particular interface fails due to an internal + MAC sublayer transmit error. A frame is only + counted by an instance of this object if it is + not counted by the corresponding instance of + either the dot3StatsLateCollisions object, the + dot3StatsExcessiveCollisions object, or the + dot3StatsCarrierSenseErrors object. + + + + +Flick & Johnson Standards Track [Page 16] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + The precise meaning of the count represented by + an instance of this object is implementation- + specific. In particular, an instance of this + object may represent a count of transmission + errors on a particular interface that are not + otherwise counted." + REFERENCE "IEEE 802.3 Layer Management" + ::= { dot3StatsEntry 10 } + + dot3StatsCarrierSenseErrors OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The number of times that the carrier sense + condition was lost or never asserted when + attempting to transmit a frame on a particular + interface. + + The count represented by an instance of this + object is incremented at most once per + transmission attempt, even if the carrier sense + condition fluctuates during a transmission + attempt." + REFERENCE "IEEE 802.3 Layer Management" + ::= { dot3StatsEntry 11 } + + -- { dot3StatsEntry 12 } is not assigned + + dot3StatsFrameTooLongs OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "A count of frames received on a particular + interface that exceed the maximum permitted + frame size. + + The count represented by an instance of this + object is incremented when the frameTooLong + status is returned by the MAC service to the + LLC (or other MAC user). Received frames for + which multiple error conditions obtain are, + according to the conventions of IEEE 802.3 + Layer Management, counted exclusively according + to the error status presented to the LLC." + REFERENCE "IEEE 802.3 Layer Management" + ::= { dot3StatsEntry 13 } + + -- { dot3StatsEntry 14 } is not assigned + + + +Flick & Johnson Standards Track [Page 17] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + -- { dot3StatsEntry 15 } is not assigned + + dot3StatsInternalMacReceiveErrors OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "A count of frames for which reception on a + particular interface fails due to an internal + MAC sublayer receive error. A frame is only + counted by an instance of this object if it is + not counted by the corresponding instance of + either the dot3StatsFrameTooLongs object, the + dot3StatsAlignmentErrors object, or the + dot3StatsFCSErrors object. + The precise meaning of the count represented by + an instance of this object is implementation- + specific. In particular, an instance of this + object may represent a count of receive errors + on a particular interface that are not + otherwise counted." + REFERENCE "IEEE 802.3 Layer Management" + ::= { dot3StatsEntry 16 } + + dot3StatsEtherChipSet OBJECT-TYPE + SYNTAX OBJECT IDENTIFIER + MAX-ACCESS read-only + STATUS current + DESCRIPTION "This object contains an OBJECT IDENTIFIER + which identifies the chipset used to + realize the interface. Ethernet-like + interfaces are typically built out of + several different chips. The MIB implementor + is presented with a decision of which chip + to identify via this object. The implementor + should identify the chip which is usually + called the Medium Access Control chip. + If no such chip is easily identifiable, + the implementor should identify the chip + which actually gathers the transmit + and receive statistics and error + indications. This would allow a + manager station to correlate the + statistics and the chip generating + them, giving it the ability to take + into account any known anomalies + in the chip." + ::= { dot3StatsEntry 17 } + + + + +Flick & Johnson Standards Track [Page 18] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + dot3StatsSymbolErrors OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The number of times there was an invalid data + symbol when a valid carrier was present on a + particular interface. + + The count represented by an instance of this + object is incremented at most once per carrier + event, even if multiple symbol errors occur + during the carrier event." + REFERENCE "IEEE 802.3u-1995 10 & 100 Mb/s Management" + ::= { dot3StatsEntry 18 } + + -- the Ethernet-like Collision Statistics group + + -- Implementation of this group is optional; it is appropriate + -- for all systems which have the necessary metering + + dot3CollTable OBJECT-TYPE + SYNTAX SEQUENCE OF Dot3CollEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION "A collection of collision histograms for a + particular set of interfaces." + ::= { dot3 5 } + + dot3CollEntry OBJECT-TYPE + SYNTAX Dot3CollEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION "A cell in the histogram of per-frame + collisions for a particular interface. An + instance of this object represents the + frequency of individual MAC frames for which + the transmission (successful or otherwise) on a + particular interface is accompanied by a + particular number of media collisions." + INDEX { ifIndex, dot3CollCount } + ::= { dot3CollTable 1 } + + Dot3CollEntry ::= + SEQUENCE { + dot3CollCount INTEGER, + dot3CollFrequencies Counter32 + } + + + + +Flick & Johnson Standards Track [Page 19] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + -- { dot3CollEntry 1 } is no longer in use + + dot3CollCount OBJECT-TYPE + SYNTAX INTEGER (1..16) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION "The number of per-frame media collisions for + which a particular collision histogram cell + represents the frequency on a particular + interface." + ::= { dot3CollEntry 2 } + + + dot3CollFrequencies OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "A count of individual MAC frames for which the + transmission (successful or otherwise) on a + particular interface occurs after the + frame has experienced exactly the number + of collisions in the associated + dot3CollCount object. + + For example, a frame which is transmitted + on interface 77 after experiencing + exactly 4 collisions would be indicated + by incrementing only dot3CollFrequencies.77.4. + No other instance of dot3CollFrequencies would + be incremented in this example." + ::= { dot3CollEntry 3 } + + -- 802.3 Tests + + dot3Tests OBJECT IDENTIFIER ::= { dot3 6 } + + dot3Errors OBJECT IDENTIFIER ::= { dot3 7 } + + + -- TDR Test + + dot3TestTdr OBJECT-IDENTITY + STATUS current + DESCRIPTION "The Time-Domain Reflectometry (TDR) test is + specific to ethernet-like interfaces of type + 10Base5 and 10Base2. The TDR value may be + useful in determining the approximate distance + to a cable fault. It is advisable to repeat + + + +Flick & Johnson Standards Track [Page 20] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + this test to check for a consistent resulting + TDR value, to verify that there is a fault. + + A TDR test returns as its result the time + interval, measured in 10 MHz ticks or 100 nsec + units, between the start of TDR test + transmission and the subsequent detection of a + collision or deassertion of carrier. On + successful completion of a TDR test, the result + is stored as the value of an appropriate + instance of an appropriate vendor specific MIB + object, and the OBJECT IDENTIFIER of that + instance is stored in the appropriate instance + of the appropriate test result code object + (thereby indicating where the result has been + stored)." + ::= { dot3Tests 1 } + + -- Loopback Test + + dot3TestLoopBack OBJECT-IDENTITY + STATUS current + DESCRIPTION "This test configures the MAC chip and executes + an internal loopback test of memory, data paths, + and the MAC chip logic. This loopback test can + only be executed if the interface is offline. + Once the test has completed, the MAC chip should + be reinitialized for network operation, but it + should remain offline. + + If an error occurs during a test, the + appropriate test result object will be set + to indicate a failure. The two OBJECT + IDENTIFIER values dot3ErrorInitError and + dot3ErrorLoopbackError may be used to provided + more information as values for an appropriate + test result code object." + ::= { dot3Tests 2 } + + dot3ErrorInitError OBJECT-IDENTITY + STATUS current + DESCRIPTION "Couldn't initialize MAC chip for test." + ::= { dot3Errors 1 } + + dot3ErrorLoopbackError OBJECT-IDENTITY + STATUS current + DESCRIPTION "Expected data not received (or not received + correctly) in loopback test." + + + +Flick & Johnson Standards Track [Page 21] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + ::= { dot3Errors 2 } + + + -- 802.3 Hardware Chipsets + + -- The object dot3StatsEtherChipSet is provided to + -- identify the MAC hardware used to communicate on an + -- interface. The following hardware chipsets are + -- registered: + + dot3ChipSets OBJECT IDENTIFIER ::= { dot3 8 } + + dot3ChipSetAMD OBJECT IDENTIFIER ::= { dot3ChipSets 1 } + + dot3ChipSetAMD7990 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Advanced + Micro Devices Am7990 Local Area Network + Controller for Ethernet (LANCE)." + ::= { dot3ChipSetAMD 1 } + + dot3ChipSetAMD79900 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Advanced + Micro Devices Am79900 chip." + ::= { dot3ChipSetAMD 2 } + + dot3ChipSetAMD79C940 OBJECT-IDENTITY + + STATUS current + DESCRIPTION "The authoritative identifier for the Advanced + Micro Devices Am79C940 Media Access Controller + for Ethernet (MACE)." + ::= { dot3ChipSetAMD 3 } + + dot3ChipSetAMD79C90 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Advanced + Micro Devices Am79C90 CMOS Local Area Network + Controller for Ethernet (C-LANCE)." + ::= { dot3ChipSetAMD 4 } + + dot3ChipSetAMD79C960 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Advanced + Micro Devices Am79C960 PCnet-ISA Single Chip + Ethernet Controller for ISA." + ::= { dot3ChipSetAMD 5 } + + + +Flick & Johnson Standards Track [Page 22] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + dot3ChipSetAMD79C961 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Advanced + Micro Devices Am79C961 PCnet-ISA+ Single Chip + Plug & Play Full-Duplex Ethernet Controller + for ISA." + ::= { dot3ChipSetAMD 6 } + + dot3ChipSetAMD79C961A OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Advanced + Micro Devices Am79C961A PCnet-ISA II Single Chip + Plug & Play Full-Duplex Ethernet Controller + for ISA." + ::= { dot3ChipSetAMD 7 } + + dot3ChipSetAMD79C965 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Advanced + Micro Devices Am79C965 PCnet-32 Single Chip + Ethernet Controller for PCI." + ::= { dot3ChipSetAMD 8 } + + dot3ChipSetAMD79C970 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Advanced + Micro Devices Am79C970 PCnet PCI Single Chip + Ethernet Controller for PCI Local Bus." + + ::= { dot3ChipSetAMD 9 } + + dot3ChipSetAMD79C970A OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Advanced + Micro Devices AM79C970A PCnet PCI II Single Chip + Full-Duplex Ethernet Controller for PCI Local + Bus." + ::= { dot3ChipSetAMD 10 } + + dot3ChipSetAMD79C971 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Advanced + Micro Devices Am79C971 PCnet-FAST Single Chip + Full-Duplex 10/100 Mbps Ethernet Controller for + PCI Local Bus." + ::= { dot3ChipSetAMD 11 } + + dot3ChipSetAMD79C972 OBJECT-IDENTITY + + + +Flick & Johnson Standards Track [Page 23] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + STATUS current + DESCRIPTION "The authoritative identifier for the Advanced + Micro Devices Am79C972 PCnet-FAST+ Enhanced + 10/100 Mbps PCI Ethernet Controller with OnNow + Support." + ::= { dot3ChipSetAMD 12 } + + dot3ChipSetIntel OBJECT IDENTIFIER ::= { dot3ChipSets 2 } + + dot3ChipSetIntel82586 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Intel + 82586 IEEE 802.3 Ethernet LAN Coprocessor." + ::= { dot3ChipSetIntel 1 } + + dot3ChipSetIntel82596 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Intel + 82596 High-Performance 32-Bit Local Area Network + Coprocessor." + ::= { dot3ChipSetIntel 2 } + + dot3ChipSetIntel82595 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Intel + 82595 High Integration Ethernet Controller." + ::= { dot3ChipSetIntel 3 } + + dot3ChipSetIntel82557 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Intel + 82557 Fast Ethernet PCI Bus Lan Controller." + ::= { dot3ChipSetIntel 4 } + + dot3ChipSetIntel82558 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Intel + 82558 Fast Ethernet PCI Bus LAN Controller with + Integrated PHY." + ::= { dot3ChipSetIntel 5 } + + dot3ChipSetSeeq OBJECT IDENTIFIER ::= { dot3ChipSets 3 } + + dot3ChipSetSeeq8003 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the SEEQ + 8003 chip set." + ::= { dot3ChipSetSeeq 1 } + + + +Flick & Johnson Standards Track [Page 24] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + dot3ChipSetSeeq80C03 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the SEEQ + 80C03 Full-Duplex CMOS Ethernet Data Link + Controller (MAC)." + ::= { dot3ChipSetSeeq 2 } + + dot3ChipSetSeeq84C30 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the SEEQ + 4-Port 84C30 Full-Duplex CMOS Ethernet 10 + MBit/Sec Data Link Controller (MAC)." + ::= { dot3ChipSetSeeq 3 } + + dot3ChipSetSeeq8431 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the SEEQ + 4-Port 8431 Full-Duplex CMOS Ethernet 10 + MBit/Sec Data Link Controller (MAC)." + ::= { dot3ChipSetSeeq 4 } + + dot3ChipSetSeeq80C300 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the SEEQ + 80C300 Full-Duplex CMOS Ethernet 10/100 + Mbit/Sec Data Link Controller (MAC)." + ::= { dot3ChipSetSeeq 5 } + + dot3ChipSetSeeq84C300 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the SEEQ + 4-Port 84C300 Fast Ethernet Controller (MAC)." + ::= { dot3ChipSetSeeq 6 } + + dot3ChipSetSeeq84301 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the SEEQ + 4-Port 84301 Fast Ethernet Controller (MAC)." + ::= { dot3ChipSetSeeq 7 } + + dot3ChipSetSeeq84302 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the SEEQ + 4-Port 84302 Fast Ethernet Controller (MAC)." + ::= { dot3ChipSetSeeq 8 } + + dot3ChipSetSeeq8100 OBJECT-IDENTITY + STATUS current + + + +Flick & Johnson Standards Track [Page 25] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + DESCRIPTION "The authoritative identifier for the SEEQ + 8100 Gigabit Ethernet Controller (MAC & PCS)." + ::= { dot3ChipSetSeeq 9 } + + dot3ChipSetNational OBJECT IDENTIFIER ::= { dot3ChipSets 4 } + + dot3ChipSetNational8390 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the National + Semiconductor DP8390 Network Interface + Controller." + ::= { dot3ChipSetNational 1 } + + dot3ChipSetNationalSonic OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the National + Semiconductor DP83932 Systems-Oriented Network + Interface Controller (SONIC)." + ::= { dot3ChipSetNational 2 } + + dot3ChipSetNational83901 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the National + Semiconductor DP83901 Serial Network Interface + Controller (SNIC)." + ::= { dot3ChipSetNational 3 } + + dot3ChipSetNational83902 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the National + Semiconductor DP83902 Serial Network Interface + Controller for Twisted Pair (ST-NIC)." + ::= { dot3ChipSetNational 4 } + + dot3ChipSetNational83905 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the National + Semiconductor DP83905 AT Local Area Network + Twisted-Pair Interface (AT/LANTIC)." + ::= { dot3ChipSetNational 5 } + + dot3ChipSetNational83907 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the National + Semiconductor DP83907 AT Twisted-Pair Enhanced + Coaxial Network Interface Controller + (AT/LANTIC II)." + ::= { dot3ChipSetNational 6 } + + + +Flick & Johnson Standards Track [Page 26] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + dot3ChipSetNational83916 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the National + Semiconductor DP83916 Systems-Oriented Network + Interface Controller (SONIC-16)." + ::= { dot3ChipSetNational 7 } + + dot3ChipSetNational83934 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the National + Semiconductor DP83934 Systems-Oriented Network + Interface Controller with Twisted Pair Interface + (SONIC-T)." + ::= { dot3ChipSetNational 8 } + + dot3ChipSetNational83936 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the National + Semiconductor DP83936AVUL Full-Duplex Systems- + Oriented Network Interface Controller with + Twisted Pair Interface (SONIC-T)." + ::= { dot3ChipSetNational 9 } + + dot3ChipSetFujitsu OBJECT IDENTIFIER ::= { dot3ChipSets 5 } + + dot3ChipSetFujitsu86950 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Fujitsu + 86950 chip." + ::= { dot3ChipSetFujitsu 1 } + + dot3ChipSetFujitsu86960 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Fujitsu + MB86960 Network Interface Controller with + Encoder/Decoder (NICE)." + ::= { dot3ChipSetFujitsu 2 } + + dot3ChipSetFujitsu86964 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Fujitsu + MB86964 Ethernet Controller with 10BASE-T + Tranceiver." + ::= { dot3ChipSetFujitsu 3 } + + dot3ChipSetFujitsu86965A OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Fujitsu + + + +Flick & Johnson Standards Track [Page 27] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + MB86965A EtherCoupler Single-Chip Ethernet + Controller." + ::= { dot3ChipSetFujitsu 4 } + + dot3ChipSetFujitsu86965B OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Fujitsu + MB86965B EtherCoupler Single-Chip Ethernet + Controller (supports full-duplex)." + ::= { dot3ChipSetFujitsu 5 } + + dot3ChipSetDigital OBJECT IDENTIFIER ::= { dot3ChipSets 6 } + + dot3ChipSetDigitalDC21040 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Digital + Semiconductor DC21040 chip." + ::= { dot3ChipSetDigital 1 } + + dot3ChipSetDigital21041 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Digital + Semiconductor 21041 PCI Ethernet LAN + Controller." + ::= { dot3ChipSetDigital 2 } + + dot3ChipSetDigital21140 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Digital + Semiconductor 21140 PCI Fast Ethernet LAN + Controller." + ::= { dot3ChipSetDigital 3 } + + dot3ChipSetDigital21143 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Digital + Semiconductor 21143 PCI/CardBus 10/100-Mb/s + Ethernet LAN Controller." + ::= { dot3ChipSetDigital 4 } + + dot3ChipSetDigital21340 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Digital + Semiconductor 21340 10/100-MB/s managed buffered + port switch." + ::= { dot3ChipSetDigital 5 } + + dot3ChipSetDigital21440 OBJECT-IDENTITY + + + +Flick & Johnson Standards Track [Page 28] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + STATUS current + DESCRIPTION "The authoritative identifier for the Digital + Semiconductor 21440 Multiport 10/100Mbps + Ethernet Controller." + ::= { dot3ChipSetDigital 6 } + + dot3ChipSetDigital21540 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Digital + Semiconductor 21540 PCI/CardBus Ethernet LAN + Controller with Modem Interface." + ::= { dot3ChipSetDigital 7 } + + dot3ChipSetTI OBJECT IDENTIFIER ::= { dot3ChipSets 7 } + + dot3ChipSetTIE100 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Texas + Instruments TNETE100 ThunderLAN PCI Fast + Ethernet Controller." + ::= { dot3ChipSetTI 1 } + + dot3ChipSetTIE110 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Texas + Instruments TNETE110 ThunderLAN PCI 10BASE-T + Ethernet Adapter." + ::= { dot3ChipSetTI 2 } + + dot3ChipSetTIX3100 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Texas + Instruments TNETX3100 Desktop ThunderSWITCH + 8/2." + ::= { dot3ChipSetTI 3 } + + dot3ChipSetTIX3150 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Texas + Instruments TNETX3150 ThunderSWITCH 12/3." + ::= { dot3ChipSetTI 4 } + + dot3ChipSetTIX3270 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Texas + Instruments TNETX3270 ThunderSWITCH 24/3." + ::= { dot3ChipSetTI 5 } + + + + +Flick & Johnson Standards Track [Page 29] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + dot3ChipSetToshiba OBJECT IDENTIFIER ::= { dot3ChipSets 8 } + + dot3ChipSetToshibaTC35815F OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Toshiba + TC35815F PCI-Based 100/10Mbps Ethernet + Controller." + ::= { dot3ChipSetToshiba 1 } + + dot3ChipSetLucent OBJECT IDENTIFIER ::= { dot3ChipSets 9 } + + dot3ChipSetLucentATT1MX10 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Lucent + Technologies ATT1MX10 (Spinnaker) Quad MAC and + Tranceiver for Ethernet Frame Switching." + ::= { dot3ChipSetLucent 1 } + + dot3ChipSetLucentLUC3M08 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Lucent + Technologies LUC3M08 Eight Ethernet MACs for + 10/100 Mbits/s Frame Switching." + ::= { dot3ChipSetLucent 2 } + + dot3ChipSetGalileo OBJECT IDENTIFIER ::= { dot3ChipSets 10 } + + dot3ChipSetGalileoGT48001 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Galileo + Technology GT-48001A Switched Ethernet + Controller." + ::= { dot3ChipSetGalileo 1 } + + dot3ChipSetGalileoGT48002 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Galileo + Technology GT-48002A Switched Fast Ethernet + Controller." + ::= { dot3ChipSetGalileo 2 } + + dot3ChipSetGalileoGT48004 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Galileo + Technology GT-48004A Four Port Fast Ethernet + Switch for Multiport 10/100BASE-X Systems." + ::= { dot3ChipSetGalileo 3 } + + + + +Flick & Johnson Standards Track [Page 30] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + dot3ChipSetGalileoGT48207 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Galileo + Technology GT-48207 Low-Cost 10 Port Switched + Ethernet Controller for 10+10/100BASE-X." + ::= { dot3ChipSetGalileo 4 } + + dot3ChipSetGalileoGT48208 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Galileo + Technology GT-48208 Advanced 10 Port Switched + Ethernet Controller for 10+10/100BASE-X." + ::= { dot3ChipSetGalileo 5 } + + dot3ChipSetGalileoGT48212 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Galileo + Technology GT-48212 Advanced 14 Port Switched + Ethernet Controller for 10+10/100BASE-X." + ::= { dot3ChipSetGalileo 6 } + + dot3ChipSetJato OBJECT IDENTIFIER ::= { dot3ChipSets 11 } + + dot3ChipSetJatoJT1001 OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the Jato + Technologies JT1001 GigEMAC Server + 10/100/1000Mbps Ethernet Controller with PCI + interface." + ::= { dot3ChipSetJato 1 } + + dot3ChipSetXaQti OBJECT IDENTIFIER ::= { dot3ChipSets 12 } + + dot3ChipSetXaQtiXQ11800FP OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the XaQTI + XQ11800FP XMAC II Gigabit Ethernet Media Access + Controller." + ::= { dot3ChipSetXaQti 1 } + + dot3ChipSetXaQtiXQ18110FP OBJECT-IDENTITY + STATUS current + DESCRIPTION "The authoritative identifier for the XaQTI + XQ18110FP GigaPower Protocol Accelerator." + ::= { dot3ChipSetXaQti 2 } + + -- For those chipsets not represented above, OBJECT IDENTIFIER + -- assignment is required in other documentation, e.g., + + + +Flick & Johnson Standards Track [Page 31] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + -- assignment within that part of the registration tree + -- delegated to individual enterprises (see RFC 1155 and + -- RFC 1902). + -- + -- In the future, management of chipset registrations may be + -- delegated to the Internet Assigned Numbers Authority (IANA). + + -- conformance information + + etherConformance OBJECT IDENTIFIER ::= { etherMIB 2 } + + etherGroups OBJECT IDENTIFIER ::= { etherConformance 1 } + etherCompliances OBJECT IDENTIFIER ::= { etherConformance 2 } + + + -- compliance statements + + etherCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION "The compliance statement for managed network + entities which have ethernet-like network + interfaces." + + MODULE -- this module + MANDATORY-GROUPS { etherStatsGroup } + + GROUP etherCollisionTableGroup + DESCRIPTION "This group is optional. It is appropriate + for all systems which have the necessary + metering. Implementation in such systems is + highly recommended." + ::= { etherCompliances 1 } + + ether100MbsCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION "The compliance statement for managed network + entities which have 100 Mb/sec ethernet-like + network interfaces." + + MODULE -- this module + MANDATORY-GROUPS { etherStats100MbsGroup } + + GROUP etherCollisionTableGroup + DESCRIPTION "This group is optional. It is appropriate + for all systems which have the necessary + metering. Implementation in such systems is + highly recommended." + ::= { etherCompliances 2 } + + + +Flick & Johnson Standards Track [Page 32] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + -- units of conformance + + etherStatsGroup OBJECT-GROUP + OBJECTS { dot3StatsIndex, + dot3StatsAlignmentErrors, + dot3StatsFCSErrors, + dot3StatsSingleCollisionFrames, + dot3StatsMultipleCollisionFrames, + dot3StatsSQETestErrors, + dot3StatsDeferredTransmissions, + dot3StatsLateCollisions, + dot3StatsExcessiveCollisions, + dot3StatsInternalMacTransmitErrors, + dot3StatsCarrierSenseErrors, + dot3StatsFrameTooLongs, + dot3StatsInternalMacReceiveErrors, + dot3StatsEtherChipSet + } + STATUS current + DESCRIPTION "A collection of objects providing information + applicable to all ethernet-like network + interfaces." + ::= { etherGroups 1 } + + + etherCollisionTableGroup OBJECT-GROUP + OBJECTS { dot3CollFrequencies + } + STATUS current + DESCRIPTION "A collection of objects providing a histogram + of packets successfully transmitted after + experiencing exactly N collisions." + ::= { etherGroups 2 } + + + etherStats100MbsGroup OBJECT-GROUP + OBJECTS { dot3StatsIndex, + dot3StatsAlignmentErrors, + dot3StatsFCSErrors, + dot3StatsSingleCollisionFrames, + dot3StatsMultipleCollisionFrames, + dot3StatsDeferredTransmissions, + dot3StatsLateCollisions, + dot3StatsExcessiveCollisions, + dot3StatsInternalMacTransmitErrors, + dot3StatsCarrierSenseErrors, + dot3StatsFrameTooLongs, + dot3StatsInternalMacReceiveErrors, + + + +Flick & Johnson Standards Track [Page 33] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + dot3StatsEtherChipSet, + dot3StatsSymbolErrors + } + STATUS current + DESCRIPTION "A collection of objects providing information + applicable to 100 Mb/sec ethernet-like network + interfaces." + ::= { etherGroups 3 } + + + END + +5. Intellectual Property + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + +6. Acknowledgements + + This document was produced by the 802.3 Hub MIB Working Group. + + This document is almost completely based on both the Standard + Ethernet MIB, RFC 1643 [10], and the Proposed Standard Ethernet MIB + using the SNMPv2 SMI, RFC 1650 [11], both of which were edited by + Frank Kastenholz of FTP Software and produced by the Ethernet MIB + Working Group. This document extends those documents by providing + support for 100 Mb/sec ethernet interfaces as outlined in [6]. + + RFC 1643 and RFC 1650, in turn, are based on the Draft Standard + Ethernet MIB, RFC 1398 [9], also edited by Frank Kastenholz and + produced by the Ethernet MIB Working Group. + + + +Flick & Johnson Standards Track [Page 34] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + RFC 1398, in turn, is based on the Proposed Standard Ethernet MIB, + RFC 1284 [8], which was edited by John Cook of Chipcom and produced + by the Transmission MIB Working Group. The Ethernet MIB Working + Group gathered implementation experience of the variables specified + in RFC 1284 and used that information to develop this revised MIB. + + RFC 1284, in turn, is based on a document written by Frank + Kastenholz, then of Interlan, entitled IEEE 802.3 Layer Management + Draft M compatible MIB for TCP/IP Networks [7]. This document has + been modestly reworked, initially by the SNMP Working Group, and then + by the Transmission Working Group, to reflect the current conventions + for defining objects for MIB interfaces. James Davin, of the MIT + Laboratory for Computer Science, and Keith McCloghrie of Hughes LAN + Systems, contributed to later drafts of this memo. Marshall Rose of + Performance Systems International, Inc. converted the document into + its current concise format. Anil Rijsinghani of DEC contributed text + that more adequately describes the TDR test. Thanks to Frank + Kastenholz of Interlan and Louis Steinberg of IBM for their + experimentation. + +7. References + + [1] Information processing systems - Open Systems Interconnection - + Specification of Abstract Syntax Notation One (ASN.1), + International Organization for Standardization, International + Standard 8824, December 1987. + + [2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. + Waldbusser, "Structure of Management Information for Version 2 of + the Simple Network Management Protocol (SNMPv2)", RFC 1902, + January 1996. + + [3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. + Waldbusser, "Textual Conventions for Version 2 of the Simple + Network Management Protocol (SNMPv2)", RFC 1903, January 1996. + + [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. + Waldbusser, "Conformance Statements for Version 2 of the Simple + Network Management Protocol (SNMPv2)", RFC 1904, January 1996. + + [5] IEEE, IEEE 802.3 Layer Management, November 1988. + + [6] IEEE, IEEE 802.3u-1995, "10 & 100 Mb/s Management," Section 30, + Supplement to IEEE Std 802.3, October 26, 1995. + + [7] Kastenholz, F., "IEEE 802.3 Layer Management Draft compatible MIB + for TCP/IP Networks", electronic mail message to mib- + wg@nnsc.nsf.net, 9 June 1989. + + + +Flick & Johnson Standards Track [Page 35] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + [8] Cook, J., "Definitions of Managed Objects for Ethernet-Like + Interface Types", RFC 1284, December 1991. + + [9] Kastenholz, F., "Definitions of Managed Objects for the + Ethernet-like Interface Types", RFC 1398, January 1993. + + [10] Kastenholz, F., "Definitions of Managed Objects for the + Ethernet-like Interface Types", RFC 1643, July 1994. + + [11] Kastenholz, F., "Definitions of Managed Objects for the + Ethernet-like Interface Types using SMIv2", RFC 1650, August + 1994. + + [12] McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB + using SMIv2", RFC 2233, Cisco Systems, November 1997. + + [13] Bradner, S., "Key words for use in RFCs to Indicate Requirements + Levels", BCP 14, RFC 2119, March 1997. + + [14] deGraaf, K., Romascanu, D., McMaster, D., McCloghrie, K., and S. + Roberts, "Definitions of Managed Objects for IEEE 802.3 Medium + Attachment Units (MAUs) using SMIv2", RFC 2239, November 1997. + + [15] Kastenholz, F., "Implementation Notes and Experience for The + Internet Ethernet MIB", RFC 1369, October 1992. + + [16] McCloghrie, K., and M. Rose, Editors, "Management Information + Base for Network Management of TCP/IP-based internets: MIB-II", + STD 17, RFC 1213, March 1991. + + [17] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) + for version 3 of the Simple Network Management Protocol + (SNMPv3)", RFC 2274, January 1998. + + [18] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access + Control Model for the Simple Network Management Protocol (SNMP)", + RFC 2275, January 1998. + +8. Security Considerations + + There are no management objects defined in this MIB that have a MAX- + ACCESS clause of read-write and/or read-create. So, if this MIB is + implemented correctly, then there is no risk that an intruder can + alter or create any management objects of this MIB via direct SNMP + SET operations. + + + + + + +Flick & Johnson Standards Track [Page 36] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + + There are a number of managed objects in this MIB that may be + considered to contain sensitive information. In particular, the + dot3StatsEtherChipSet object may be considered sensitive in many + environments, since it would allow an intruder to obtain information + about which vendor's equipment is in use on the network. + + Therefore, it may be important in some environments to control read + access to these objects and possibly to even encrypt the values of + these object when sending them over the network via SNMP. Not all + versions of SNMP provide features for such a secure environment. + + SNMPv1 by itself is such an insecure environment. Even if the + network itself is secure (for example by using IPSec), even then, + there is no control as to who on the secure network is allowed to + access and GET (read) the objects in this MIB. + + It is recommended that the implementors consider the security + features as provided by the SNMPv3 framework. Specifically, the use + of the User-based Security Model RFC 2274 [17] and the View-based + Access Control Model RFC 2275 [18] is recommended. + + It is then a customer/user responsibility to ensure that the SNMP + entity giving access to an instance of this MIB, is properly + configured to give access to those objects only to those principals + (users) that have legitimate rights to access them. + +9. Authors' Addresses + + John Flick + Hewlett-Packard Company + 8000 Foothills Blvd. M/S 5556 + Roseville, CA 95747-5556 + + Phone: +1 916 785 4018 + EMail: johnf@hprnd.rose.hp.com + + + Jeffrey Johnson + RedBack Networks + 2570 North First Street, Suite 410 + San Jose, CA, 95131, USA + + Phone: +1 408 571 2699 + EMail: jeff@redbacknetworks.com + + + + + + + +Flick & Johnson Standards Track [Page 37] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + +A. Change Log + + This section enumerates changes made to RFC 1650 to produce this + document. + + (1) The MODULE-IDENTITY has been updated to reflect the changes + in the MIB. + + (2) A new object, dot3StatsSymbolErrors, has been added. + + (3) The definition of the object dot3StatsIndex has been + converted to use the SMIv2 OBJECT-TYPE macro. + + (4) A new conformance group, etherStats100MbsGroup, has been + added. + + (5) A new compliance statement, ether100MbsCompliance, has + been added. + + (6) The Acknowledgements were extended to provide a more + complete history of the origin of this document. + + (7) The discussion of ifType has been expanded. + + (8) A section on mapping of Interfaces MIB objects has + been added. + + (9) A section defining the relationship of this MIB to + the MAU MIB has been added. + + (10) A section on the mapping of IEEE 802.3 managed objects + to this MIB and the Interfaces MIB has been added. + + (11) Converted the dot3Tests, dot3Errors, and dot3ChipSets + OIDs to use the OBJECT-IDENTITY macro. + + (12) Added to the list of registered dot3ChipSets. + + (13) An intellectual property notice and copyright notice + were added, as required by RFC 2026. + + + + + + + + + + + +Flick & Johnson Standards Track [Page 38] + +RFC 2358 MIB for Ethernet-like Interface Types June 1998 + + +B. Full Copyright Statement + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + + + +Flick & Johnson Standards Track [Page 39] + -- cgit v1.2.3