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
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].
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.
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.
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
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
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.
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
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.
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.