draft-ietf-hubmib-etherif-mib-v3-00.txt   draft-ietf-hubmib-etherif-mib-v3-01.txt 
skipping to change at page 1, line 14 skipping to change at page 1, line 14
INTERNET DRAFT J. Flick INTERNET DRAFT J. Flick
Hewlett-Packard Company Hewlett-Packard Company
Editors of previous versions: Editors of previous versions:
J. Flick J. Flick
Hewlett-Packard Company Hewlett-Packard Company
J. Johnson J. Johnson
RedBack Networks RedBack Networks
F. Kastenholz F. Kastenholz
Unisphere Networks Unisphere Networks
June 2001 February 2002
Definitions of Managed Objects for Definitions of Managed Objects for
the Ethernet-like Interface Types the Ethernet-like Interface Types
<draft-ietf-hubmib-etherif-mib-v3-00.txt> <draft-ietf-hubmib-etherif-mib-v3-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
This memo defines a portion of the Management Information Base (MIB) This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community. for use with network management protocols in the Internet community.
This memo obsoletes RFC 2665 ''Definitions of Managed Objects for the This memo obsoletes RFC 2665 ''Definitions of Managed Objects for the
Ethernet-like Interface Types''. This memo updates that Ethernet-like Interface Types''. This memo updates that
specification by including management information useful for the specification by including management information useful for the
management of 10 Gigabit per second (Gb/s) Ethernet interfaces. management of 10 Gigabit per second (Gb/s) Ethernet interfaces.
skipping to change at page 2, line 37 skipping to change at page 2, line 37
2. The SNMP Management Framework .............................. 3 2. The SNMP Management Framework .............................. 3
3. Overview ................................................... 4 3. Overview ................................................... 4
3.1. Relation to MIB-2 ........................................ 5 3.1. Relation to MIB-2 ........................................ 5
3.2. Relation to the Interfaces MIB ........................... 5 3.2. Relation to the Interfaces MIB ........................... 5
3.2.1. Layering Model ......................................... 5 3.2.1. Layering Model ......................................... 5
3.2.2. Virtual Circuits ....................................... 6 3.2.2. Virtual Circuits ....................................... 6
3.2.3. ifRcvAddressTable ...................................... 6 3.2.3. ifRcvAddressTable ...................................... 6
3.2.4. ifType ................................................. 6 3.2.4. ifType ................................................. 6
3.2.5. ifXxxOctets ............................................ 7 3.2.5. ifXxxOctets ............................................ 7
3.2.6. ifXxxXcastPkts ......................................... 8 3.2.6. ifXxxXcastPkts ......................................... 8
3.2.7. ifMtu .................................................. 8 3.2.7. ifMtu .................................................. 9
3.2.8. ifSpeed and ifHighSpeed ................................ 9 3.2.8. ifSpeed and ifHighSpeed ................................ 10
3.2.9. ifPhysAddress .......................................... 10 3.2.9. ifPhysAddress .......................................... 10
3.2.10. Specific Interface MIB Objects ........................ 10 3.2.10. Specific Interface MIB Objects ........................ 11
3.3. Relation to the 802.3 MAU MIB ............................ 13 3.3. Relation to the 802.3 MAU MIB ............................ 14
3.4. dot3StatsEtherChipSet .................................... 14 3.4. dot3StatsEtherChipSet .................................... 14
3.5. Mapping of IEEE 802.3 Managed Objects .................... 14 3.5. Mapping of IEEE 802.3 Managed Objects .................... 15
4. Definitions ................................................ 17 4. Definitions ................................................ 18
5. Intellectual Property ...................................... 53 5. Intellectual Property ...................................... 54
6. Acknowledgements ........................................... 54 6. Acknowledgements ........................................... 55
7. References ................................................. 55 7. References ................................................. 56
8. Security Considerations .................................... 58 8. Security Considerations .................................... 59
9. Author's Address ........................................... 58 9. Author's Address ........................................... 60
A. Change Log ................................................. 59 A. Change Log ................................................. 60
A.1. Changes since RFC 2665 ................................... 59 A.1. Changes since RFC 2665 ................................... 60
A.2. Changes between RFC 2358 and RFC 2665 .................... 60 A.2. Changes between RFC 2358 and RFC 2665 .................... 61
A.3. Changes between RFC 1650 and RFC 2358 .................... 60 A.3. Changes between RFC 1650 and RFC 2358 .................... 62
B. Full Copyright Statement ................................... 61 B. Full Copyright Statement ................................... 63
1. Introduction 1. Introduction
This memo defines a portion of the Management Information Base (MIB) This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community. for use with network management protocols in the Internet community.
In particular, it defines objects for managing Ethernet-like In particular, it defines objects for managing Ethernet-like
interfaces. interfaces.
This memo also includes a MIB module. This MIB module updates the This memo also includes a MIB module. This MIB module updates the
list of managed objects specified in the earlier version of this MIB, list of managed objects specified in the earlier version of this MIB,
RFC 2665 [26]. RFC 2665 [RFC2665].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [29]. document are to be interpreted as described in [RFC2119].
2. The SNMP Management Framework 2. The SNMP Management Framework
The SNMP Management Framework presently consists of five major The SNMP Management Framework presently consists of five major
components: components:
o An overall architecture, described in RFC 2571 [1]. o An overall architecture, described in RFC 2571 [RFC2571].
o Mechanisms for describing and naming objects and events for the o Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and described in Management Information (SMI) is called SMIv1 and described in
STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC
The second version, called SMIv2, is described in STD 58, RFC 1215 [RFC1215]. The second version, called SMIv2, is described
2578 [5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7]. in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and
STD 58, RFC 2580 [RFC2580].
o Message protocols for transferring management information. The o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC 1157 [8]. A second version of the SNMP described in STD 15, RFC 1157 [RFC1157]. A second version of
message protocol, which is not an Internet standards track the SNMP message protocol, which is not an Internet standards
protocol, is called SNMPv2c and described in RFC 1901 [9] and track protocol, is called SNMPv2c and described in RFC 1901
RFC 1906 [10]. The third version of the message protocol is [RFC1901] and RFC 1906 [RFC1906]. The third version of the
called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and message protocol is called SNMPv3 and described in RFC 1906
RFC 2574 [12]. [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574].
o Protocol operations for accessing management information. The o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is first set of protocol operations and associated PDU formats is
described in STD 15, RFC 1157 [8]. A second set of protocol described in STD 15, RFC 1157 [RFC1157]. A second set of
operations and associated PDU formats is described in RFC 1905 protocol operations and associated PDU formats is described in
[13]. RFC 1905 [RFC1905].
o A set of fundamental applications described in RFC 2573 [14] and o A set of fundamental applications described in RFC 2573
the view-based access control mechanism described in RFC 2575 [RFC2573] and the view-based access control mechanism described
[15]. in RFC 2575 [RFC2575].
A more detailed introduction to the current SNMP Management Framework A more detailed introduction to the current SNMP Management Framework
can be found in RFC 2570 [16]. can be found in RFC 2570 [RFC2570].
Managed objects are accessed via a virtual information store, termed Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are the Management Information Base or MIB. Objects in the MIB are
defined using the mechanisms defined in the SMI. defined using the mechanisms defined in the SMI.
This memo specifies a MIB module that is compliant to the SMIv2. A This memo specifies a MIB module that is compliant to the SMIv2. A
MIB conforming to the SMIv1 can be produced through the appropriate MIB conforming to the SMIv1 can be produced through the appropriate
translations. The resulting translated MIB must be semantically translations. The resulting translated MIB must be semantically
equivalent, except where objects or events are omitted because no equivalent, except where objects or events are omitted because no
translation is possible (use of Counter64). Some machine readable translation is possible (use of Counter64). Some machine readable
information in SMIv2 will be converted into textual descriptions in information in SMIv2 will be converted into textual descriptions in
SMIv1 during the translation process. However, this loss of machine SMIv1 during the translation process. However, this loss of machine
readable information is not considered to change the semantics of the readable information is not considered to change the semantics of the
MIB. MIB.
3. Overview 3. Overview
Instances of these object types represent attributes of an interface Instances of these object types represent attributes of an interface
to an ethernet-like communications medium. At present, ethernet-like to an ethernet-like communications medium. At present, ethernet-like
media are identified by the value ethernetCsmacd(6) of the ifType media are identified by the value ethernetCsmacd(6) of the ifType
object in the Interfaces MIB [28]. Some older implementations may object in the Interfaces MIB [RFC2863]. Some older implementations
return the values iso88023Csmacd(7) or starLan(11) for ifType for may return the values iso88023Csmacd(7) or starLan(11) for ifType for
ethernet-like media. ethernet-like media.
The definitions presented here are based on Section 30, "10 Mb/s, 100 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 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, Specification for 802.3 managed object classes" of IEEE Std. 802.3,
2000 Edition [17], ammended by IEEE Draft P802.3ae/D3.0 [18], as 2000 Edition [IEEE802.3], ammended by IEEE Draft P802.3ae/D4.01
originally interpreted by Frank Kastenholz, then of Interlan in [19]. [P802.3a3], as originally interpreted by Frank Kastenholz, then of
Implementors of these MIB objects should note that IEEE Std. 802.3 Interlan in [KASTEN]. Implementors of these MIB objects should note
[17] explicitly describes (in the form of Pascal pseudocode) when, that IEEE Std. 802.3 [IEEE802.3] explicitly describes (in the form of
where, and how various MAC attributes are measured. The IEEE document Pascal pseudocode) when, where, and how various MAC attributes are
also describes the effects of MAC actions that may be invoked by measured. The IEEE document also describes the effects of MAC actions
manipulating instances of the MIB objects defined here. that may be invoked by manipulating instances of the MIB objects
defined here.
To the extent that some of the attributes defined in [17] are To the extent that some of the attributes defined in [IEEE802.3] are
represented by previously defined objects in MIB-2 [27] or in the represented by previously defined objects in MIB-2 [RFC1213] or in
Interfaces MIB [28], such attributes are not redundantly represented the Interfaces MIB [RFC2863], such attributes are not redundantly
by objects defined in this memo. Among the attributes represented by represented by objects defined in this memo. Among the attributes
objects defined in other memos are the number of octets transmitted represented by objects defined in other memos are the number of
or received on a particular interface, the number of frames octets transmitted or received on a particular interface, the number
transmitted or received on a particular interface, the promiscuous of frames transmitted or received on a particular interface, the
status of an interface, the MAC address of an interface, and promiscuous status of an interface, the MAC address of an interface,
multicast information associated with an interface. and multicast information associated with an interface.
3.1. Relation to MIB-2 3.1. Relation to MIB-2
This section applies only when this MIB is used in conjunction with This section applies only when this MIB is used in conjunction with
the "old" (RFC 1213) [27] interface group. the "old" [RFC1213] interface group.
The relationship between an ethernet-like interface and an interface 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 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 ifIndex object instance can be directly used to identify
corresponding instances of the objects defined herein. corresponding instances of the objects defined herein.
For agents which implement the (now deprecated) ifSpecific object, an For agents which implement the (now deprecated) ifSpecific object, an
instance of that object that is associated with an ethernet-like instance of that object that is associated with an ethernet-like
interface has the OBJECT IDENTIFIER value: interface has the OBJECT IDENTIFIER value:
dot3 OBJECT IDENTIFER ::= { transmission 7 } dot3 OBJECT IDENTIFER ::= { transmission 7 }
3.2. Relation to the Interfaces MIB 3.2. Relation to the Interfaces MIB
The Interface MIB [28] requires that any MIB which is an adjunct of The Interface MIB [RFC2863] requires that any MIB which is an adjunct
the Interface MIB clarify specific areas within the Interface MIB. of the Interface MIB clarify specific areas within the Interface MIB.
These areas were intentionally left vague in the Interface MIB to These areas were intentionally left vague in the Interface MIB to
avoid over constraining the MIB, thereby precluding management of avoid over constraining the MIB, thereby precluding management of
certain media-types. certain media-types.
Section 4 of [28] enumerates several areas which a media-specific MIB Section 4 of [RFC2863] enumerates several areas which a media-
must clarify. Each of these areas is addressed in a following specific MIB must clarify. Each of these areas is addressed in a
subsection. The implementor is referred to [28] in order to following subsection. The implementor is referred to [RFC2863] in
understand the general intent of these areas. order to understand the general intent of these areas.
3.2.1. Layering Model 3.2.1. Layering Model
Ordinarily, there are no sublayers for an ethernet-like interface. Ordinarily, there are no sublayers for an ethernet-like interface.
However there may be implementation-specific requirements which However there may be implementation-specific requirements which
require the use of sublayers. One example is the use of 802.3 link require the use of sublayers. One example is the use of 802.3 link
aggregation. In this case, Annex 30C of [17] describes the layering aggregation. In this case, Annex 30C of [IEEE802.3] describes the
model and the use of the ifStackTable for representing aggregated layering model and the use of the ifStackTable for representing
links. aggregated links. Another example is the use of the 802.3 WAN
Interface Sublayer. In this case, The 802.3 WIS MIB [ETHERWIS]
describes the layering model and the use of the ifStackTable for
representing the WAN sublayer.
3.2.2. Virtual Circuits 3.2.2. Virtual Circuits
This medium does not support virtual circuits and this area is not This medium does not support virtual circuits and this area is not
applicable to this MIB. applicable to this MIB.
3.2.3. ifRcvAddressTable 3.2.3. ifRcvAddressTable
This table contains all IEEE 802.3 addresses, unicast, multicast, and This table contains all IEEE 802.3 addresses, unicast, multicast, and
broadcast, for which this interface will receive packets and forward broadcast, for which this interface will receive packets and forward
skipping to change at page 6, line 47 skipping to change at page 7, line 7
individual vendors, not by any IETF working group. A requirement for individual vendors, not by any IETF working group. A requirement for
compliance with this document is that all ethernet-like interfaces compliance with this document is that all ethernet-like interfaces
MUST return ethernetCsmacd(6) for ifType, and MUST NOT return MUST return ethernetCsmacd(6) for ifType, and MUST NOT return
fastEther(62), fastEtherFX(69), or gigabitEthernet(117). However, as fastEther(62), fastEtherFX(69), or gigabitEthernet(117). However, as
there are fielded implementations that do return these obsolete there are fielded implementations that do return these obsolete
ifType values, management applications SHOULD be prepared to receive ifType values, management applications SHOULD be prepared to receive
them from older implementations. them from older implementations.
Information on the particular flavor of Ethernet that an interface is Information on the particular flavor of Ethernet that an interface is
running is available from ifSpeed in the Interfaces MIB, and running is available from ifSpeed in the Interfaces MIB, and
ifMauType in the 802.3 MAU MIB [30]. Note that implementation of the ifMauType in the 802.3 MAU MIB [MAU-MIB]. Note that implementation
802.3 MAU MIB [30] is REQUIRED for all ethernet-like interfaces. of the 802.3 MAU MIB [MAU-MIB] is REQUIRED for all ethernet-like
interfaces.
3.2.5. ifXxxOctets 3.2.5. ifXxxOctets
The Interface MIB octet counters, ifInOctets, ifOutOctets, The Interface MIB octet counters, ifInOctets, ifOutOctets,
ifHCInOctets and ifHCOutOctets, MUST include all octets in valid ifHCInOctets and ifHCOutOctets, MUST include all octets in valid
frames sent or received on the interface, including the MAC header frames sent or received on the interface, including the MAC header
and FCS, but not the preamble, start of frame delimiter, or extension and FCS, but not the preamble, start of frame delimiter, or extension
octets. This corresponds to the definition of frameSize/8 in section octets. This corresponds to the definition of frameSize/8 in section
4.2.7.1 of [17] (frameSize is defined in bits rather than octets, and 4.2.7.1 of [IEEE802.3] (frameSize is defined in bits rather than
is defined as 2 x addressSize + lengthOrTypeSize + dataSize + octets, and is defined as 2 x addressSize + lengthOrTypeSize +
crcSize). They do not include the number of octets in collided or dataSize + crcSize). They do not include the number of octets in
failed transmit attempts, since the MAC layer driver typically does collided or failed transmit attempts, since the MAC layer driver
not have visibility to count these octets. They also do not include typically does not have visibility to count these octets. They also
octets in received invalid frames, since this information is normally do not include octets in received invalid frames, since this
not passed to the MAC layer, and since non-promiscuous MAC information is normally not passed to the MAC layer, and since non-
implementations cannot reliably determine whether an invalid frame promiscuous MAC implementations cannot reliably determine whether an
was actually addressed to this station. invalid frame was actually addressed to this station.
Note that these counters do include octets in valid MAC control Note that these counters do include octets in valid MAC control
frames sent or received on the interface, as well as octets in frames sent or received on the interface, as well as octets in
otherwise valid received MAC frames that are discarded by the MAC otherwise valid received MAC frames that are discarded by the MAC
layer for some reason (insufficient buffer space, unknown protocol, layer for some reason (insufficient buffer space, unknown protocol,
etc.). etc.).
Note that the octet counters in IF-MIB do not exactly match the Note that the octet counters in IF-MIB do not exactly match the
definition of the octet counters in IEEE 802.3. aOctetsTransmittedOK definition of the octet counters in IEEE 802.3. aOctetsTransmittedOK
and aOctetsReceivedOK count only the octets in the clientData and Pad and aOctetsReceivedOK count only the octets in the clientData and Pad
skipping to change at page 8, line 49 skipping to change at page 9, line 9
This specification chooses to treat MAC control frames as being This specification chooses to treat MAC control frames as being
originated and consumed within the interface and not counted by the originated and consumed within the interface and not counted by the
IF-MIB packet counters. MAC control frames are normally sent as IF-MIB packet counters. MAC control frames are normally sent as
multicast packets. In many network environments, MAC control frames multicast packets. In many network environments, MAC control frames
can greatly outnumber multicast frames carrying actual data. If MAC can greatly outnumber multicast frames carrying actual data. If MAC
control frames were included in the ifInMulticastPkts and control frames were included in the ifInMulticastPkts and
ifOutMulticastPkts, the count of data-carrying multicast packets ifOutMulticastPkts, the count of data-carrying multicast packets
would tend to be drowned out by the count of MAC control frames, would tend to be drowned out by the count of MAC control frames,
rendering those counters considerably less useful. rendering those counters considerably less useful.
To better understand the issues surrounding the mapping of 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.
layer above
--------------------------------------------------------------------
ifInUcastPkts+ ^ | ifOutUcastPkts+
ifInBroadcastPkts+ ----|---- ----|---- ifOutBroadcastPkts+
ifInMulticastPkts | | ifOutMulticastPkts
| |
dot3InPauseFrames <---| |<--- dot3OutPauseFrames
| |
ifInDiscards <---| |
| |
ifInUnknownProtos <---| |---> ifOutDiscards
| |
ifInOctets ----|---- ----|---- ifOutOctets
| |
ifInErrors <---| |---> ifOutErrors
| V
--------------------------------------------------------------------
layer below
3.2.7. ifMtu 3.2.7. ifMtu
The defined standard MTU for ethernet-like interfaces is 1500 octets. The defined standard MTU for ethernet-like interfaces is 1500 octets.
However, many implementations today support larger packet sizes than However, many implementations today support larger packet sizes than
the IEEE 802.3 standard. The value of this object MUST reflect the 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 actual MTU in use on the interface, whether it matches the standard
MTU or not. MTU or not.
This value should reflect the value seen by the MAC client interface. This value should reflect the value seen by the MAC client interface.
When a higher layer protocol, like IP, is running over Ethernet When a higher layer protocol, like IP, is running over Ethernet
framing, this is the MTU that will be seen by that higher layer framing, this is the MTU that will be seen by that higher layer
protocol. However, most ethernet-like interfaces today run multiple protocol. However, most ethernet-like interfaces today run multiple
protocols that use a mix of different framing types. For example, an protocols that use a mix of different framing types. For example, an
skipping to change at page 9, line 42 skipping to change at page 10, line 26
1, 10, 100, or 1,000. If the interface implements auto-negotiation, 1, 10, 100, or 1,000. If the interface implements auto-negotiation,
auto-negotiation is enabled for this interface, and the interface has auto-negotiation is enabled for this interface, and the interface has
not yet negotiated to an operational speed, these objects SHOULD not yet negotiated to an operational speed, these objects SHOULD
reflect the maximum speed supported by the interface. reflect the maximum speed supported by the interface.
For ethernet-like interfaces operating at greater than 1000 Mb/s, For ethernet-like interfaces operating at greater than 1000 Mb/s,
ifHighSpeed will represent the current operational speed of the ifHighSpeed will represent the current operational speed of the
interface in millions of bits per second. Note that for WAN interface in millions of bits per second. Note that for WAN
implementations, this will be the payload data rate over the WAN implementations, this will be the payload data rate over the WAN
interface sublayer. For current implementations, this will be equal interface sublayer. For current implementations, this will be equal
to 10,000 for LAN implentations of 10 Gb/s, and 9,585 for WAN to 10,000 for LAN implentations of 10 Gb/s, and 9,294 for WAN
implementations of the 10 Gb/s MAC over an OC-192 PHY. For these 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 speeds, ifSpeed should report a maximum unsigned 32-bit value of
4,294,967,295 as specified in [28]. 4,294,967,295 as specified in [RFC2863].
Note that these object MUST NOT indicate a doubled value when Note that these object MUST NOT indicate a doubled value when
operating in full-duplex mode. It MUST indicate the correct line operating in full-duplex mode. It MUST indicate the correct line
speed regardless of the current duplex mode. The duplex mode of the speed regardless of the current duplex mode. The duplex mode of the
interface may be determined by examining either the interface may be determined by examining either the
dot3StatsDuplexStatus object in this MIB module, or the ifMauType dot3StatsDuplexStatus object in this MIB module, or the ifMauType
object in the 802.3 MAU MIB [30]. object in the 802.3 MAU MIB [MAU-MIB].
3.2.9. ifPhysAddress 3.2.9. ifPhysAddress
This object contains the IEEE 802.3 address which is placed in the 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 source-address field of any Ethernet, Starlan, or IEEE 802.3 frames
that originate at this interface. Usually this will be kept in ROM that originate at this interface. Usually this will be kept in ROM
on the interface hardware. Some systems may set this address via on the interface hardware. Some systems may set this address via
software. software.
In a system where there are several such addresses the designer has a In a system where there are several such addresses the designer has a
skipping to change at page 10, line 45 skipping to change at page 11, line 31
Object Guidelines Object Guidelines
ifIndex Each ethernet-like interface is ifIndex Each ethernet-like interface is
represented by an ifEntry. The represented by an ifEntry. The
dot3StatsTable in this MIB module is dot3StatsTable in this MIB module is
indexed by dot3StatsIndex. The interface indexed by dot3StatsIndex. The interface
identified by a particular value of identified by a particular value of
dot3StatsIndex is the same interface as dot3StatsIndex is the same interface as
identified by the same value of ifIndex. identified by the same value of ifIndex.
ifDescr Refer to [28]. ifDescr Refer to [RFC2863].
ifType Refer to section 3.2.4. ifType Refer to section 3.2.4.
ifMtu Refer to section 3.2.7. ifMtu Refer to section 3.2.7.
ifSpeed Refer to section 3.2.8. ifSpeed Refer to section 3.2.8.
ifPhysAddress Refer to section 3.2.9. ifPhysAddress Refer to section 3.2.9.
ifAdminStatus Write access is not required. Support ifAdminStatus Write access is not required. Support
for 'testing' is not required. for 'testing' is not required.
ifOperStatus The operational state of the interface. ifOperStatus The operational state of the interface.
Support for 'testing' is not required. Support for 'testing' is not required.
The value 'dormant' has no meaning for The value 'dormant' has no meaning for
an ethernet-like interface. an ethernet-like interface.
ifLastChange Refer to [28]. ifLastChange Refer to [RFC2863].
ifInOctets The number of octets in valid MAC frames ifInOctets The number of octets in valid MAC frames
received on this interface, including received on this interface, including
the MAC header and FCS. This does the MAC header and FCS. This does
include the number of octets in valid include the number of octets in valid
MAC Control frames received on this MAC Control frames received on this
interface. See section 3.2.5. interface. See section 3.2.5.
ifInUcastPkts Refer to [28]. Note that this does not ifInUcastPkts Refer to [RFC2863]. Note that this does
include MAC Control frames, since MAC not include MAC Control frames, since
Control frames are consumed by the MAC Control frames are consumed by the
interface layer and are not passed to interface layer and are not passed to
any higher layer protocol. See any higher layer protocol. See
section 3.2.6. section 3.2.6.
ifInDiscards Refer to [28]. ifInDiscards Refer to [RFC2863].
ifInErrors The sum for this interface of ifInErrors The sum for this interface of
dot3StatsAlignmentErrors, dot3StatsAlignmentErrors,
dot3StatsFCSErrors, dot3StatsFCSErrors,
dot3StatsFrameTooLongs, dot3StatsFrameTooLongs,
and dot3StatsInternalMacReceiveErrors. and dot3StatsInternalMacReceiveErrors.
ifInUnknownProtos Refer to [28]. ifInUnknownProtos Refer to [RFC2863].
ifOutOctets The number of octets transmitted in ifOutOctets The number of octets transmitted in
valid MAC frames on this interface, valid MAC frames on this interface,
including the MAC header and FCS. This including the MAC header and FCS. This
does include the number of octets in does include the number of octets in
valid MAC Control frames transmitted on valid MAC Control frames transmitted on
this interface. See section 3.2.5. this interface. See section 3.2.5.
ifOutUcastPkts Refer to [28]. Note that this does not ifOutUcastPkts Refer to [RFC2863]. Note that this does
include MAC Control frames, since MAC not include MAC Control frames, since
Control frames are generated by the MAC Control frames are generated by the
interface layer, and are not passed from interface layer, and are not passed from
any higher layer protocol. See section any higher layer protocol. See section
3.2.6. 3.2.6.
ifOutDiscards Refer to [28]. ifOutDiscards Refer to [RFC2863].
ifOutErrors The sum for this interface of: ifOutErrors The sum for this interface of:
dot3StatsSQETestErrors, dot3StatsSQETestErrors,
dot3StatsLateCollisions, dot3StatsLateCollisions,
dot3StatsExcessiveCollisions, dot3StatsExcessiveCollisions,
dot3StatsInternalMacTransmitErrors and dot3StatsInternalMacTransmitErrors and
dot3StatsCarrierSenseErrors. dot3StatsCarrierSenseErrors.
ifName Locally-significant textual name for the ifName Locally-significant textual name for the
interface (e.g. lan0). interface (e.g. lan0).
ifInMulticastPkts Refer to [28]. Note that this does not ifInMulticastPkts Refer to [RFC2863]. Note that this does
include MAC Control frames, since MAC not include MAC Control frames, since
Control frames are consumed by the MAC Control frames are consumed by the
interface layer and are not passed to interface layer and are not passed to
any higher layer protocol. See section any higher layer protocol. See section
3.2.6. 3.2.6.
ifInBroadcastPkts Refer to [28]. Note that this does not ifInBroadcastPkts Refer to [RFC2863]. Note that this does
include MAC Control frames, since MAC not include MAC Control frames, since
Control frames are generated by the MAC Control frames are generated by the
interface layer, and are not passed from interface layer, and are not passed from
any higher layer protocol. See section any higher layer protocol. See section
3.2.6. 3.2.6.
ifOutMulticastPkts Refer to [28]. Note that this does not ifOutMulticastPkts Refer to [RFC2863]. Note that this does
include MAC Control frames, since MAC not include MAC Control frames, since
Control frames are consumed by the MAC Control frames are consumed by the
interface layer and are not passed to interface layer and are not passed to
any higher layer protocol. See section any higher layer protocol. See section
3.2.6. 3.2.6.
ifOutBroadcastPkts Refer to [28]. Note that this does not ifOutBroadcastPkts Refer to [RFC2863]. Note that this does
include MAC Control frames, since MAC not include MAC Control frames, since
Control frames are generated by the MAC Control frames are generated by the
interface layer, and are not passed from interface layer, and are not passed from
any higher layer protocol. See section any higher layer protocol. See section
3.2.6. 3.2.6.
ifHCInOctets 64-bit versions of counters. Required ifHCInOctets 64-bit versions of counters. Required
ifHCOutOctets for ethernet-like interfaces that are ifHCOutOctets for ethernet-like interfaces that are
capable of operating at 20 Mb/s or capable of operating at 20 Mb/s or
faster, even if the interface is faster, even if the interface is
currently operating at less than currently operating at less than
20 Mb/s. 20 Mb/s.
ifHCInUcastPkts 64-bit versions of packet counters. ifHCInUcastPkts 64-bit versions of packet counters.
ifHCInMulticastPkts Required for ethernet-like interfaces ifHCInMulticastPkts Required for ethernet-like interfaces
ifHCInBroadcastPkts that are capable of operating at ifHCInBroadcastPkts that are capable of operating at
ifHCOutUcastPkts 640 Mb/s or faster, even if the ifHCOutUcastPkts 640 Mb/s or faster, even if the
ifHCOutMulticastPkts interface is currently operating at ifHCOutMulticastPkts interface is currently operating at
ifHCOutBroadcastPkts less than 640 Mb/s. ifHCOutBroadcastPkts less than 640 Mb/s.
ifLinkUpDownTrapEnable Refer to [28]. Default is 'enabled' ifLinkUpDownTrapEnable Refer to [RFC2863]. Default is
'enabled'
ifHighSpeed Refer to section 3.2.8. ifHighSpeed Refer to section 3.2.8.
ifPromiscuousMode Refer to [28]. ifPromiscuousMode Refer to [RFC2863].
ifConnectorPresent This will normally be 'true'. ifConnectorPresent This will normally be 'true'. It will
be 'false' in the case where this
interface uses the WAN Interface
Sublayer. See [ETHERWIS] for details.
ifAlias Refer to [28]. ifAlias Refer to [RFC2863].
ifCounterDiscontinuityTime Refer to [28]. Note that a ifCounterDiscontinuityTime Refer to [RFC2863]. Note that a
discontinuity in the Interface MIB discontinuity in the Interface MIB
counters may also indicate a counters may also indicate a
discontinuity in some or all of the discontinuity in some or all of the
counters in this MIB that are associated counters in this MIB that are associated
with that interface. with that interface.
ifStackHigherLayer Refer to section 3.2.1. ifStackHigherLayer Refer to section 3.2.1.
ifStackLowerLayer ifStackLowerLayer
ifStackStatus ifStackStatus
ifRcvAddressAddress Refer to section 3.2.3. ifRcvAddressAddress Refer to section 3.2.3.
ifRcvAddressStatus ifRcvAddressStatus
ifRcvAddressType ifRcvAddressType
3.3. Relation to the 802.3 MAU MIB 3.3. Relation to the 802.3 MAU MIB
Support for the mauModIfCompl2 compliance statement of the MAU-MIB Support for the mauModIfCompl3 compliance statement of the MAU-MIB
[30] is REQUIRED for Ethernet-like interfaces. This MIB is needed in [MAU-MIB] is REQUIRED for Ethernet-like interfaces. This MIB is
order to allow applications to determine the current MAU type in use needed in order to allow applications to determine the current MAU
by the interface, and to control autonegotiation and duplex mode for type in use by the interface, and to control autonegotiation and
the interface. Implementing this MIB module without implementing the duplex mode for the interface. Implementing this MIB module without
MAU-MIB would leave applications with no standard way to determine implementing the MAU-MIB would leave applications with no standard
the media type in use, and no standard way to control the duplex mode way to determine the media type in use, and no standard way to
of the interface. control the duplex mode of the interface.
3.4. dot3StatsEtherChipSet 3.4. dot3StatsEtherChipSet
This document defines an object called dot3StatsEtherChipSet, which This document defines an object called dot3StatsEtherChipSet, which
is used to identify the MAC hardware used to communicate on an is used to identify the MAC hardware used to communicate on an
interface. Previous versions of this document contained a number of interface. Previous versions of this document contained a number of
OID assignments for some existing Ethernet chipsets. Maintaining OID assignments for some existing Ethernet chipsets. Maintaining
that list as part of this document has proven to be problematic, so that list as part of this document has proven to be problematic, so
the OID assignments contained in prevous versions of this document the OID assignments contained in prevous versions of this document
have now been moved to a separate document [31]. have now been moved to a separate document [RFC2666].
The dot3StatsEtherChipSet object has now been deprecated. The dot3StatsEtherChipSet object has now been deprecated.
Implementation feedback indicates that this object is much more Implementation feedback indicates that this object is much more
useful in theory than in practice. The object's utility in debugging useful in theory than in practice. The object's utility in debugging
network problems in the field appears to be limited. In those cases network problems in the field appears to be limited. In those cases
where it may be useful, it is not sufficient, since it identifies where it may be useful, it is not sufficient, since it identifies
only the MAC chip, and not the PHY, PMD, or driver. The only the MAC chip, and not the PHY, PMD, or driver. The
administrative overhead involved in maintaining a central registry of administrative overhead involved in maintaining a central registry of
chipset OIDs cannot be justified for an object whose usefulness is chipset OIDs cannot be justified for an object whose usefulness is
questionable at best. questionable at best.
Implementations which continue to support this object for the purpose Implementations which continue to support this object for the purpose
skipping to change at page 14, line 27 skipping to change at page 15, line 16
useful in theory than in practice. The object's utility in debugging useful in theory than in practice. The object's utility in debugging
network problems in the field appears to be limited. In those cases network problems in the field appears to be limited. In those cases
where it may be useful, it is not sufficient, since it identifies where it may be useful, it is not sufficient, since it identifies
only the MAC chip, and not the PHY, PMD, or driver. The only the MAC chip, and not the PHY, PMD, or driver. The
administrative overhead involved in maintaining a central registry of administrative overhead involved in maintaining a central registry of
chipset OIDs cannot be justified for an object whose usefulness is chipset OIDs cannot be justified for an object whose usefulness is
questionable at best. questionable at best.
Implementations which continue to support this object for the purpose Implementations which continue to support this object for the purpose
of backwards compatability may continue to use the values defined in of backwards compatability may continue to use the values defined in
[31]. For chipsets not listed in [31], implementors that wish to [RFC2666]. For chipsets not listed in [RFC2666], implementors that
support this object and return a valid OBJECT IDENTIFIER value may wish to support this object and return a valid OBJECT IDENTIFIER
assign OBJECT IDENTIFIERS within that part of the registration tree value may assign OBJECT IDENTIFIERS within that part of the
delegated to individual enterprises. registration tree delegated to individual enterprises.
3.5. Mapping of IEEE 802.3 Managed Objects 3.5. Mapping of IEEE 802.3 Managed Objects
IEEE 802.3 Managed Object Corresponding SNMP Object IEEE 802.3 Managed Object Corresponding SNMP Object
oMacEntity oMacEntity
.aMACID dot3StatsIndex or .aMACID dot3StatsIndex or
IF-MIB - ifIndex IF-MIB - ifIndex
.aFramesTransmittedOK IF-MIB - ifOutUCastPkts + .aFramesTransmittedOK IF-MIB - ifOutUCastPkts +
ifOutMulticastPkts + ifOutMulticastPkts +
skipping to change at page 16, line 14 skipping to change at page 17, line 4
MIB module as a result of implementation feedback: MIB module as a result of implementation feedback:
oMacEntity oMacEntity
.aFramesWithExcessiveDeferral .aFramesWithExcessiveDeferral
.aInRangeLengthErrors .aInRangeLengthErrors
.aOutOfRangeLengthField .aOutOfRangeLengthField
.aMACEnableStatus .aMACEnableStatus
.aTransmitEnableStatus .aTransmitEnableStatus
.aMulticastReceiveStatus .aMulticastReceiveStatus
.acInitializeMAC .acInitializeMAC
Please see [RFC1369] for the detailed reasoning on why these objects
Please see [21] for the detailed reasoning on why these objects were were removed.
removed.
In addition, the following IEEE 802.3 managed objects have not been In addition, the following IEEE 802.3 managed objects have not been
included in this MIB for the following reasons. included in this MIB for the following reasons.
IEEE 802.3 Managed Object Disposition IEEE 802.3 Managed Object Disposition
oMACEntity oMACEntity
.aMACCapabilities Can be derived from .aMACCapabilities Can be derived from
MAU-MIB - ifMauTypeListBits MAU-MIB - ifMauTypeListBits
skipping to change at page 17, line 33 skipping to change at page 18, line 21
Counter32, Counter64, mib-2, transmission Counter32, Counter64, mib-2, transmission
FROM SNMPv2-SMI FROM SNMPv2-SMI
MODULE-COMPLIANCE, OBJECT-GROUP MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF FROM SNMPv2-CONF
TruthValue TruthValue
FROM SNMPv2-TC FROM SNMPv2-TC
ifIndex, InterfaceIndex ifIndex, InterfaceIndex
FROM IF-MIB; FROM IF-MIB;
etherMIB MODULE-IDENTITY etherMIB MODULE-IDENTITY
LAST-UPDATED "200106260024Z" -- June 26, 2001 LAST-UPDATED "200202280000Z" -- February 28, 2002
ORGANIZATION "IETF Ethernet Interfaces and Hub MIB ORGANIZATION "IETF Ethernet Interfaces and Hub MIB
Working Group" Working Group"
CONTACT-INFO CONTACT-INFO
"WG E-mail: hubmib@ietf.org "WG E-mail: hubmib@ietf.org
To subscribe: hubmib-request@ietf.org To subscribe: hubmib-request@ietf.org
Chair: Dan Romascanu Chair: Dan Romascanu
Postal: Avaya Inc. Postal: Avaya Inc.
Atidum Technology Park, Bldg. 3 Atidum Technology Park, Bldg. 3
Tel Aviv 61131 Tel Aviv 61131
skipping to change at page 18, line 24 skipping to change at page 19, line 11
[IEEE 802.3 Std] refers to: [IEEE 802.3 Std] refers to:
IEEE Std 802.3, 2000 Edition: 'IEEE Standard IEEE Std 802.3, 2000 Edition: 'IEEE Standard
for Information technology - for Information technology -
Telecommunications and information exchange Telecommunications and information exchange
between systems - Local and metropolitan between systems - Local and metropolitan
area networks - Specific requirements - area networks - Specific requirements -
Part 3: Carrier sense multiple access with Part 3: Carrier sense multiple access with
collision detection (CSMA/CD) access method collision detection (CSMA/CD) access method
and physical layer specifications', as and physical layer specifications', as
ammended by IEEE Draft P802.3ae/D3.0: ammended by IEEE Draft P802.3ae/D4.01:
'Supplement to Carrier Sense Multiple Access 'Supplement to Carrier Sense Multiple Access
with Collision Detection (CSMA/CD) Access with Collision Detection (CSMA/CD) Access
Method & Physical Layer Specifications - Method & Physical Layer Specifications -
Media Access Control (MAC) Parameters, Media Access Control (MAC) Parameters,
Physical Layer, and Management Parameters Physical Layer, and Management Parameters
for 10 Gb/s Operation', March, 2001. for 10 Gb/s Operation', February, 2002.
Of particular interest is Clause 30, '10 Mb/s, Of particular interest is Clause 30, '10 Mb/s,
100 Mb/s, 1000 Mb/s, and 10 Gb/s Management'." 100 Mb/s, 1000 Mb/s, and 10 Gb/s Management'."
REVISION "200106260024Z" -- June 26, 2001 REVISION "200202280000Z" -- February 28, 2002
DESCRIPTION "Updated to include support for 10 Gb/sec DESCRIPTION "Updated to include support for 10 Gb/sec
interfaces. interfaces.
This version published as RFC XXXX." This version published as RFC XXXX."
REVISION "9908240400Z" -- August 24, 1999 REVISION "9908240400Z" -- August 24, 1999
DESCRIPTION "Updated to include support for 1000 Mb/sec DESCRIPTION "Updated to include support for 1000 Mb/sec
interfaces and full-duplex interfaces. interfaces and full-duplex interfaces.
This version published as RFC 2665." This version published as RFC 2665."
REVISION "9806032150Z" -- June 3, 1998 REVISION "9806032150Z" -- June 3, 1998
skipping to change at page 26, line 38 skipping to change at page 27, line 26
The count represented by an instance of this The count represented by an instance of this
object is incremented when the frameTooLong object is incremented when the frameTooLong
status is returned by the MAC service to the status is returned by the MAC service to the
LLC (or other MAC user). Received frames for LLC (or other MAC user). Received frames for
which multiple error conditions pertain are, which multiple error conditions pertain are,
according to the conventions of IEEE 802.3 according to the conventions of IEEE 802.3
Layer Management, counted exclusively according Layer Management, counted exclusively according
to the error status presented to the LLC. to the error status presented to the LLC.
For interfaces operating at 10 Gb/s, this For interfaces operating at 10 Gb/s, this
counter can roll over in less than 5 minutes if counter can roll over in less than 80 minutes if
it is incrementing at its maximum rate. Since it is incrementing at its maximum rate. Since
that amount of time could be less than a that amount of time could be less than a
management station's poll cycle time, in order management station's poll cycle time, in order
to avoid a loss of information, a management to avoid a loss of information, a management
station is advised to poll the station is advised to poll the
dot3HCStatsFrameTooLongs object for 10 Gb/s dot3HCStatsFrameTooLongs object for 10 Gb/s
or faster interfaces. or faster interfaces.
Discontinuities in the value of this counter can Discontinuities in the value of this counter can
occur at re-initialization of the management occur at re-initialization of the management
skipping to change at page 44, line 29 skipping to change at page 45, line 22
-- 802.3 Tests -- 802.3 Tests
dot3Tests OBJECT IDENTIFIER ::= { dot3 6 } dot3Tests OBJECT IDENTIFIER ::= { dot3 6 }
dot3Errors OBJECT IDENTIFIER ::= { dot3 7 } dot3Errors OBJECT IDENTIFIER ::= { dot3 7 }
-- TDR Test -- TDR Test
dot3TestTdr OBJECT-IDENTITY dot3TestTdr OBJECT-IDENTITY
STATUS current STATUS deprecated
DESCRIPTION "The Time-Domain Reflectometry (TDR) test is DESCRIPTION "The Time-Domain Reflectometry (TDR) test is
specific to ethernet-like interfaces of type specific to ethernet-like interfaces of type
10Base5 and 10Base2. The TDR value may be 10Base5 and 10Base2. The TDR value may be
useful in determining the approximate distance useful in determining the approximate distance
to a cable fault. It is advisable to repeat to a cable fault. It is advisable to repeat
this test to check for a consistent resulting this test to check for a consistent resulting
TDR value, to verify that there is a fault. TDR value, to verify that there is a fault.
A TDR test returns as its result the time A TDR test returns as its result the time
interval, measured in 10 MHz ticks or 100 nsec interval, measured in 10 MHz ticks or 100 nsec
skipping to change at page 45, line 10 skipping to change at page 45, line 49
object, and the OBJECT IDENTIFIER of that object, and the OBJECT IDENTIFIER of that
instance is stored in the appropriate instance instance is stored in the appropriate instance
of the appropriate test result code object of the appropriate test result code object
(thereby indicating where the result has been (thereby indicating where the result has been
stored)." stored)."
::= { dot3Tests 1 } ::= { dot3Tests 1 }
-- Loopback Test -- Loopback Test
dot3TestLoopBack OBJECT-IDENTITY dot3TestLoopBack OBJECT-IDENTITY
STATUS current STATUS deprecated
DESCRIPTION "This test configures the MAC chip and executes DESCRIPTION "This test configures the MAC chip and executes
an internal loopback test of memory, data paths, an internal loopback test of memory, data paths,
and the MAC chip logic. This loopback test can and the MAC chip logic. This loopback test can
only be executed if the interface is offline. only be executed if the interface is offline.
Once the test has completed, the MAC chip should Once the test has completed, the MAC chip should
be reinitialized for network operation, but it be reinitialized for network operation, but it
should remain offline. should remain offline.
If an error occurs during a test, the If an error occurs during a test, the
appropriate test result object will be set appropriate test result object will be set
to indicate a failure. The two OBJECT to indicate a failure. The two OBJECT
IDENTIFIER values dot3ErrorInitError and IDENTIFIER values dot3ErrorInitError and
dot3ErrorLoopbackError may be used to provided dot3ErrorLoopbackError may be used to provided
more information as values for an appropriate more information as values for an appropriate
test result code object." test result code object."
::= { dot3Tests 2 } ::= { dot3Tests 2 }
dot3ErrorInitError OBJECT-IDENTITY dot3ErrorInitError OBJECT-IDENTITY
STATUS current STATUS deprecated
DESCRIPTION "Couldn't initialize MAC chip for test." DESCRIPTION "Couldn't initialize MAC chip for test."
::= { dot3Errors 1 } ::= { dot3Errors 1 }
dot3ErrorLoopbackError OBJECT-IDENTITY dot3ErrorLoopbackError OBJECT-IDENTITY
STATUS current STATUS deprecated
DESCRIPTION "Expected data not received (or not received DESCRIPTION "Expected data not received (or not received
correctly) in loopback test." correctly) in loopback test."
::= { dot3Errors 2 } ::= { dot3Errors 2 }
-- { dot3 8 }, the dot3ChipSets tree, is defined in [31] -- { dot3 8 }, the dot3ChipSets tree, is defined in [31]
-- conformance information -- conformance information
etherConformance OBJECT IDENTIFIER ::= { etherMIB 2 } etherConformance OBJECT IDENTIFIER ::= { etherMIB 2 }
skipping to change at page 54, line 26 skipping to change at page 55, line 17
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
6. Acknowledgements 6. Acknowledgements
This document was produced by the IETF Ethernet Interfaces and Hub This document was produced by the IETF Ethernet Interfaces and Hub
MIB Working Group, whose efforts were greatly advanced by the MIB Working Group, whose efforts were greatly advanced by the
contributions of the following people: contributions of the following people:
Ran Atkinson
Mike Ayers
Mike Heard
Lynn Kubinec Lynn Kubinec
Kam Lam
Kerry McDonald
Steve McRobert Steve McRobert
K.C. Norseth
Dan Romascanu Dan Romascanu
Randy Presuhn
Andrew Smith Andrew Smith
Kaj Tesink
Geoff Thompson Geoff Thompson
This document is based on the Proposed Standard Ethernet MIB, RFC This document is based on the Proposed Standard Ethernet MIB, RFC
2665 [26], edited by John Flick of Hewlett-Packard and Jeffrey 2665 [RFC2665], edited by John Flick of Hewlett-Packard and Jeffrey
Johnson of RedBack Networks and produced by the Ethernet Interfaces Johnson of RedBack Networks and produced by the Ethernet Interfaces
and Hub MIB Working Group. It extends that document by providing and Hub MIB Working Group. It extends that document by providing
support for 10 Gb/s Ethernet interfaces as defined in [18]. support for 10 Gb/s Ethernet interfaces as defined in [P802.3ae].
RFC 2665, in turn, is based on the Proposed Standard Ethernet MIB, RFC 2665, in turn, is based on the Proposed Standard Ethernet MIB,
RFC 2358 [25], edited by John Flick of Hewlett-Packard and Jeffrey RFC 2358 [RFC2358], edited by John Flick of Hewlett-Packard and
Johnson of RedBack Networks and produced by the 802.3 Hub MIB Working Jeffrey Johnson of RedBack Networks and produced by the 802.3 Hub MIB
Group. It extends that document by providing support for full-duplex Working Group. It extends that document by providing support for
Ethernet interfaces and 1000 Mb/sec Ethernet interfaces as outlined full-duplex Ethernet interfaces and 1000 Mb/sec Ethernet interfaces
in [17]. as outlined in [IEEE802.3].
RFC 2358, in turn, is almost completely based on both the Standard RFC 2358, in turn, is almost completely based on both the Standard
Ethernet MIB, RFC 1643 [23], and the Proposed Standard Ethernet MIB Ethernet MIB, RFC 1643 [RFC1643], and the Proposed Standard Ethernet
using the SNMPv2 SMI, RFC 1650 [24], both of which were edited by MIB using the SNMPv2 SMI, RFC 1650 [RFC1650], both of which were
Frank Kastenholz of FTP Software and produced by the Interfaces MIB edited by Frank Kastenholz of FTP Software and produced by the
Working Group. RFC 2358 extends those documents by providing support Interfaces MIB Working Group. RFC 2358 extends those documents by
for 100 Mb/sec ethernet interfaces. providing support for 100 Mb/sec ethernet interfaces.
RFC 1643 and RFC 1650, in turn, are based on the Draft Standard RFC 1643 and RFC 1650, in turn, are based on the Draft Standard
Ethernet MIB, RFC 1398 [22], also edited by Frank Kastenholz and Ethernet MIB, RFC 1398 [RFC1398], also edited by Frank Kastenholz and
produced by the Ethernet MIB Working Group. produced by the Ethernet MIB Working Group.
RFC 1398, in turn, is based on the Proposed Standard Ethernet MIB, RFC 1398, in turn, is based on the Proposed Standard Ethernet MIB,
RFC 1284 [20], which was edited by John Cook of Chipcom and produced RFC 1284 [RFC1284], which was edited by John Cook of Chipcom and
by the Transmission MIB Working Group. The Ethernet MIB Working produced by the Transmission MIB Working Group. The Ethernet MIB
Group gathered implementation experience of the variables specified Working Group gathered implementation experience of the variables
in RFC 1284, documented that experience in RFC 1369 [21], and used specified in RFC 1284, documented that experience in RFC 1369
that information to develop this revised MIB. [RFC1369], and used that information to develop this revised MIB.
RFC 1284, in turn, is based on a document written by Frank RFC 1284, in turn, is based on a document written by Frank
Kastenholz, then of Interlan, entitled IEEE 802.3 Layer Management Kastenholz, then of Interlan, entitled IEEE 802.3 Layer Management
Draft M compatible MIB for TCP/IP Networks [19]. This document was Draft M compatible MIB for TCP/IP Networks [KASTEN]. This document
modestly reworked, initially by the SNMP Working Group, and then by was modestly reworked, initially by the SNMP Working Group, and then
the Transmission Working Group, to reflect the current conventions by the Transmission Working Group, to reflect the current conventions
for defining objects for MIB interfaces. James Davin, of the MIT for defining objects for MIB interfaces. James Davin, of the MIT
Laboratory for Computer Science, and Keith McCloghrie of Hughes LAN Laboratory for Computer Science, and Keith McCloghrie of Hughes LAN
Systems, contributed to later drafts of this memo. Marshall Rose of Systems, contributed to later drafts of this memo. Marshall Rose of
Performance Systems International, Inc. converted the document into Performance Systems International, Inc. converted the document into
RFC 1212 [3] concise format. Anil Rijsinghani of DEC contributed RFC 1212 [RFC1212] concise format. Anil Rijsinghani of DEC
text that more adequately describes the TDR test. Thanks to Frank contributed text that more adequately describes the TDR test. Thanks
Kastenholz of Interlan and Louis Steinberg of IBM for their to Frank Kastenholz of Interlan and Louis Steinberg of IBM for their
experimentation. experimentation.
7. References 7. References
[1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Normative References
Describing SNMP Management Frameworks", RFC 2571, May 1999.
[2] Rose, M. and K. McCloghrie, "Structure and Identification of [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
Management Information for TCP/IP-based Internets", STD 16, J., Rose, M. and S. Waldbusser, "Structure of Management
RFC 1155, May 1990. Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
RFC 1212, March 1991. J., Rose, M. and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999.
[4] Rose, M., "A Convention for Defining Traps for use with the [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
SNMP", RFC 1215, March 1991. J., Rose, M. and S. Waldbusser, "Conformance Statements
for SMIv2", STD 58, RFC 2580, April 1999.
[5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, [IEEE802.3] IEEE, IEEE Std 802.3, 2000 Edition: "Information
M. and S. Waldbusser, "Structure of Management Information technology - Telecommunications and information exchange
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 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", (Adopted by ISO/IEC
and redesignated as ISO/IEC 8802-3:2000(E), 2000.
[6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, [P802.3ae] Law, D., Editor, Draft Supplement to IEEE Std. 802.3,
M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, IEEE Draft P802.3ae/D4.01, February 2002, work in
RFC 2579, April 1999. progress.
[7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
M. and S. Waldbusser, "Conformance Statements for SMIv2", STD MIB using SMIv2", RFC 2863, June 2000.
58, RFC 2580, April 1999.
[8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple [MAU-MIB] Flick, J., "Definitions of Managed Objects for IEEE
Network Management Protocol", STD 15, RFC 1157, May 1990. 802.3 Medium Attachment Units (MAUs) using SMIv2", work
in progress, draft-ietf-hubmib-mau-mib-v3-01.txt,
February 2002.
[9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, Non-Normative References
"Introduction to Community-based SNMPv2", RFC 1901, January
1996.
[10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An
Mappings for Version 2 of the Simple Network Management Protocol Architecture for Describing SNMP Management Frameworks",
(SNMPv2)", RFC 1906, January 1996. RFC 2571, April 1999.
[11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message [RFC1155] Rose, M. and K. McCloghrie, "Structure and
Processing and Dispatching for the Simple Network Management Identification of Management Information for
Protocol (SNMP)", RFC 2572, May 1999. TCP/IP-based Internets", STD 16, RFC 1155, May 1990.
[12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions",
for version 3 of the Simple Network Management Protocol STD 16, RFC 1212, March 1991.
(SNMPv3)", RFC 2574, May 1999.
[13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol [RFC1215] Rose, M., "A Convention for Defining Traps for use with
Operations for Version 2 of the Simple Network Management the SNMP", RFC 1215, March 1991.
Protocol (SNMPv2)", RFC 1905, January 1996.
[14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin,
2573, May 1999. "Simple Network Management Protocol", STD 15, RFC 1157,
May 1990.
[15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
Control Model (VACM) for the Simple Network Management Protocol "Introduction to Community-based SNMPv2", RFC 1901,
(SNMP)", RFC 2575, May 1999. January 1996.
[16] Case, J., Mundy, R., Partain, D. and B. Stewart, [RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Introduction to Version 3 of the Internet-Standard Network "Transport Mappings for Version 2 of the Simple Network
Management Framework", RFC 2570, April 1999. Management Protocol (SNMPv2)", RFC 1906, January 1996.
[17] IEEE, IEEE Std 802.3, 2000 Edition: "Information technology - [RFC2572] Case, J., Harrington, D., Presuhn R. and B. Wijnen,
Telecommunications and information exchange between systems - "Message Processing and Dispatching for the Simple
Local and metropolitan area networks - Specific requirements - Network Management Protocol (SNMP)", RFC 2572, May 1999.
Part 3: Carrier sense multiple access with collision detection
(CSMA/CD) access method and physical layer specifications",
(Adopted by ISO/IEC and redesignated as ISO/IEC 8802-3:2000(E),
2000.
[18] IEEE, IEEE Draft P802.3ae/D3.0: "Supplement to Carrier Sense [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model
Multiple Access with Collision Detection (CSMA/CD) Access (USM) for version 3 of the Simple Network Management
Method & Physical Layer Specifications - Media Access Control Protocol (SNMPv3)", RFC 2574, May 1999.
(MAC) Parameters, Physical Layer, and Management Parameters
for 10 Gb/s Operation", March 2001.
[19] Kastenholz, F., "IEEE 802.3 Layer Management Draft compatible [RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
MIB for TCP/IP Networks", electronic mail message to mib- "Protocol Operations for Version 2 of the Simple Network
wg@nnsc.nsf.net, 9 June 1989. Management Protocol (SNMPv2)", RFC 1905, January 1996.
[20] Cook, J., "Definitions of Managed Objects for Ethernet-Like [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3
Interface Types", RFC 1284, December 1991. Applications", RFC 2573, May 1999.
[21] Kastenholz, F., "Implementation Notes and Experience for The [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
Internet Ethernet MIB", RFC 1369, October 1992. Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", RFC 2575, May 1999.
[22] Kastenholz, F., "Definitions of Managed Objects for the [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart,
Ethernet-like Interface Types", RFC 1398, January 1993. "Introduction to Version 3 of the Internet-Standard
Network Management Framework", RFC 2570, April 1999.
[23] Kastenholz, F., "Definitions of Managed Objects for the [KASTEN] Kastenholz, F., "IEEE 802.3 Layer Management Draft
Ethernet-like Interface Types", STD 50, RFC 1643, July 1994. compatible MIB for TCP/IP Networks", electronic mail
message to mib-wg@nnsc.nsf.net, 9 June 1989.
[24] Kastenholz, F., "Definitions of Managed Objects for the [RFC1284] Cook, J., "Definitions of Managed Objects for
Ethernet-like Interface Types using SMIv2", RFC 1650, August 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. 1994.
[25] Flick, J. and J. Johnson, "Definitions of Managed Objects [RFC1650] Kastenholz, F., "Definitions of Managed Objects for the
for the Ethernet-like Interface Types", RFC 2358, June 1998. Ethernet-like Interface Types using SMIv2", RFC 1650,
August 1994.
[26] Flick, J., and J. Johnson, "Definitions of Managed Objects [RFC2358] Flick, J. and J. Johnson, "Definitions of Managed
for the Ethernet-like Interface Types", RFC 2665, August 1999. Objects for the Ethernet-like Interface Types", RFC
2358, June 1998.
[27] McCloghrie, K. and M. Rose, Editors, "Management Information [RFC2665] Flick, J., and J. Johnson, "Definitions of Managed
Base for Network Management of TCP/IP-based internets: MIB-II", Objects for the Ethernet-like Interface Types", RFC
STD 17, RFC 1213, March 1991. 2665, August 1999.
[28] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB [RFC1213] McCloghrie, K. and M. Rose, Editors, "Management
using SMIv2", RFC 2863, June 2000. Information Base for Network Management of TCP/IP-based
internets: MIB-II", STD 17, RFC 1213, March 1991.
[29] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirements Levels", BCP 14, RFC 2119, March 1997. Requirements Levels", BCP 14, RFC 2119, March 1997.
[30] Flick, J., Smith, A., deGraaf, K., Romascanu, D., McMaster, [RFC2666] Flick, J., "Definitions of Object Identifiers for
D., McCloghrie, K. and S. Roberts, "Definitions of Managed Identifying Ethernet Chip Sets", RFC 2666, August 1999.
Objects for IEEE 802.3 Medium Attachment Units (MAUs) using
SMIv2", work in progress, draft-ietf-hubmib-mau-mib-v3-00.txt,
June 2001.
[31] Flick, J., "Definitions of Object Identifiers for Identifying [ETHERWIS] Ayers, M., Flick, J., Heard, C. M., Lam, K., McDonald,
Ethernet Chip Sets", RFC 2666, August 1999. K., Norseth, K. C., and K. Tesink, "Definitions of
Managed Objects for the Ethernet WAN Interface
Sublayer", work in progress,
draft-ietf-hubmib-wis-mib-02.txt, February 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.
8. Security Considerations 8. Security Considerations
There are two management objects defined in this MIB that have a There are two management objects defined in this MIB that have a
MAX-ACCESS clause of read-write. Such objects may be considered MAX-ACCESS clause of read-write. Such objects may be considered
sensitive or vulnerable in some network environments. The support sensitive or vulnerable in some network environments. The support
for SET operations in a non-secure environment without proper for SET operations in a non-secure environment without proper
protection can have a negative effect on network operations. protection can have a negative effect on network operations.
There are a number of managed objects in this MIB that may be There are a number of managed objects in this MIB that may be
skipping to change at page 58, line 33 skipping to change at page 59, line 50
these objects when sending them over the network via SNMP. Not all these objects when sending them over the network via SNMP. Not all
versions of SNMP provide features for such a secure environment. versions of SNMP provide features for such a secure environment.
SNMPv1 by itself is such an insecure environment. Even if the SNMPv1 by itself is such an insecure environment. Even if the
network itself is secure (for example by using IPSec), even then, 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 there is no control as to who on the secure network is allowed to
access and GET (read) the objects in this MIB. access and GET (read) the objects in this MIB.
It is recommended that the implementors consider the security It is recommended that the implementors consider the security
features as provided by the SNMPv3 framework. Specifically, the use features as provided by the SNMPv3 framework. Specifically, the use
of the User-based Security Model RFC 2574 [12] and the View-based of the User-based Security Model RFC 2574 [RFC2574] and the View-
Access Control Model RFC 2575 [15] is recommended. based Access Control Model RFC 2575 [RFC2575] is recommended.
It is then a customer/user responsibility to ensure that the SNMP It is then a customer/user responsibility to ensure that the SNMP
entity giving access to an instance of this MIB, is properly entity giving access to an instance of this MIB, is properly
configured to give access to those objects only to those principals configured to give access to those objects only to those principals
(users) that have legitimate rights to access them. (users) that have legitimate rights to access them.
9. Author's Address 9. Author's Address
John Flick John Flick
Hewlett-Packard Company Hewlett-Packard Company
skipping to change at page 61, line 40 skipping to change at page 63, line 13
(11) Converted the dot3Tests, dot3Errors, and dot3ChipSets (11) Converted the dot3Tests, dot3Errors, and dot3ChipSets
OIDs to use the OBJECT-IDENTITY macro. OIDs to use the OBJECT-IDENTITY macro.
(12) Added to the list of registered dot3ChipSets. (12) Added to the list of registered dot3ChipSets.
(13) An intellectual property notice and copyright notice (13) An intellectual property notice and copyright notice
were added, as required by RFC 2026. were added, as required by RFC 2026.
B. Full Copyright Statement B. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/