Tech-invite3GPPspecsSIPRFCs
898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 3635

Definitions of Managed Objects for the Ethernet-like Interface Types

Pages: 64
Proposed Standard
Obsoletes:  2665
Part 1 of 3 – Pages 1 to 16
None   None   Next

Top   ToC   RFC3635 - Page 1
Network Working Group                                           J. Flick
Request for Comments: 3635                       Hewlett-Packard Company
Obsoletes: 2665                                           September 2003
Category: Standards Track


                   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 (2003).  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. In particular, it defines objects for managing Ethernet-like interfaces. This memo obsoletes RFC 2665. It updates that specification by including management information useful for the management of 10 Gigabit per second (Gb/s) Ethernet interfaces.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Internet-Standard Management Framework . . . . . . . . . . 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. ifRcvAddressTable. . . . . . . . . . . . . . . . 5 3.2.4. ifType . . . . . . . . . . . . . . . . . . . . . 5 3.2.5. ifXxxOctets. . . . . . . . . . . . . . . . . . . 5 3.2.6. ifXxxXcastPkts . . . . . . . . . . . . . . . . . 6 3.2.7. ifMtu. . . . . . . . . . . . . . . . . . . . . . 8 3.2.8. ifSpeed and ifHighSpeed. . . . . . . . . . . . . 8 3.2.9. ifPhysAddress. . . . . . . . . . . . . . . . . . 9 3.2.10. Specific Interface MIB Objects. . . . . . . . . 10 3.3. Relation to the 802.3 MAU MIB. . . . . . . . . . . . . . 13
Top   ToC   RFC3635 - Page 2
       3.4.  dot3StatsEtherChipSet. . . . . . . . . . . . . . . . . . 13
       3.5.  Mapping of IEEE 802.3 Managed Objects. . . . . . . . . . 14
   4.  Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 17
   5.  Intellectual Property Statement. . . . . . . . . . . . . . . . 55
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56
   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 57
   8.  Informative References . . . . . . . . . . . . . . . . . . . . 58
   9.  Security Considerations. . . . . . . . . . . . . . . . . . . . 59
   10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 60
   A.  Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 61
       A.1.  Changes since RFC 2665 . . . . . . . . . . . . . . . . . 61
       A.2.  Changes between RFC 2358 and RFC 2665  . . . . . . . . . 62
       A.3.  Changes between RFC 1650 and RFC 2358. . . . . . . . . . 62
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 63
   Full Copyright Statement  . . . . . . . . . . . . . . . . . . . . .64

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 updates the list of managed objects specified in the earlier version of this MIB, module, RFC 2665 [RFC2665]. 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, reflects 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. 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 [RFC2119].
Top   ToC   RFC3635 - Page 3

2. The Internet-Standard Management Framework

For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].

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 value ethernetCsmacd(6) of the ifType object in the Interfaces MIB [RFC2863]. Some older implementations may return the values iso88023Csmacd(7) or starLan(11) for ifType for ethernet-like media. The definitions presented here are based on Section 30, "10 Mb/s, 100 Mb/s 1000 Mb/s and 10 Gb/s Management", and Annex 30A, "GDMO Specification for 802.3 managed object classes" of IEEE Std. 802.3, 2002 Edition [IEEE802.3], amended by IEEE Std. 802.3ae-2002 [IEEE802.3ae], as originally interpreted by Frank Kastenholz, then of Interlan in [KASTEN]. Implementors of these MIB objects should note that IEEE Std. 802.3 [IEEE802.3] 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 [IEEE802.3] are represented by previously defined objects in MIB-2 [RFC1213] or in the Interfaces MIB [RFC2863], 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.
Top   ToC   RFC3635 - Page 4

3.1. Relation to MIB-2

This section applies only when this MIB is used in conjunction with the "old" [RFC1213] interface group. The relationship between an ethernet-like interface and an interface in the context of MIB-2 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 IDENTIFIER ::= { transmission 7 }

3.2. Relation to the Interfaces MIB

The Interface MIB [RFC2863] 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 4 of [RFC2863] 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 [RFC2863] in order to understand the general intent of these areas.

3.2.1. Layering Model

Ordinarily, there are no sublayers for an ethernet-like interface. However there may be implementation-specific requirements which require the use of sublayers. One example is the use of 802.3 link aggregation. In this case, Annex 30C of [IEEE802.3] describes the layering model and the use of the ifStackTable for representing aggregated links. Another example is the use of the 802.3 WAN Interface Sublayer. In this case, The 802.3 WIS MIB [RFC3637] describes the layering model and the use of the ifStackTable for representing the WAN sublayer.

3.2.2. Virtual Circuits

This medium does not support virtual circuits and this area is not applicable to this MIB.
Top   ToC   RFC3635 - Page 5

3.2.3. 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.4. ifType

This MIB applies to interfaces which have the ifType value ethernetCsmacd(6). It is REQUIRED 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. Use of the ifType values iso88023Csmacd(7) and starLan(11) are deprecated, however some older implementations may return these values. Management applications should be prepared to receive these deprecated ifType values from older implementations. There are three other interface types defined in the IANAifType-MIB for Ethernet. They are fastEther(62), fastEtherFX(69), and gigabitEthernet(117). These interface types were registered by individual vendors, not by any IETF working group. A requirement for compliance with this document is that all ethernet-like interfaces MUST return ethernetCsmacd(6) for ifType, and MUST NOT return fastEther(62), fastEtherFX(69), or gigabitEthernet(117). However, as there are fielded implementations that do return these obsolete ifType values, management applications SHOULD be prepared to receive them from older implementations. 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 [RFC3636]. Note that implementation of the 802.3 MAU MIB [RFC3636] is REQUIRED for all ethernet-like interfaces.

3.2.5. ifXxxOctets

The Interface MIB octet counters, ifInOctets, ifOutOctets, ifHCInOctets and ifHCOutOctets, MUST include all octets in valid frames sent or received on the interface, including the MAC header and FCS, but not the preamble, start of frame delimiter, or extension octets. This corresponds to the definition of frameSize/8 in section
Top   ToC   RFC3635 - Page 6
   4.2.7.1 of [IEEE802.3] (frameSize is defined in bits rather than
   octets, and is defined as 2 x addressSize + lengthOrTypeSize +
   dataSize + crcSize).  They do not include the number of octets in
   collided or failed transmit attempts, since the MAC layer driver
   typically does not have visibility to count these octets.  They also
   do not include octets in received invalid frames, since this
   information is normally not passed to the MAC layer, and since
   non-promiscuous MAC implementations cannot reliably determine whether
   an invalid frame was actually addressed to this station.

   Note that these counters do include octets in valid MAC control
   frames sent or received on the interface, as well as octets in
   otherwise valid received MAC frames that are discarded by the MAC
   layer for some reason (insufficient buffer space, unknown protocol,
   etc.).

   Note that the octet counters in IF-MIB do not exactly match the
   definition of the octet counters in IEEE 802.3.  aOctetsTransmittedOK
   and aOctetsReceivedOK count only the octets in the clientData and Pad
   fields, whereas ifInOctets and ifOutOctets include the entire MAC
   frame, including MAC header and FCS.  However, the IF-MIB counters
   can be derived from the IEEE 802.3 counters as follows:

     ifInOctets = aOctetsReceivedOK + (18 * aFramesReceivedOK)
     ifOutOctets = aOctetsTransmittedOK + (18 * aFramesTransmittedOK)

   Another difference to keep in mind between the IF-MIB counters and
   IEEE 802.3 counters is that in the IEEE 802.3 document, the frame
   counters and octet counters are always incremented together.
   aOctetsTransmittedOK counts the number of octets in frames that were
   counted by aFramesTransmittedOK.  aOctetsReceivedOK counts the number
   of octets in frames that were counted by aFramesReceivedOK.  This is
   not the case with the IF-MIB counters.  The IF-MIB octet counters
   count the number of octets sent to or received from the layer below
   this interface, whereas the packet counters count the number of
   packets sent to or received from the layer above.  Therefore,
   received MAC Control frames, ifInDiscards, and ifInUnknownProtos are
   counted by ifInOctets, but not ifInXcastPkts.  Transmitted MAC
   Control frames are counted by ifOutOctets, but not ifOutXcastPkts.
   ifOutDiscards and ifOutErrors are counted by ifOutXcastPkts, but not
   ifOutOctets.

3.2.6. ifXxxXcastPkts

The packet counters in the IF-MIB do not exactly match the definition of the frame counters in IEEE 802.3. aFramesTransmittedOK counts the number of frames successfully transmitted on the interface, whereas ifOutUcastPkts, ifOutMulticastPkts and ifOutBroadcastPkts count the
Top   ToC   RFC3635 - Page 7
   number of transmit requests made from a higher layer, whether or not
   the transmit attempt was successful.  This means that packets counted
   by ifOutErrors or ifOutDiscards are also counted by ifOutXcastPkts,
   but are not counted by aFramesTransmittedOK.  This also means that,
   since MAC Control frames are generated by a sublayer internal to the
   interface layer rather than by a higher layer, they are not counted
   by ifOutXcastPkts, but are counted by aFramesTransmittedOK.  Roughly:

     aFramesTransmittedOK = ifOutUcastPkts + ifOutMulticastPkts +
                            ifOutBroadcastPkts + dot3OutPauseFrames -
                            (ifOutErrors + ifOutDiscards)

   Similarly, aFramesReceivedOK counts the number of frames received
   successfully by the interface, whether or not they are passed to a
   higher layer, whereas ifInUcastPkts, ifInMulticastPkts and
   ifInBroadcastPkts count only the number of packets passed to a higher
   layer.  This means that packets counted by ifInDiscards or
   ifInUnknownProtos are also counted by aFramesReceivedOK, but are not
   counted by ifInXcastPkts.  This also means that, since MAC Control
   frames are consumed by a sublayer internal to the interface layer and
   not passed to a higher layer, they are not counted by ifInXcastPkts,
   but are counted by aFramesReceivedOK.  Roughly:

     aFramesReceivedOK = ifInUcastPkts + ifInMulticastPkts +
                         ifInBroadcastPkts + dot3InPauseFrames +
                         ifInDiscards + ifInUnknownProtos

   This specification chooses to treat MAC control frames as being
   originated and consumed within the interface and not counted by the
   IF-MIB packet counters.  MAC control frames are normally sent as
   multicast packets.  In many network environments, MAC control frames
   can greatly outnumber multicast frames carrying actual data.  If MAC
   control frames were included in the ifInMulticastPkts and
   ifOutMulticastPkts, the count of data-carrying multicast packets
   would tend to be drowned out by the count of MAC control frames,
   rendering those counters considerably less useful.

   To better understand the issues surrounding the mapping of the IF-MIB
   packet and octet counters to an Ethernet interface, it is useful to
   refer to a Case Diagram [CASE] for the IF-MIB counters, with
   modifications to show the proper interpretation for the Ethernet
   interface layer.
Top   ToC   RFC3635 - Page 8
                               layer above
   --------------------------------------------------------------------
       ifInUcastPkts+         ^           |     ifOutUcastPkts+
       ifInBroadcastPkts+ ----|----   ----|---- ifOutBroadcastPkts+
       ifInMulticastPkts      |           |     ifOutMulticastPkts
                              |           |
        dot3InPauseFrames <---|           |<--- dot3OutPauseFrames
                              |           |
             ifInDiscards <---|           |
                              |           |
        ifInUnknownProtos <---|           |---> ifOutDiscards
                              |           |
               ifInOctets ----|----   ----|---- ifOutOctets
                              |           |
               ifInErrors <---|           |---> ifOutErrors
                              |           V
   --------------------------------------------------------------------
                               layer below

3.2.7. ifMtu

The defined standard MTU for ethernet-like interfaces is 1500 octets. However, many implementations today support larger packet sizes than the IEEE 802.3 standard. The value of this object MUST reflect the actual MTU in use on the interface, whether it matches the standard MTU or not. This value should reflect the value seen by the MAC client interface. When a higher layer protocol, like IP, is running over Ethernet framing, this is the MTU that will be seen by that higher layer protocol. However, most ethernet-like interfaces today run multiple protocols that use a mix of different framing types. For example, an IEEE 802.2 LLC type 1 client protocol will see an MTU of 1497 octets on an interface using the IEEE standard maximum packet size, and a protocol running over SNAP will see an MTU of 1492 octets on an interface using the IEEE standard maximum packet size. However, since specification mandates using the MTU as seen at the MAC client interface, the value of ifMtu would be reported as 1500 octets in these cases.

3.2.8. ifSpeed and ifHighSpeed

For ethernet-like interfaces operating at 1000 Megabits per second (Mb/s) or less, ifSpeed will represent the current operational speed of the interface in bits per second. For current interface types, this will be equal to 1,000,000 (1 million), 10,000,000 (10 million), 100,000,000 (100 million), or 1,000,000,000 (1 billion). ifHighSpeed will represent the current operational speed in millions of bits per
Top   ToC   RFC3635 - Page 9
   second.  For current ethernet-like interfaces, this will be equal to
   1, 10, 100, or 1,000.  If the interface implements auto-negotiation,
   auto-negotiation is enabled for this interface, and the interface has
   not yet negotiated to an operational speed, these objects SHOULD
   reflect the maximum speed supported by the interface.

   For ethernet-like interfaces operating at greater than 1000 Mb/s,
   ifHighSpeed will represent the current operational speed of the
   interface in millions of bits per second.  Note that for WAN
   implementations, this will be the payload data rate over the WAN
   interface sublayer.  For current implementations, this will be equal
   to 10,000 for LAN implementations of 10 Gb/s, and 9,294 for WAN
   implementations of the 10 Gb/s MAC over an OC-192 PHY.  For these
   speeds, ifSpeed should report a maximum unsigned 32-bit value of
   4,294,967,295 as specified in [RFC2863].

   Note that these 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 duplex mode of the
   interface may be determined by examining either the
   dot3StatsDuplexStatus object in this MIB module, or the ifMauType
   object in the 802.3 MAU MIB [RFC3636].

3.2.9. 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. 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.
Top   ToC   RFC3635 - Page 10

3.2.10. Specific Interface MIB Objects

The following table provides specific implementation guidelines for applying the interface group objects to ethernet-like media. Object Guidelines 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 [RFC2863]. ifType Refer to section 3.2.4. ifMtu Refer to section 3.2.7. ifSpeed Refer to section 3.2.8. ifPhysAddress Refer to section 3.2.9. ifAdminStatus Write access is not required. Support for 'testing' is not required. 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 [RFC2863]. ifInOctets The number of octets in valid MAC frames received on this interface, including the MAC header and FCS. This does include the number of octets in valid MAC Control frames received on this interface. See section 3.2.5. ifInUcastPkts Refer to [RFC2863]. Note that this does not include MAC Control frames, since MAC Control frames are consumed by the interface layer and are not passed to any higher layer protocol. See section 3.2.6.
Top   ToC   RFC3635 - Page 11
     ifInDiscards               Refer to [RFC2863].

     ifInErrors                 The sum for this interface of
                                dot3StatsAlignmentErrors,
                                dot3StatsFCSErrors,
                                dot3StatsFrameTooLongs,
                                and dot3StatsInternalMacReceiveErrors.

     ifInUnknownProtos          Refer to [RFC2863].

     ifOutOctets                The number of octets transmitted in
                                valid MAC frames on this interface,
                                including the MAC header and FCS.  This
                                does include the number of octets in
                                valid MAC Control frames transmitted on
                                this interface.  See section 3.2.5.

     ifOutUcastPkts             Refer to [RFC2863].  Note that this does
                                not include MAC Control frames, since
                                MAC Control frames are generated by the
                                interface layer, and are not passed from
                                any higher layer protocol.  See section
                                3.2.6.

     ifOutDiscards              Refer to [RFC2863].

     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 [RFC2863].  Note that this does
                                not include MAC Control frames, since
                                MAC Control frames are consumed by the
                                interface layer and are not passed to
                                any higher layer protocol.  See section
                                3.2.6.
Top   ToC   RFC3635 - Page 12
     ifInBroadcastPkts          Refer to [RFC2863].  Note that this does
                                not include MAC Control frames, since
                                MAC Control frames are consumed by the
                                interface layer, and are not passed to
                                any higher layer protocol.  See section
                                3.2.6.

     ifOutMulticastPkts         Refer to [RFC2863].  Note that this does
                                not include MAC Control frames, since
                                MAC Control frames are generated by the
                                interface layer, and are not passed from
                                any higher layer protocol.  See section
                                3.2.6.

     ifOutBroadcastPkts         Refer to [RFC2863].  Note that this does
                                not include MAC Control frames, since
                                MAC Control frames are generated by the
                                interface layer, and are not passed from
                                any higher layer protocol.  See section
                                3.2.6.

     ifHCInOctets               64-bit versions of counters.  Required
     ifHCOutOctets              for ethernet-like interfaces that are
                                capable of operating at 20 Mb/s or
                                faster, even if the interface is
                                currently operating at less than
                                20 Mb/s.

     ifHCInUcastPkts            64-bit versions of packet counters.
     ifHCInMulticastPkts        Required for ethernet-like interfaces
     ifHCInBroadcastPkts        that are capable of operating at
     ifHCOutUcastPkts           640 Mb/s or faster, even if the
     ifHCOutMulticastPkts       interface is currently operating at
     ifHCOutBroadcastPkts       less than 640 Mb/s.

     ifLinkUpDownTrapEnable     Refer to [RFC2863].  Default is
                                'enabled'

     ifHighSpeed                Refer to section 3.2.8.

     ifPromiscuousMode          Refer to [RFC2863].

     ifConnectorPresent         This will normally be 'true'. It will
                                be 'false' in the case where this
                                interface uses the WAN Interface
                                Sublayer.  See [RFC3637] for details.

     ifAlias                    Refer to [RFC2863].
Top   ToC   RFC3635 - Page 13
     ifCounterDiscontinuityTime Refer to [RFC2863].  Note that a
                                discontinuity in the Interface MIB
                                counters may also indicate a
                                discontinuity in some or all of the
                                counters in this MIB that are associated
                                with that interface.

     ifStackHigherLayer         Refer to section 3.2.1.
     ifStackLowerLayer
     ifStackStatus

     ifRcvAddressAddress        Refer to section 3.2.3.
     ifRcvAddressStatus
     ifRcvAddressType

3.3. Relation to the 802.3 MAU MIB

Support for the mauModIfCompl3 compliance statement of the MAU-MIB [RFC3636] 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, and to control autonegotiation and duplex mode for the interface. Implementing this MIB module without implementing the MAU-MIB would leave applications with no standard way to determine the media type in use, and no standard way to control the duplex mode of the interface.

3.4. dot3StatsEtherChipSet

This document defines an object called dot3StatsEtherChipSet, which is used to identify the MAC hardware used to communicate on an interface. Previous versions of this document contained a number of OID assignments for some existing Ethernet chipsets. Maintaining that list as part of this document has proven to be problematic, so the OID assignments contained in previous versions of this document have now been moved to a separate document [RFC2666]. The dot3StatsEtherChipSet object has now been deprecated. Implementation feedback indicates that this object is much more useful in theory than in practice. The object's utility in debugging network problems in the field appears to be limited. In those cases where it may be useful, it is not sufficient, since it identifies only the MAC chip, and not the PHY, PMD, or driver. The administrative overhead involved in maintaining a central registry of chipset OIDs cannot be justified for an object whose usefulness is questionable at best.
Top   ToC   RFC3635 - Page 14
   Implementations which continue to support this object for the purpose
   of backwards compatibility may continue to use the values defined in
   [RFC2666].  For chipsets not listed in [RFC2666], implementors that
   wish to support this object and return a valid OBJECT IDENTIFIER
   value may assign OBJECT IDENTIFIERS within that part of the
   registration tree delegated to individual enterprises.

3.5. 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* .aMulticastFramesReceivedOK IF-MIB - ifInMulticastPkts* .aBroadcastFramesReceivedOK IF-MIB - ifInBroadcastPkts* .aFrameTooLongErrors dot3StatsFrameTooLongs .aReadWriteMACAddress IF-MIB - ifPhysAddress .aCollisionFrames dot3CollFrequencies .aDuplexStatus dot3StatsDuplexStatus .aRateControlAbility dot3StatsRateControlAbility .aRateControlStatus dot3StatsRateControlStatus .acAddGroupAddress IF-MIB - ifRcvAddressTable .acDeleteGroupAddress IF-MIB - ifRcvAddressTable .acExecuteSelfTest dot3TestLoopBack
Top   ToC   RFC3635 - Page 15
oPHYEntity
 .aPHYID                          dot3StatsIndex or
                                  IF-MIB - ifIndex
 .aSQETestErrors                  dot3StatsSQETestErrors
 .aSymbolErrorDuringCarrier       dot3StatsSymbolErrors

oMACControlEntity
 .aMACControlID                   dot3StatsIndex or
                                  IF-MIB - ifIndex
 .aMACControlFunctionsSupported   dot3ControlFunctionsSupported and
                                  dot3ControlFunctionsEnabled
 .aUnsupportedOpcodesReceived     dot3ControlInUnknownOpcodes

oPAUSEEntity
 .aPAUSEMACCtrlFramesTransmitted  dot3OutPauseFrames
 .aPAUSEMACCtrlFramesReceived     dot3InPauseFrames


   * Note that the octet counters in IF-MIB do not exactly match the
   definition of the octet counters in IEEE 802.3.  See section 3.2.5
   for details.

   Also note that the packet counters in the IF-MIB do not exactly match
   the definition of the frame counters in IEEE 802.3.  See section
   3.2.6 for details.

   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 [RFC1369] for the detailed reasoning on why these objects
   were removed.

   In addition, the following IEEE 802.3 managed objects have not been
   included in this MIB for the following reasons.
Top   ToC   RFC3635 - Page 16
   IEEE 802.3 Managed Object         Disposition

   oMACEntity
    .aMACCapabilities                Can be derived from
                                     MAU-MIB - ifMauTypeListBits

     .aStretchRatio                  Implementation constant.

   oPHYEntity
    .aPhyType                        Can be derived from
                                     MAU-MIB - ifMauType

    .aPhyTypeList                    Can be derived from
                                     MAU-MIB - ifMauTypeListBits

    .aMIIDetect                      Not considered useful.

    .aPhyAdminState                  Can already obtain interface
                                     state from IF-MIB - ifAdminStatus
                                     and MAU state from MAU-MIB -
                                     ifMauStatus.  Providing an
                                     additional state for the PHY
                                     was not considered useful.

    .acPhyAdminControl               Can already control interface
                                     state from IF-MIB - ifAdminStatus
                                     and MAU state from MAU-MIB -
                                     ifMauStatus.  Providing separate
                                     admin control of the PHY was not
                                     considered useful.

   oMACControlEntity
    .aMACControlFramesTransmitted    Can be determined by summing the
                                     OutFrames counters for the
                                     individual control functions

    .aMACControlFramesReceived       Can be determined by summing the
                                     InFrames counters for the
                                     individual control functions

   oPAUSEEntity
    .aPAUSELinkDelayAllowance        Not considered useful.