tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3635

Proposed STD
Pages: 64
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: HUBMIB

Definitions of Managed Objects for the Ethernet-like Interface Types

Part 1 of 3, p. 1 to 16
None       Next RFC Part

Obsoletes:    2665


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


Next RFC Part