summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3635.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3635.txt')
-rw-r--r--doc/rfc/rfc3635.txt3587
1 files changed, 3587 insertions, 0 deletions
diff --git a/doc/rfc/rfc3635.txt b/doc/rfc/rfc3635.txt
new file mode 100644
index 0000000..8369fe3
--- /dev/null
+++ b/doc/rfc/rfc3635.txt
@@ -0,0 +1,3587 @@
+
+
+
+
+
+
+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
+
+
+
+Flick Standards Track [Page 1]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ 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].
+
+
+
+
+
+
+
+
+
+
+Flick Standards Track [Page 2]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+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.
+
+
+
+
+
+
+Flick Standards Track [Page 3]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+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.
+
+
+
+
+
+
+Flick Standards Track [Page 4]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+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
+
+
+
+Flick Standards Track [Page 5]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ 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
+
+
+
+Flick Standards Track [Page 6]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+Flick Standards Track [Page 7]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ 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
+
+
+
+Flick Standards Track [Page 8]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ 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.
+
+
+
+
+
+Flick Standards Track [Page 9]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+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.
+
+
+
+Flick Standards Track [Page 10]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+Flick Standards Track [Page 11]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ 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].
+
+
+
+Flick Standards Track [Page 12]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ 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.
+
+
+
+
+
+
+Flick Standards Track [Page 13]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ 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
+
+
+
+
+Flick Standards Track [Page 14]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+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.
+
+
+
+
+
+
+
+
+Flick Standards Track [Page 15]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+Flick Standards Track [Page 16]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+4. Definitions
+
+ EtherLike-MIB DEFINITIONS ::= BEGIN
+
+ IMPORTS
+ MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY,
+ Integer32, Counter32, Counter64, mib-2, transmission
+ FROM SNMPv2-SMI
+ MODULE-COMPLIANCE, OBJECT-GROUP
+ FROM SNMPv2-CONF
+ TruthValue
+ FROM SNMPv2-TC
+ ifIndex, InterfaceIndex
+ FROM IF-MIB;
+
+ etherMIB MODULE-IDENTITY
+ LAST-UPDATED "200309190000Z" -- September 19, 2003
+ ORGANIZATION "IETF Ethernet Interfaces and Hub MIB
+ Working Group"
+ CONTACT-INFO
+ "WG E-mail: hubmib@ietf.org
+ To subscribe: hubmib-request@ietf.org
+
+ Chair: Dan Romascanu
+ Postal: Avaya Inc.
+ Atidum Technology Park, Bldg. 3
+ Tel Aviv 61131
+ Israel
+ Tel: +972 3 645 8414
+ E-mail: dromasca@avaya.com
+
+ Editor: John Flick
+ Postal: Hewlett-Packard Company
+ 8000 Foothills Blvd. M/S 5557
+ Roseville, CA 95747-5557
+ USA
+ Tel: +1 916 785 4018
+ Fax: +1 916 785 1199
+ E-mail: johnf@rose.hp.com"
+
+ DESCRIPTION "The MIB module to describe generic objects for
+ ethernet-like network interfaces.
+
+ The following reference is used throughout this
+ MIB module:
+
+ [IEEE 802.3 Std] refers to:
+ IEEE Std 802.3, 2002 Edition: 'IEEE Standard
+
+
+
+Flick Standards Track [Page 17]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ for Information technology -
+ Telecommunications and information exchange
+ between systems - Local and metropolitan
+ area networks - Specific requirements -
+ Part 3: Carrier sense multiple access with
+ collision detection (CSMA/CD) access method
+ and physical layer specifications', as
+ amended by IEEE Std 802.3ae-2002:
+ 'Amendment: Media Access Control (MAC)
+ Parameters, Physical Layer, and Management
+ Parameters for 10 Gb/s Operation', August,
+ 2002.
+
+ Of particular interest is Clause 30, '10 Mb/s,
+ 100 Mb/s, 1000 Mb/s, and 10 Gb/s Management'.
+
+ Copyright (C) The Internet Society (2003). This
+ version of this MIB module is part of RFC 3635;
+ see the RFC itself for full legal notices."
+
+ REVISION "200309190000Z" -- September 19, 2003
+ DESCRIPTION "Updated to include support for 10 Gb/sec
+ interfaces. This resulted in the following
+ revisions:
+
+ - Updated dot3StatsAlignmentErrors and
+ dot3StatsSymbolErrors DESCRIPTIONs to
+ reflect behaviour at 10 Gb/s
+ - Added dot3StatsRateControlAbility and
+ dot3RateControlStatus for management
+ of the Rate Control function in 10 Gb/s
+ WAN applications
+ - Added 64-bit versions of all counters
+ that are used on high-speed ethernet
+ interfaces
+ - Added object groups to contain the new
+ objects
+ - Deprecated etherStatsBaseGroup and
+ split into etherStatsBaseGroup2 and
+ etherStatsHalfDuplexGroup, so that
+ interfaces which can only operate at
+ full-duplex do not need to implement
+ half-duplex-only statistics
+ - Deprecated dot3Compliance and replaced
+ it with dot3Compliance2, which includes
+ the compliance information for the new
+ object groups
+
+
+
+
+Flick Standards Track [Page 18]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ In addition, the dot3Tests and dot3Errors
+ object identities have been deprecated,
+ since there is no longer a standard method
+ for using them.
+
+ This version published as RFC 3635."
+
+ REVISION "199908240400Z" -- August 24, 1999
+ DESCRIPTION "Updated to include support for 1000 Mb/sec
+ interfaces and full-duplex interfaces.
+ This version published as RFC 2665."
+
+ REVISION "199806032150Z" -- June 3, 1998
+ DESCRIPTION "Updated to include support for 100 Mb/sec
+ interfaces.
+ This version published as RFC 2358."
+
+ REVISION "199402030400Z" -- February 3, 1994
+ DESCRIPTION "Initial 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
+ STATUS current
+ DESCRIPTION "Statistics for a collection of ethernet-like
+ interfaces attached to a particular system.
+ There will be one row in this table for each
+ ethernet-like interface in the 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 {
+
+
+
+Flick Standards Track [Page 19]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ 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,
+ dot3StatsDuplexStatus INTEGER,
+ dot3StatsRateControlAbility TruthValue,
+ dot3StatsRateControlStatus INTEGER
+ }
+
+ dot3StatsIndex OBJECT-TYPE
+ SYNTAX InterfaceIndex
+ MAX-ACCESS read-only -- read-only since originally an
+ -- SMIv1 index
+ 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."
+ REFERENCE "RFC 2863, ifIndex"
+ ::= { dot3StatsEntry 1 }
+
+ dot3StatsAlignmentErrors OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ 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 pertain are,
+ according to the conventions of IEEE 802.3
+ Layer Management, counted exclusively according
+
+
+
+Flick Standards Track [Page 20]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ to the error status presented to the LLC.
+
+ This counter does not increment for group
+ encoding schemes greater than 4 bits per group.
+
+ For interfaces operating at 10 Gb/s, this
+ counter can roll over in less than 5 minutes if
+ it is incrementing at its maximum rate. Since
+ that amount of time could be less than a
+ management station's poll cycle time, in order
+ to avoid a loss of information, a management
+ station is advised to poll the
+ dot3HCStatsAlignmentErrors object for 10 Gb/s
+ or faster interfaces.
+
+ Discontinuities in the value of this counter can
+ occur at re-initialization of the management
+ system, and at other times as indicated by the
+ value of ifCounterDiscontinuityTime."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.7,
+ aAlignmentErrors"
+ ::= { 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. This
+ count does not include frames received with
+ frame-too-long or frame-too-short error.
+
+ 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 pertain are,
+ according to the conventions of IEEE 802.3
+ Layer Management, counted exclusively according
+ to the error status presented to the LLC.
+
+ Note: Coding errors detected by the physical
+ layer for speeds above 10 Mb/s will cause the
+ frame to fail the FCS check.
+
+ For interfaces operating at 10 Gb/s, this
+ counter can roll over in less than 5 minutes if
+
+
+
+Flick Standards Track [Page 21]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ it is incrementing at its maximum rate. Since
+ that amount of time could be less than a
+ management station's poll cycle time, in order
+ to avoid a loss of information, a management
+ station is advised to poll the
+ dot3HCStatsFCSErrors object for 10 Gb/s or
+ faster interfaces.
+
+ Discontinuities in the value of this counter can
+ occur at re-initialization of the management
+ system, and at other times as indicated by the
+ value of ifCounterDiscontinuityTime."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.6,
+ aFrameCheckSequenceErrors."
+ ::= { dot3StatsEntry 3 }
+
+ dot3StatsSingleCollisionFrames OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "A count of frames that are involved in a single
+ collision, and are subsequently transmitted
+ successfully.
+
+ 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
+ object.
+
+ This counter does not increment when the
+ interface is operating in full-duplex mode.
+
+ Discontinuities in the value of this counter can
+ occur at re-initialization of the management
+ system, and at other times as indicated by the
+ value of ifCounterDiscontinuityTime."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.3,
+ aSingleCollisionFrames."
+ ::= { dot3StatsEntry 4 }
+
+ dot3StatsMultipleCollisionFrames OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "A count of frames that are involved in more
+
+
+
+Flick Standards Track [Page 22]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ than one collision and are subsequently
+ transmitted successfully.
+
+ 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.
+
+ This counter does not increment when the
+ interface is operating in full-duplex mode.
+
+ Discontinuities in the value of this counter can
+ occur at re-initialization of the management
+ system, and at other times as indicated by the
+ value of ifCounterDiscontinuityTime."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.4,
+ aMultipleCollisionFrames."
+ ::= { dot3StatsEntry 5 }
+
+ dot3StatsSQETestErrors OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "A count of times that the SQE TEST ERROR
+ is received on a particular interface. The
+ SQE TEST ERROR is set in accordance with the
+ rules for verification of the SQE detection
+ mechanism in the PLS Carrier Sense Function as
+ described in IEEE Std. 802.3, 2000 Edition,
+ section 7.2.4.6.
+
+ This counter does not increment on interfaces
+ operating at speeds greater than 10 Mb/s, or on
+ interfaces operating in full-duplex mode.
+
+ Discontinuities in the value of this counter can
+ occur at re-initialization of the management
+ system, and at other times as indicated by the
+ value of ifCounterDiscontinuityTime."
+ REFERENCE "[IEEE 802.3 Std.], 7.2.4.6, also 30.3.2.1.4,
+ aSQETestErrors."
+ ::= { dot3StatsEntry 6 }
+
+ dot3StatsDeferredTransmissions OBJECT-TYPE
+ SYNTAX Counter32
+
+
+
+Flick Standards Track [Page 23]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ 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.
+
+ The count represented by an instance of this
+ object does not include frames involved in
+ collisions.
+
+ This counter does not increment when the
+ interface is operating in full-duplex mode.
+
+ Discontinuities in the value of this counter can
+ occur at re-initialization of the management
+ system, and at other times as indicated by the
+ value of ifCounterDiscontinuityTime."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.9,
+ aFramesWithDeferredXmissions."
+ ::= { 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
+ one slotTime into the transmission of a packet.
+
+ 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.
+
+ This counter does not increment when the
+ interface is operating in full-duplex mode.
+
+ Discontinuities in the value of this counter can
+ occur at re-initialization of the management
+ system, and at other times as indicated by the
+ value of ifCounterDiscontinuityTime."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.10,
+ aLateCollisions."
+ ::= { dot3StatsEntry 8 }
+
+ dot3StatsExcessiveCollisions OBJECT-TYPE
+ SYNTAX Counter32
+
+
+
+Flick Standards Track [Page 24]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "A count of frames for which transmission on a
+ particular interface fails due to excessive
+ collisions.
+
+ This counter does not increment when the
+ interface is operating in full-duplex mode.
+
+ Discontinuities in the value of this counter can
+ occur at re-initialization of the management
+ system, and at other times as indicated by the
+ value of ifCounterDiscontinuityTime."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.11,
+ aFramesAbortedDueToXSColls."
+ ::= { 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.
+
+ 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.
+
+ For interfaces operating at 10 Gb/s, this
+ counter can roll over in less than 5 minutes if
+ it is incrementing at its maximum rate. Since
+ that amount of time could be less than a
+ management station's poll cycle time, in order
+ to avoid a loss of information, a management
+ station is advised to poll the
+ dot3HCStatsInternalMacTransmitErrors object for
+ 10 Gb/s or faster interfaces.
+
+ Discontinuities in the value of this counter can
+
+
+
+Flick Standards Track [Page 25]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ occur at re-initialization of the management
+ system, and at other times as indicated by the
+ value of ifCounterDiscontinuityTime."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.12,
+ aFramesLostDueToIntMACXmitError."
+ ::= { 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.
+
+ This counter does not increment when the
+ interface is operating in full-duplex mode.
+
+ Discontinuities in the value of this counter can
+ occur at re-initialization of the management
+ system, and at other times as indicated by the
+ value of ifCounterDiscontinuityTime."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.13,
+ aCarrierSenseErrors."
+ ::= { 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 pertain are,
+
+
+
+Flick Standards Track [Page 26]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ according to the conventions of IEEE 802.3
+ Layer Management, counted exclusively according
+ to the error status presented to the LLC.
+
+ For interfaces operating at 10 Gb/s, this
+ counter can roll over in less than 80 minutes if
+ it is incrementing at its maximum rate. Since
+ that amount of time could be less than a
+ management station's poll cycle time, in order
+ to avoid a loss of information, a management
+ station is advised to poll the
+ dot3HCStatsFrameTooLongs object for 10 Gb/s
+ or faster interfaces.
+
+ Discontinuities in the value of this counter can
+ occur at re-initialization of the management
+ system, and at other times as indicated by the
+ value of ifCounterDiscontinuityTime."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.25,
+ aFrameTooLongErrors."
+ ::= { dot3StatsEntry 13 }
+
+ -- { dot3StatsEntry 14 } is not assigned
+
+ -- { 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.
+
+ For interfaces operating at 10 Gb/s, this
+ counter can roll over in less than 5 minutes if
+
+
+
+Flick Standards Track [Page 27]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ it is incrementing at its maximum rate. Since
+ that amount of time could be less than a
+ management station's poll cycle time, in order
+ to avoid a loss of information, a management
+ station is advised to poll the
+ dot3HCStatsInternalMacReceiveErrors object for
+ 10 Gb/s or faster interfaces.
+
+ Discontinuities in the value of this counter can
+ occur at re-initialization of the management
+ system, and at other times as indicated by the
+ value of ifCounterDiscontinuityTime."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.15,
+ aFramesLostDueToIntMACRcvError."
+ ::= { dot3StatsEntry 16 }
+
+ dot3StatsEtherChipSet OBJECT-TYPE
+ SYNTAX OBJECT IDENTIFIER
+ MAX-ACCESS read-only
+ STATUS deprecated
+ DESCRIPTION "******** THIS OBJECT IS DEPRECATED ********
+
+ 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.
+
+ This object has been deprecated. Implementation
+ feedback indicates that it is of limited use for
+ debugging network problems in the field, and
+ the administrative overhead involved in
+ maintaining a registry of chipset OIDs is not
+ justified."
+
+
+
+Flick Standards Track [Page 28]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ ::= { dot3StatsEntry 17 }
+
+ dot3StatsSymbolErrors OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "For an interface operating at 100 Mb/s, the
+ number of times there was an invalid data symbol
+ when a valid carrier was present.
+
+ For an interface operating in half-duplex mode
+ at 1000 Mb/s, the number of times the receiving
+ media is non-idle (a carrier event) for a period
+ of time equal to or greater than slotTime, and
+ during which there was at least one occurrence
+ of an event that causes the PHY to indicate
+ 'Data reception error' or 'carrier extend error'
+ on the GMII.
+
+ For an interface operating in full-duplex mode
+ at 1000 Mb/s, the number of times the receiving
+ media is non-idle (a carrier event) for a period
+ of time equal to or greater than minFrameSize,
+ and during which there was at least one
+ occurrence of an event that causes the PHY to
+ indicate 'Data reception error' on the GMII.
+
+ For an interface operating at 10 Gb/s, the
+ number of times the receiving media is non-idle
+ (a carrier event) for a period of time equal to
+ or greater than minFrameSize, and during which
+ there was at least one occurrence of an event
+ that causes the PHY to indicate 'Receive Error'
+ on the XGMII.
+
+ 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. This count does
+ not increment if a collision is present.
+
+ This counter does not increment when the
+ interface is operating at 10 Mb/s.
+
+ For interfaces operating at 10 Gb/s, this
+ counter can roll over in less than 5 minutes if
+ it is incrementing at its maximum rate. Since
+ that amount of time could be less than a
+
+
+
+Flick Standards Track [Page 29]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ management station's poll cycle time, in order
+ to avoid a loss of information, a management
+ station is advised to poll the
+ dot3HCStatsSymbolErrors object for 10 Gb/s
+ or faster interfaces.
+
+ Discontinuities in the value of this counter can
+ occur at re-initialization of the management
+ system, and at other times as indicated by the
+ value of ifCounterDiscontinuityTime."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.2.1.5,
+ aSymbolErrorDuringCarrier."
+ ::= { dot3StatsEntry 18 }
+
+ dot3StatsDuplexStatus OBJECT-TYPE
+ SYNTAX INTEGER {
+ unknown(1),
+ halfDuplex(2),
+ fullDuplex(3)
+ }
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "The current mode of operation of the MAC
+ entity. 'unknown' indicates that the current
+ duplex mode could not be determined.
+
+ Management control of the duplex mode is
+ accomplished through the MAU MIB. When
+ an interface does not support autonegotiation,
+ or when autonegotiation is not enabled, the
+ duplex mode is controlled using
+ ifMauDefaultType. When autonegotiation is
+ supported and enabled, duplex mode is controlled
+ using ifMauAutoNegAdvertisedBits. In either
+ case, the currently operating duplex mode is
+ reflected both in this object and in ifMauType.
+
+ Note that this object provides redundant
+ information with ifMauType. Normally, redundant
+ objects are discouraged. However, in this
+ instance, it allows a management application to
+ determine the duplex status of an interface
+ without having to know every possible value of
+ ifMauType. This was felt to be sufficiently
+ valuable to justify the redundancy."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.32,
+ aDuplexStatus."
+ ::= { dot3StatsEntry 19 }
+
+
+
+Flick Standards Track [Page 30]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ dot3StatsRateControlAbility OBJECT-TYPE
+ SYNTAX TruthValue
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "'true' for interfaces operating at speeds above
+ 1000 Mb/s that support Rate Control through
+ lowering the average data rate of the MAC
+ sublayer, with frame granularity, and 'false'
+ otherwise."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.33,
+ aRateControlAbility."
+ ::= { dot3StatsEntry 20 }
+
+ dot3StatsRateControlStatus OBJECT-TYPE
+ SYNTAX INTEGER {
+ rateControlOff(1),
+ rateControlOn(2),
+ unknown(3)
+ }
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "The current Rate Control mode of operation of
+ the MAC sublayer of this interface."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.34,
+ aRateControlStatus."
+ ::= { dot3StatsEntry 21 }
+
+ -- 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."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.30,
+ aCollisionFrames."
+ ::= { 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
+
+
+
+Flick Standards Track [Page 31]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ 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 Integer32,
+ dot3CollFrequencies Counter32
+ }
+
+ -- { dot3CollEntry 1 } is no longer in use
+
+ dot3CollCount OBJECT-TYPE
+ SYNTAX Integer32 (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.
+
+ This counter does not increment when the
+ interface is operating in full-duplex mode.
+
+ Discontinuities in the value of this counter can
+
+
+
+Flick Standards Track [Page 32]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ occur at re-initialization of the management
+ system, and at other times as indicated by the
+ value of ifCounterDiscontinuityTime."
+ ::= { dot3CollEntry 3 }
+
+ dot3ControlTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF Dot3ControlEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION "A table of descriptive and status information
+ about the MAC Control sublayer on the
+ ethernet-like interfaces attached to a
+ particular system. There will be one row in
+ this table for each ethernet-like interface in
+ the system which implements the MAC Control
+ sublayer. If some, but not all, of the
+ ethernet-like interfaces in the system implement
+ the MAC Control sublayer, there will be fewer
+ rows in this table than in the dot3StatsTable."
+ ::= { dot3 9 }
+
+ dot3ControlEntry OBJECT-TYPE
+ SYNTAX Dot3ControlEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION "An entry in the table, containing information
+ about the MAC Control sublayer on a single
+ ethernet-like interface."
+ INDEX { dot3StatsIndex }
+ ::= { dot3ControlTable 1 }
+
+ Dot3ControlEntry ::=
+ SEQUENCE {
+ dot3ControlFunctionsSupported BITS,
+ dot3ControlInUnknownOpcodes Counter32,
+ dot3HCControlInUnknownOpcodes Counter64
+ }
+
+ dot3ControlFunctionsSupported OBJECT-TYPE
+ SYNTAX BITS {
+ pause(0) -- 802.3 flow control
+ }
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "A list of the possible MAC Control functions
+ implemented for this interface."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.3.2,
+ aMACControlFunctionsSupported."
+
+
+
+Flick Standards Track [Page 33]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ ::= { dot3ControlEntry 1 }
+
+ dot3ControlInUnknownOpcodes OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "A count of MAC Control frames received on this
+ interface that contain an opcode that is not
+ supported by this device.
+
+ For interfaces operating at 10 Gb/s, this
+ counter can roll over in less than 5 minutes if
+ it is incrementing at its maximum rate. Since
+ that amount of time could be less than a
+ management station's poll cycle time, in order
+ to avoid a loss of information, a management
+ station is advised to poll the
+ dot3HCControlInUnknownOpcodes object for 10 Gb/s
+ or faster interfaces.
+
+ Discontinuities in the value of this counter can
+ occur at re-initialization of the management
+ system, and at other times as indicated by the
+ value of ifCounterDiscontinuityTime."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.3.5,
+ aUnsupportedOpcodesReceived"
+ ::= { dot3ControlEntry 2 }
+
+ dot3HCControlInUnknownOpcodes OBJECT-TYPE
+ SYNTAX Counter64
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "A count of MAC Control frames received on this
+ interface that contain an opcode that is not
+ supported by this device.
+
+ This counter is a 64 bit version of
+ dot3ControlInUnknownOpcodes. It should be used
+ on interfaces operating at 10 Gb/s or faster.
+
+ Discontinuities in the value of this counter can
+ occur at re-initialization of the management
+ system, and at other times as indicated by the
+ value of ifCounterDiscontinuityTime."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.3.5,
+ aUnsupportedOpcodesReceived"
+ ::= { dot3ControlEntry 3 }
+
+
+
+
+Flick Standards Track [Page 34]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ dot3PauseTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF Dot3PauseEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION "A table of descriptive and status information
+ about the MAC Control PAUSE function on the
+ ethernet-like interfaces attached to a
+ particular system. There will be one row in
+ this table for each ethernet-like interface in
+ the system which supports the MAC Control PAUSE
+ function (i.e., the 'pause' bit in the
+ corresponding instance of
+ dot3ControlFunctionsSupported is set). If some,
+ but not all, of the ethernet-like interfaces in
+ the system implement the MAC Control PAUSE
+ function (for example, if some interfaces only
+ support half-duplex), there will be fewer rows
+ in this table than in the dot3StatsTable."
+ ::= { dot3 10 }
+
+ dot3PauseEntry OBJECT-TYPE
+ SYNTAX Dot3PauseEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION "An entry in the table, containing information
+ about the MAC Control PAUSE function on a single
+ ethernet-like interface."
+ INDEX { dot3StatsIndex }
+ ::= { dot3PauseTable 1 }
+
+ Dot3PauseEntry ::=
+
+ SEQUENCE {
+ dot3PauseAdminMode INTEGER,
+ dot3PauseOperMode INTEGER,
+ dot3InPauseFrames Counter32,
+ dot3OutPauseFrames Counter32,
+ dot3HCInPauseFrames Counter64,
+ dot3HCOutPauseFrames Counter64
+ }
+
+ dot3PauseAdminMode OBJECT-TYPE
+ SYNTAX INTEGER {
+ disabled(1),
+ enabledXmit(2),
+ enabledRcv(3),
+ enabledXmitAndRcv(4)
+ }
+
+
+
+Flick Standards Track [Page 35]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION "This object is used to configure the default
+ administrative PAUSE mode for this interface.
+
+ This object represents the
+ administratively-configured PAUSE mode for this
+ interface. If auto-negotiation is not enabled
+ or is not implemented for the active MAU
+ attached to this interface, the value of this
+ object determines the operational PAUSE mode
+ of the interface whenever it is operating in
+ full-duplex mode. In this case, a set to this
+ object will force the interface into the
+ specified mode.
+
+ If auto-negotiation is implemented and enabled
+ for the MAU attached to this interface, the
+ PAUSE mode for this interface is determined by
+ auto-negotiation, and the value of this object
+ denotes the mode to which the interface will
+ automatically revert if/when auto-negotiation is
+ later disabled. Note that when auto-negotiation
+ is running, administrative control of the PAUSE
+ mode may be accomplished using the
+ ifMauAutoNegCapAdvertisedBits object in the
+ MAU-MIB.
+
+ Note that the value of this object is ignored
+ when the interface is not operating in
+ full-duplex mode.
+
+ An attempt to set this object to
+ 'enabledXmit(2)' or 'enabledRcv(3)' will fail
+ on interfaces that do not support operation
+ at greater than 100 Mb/s."
+ ::= { dot3PauseEntry 1 }
+
+ dot3PauseOperMode OBJECT-TYPE
+ SYNTAX INTEGER {
+ disabled(1),
+ enabledXmit(2),
+ enabledRcv(3),
+ enabledXmitAndRcv(4)
+ }
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "This object reflects the PAUSE mode currently
+
+
+
+Flick Standards Track [Page 36]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ in use on this interface, as determined by
+ either (1) the result of the auto-negotiation
+ function or (2) if auto-negotiation is not
+ enabled or is not implemented for the active MAU
+ attached to this interface, by the value of
+ dot3PauseAdminMode. Interfaces operating at
+ 100 Mb/s or less will never return
+ 'enabledXmit(2)' or 'enabledRcv(3)'. Interfaces
+ operating in half-duplex mode will always return
+ 'disabled(1)'. Interfaces on which
+ auto-negotiation is enabled but not yet
+ completed should return the value
+ 'disabled(1)'."
+ ::= { dot3PauseEntry 2 }
+
+ dot3InPauseFrames OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "A count of MAC Control frames received on this
+ interface with an opcode indicating the PAUSE
+ operation.
+
+ This counter does not increment when the
+ interface is operating in half-duplex mode.
+
+ For interfaces operating at 10 Gb/s, this
+ counter can roll over in less than 5 minutes if
+ it is incrementing at its maximum rate. Since
+ that amount of time could be less than a
+ management station's poll cycle time, in order
+ to avoid a loss of information, a management
+ station is advised to poll the
+ dot3HCInPauseFrames object for 10 Gb/s or
+ faster interfaces.
+
+ Discontinuities in the value of this counter can
+ occur at re-initialization of the management
+ system, and at other times as indicated by the
+ value of ifCounterDiscontinuityTime."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.4.3,
+ aPAUSEMACCtrlFramesReceived."
+ ::= { dot3PauseEntry 3 }
+
+ dot3OutPauseFrames OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+
+
+
+Flick Standards Track [Page 37]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ DESCRIPTION "A count of MAC Control frames transmitted on
+ this interface with an opcode indicating the
+ PAUSE operation.
+
+ This counter does not increment when the
+ interface is operating in half-duplex mode.
+
+ For interfaces operating at 10 Gb/s, this
+ counter can roll over in less than 5 minutes if
+ it is incrementing at its maximum rate. Since
+ that amount of time could be less than a
+ management station's poll cycle time, in order
+ to avoid a loss of information, a management
+ station is advised to poll the
+ dot3HCOutPauseFrames object for 10 Gb/s or
+ faster interfaces.
+
+ Discontinuities in the value of this counter can
+ occur at re-initialization of the management
+ system, and at other times as indicated by the
+ value of ifCounterDiscontinuityTime."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.4.2,
+ aPAUSEMACCtrlFramesTransmitted."
+ ::= { dot3PauseEntry 4 }
+
+ dot3HCInPauseFrames OBJECT-TYPE
+ SYNTAX Counter64
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "A count of MAC Control frames received on this
+ interface with an opcode indicating the PAUSE
+ operation.
+
+ This counter does not increment when the
+ interface is operating in half-duplex mode.
+
+ This counter is a 64 bit version of
+ dot3InPauseFrames. It should be used on
+ interfaces operating at 10 Gb/s or faster.
+
+ Discontinuities in the value of this counter can
+ occur at re-initialization of the management
+ system, and at other times as indicated by the
+ value of ifCounterDiscontinuityTime."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.4.3,
+ aPAUSEMACCtrlFramesReceived."
+ ::= { dot3PauseEntry 5 }
+
+
+
+
+Flick Standards Track [Page 38]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ dot3HCOutPauseFrames OBJECT-TYPE
+ SYNTAX Counter64
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "A count of MAC Control frames transmitted on
+ this interface with an opcode indicating the
+ PAUSE operation.
+
+ This counter does not increment when the
+ interface is operating in half-duplex mode.
+
+ This counter is a 64 bit version of
+ dot3OutPauseFrames. It should be used on
+ interfaces operating at 10 Gb/s or faster.
+
+ Discontinuities in the value of this counter can
+ occur at re-initialization of the management
+ system, and at other times as indicated by the
+ value of ifCounterDiscontinuityTime."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.4.2,
+ aPAUSEMACCtrlFramesTransmitted."
+ ::= { dot3PauseEntry 6 }
+
+ dot3HCStatsTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF Dot3HCStatsEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION "A table containing 64-bit versions of error
+ counters from the dot3StatsTable. The 32-bit
+ versions of these counters may roll over quite
+ quickly on higher speed ethernet interfaces.
+ The counters that have 64-bit versions in this
+ table are the counters that apply to full-duplex
+ interfaces, since 10 Gb/s and faster
+ ethernet-like interfaces do not support
+ half-duplex, and very few 1000 Mb/s
+ ethernet-like interfaces support half-duplex.
+
+ Entries in this table are recommended for
+ interfaces capable of operating at 1000 Mb/s or
+ faster, and are required for interfaces capable
+ of operating at 10 Gb/s or faster. Lower speed
+ ethernet-like interfaces do not need entries in
+ this table, in which case there may be fewer
+ entries in this table than in the
+ dot3StatsTable. However, implementations
+ containing interfaces with a mix of speeds may
+ choose to implement entries in this table for
+
+
+
+Flick Standards Track [Page 39]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ all ethernet-like interfaces."
+ ::= { dot3 11 }
+
+ dot3HCStatsEntry OBJECT-TYPE
+ SYNTAX Dot3HCStatsEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION "An entry containing 64-bit statistics for a
+ single ethernet-like interface."
+ INDEX { dot3StatsIndex }
+ ::= { dot3HCStatsTable 1 }
+
+ Dot3HCStatsEntry ::=
+ SEQUENCE {
+ dot3HCStatsAlignmentErrors Counter64,
+ dot3HCStatsFCSErrors Counter64,
+ dot3HCStatsInternalMacTransmitErrors Counter64,
+ dot3HCStatsFrameTooLongs Counter64,
+ dot3HCStatsInternalMacReceiveErrors Counter64,
+ dot3HCStatsSymbolErrors Counter64
+ }
+
+ dot3HCStatsAlignmentErrors OBJECT-TYPE
+ SYNTAX Counter64
+ MAX-ACCESS read-only
+ STATUS current
+ 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 pertain are,
+ according to the conventions of IEEE 802.3
+ Layer Management, counted exclusively according
+ to the error status presented to the LLC.
+
+ This counter does not increment for group
+ encoding schemes greater than 4 bits per group.
+
+ This counter is a 64 bit version of
+ dot3StatsAlignmentErrors. It should be used
+ on interfaces operating at 10 Gb/s or faster.
+
+ Discontinuities in the value of this counter can
+ occur at re-initialization of the management
+
+
+
+Flick Standards Track [Page 40]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ system, and at other times as indicated by the
+ value of ifCounterDiscontinuityTime."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.7,
+ aAlignmentErrors"
+ ::= { dot3HCStatsEntry 1 }
+
+ dot3HCStatsFCSErrors OBJECT-TYPE
+ SYNTAX Counter64
+ 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. This
+ count does not include frames received with
+ frame-too-long or frame-too-short error.
+
+ 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 pertain are,
+ according to the conventions of IEEE 802.3
+ Layer Management, counted exclusively according
+ to the error status presented to the LLC.
+
+ Note: Coding errors detected by the physical
+ layer for speeds above 10 Mb/s will cause the
+ frame to fail the FCS check.
+
+ This counter is a 64 bit version of
+ dot3StatsFCSErrors. It should be used on
+ interfaces operating at 10 Gb/s or faster.
+
+ Discontinuities in the value of this counter can
+ occur at re-initialization of the management
+ system, and at other times as indicated by the
+ value of ifCounterDiscontinuityTime."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.6,
+ aFrameCheckSequenceErrors."
+ ::= { dot3HCStatsEntry 2 }
+
+ dot3HCStatsInternalMacTransmitErrors OBJECT-TYPE
+ SYNTAX Counter64
+ 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
+
+
+
+Flick Standards Track [Page 41]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ 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.
+
+ 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.
+
+ This counter is a 64 bit version of
+ dot3StatsInternalMacTransmitErrors. It should
+ be used on interfaces operating at 10 Gb/s or
+ faster.
+
+ Discontinuities in the value of this counter can
+ occur at re-initialization of the management
+ system, and at other times as indicated by the
+ value of ifCounterDiscontinuityTime."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.12,
+ aFramesLostDueToIntMACXmitError."
+ ::= { dot3HCStatsEntry 3 }
+
+ dot3HCStatsFrameTooLongs OBJECT-TYPE
+ SYNTAX Counter64
+ 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 pertain are,
+ according to the conventions of IEEE 802.3
+ Layer Management, counted exclusively according
+ to the error status presented to the LLC.
+
+ This counter is a 64 bit version of
+ dot3StatsFrameTooLongs. It should be used on
+ interfaces operating at 10 Gb/s or faster.
+
+ Discontinuities in the value of this counter can
+
+
+
+Flick Standards Track [Page 42]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ occur at re-initialization of the management
+ system, and at other times as indicated by the
+ value of ifCounterDiscontinuityTime."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.25,
+ aFrameTooLongErrors."
+ ::= { dot3HCStatsEntry 4 }
+
+ dot3HCStatsInternalMacReceiveErrors OBJECT-TYPE
+ SYNTAX Counter64
+ 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.
+
+ This counter is a 64 bit version of
+ dot3StatsInternalMacReceiveErrors. It should be
+ used on interfaces operating at 10 Gb/s or
+ faster.
+
+ Discontinuities in the value of this counter can
+ occur at re-initialization of the management
+ system, and at other times as indicated by the
+ value of ifCounterDiscontinuityTime."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.15,
+ aFramesLostDueToIntMACRcvError."
+ ::= { dot3HCStatsEntry 5 }
+
+ dot3HCStatsSymbolErrors OBJECT-TYPE
+ SYNTAX Counter64
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "For an interface operating at 100 Mb/s, the
+ number of times there was an invalid data symbol
+ when a valid carrier was present.
+
+
+
+
+Flick Standards Track [Page 43]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ For an interface operating in half-duplex mode
+ at 1000 Mb/s, the number of times the receiving
+ media is non-idle (a carrier event) for a period
+ of time equal to or greater than slotTime, and
+ during which there was at least one occurrence
+ of an event that causes the PHY to indicate
+ 'Data reception error' or 'carrier extend error'
+ on the GMII.
+
+ For an interface operating in full-duplex mode
+ at 1000 Mb/s, the number of times the receiving
+ media is non-idle (a carrier event) for a period
+ of time equal to or greater than minFrameSize,
+ and during which there was at least one
+ occurrence of an event that causes the PHY to
+ indicate 'Data reception error' on the GMII.
+
+ For an interface operating at 10 Gb/s, the
+ number of times the receiving media is non-idle
+ (a carrier event) for a period of time equal to
+ or greater than minFrameSize, and during which
+ there was at least one occurrence of an event
+ that causes the PHY to indicate 'Receive Error'
+ on the XGMII.
+
+ 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. This count does
+ not increment if a collision is present.
+
+ This counter is a 64 bit version of
+ dot3StatsSymbolErrors. It should be used on
+ interfaces operating at 10 Gb/s or faster.
+
+ Discontinuities in the value of this counter can
+ occur at re-initialization of the management
+ system, and at other times as indicated by the
+ value of ifCounterDiscontinuityTime."
+ REFERENCE "[IEEE 802.3 Std.], 30.3.2.1.5,
+ aSymbolErrorDuringCarrier."
+ ::= { dot3HCStatsEntry 6 }
+
+
+ -- 802.3 Tests
+
+ dot3Tests OBJECT IDENTIFIER ::= { dot3 6 }
+
+
+
+
+Flick Standards Track [Page 44]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ dot3Errors OBJECT IDENTIFIER ::= { dot3 7 }
+
+ -- TDR Test
+
+ dot3TestTdr OBJECT-IDENTITY
+ STATUS deprecated
+ DESCRIPTION "******** THIS IDENTITY IS DEPRECATED *******
+
+ 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
+ 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).
+
+ This object identity has been deprecated, since
+ the ifTestTable in the IF-MIB was deprecated,
+ and there is no longer a standard mechanism for
+ initiating an interface test. This left no
+ standard way of using this object identity."
+ ::= { dot3Tests 1 }
+
+ -- Loopback Test
+
+ dot3TestLoopBack OBJECT-IDENTITY
+ STATUS deprecated
+ DESCRIPTION "******** THIS IDENTITY IS DEPRECATED *******
+
+ 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
+
+
+
+Flick Standards Track [Page 45]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ 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.
+
+ This object identity has been deprecated, since
+ the ifTestTable in the IF-MIB was deprecated,
+ and there is no longer a standard mechanism for
+ initiating an interface test. This left no
+ standard way of using this object identity."
+ ::= { dot3Tests 2 }
+
+ dot3ErrorInitError OBJECT-IDENTITY
+ STATUS deprecated
+ DESCRIPTION "******** THIS IDENTITY IS DEPRECATED *******
+
+ Couldn't initialize MAC chip for test.
+
+ This object identity has been deprecated, since
+ the ifTestTable in the IF-MIB was deprecated,
+ and there is no longer a standard mechanism for
+ initiating an interface test. This left no
+ standard way of using this object identity."
+ ::= { dot3Errors 1 }
+
+ dot3ErrorLoopbackError OBJECT-IDENTITY
+ STATUS deprecated
+ DESCRIPTION "******** THIS IDENTITY IS DEPRECATED *******
+
+ Expected data not received (or not received
+ correctly) in loopback test.
+
+ This object identity has been deprecated, since
+ the ifTestTable in the IF-MIB was deprecated,
+ and there is no longer a standard mechanism for
+ initiating an interface test. This left no
+ standard way of using this object identity."
+ ::= { dot3Errors 2 }
+
+ -- { dot3 8 }, the dot3ChipSets tree, is defined in [RFC2666]
+
+ -- conformance information
+
+
+
+Flick Standards Track [Page 46]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ etherConformance OBJECT IDENTIFIER ::= { etherMIB 2 }
+
+ etherGroups OBJECT IDENTIFIER ::= { etherConformance 1 }
+ etherCompliances OBJECT IDENTIFIER ::= { etherConformance 2 }
+
+ -- compliance statements
+
+ etherCompliance MODULE-COMPLIANCE
+ STATUS deprecated
+ DESCRIPTION "******** THIS COMPLIANCE IS DEPRECATED ********
+
+ The compliance statement for managed network
+ entities which have ethernet-like network
+ interfaces.
+
+ This compliance is deprecated and replaced by
+ dot3Compliance."
+
+ 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 deprecated
+ DESCRIPTION "******** THIS COMPLIANCE IS DEPRECATED ********
+
+ The compliance statement for managed network
+ entities which have 100 Mb/sec ethernet-like
+ network interfaces.
+
+ This compliance is deprecated and replaced by
+ dot3Compliance."
+
+ 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 Standards Track [Page 47]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ dot3Compliance MODULE-COMPLIANCE
+ STATUS deprecated
+ DESCRIPTION "******** THIS COMPLIANCE IS DEPRECATED ********
+
+ The compliance statement for managed network
+ entities which have ethernet-like network
+ interfaces.
+
+ This compliance is deprecated and replaced by
+ dot3Compliance2."
+
+ MODULE -- this module
+ MANDATORY-GROUPS { etherStatsBaseGroup }
+
+ GROUP etherDuplexGroup
+ DESCRIPTION "This group is mandatory for all
+ ethernet-like network interfaces which are
+ capable of operating in full-duplex mode.
+ It is highly recommended for all
+ ethernet-like network interfaces."
+
+ GROUP etherStatsLowSpeedGroup
+ DESCRIPTION "This group is mandatory for all
+ ethernet-like network interfaces which are
+ capable of operating at 10 Mb/s or slower in
+ half-duplex mode."
+
+ GROUP etherStatsHighSpeedGroup
+ DESCRIPTION "This group is mandatory for all
+ ethernet-like network interfaces which are
+ capable of operating at 100 Mb/s or faster."
+
+ GROUP etherControlGroup
+ DESCRIPTION "This group is mandatory for all
+ ethernet-like network interfaces that
+ support the MAC Control sublayer."
+
+ GROUP etherControlPauseGroup
+ DESCRIPTION "This group is mandatory for all
+ ethernet-like network interfaces that
+ support the MAC Control PAUSE function."
+
+ GROUP etherCollisionTableGroup
+ DESCRIPTION "This group is optional. It is appropriate
+ for all ethernet-like network interfaces
+ which are capable of operating in
+ half-duplex mode and have the necessary
+ metering. Implementation in systems with
+
+
+
+Flick Standards Track [Page 48]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ such interfaces is highly recommended."
+ ::= { etherCompliances 3 }
+
+ dot3Compliance2 MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION "The compliance statement for managed network
+ entities which have ethernet-like network
+ interfaces.
+
+ Note that compliance with this MIB module
+ requires compliance with the ifCompliance3
+ MODULE-COMPLIANCE statement of the IF-MIB
+ (RFC2863). In addition, compliance with this
+ MIB module requires compliance with the
+ mauModIfCompl3 MODULE-COMPLIANCE statement of
+ the MAU-MIB (RFC3636)."
+
+ MODULE -- this module
+ MANDATORY-GROUPS { etherStatsBaseGroup2 }
+
+ GROUP etherDuplexGroup
+ DESCRIPTION "This group is mandatory for all
+ ethernet-like network interfaces which are
+ capable of operating in full-duplex mode.
+ It is highly recommended for all
+ ethernet-like network interfaces."
+
+ GROUP etherRateControlGroup
+ DESCRIPTION "This group is mandatory for all
+ ethernet-like network interfaces which are
+ capable of operating at speeds faster than
+ 1000 Mb/s. It is highly recommended for all
+ ethernet-like network interfaces."
+
+ GROUP etherStatsLowSpeedGroup
+ DESCRIPTION "This group is mandatory for all
+ ethernet-like network interfaces which are
+ capable of operating at 10 Mb/s or slower in
+ half-duplex mode."
+
+ GROUP etherStatsHighSpeedGroup
+ DESCRIPTION "This group is mandatory for all
+ ethernet-like network interfaces which are
+ capable of operating at 100 Mb/s or faster."
+
+ GROUP etherStatsHalfDuplexGroup
+ DESCRIPTION "This group is mandatory for all
+ ethernet-like network interfaces which are
+
+
+
+Flick Standards Track [Page 49]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ capable of operating in half-duplex mode."
+
+ GROUP etherHCStatsGroup
+ DESCRIPTION "This group is mandatory for all
+ ethernet-like network interfaces which are
+ capable of operating at 10 Gb/s or faster.
+ It is recommended for all ethernet-like
+ network interfaces which are capable of
+ operating at 1000 Mb/s or faster."
+
+ GROUP etherControlGroup
+ DESCRIPTION "This group is mandatory for all
+ ethernet-like network interfaces that
+ support the MAC Control sublayer."
+
+ GROUP etherHCControlGroup
+ DESCRIPTION "This group is mandatory for all
+ ethernet-like network interfaces that
+ support the MAC Control sublayer and are
+ capable of operating at 10 Gb/s or faster."
+
+ GROUP etherControlPauseGroup
+ DESCRIPTION "This group is mandatory for all
+ ethernet-like network interfaces that
+ support the MAC Control PAUSE function."
+
+ GROUP etherHCControlPauseGroup
+ DESCRIPTION "This group is mandatory for all
+ ethernet-like network interfaces that
+ support the MAC Control PAUSE function and
+ are capable of operating at 10 Gb/s or
+ faster."
+
+ GROUP etherCollisionTableGroup
+ DESCRIPTION "This group is optional. It is appropriate
+ for all ethernet-like network interfaces
+ which are capable of operating in
+ half-duplex mode and have the necessary
+ metering. Implementation in systems with
+ such interfaces is highly recommended."
+ ::= { etherCompliances 4 }
+
+ -- units of conformance
+
+ etherStatsGroup OBJECT-GROUP
+ OBJECTS { dot3StatsIndex,
+ dot3StatsAlignmentErrors,
+ dot3StatsFCSErrors,
+
+
+
+Flick Standards Track [Page 50]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ dot3StatsSingleCollisionFrames,
+ dot3StatsMultipleCollisionFrames,
+ dot3StatsSQETestErrors,
+ dot3StatsDeferredTransmissions,
+ dot3StatsLateCollisions,
+ dot3StatsExcessiveCollisions,
+ dot3StatsInternalMacTransmitErrors,
+ dot3StatsCarrierSenseErrors,
+ dot3StatsFrameTooLongs,
+ dot3StatsInternalMacReceiveErrors,
+ dot3StatsEtherChipSet
+ }
+ STATUS deprecated
+ DESCRIPTION "********* THIS GROUP IS DEPRECATED **********
+
+ A collection of objects providing information
+ applicable to all ethernet-like network
+ interfaces.
+
+ This object group has been deprecated and
+ replaced by etherStatsBaseGroup and
+ etherStatsLowSpeedGroup."
+ ::= { 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,
+ dot3StatsEtherChipSet,
+ dot3StatsSymbolErrors
+
+
+
+Flick Standards Track [Page 51]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ }
+ STATUS deprecated
+ DESCRIPTION "********* THIS GROUP IS DEPRECATED **********
+
+ A collection of objects providing information
+ applicable to 100 Mb/sec ethernet-like network
+ interfaces.
+
+ This object group has been deprecated and
+ replaced by etherStatsBaseGroup and
+ etherStatsHighSpeedGroup."
+ ::= { etherGroups 3 }
+
+ etherStatsBaseGroup OBJECT-GROUP
+ OBJECTS { dot3StatsIndex,
+ dot3StatsAlignmentErrors,
+ dot3StatsFCSErrors,
+ dot3StatsSingleCollisionFrames,
+ dot3StatsMultipleCollisionFrames,
+ dot3StatsDeferredTransmissions,
+ dot3StatsLateCollisions,
+ dot3StatsExcessiveCollisions,
+ dot3StatsInternalMacTransmitErrors,
+ dot3StatsCarrierSenseErrors,
+ dot3StatsFrameTooLongs,
+ dot3StatsInternalMacReceiveErrors
+ }
+ STATUS deprecated
+ DESCRIPTION "********* THIS GROUP IS DEPRECATED **********
+
+ A collection of objects providing information
+ applicable to all ethernet-like network
+ interfaces.
+
+ This object group has been deprecated and
+ replaced by etherStatsBaseGroup2 and
+ etherStatsHalfDuplexGroup, to separate
+ objects which must be implemented by all
+ ethernet-like network interfaces from
+ objects that need only be implemented on
+ ethernet-like network interfaces that are
+ capable of half-duplex operation."
+ ::= { etherGroups 4 }
+
+ etherStatsLowSpeedGroup OBJECT-GROUP
+ OBJECTS { dot3StatsSQETestErrors }
+ STATUS current
+ DESCRIPTION "A collection of objects providing information
+
+
+
+Flick Standards Track [Page 52]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ applicable to ethernet-like network interfaces
+ capable of operating at 10 Mb/s or slower in
+ half-duplex mode."
+ ::= { etherGroups 5 }
+
+ etherStatsHighSpeedGroup OBJECT-GROUP
+ OBJECTS { dot3StatsSymbolErrors }
+ STATUS current
+ DESCRIPTION "A collection of objects providing information
+ applicable to ethernet-like network interfaces
+ capable of operating at 100 Mb/s or faster."
+ ::= { etherGroups 6 }
+
+ etherDuplexGroup OBJECT-GROUP
+ OBJECTS { dot3StatsDuplexStatus }
+ STATUS current
+ DESCRIPTION "A collection of objects providing information
+ about the duplex mode of an ethernet-like
+ network interface."
+ ::= { etherGroups 7 }
+
+ etherControlGroup OBJECT-GROUP
+ OBJECTS { dot3ControlFunctionsSupported,
+ dot3ControlInUnknownOpcodes
+ }
+ STATUS current
+ DESCRIPTION "A collection of objects providing information
+ about the MAC Control sublayer on ethernet-like
+ network interfaces."
+ ::= { etherGroups 8 }
+
+ etherControlPauseGroup OBJECT-GROUP
+ OBJECTS { dot3PauseAdminMode,
+ dot3PauseOperMode,
+ dot3InPauseFrames,
+ dot3OutPauseFrames
+ }
+ STATUS current
+ DESCRIPTION "A collection of objects providing information
+ about and control of the MAC Control PAUSE
+ function on ethernet-like network interfaces."
+ ::= { etherGroups 9 }
+
+ etherStatsBaseGroup2 OBJECT-GROUP
+ OBJECTS { dot3StatsIndex,
+ dot3StatsAlignmentErrors,
+ dot3StatsFCSErrors,
+ dot3StatsInternalMacTransmitErrors,
+
+
+
+Flick Standards Track [Page 53]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ dot3StatsFrameTooLongs,
+ dot3StatsInternalMacReceiveErrors
+ }
+ STATUS current
+ DESCRIPTION "A collection of objects providing information
+ applicable to all ethernet-like network
+ interfaces."
+ ::= { etherGroups 10 }
+
+ etherStatsHalfDuplexGroup OBJECT-GROUP
+ OBJECTS { dot3StatsSingleCollisionFrames,
+ dot3StatsMultipleCollisionFrames,
+ dot3StatsDeferredTransmissions,
+ dot3StatsLateCollisions,
+ dot3StatsExcessiveCollisions,
+ dot3StatsCarrierSenseErrors
+ }
+ STATUS current
+ DESCRIPTION "A collection of objects providing information
+ applicable only to half-duplex ethernet-like
+ network interfaces."
+ ::= { etherGroups 11 }
+
+ etherHCStatsGroup OBJECT-GROUP
+ OBJECTS { dot3HCStatsAlignmentErrors,
+ dot3HCStatsFCSErrors,
+ dot3HCStatsInternalMacTransmitErrors,
+ dot3HCStatsFrameTooLongs,
+ dot3HCStatsInternalMacReceiveErrors,
+ dot3HCStatsSymbolErrors
+ }
+ STATUS current
+ DESCRIPTION "A collection of objects providing high-capacity
+ statistics applicable to higher-speed
+ ethernet-like network interfaces."
+ ::= { etherGroups 12 }
+
+ etherHCControlGroup OBJECT-GROUP
+ OBJECTS { dot3HCControlInUnknownOpcodes }
+ STATUS current
+ DESCRIPTION "A collection of objects providing high-capacity
+ statistics for the MAC Control sublayer on
+ higher-speed ethernet-like network interfaces."
+ ::= { etherGroups 13 }
+
+ etherHCControlPauseGroup OBJECT-GROUP
+ OBJECTS { dot3HCInPauseFrames,
+ dot3HCOutPauseFrames
+
+
+
+Flick Standards Track [Page 54]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ }
+ STATUS current
+ DESCRIPTION "A collection of objects providing high-capacity
+ statistics for the MAC Control PAUSE function on
+ higher-speed ethernet-like network interfaces."
+ ::= { etherGroups 14 }
+
+ etherRateControlGroup OBJECT-GROUP
+ OBJECTS { dot3StatsRateControlAbility,
+ dot3StatsRateControlStatus
+ }
+ STATUS current
+ DESCRIPTION "A collection of objects providing information
+ about the Rate Control function on ethernet-like
+ interfaces."
+ ::= { etherGroups 15 }
+
+ END
+
+5. Intellectual Property Statement
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+Flick Standards Track [Page 55]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+6. Acknowledgements
+
+ This document was produced by the IETF Ethernet Interfaces and Hub
+ MIB Working Group, whose efforts were greatly advanced by the
+ contributions of the following people:
+
+ Ran Atkinson
+ Mike Ayers
+ Mike Heard
+ Jeffrey Johnson
+ Lynn Kubinec
+ Kam Lam
+ Kerry McDonald
+ Steve McRobert
+ K.C. Norseth
+ Dan Romascanu
+ Randy Presuhn
+ Andrew Smith
+ Kaj Tesink
+ Geoff Thompson
+
+ This document is based on the Proposed Standard Ethernet MIB, RFC
+ 2665 [RFC2665], edited by John Flick of Hewlett-Packard and Jeffrey
+ Johnson of RedBack Networks and produced by the Ethernet Interfaces
+ and Hub MIB Working Group. It extends that document by providing
+ support for 10 Gb/s Ethernet interfaces as defined in [IEEE802.3ae].
+
+ RFC 2665, in turn, is based on the Proposed Standard Ethernet MIB,
+ RFC 2358 [RFC2358], edited by John Flick of Hewlett-Packard and
+ Jeffrey Johnson of RedBack Networks and produced by the 802.3 Hub MIB
+ Working Group. It extends that document by providing support for
+ full-duplex Ethernet interfaces and 1000 Mb/sec Ethernet interfaces
+ as outlined in [IEEE802.3].
+
+ RFC 2358, in turn, is almost completely based on both the Standard
+ Ethernet MIB, RFC 1643 [RFC1643], and the Proposed Standard Ethernet
+ MIB using the SNMPv2 SMI, RFC 1650 [RFC1650], both of which were
+ edited by Frank Kastenholz of FTP Software and produced by the
+ Interfaces MIB Working Group. RFC 2358 extends those documents by
+ providing support for 100 Mb/sec ethernet interfaces.
+
+ RFC 1643 and RFC 1650, in turn, are based on the Draft Standard
+ Ethernet MIB, RFC 1398 [RFC1398], also edited by Frank Kastenholz and
+ produced by the Ethernet MIB Working Group.
+
+
+
+
+
+
+
+Flick Standards Track [Page 56]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ RFC 1398, in turn, is based on the Proposed Standard Ethernet MIB,
+ RFC 1284 [RFC1284], 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, documented that experience in RFC 1369
+ [RFC1369], 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 [KASTEN]. This document
+ was 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
+ RFC 1212 [RFC1212] 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. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirements Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
+ J., Rose, M. and S. Waldbusser, "Structure of
+ Management Information Version 2 (SMIv2)", STD 58, RFC
+ 2578, April 1999.
+
+ [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
+ J., Rose, M. and S. Waldbusser, "Textual Conventions
+ for SMIv2", STD 58, RFC 2579, April 1999.
+
+ [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
+ J., Rose, M. and S. Waldbusser, "Conformance Statements
+ for SMIv2", STD 58, RFC 2580, April 1999.
+
+ [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
+ MIB using SMIv2", RFC 2863, June 2000.
+
+ [IEEE802.3] IEEE, IEEE Std 802.3, 2002 Edition: "Carrier Sense
+ Multiple Access with Collision Detection (CSMA/CD)
+ Access Method and Physical Layer Specifications", March
+ 2002.
+
+
+
+
+
+Flick Standards Track [Page 57]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ [IEEE802.3ae] IEEE, IEEE Std 802.3ae-2002, "Amendment: Media Access
+ Control (MAC) Parameters, Physical Layers, and
+ Management Parameters for 10 Gb/s Operation", August,
+ 2002.
+
+ [RFC3636] Flick, J., "Definitions of Managed Objects for IEEE
+ 802.3 Medium Attachment Units (MAUs) using SMIv2", RFC
+ 3636, September 2003.
+
+8. Informative References
+
+ [RFC1212] Rose, M. and K. McCloghrie, Editors, "Concise MIB
+ Definitions", STD 16, RFC 1212, March 1991.
+
+ [RFC1213] 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.
+
+ [RFC1284] Cook, J., "Definitions of Managed Objects for
+ Ethernet-Like Interface Types", RFC 1284, December
+ 1991.
+
+ [RFC1369] Kastenholz, F., "Implementation Notes and Experience
+ for The Internet Ethernet MIB", RFC 1369, October 1992.
+
+ [RFC1398] Kastenholz, F., "Definitions of Managed Objects for the
+ Ethernet-like Interface Types", RFC 1398, January 1993.
+
+ [RFC1643] Kastenholz, F., "Definitions of Managed Objects for the
+ Ethernet-like Interface Types", STD 50, RFC 1643, July
+ 1994.
+
+ [RFC1650] Kastenholz, F., "Definitions of Managed Objects for the
+ Ethernet-like Interface Types using SMIv2", RFC 1650,
+ August 1994.
+
+ [RFC2358] Flick, J. and J. Johnson, "Definitions of Managed
+ Objects for the Ethernet-like Interface Types", RFC
+ 2358, June 1998.
+
+ [RFC2665] Flick, J. and J. Johnson, "Definitions of Managed
+ Objects for the Ethernet-like Interface Types", RFC
+ 2665, August 1999.
+
+ [RFC2666] Flick, J., "Definitions of Object Identifiers for
+ Identifying Ethernet Chip Sets", RFC 2666, August 1999.
+
+
+
+
+
+Flick Standards Track [Page 58]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
+ "Introduction and Applicability Statements for
+ Internet-Standard Network Management Framework", RFC
+ 3410, December 2002.
+
+ [CASE] Case, J., and C. Partridge, "Case Diagrams: A First
+ Step to Diagrammed Management Information Bases",
+ Computer Communications Review, 19(1):13-16, January
+ 1989.
+
+ [RFC3637] Heard, C., "Definitions of Managed Objects for the
+ Ethernet WAN Interface Sublayer", RFC 3637, September
+ 2003.
+
+ [KASTEN] 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.
+
+9. Security Considerations
+
+ There is one management object defined in this MIB that has a MAX-
+ ACCESS clause of read-write. That object, dot3PauseAdminMode, may be
+ used to change the flow control configuration on a network interface,
+ which may result in dropped packets, or sending flow control packets
+ on links where the link partner will not understand them. Either
+ action could be detrimental to network performance.
+
+ Such objects may be considered sensitive or vulnerable in some
+ network environments. The support for SET operations in a non-secure
+ environment without proper protection can have a negative effect on
+ network operations.
+
+ Some of the readable objects in this MIB module (i.e., objects with a
+ MAX-ACCESS other than not-accessible) may be considered sensitive or
+ vulnerable in some network environments. 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. Note that
+ this object has been deprecated. However, some implementors may
+ still choose to implement it for backwards compatability.
+
+ Most of the objects in this MIB module contain statistical
+ information about particular network links. In some network
+ environments, this information may be considered sensitive.
+
+
+
+
+
+
+
+Flick Standards Track [Page 59]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ It is thus important to control even GET and/or NOTIFY access to
+ these objects and possibly to even encrypt the values of these
+ objects when sending them over the network via SNMP.
+
+ SNMP versions prior to SNMPv3 did not include adequate security.
+ 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/SET (read/change/create/delete) the objects
+ in this MIB module.
+
+ It is recommended that the implementors consider the security
+ features as provided by the SNMPv3 framework (see [RFC3410], section
+ 8), including full support for the SNMPv3 cryptographic mechanisms
+ (for authentication and privacy).
+
+ Furthermore, deployment of SNMP versions prior to SNMPv3 is NOT
+ RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
+ enable cryptographic security. It is then a customer/operator
+ responsibility to ensure that the SNMP entity giving access to an
+ instance of this MIB module is properly configured to give access to
+ the objects only to those principals (users) that have legitimate
+ rights to indeed GET or SET (change/create/delete) them.
+
+10. IANA Considerations
+
+ This document does not define any new name space to be administered
+ by IANA. However, section 3.2.4 does specify that some of the
+ defined values in a current IANA-maintained name space are to be
+ marked as deprecated or obsolete. In particular, the following
+ enumerated values in the IANAifType TEXTUAL-CONVENTION in the
+ IANAifType-MIB module have had an ASN.1 comment added by IANA stating
+ that they have been deprecated:
+
+ - iso88032Csmacd(7)
+ - starLan(11)
+
+ In addition, the following enumerated values have had an ASN.1
+ comment added by IANA stating that they are obsolete:
+
+ - fastEther(62)
+ - fastEtherFX(69)
+ - gigabitEthernet(117)
+
+ In all of the above cases, the ASN.1 comment indicates that
+ ethernetCsmacd(6) should be used instead of these values.
+
+
+
+
+
+
+Flick Standards Track [Page 60]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+A. Change Log
+
+A.1. Changes since RFC 2665
+
+ This section enumerates changes made to RFC 2665 to produce this
+ document.
+
+ (1) Updated references to the IEEE 802.3 standard to
+ refer to the 2002 edition.
+
+ (2) Added reference to IEEE 802.3ae-2002.
+
+ (3) Updated WG e-mail address.
+
+ (4) The following DESCRIPTION clauses have been updated
+ to reflect behaviour on 10 Gb/s interfaces:
+ dot3StatsAlignmentErrors and dot3StatsSymbolErrors.
+
+ (5) The following objects have been added for management
+ of the Rate Control function in WAN applications of
+ ethernet: dot3StatsRateControlAbility and
+ dot3StatsRateControlStatus.
+
+ (6) The following 64-bit counters have been added to
+ support operation on high-speed ethernet interfaces:
+ dot3HCControlInUnknownOpcodes, dot3HCInPauseFrames,
+ dot3HCOutPauseFrames, dot3HCStatsAlignmentErrors,
+ dot3HCStatsFCSErrors, dot3HCStatsFrameTooLongs,
+ dot3HCStatsInternalMacTransmitErrors,
+ dot3HCStatsInternalMacReceiveErrors,
+ dot3HCStatsSymbolErrors
+
+ (7) Object groups and compliances have been added to
+ contain the new objects.
+
+ (8) The MODULE-IDENTITY clause has been updated to
+ reflect the changes in the MIB module.
+
+ (9) Use of the various ifType values for ethernet has
+ been clarified to emphasize that all ethernet-like
+ interfaces must use the ethernetCsmacd ifType.
+
+ (10) Several clarifications were made to the section on
+ the mapping of the Interface MIB objects to ethernet.
+
+ (11) MIB boilerplate in section 2 has been updated to the
+ latest approved text.
+
+
+
+
+Flick Standards Track [Page 61]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+A.2. Changes between RFC 2358 and RFC 2665
+
+ This section enumerates changes made to RFC 2358 to produce RFC 2665.
+
+ (1) Section 2 has been replaced with the current SNMP
+ Management Framework boilerplate.
+
+ (2) The ifMtu mapping has been clarified.
+
+ (3) The relationship between the IEEE 802.3 octet counters
+ and the IF-MIB octet counters has been clarified.
+
+ (4) REFERENCE clauses have been updated to reflect the
+ actual IEEE 802.3 managed object that each MIB object
+ is based on.
+
+ (5) The following object DESCRIPTION clauses have been
+ updated to reflect that they do not increment in
+ full-duplex mode: dot3StatsSingleCollisionFrames,
+ dot3StatsMultipleCollisionFrames, dot3StatsSQETestErrors,
+ dot3StatsDeferredTransmissions, dot3StatsLateCollisions,
+ dot3StatsExcessiveCollisions, dot3StatsCarrierSenseErrors,
+ dot3CollFrequencies.
+
+ (6) The following object DESCRIPTION clauses have been
+ updated to reflect behaviour on full-duplex and
+ 1000 Mb/s interfaces: dot3StatsAlignmentErrors,
+ dot3StatsFCSErrors, dot3StatsSQETestErrors,
+ dot3StatsLateCollisions, dot3StatsSymbolErrors.
+
+ (7) Two new tables, dot3ControlTable and dot3PauseTable,
+ have been added.
+
+ (8) A new object, dot3StatsDuplexStatus, has been added.
+
+ (9) The object groups and compliances have been restructured.
+
+ (10) The dot3StatsEtherChipSet object has been deprecated.
+
+ (11) The dot3ChipSets have been moved to a separate document.
+
+A.3. Changes between RFC 1650 and RFC 2358
+
+ This section enumerates changes made to RFC 1650 to produce RFC 2358.
+
+ (1) The MODULE-IDENTITY has been updated to reflect the changes
+ in the MIB.
+
+
+
+
+Flick Standards Track [Page 62]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+ (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.
+
+Author's Address
+
+ John Flick
+ Hewlett-Packard Company
+ 8000 Foothills Blvd. M/S 5557
+ Roseville, CA 95747-5557
+
+ Phone: +1 916 785 4018
+ EMail: johnf@rose.hp.com
+
+
+
+
+
+
+
+
+
+Flick Standards Track [Page 63]
+
+RFC 3635 Ethernet-Like MIB September 2003
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ 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 assignees.
+
+ 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Flick Standards Track [Page 64]
+