As per Relevance of the word evolution, we have this rfc below:
Network Working Group K.
Request for Comments: 1573 Hughes LAN
Obsoletes: 1229 F.
Category: Standards Track FTP
January 1994
Evolution of the Interfaces Group of MIB-
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Table of
1. Introduction ............................................. 2
2. The SNMPv2 Network Management Framework .................. 2
2.1 Object Definitions ...................................... 3
3 Experience with the Interfaces Group ...................... 3
3.1 Areas of Clarification/Revision ......................... 3
3.1.1 Interface Numbering ................................... 4
3.1.2 Interface Sub-Layers .................................. 4
3.1.3 Virtual Circuits ...................................... 5
3.1.4 Bit, Character, and Fixed-Length Interfaces ........... 5
3.1.5 Counter Size .......................................... 5
3.1.6 Interface Speed ....................................... 6
3.1.7 Multicast/Broadcast Counters .......................... 6
3.1.8 Addition of New ifType values ......................... 6
3.1.9 ifSpecific ............................................ 6
3.2 Clarifications/Revisions ................................ 7
3.2.1 Interface Numbering ................................... 7
3.2.2 Interface Sub-Layers .................................. 8
3.2.3 Guidance on Defining Sub-layers ....................... 11
3.2.4 Virtual Circuits ...................................... 12
3.2.5 Bit, Character, and Fixed-Length Interfaces ........... 12
3.2.6 Counter Size .......................................... 14
3.2.7 Interface Speed ....................................... 16
3.2.8 Multicast/Broadcast Counters .......................... 16
3.2.9 Trap Enable ........................................... 17
3.2.10 Addition of New ifType values ........................ 17
3.2.11 InterfaceIndex Textual Convention .................... 17
3.2.12 IfAdminStatus and IfOperStatus ....................... 18
3.2.13 Traps ................................................ 19
3.2.14 ifSpecific ........................................... 20
McCloghrie & Kastenholz [Page 1]
RFC 1573 Interfaces Group Evolution January 1994
3.3 Media-Specific MIB Applicability ........................ 20
4. Overview ................................................. 21
5. IANAifType Definition .................................... 22
6. Interfaces Group Definitions ............................. 24
7. Acknowledgements ......................................... 53
8. References ............................................... 53
9. Security Considerations .................................. 55
10. Authors' Addresses....................................... 55
1.
This memo defines a portion of the Management Information Base (MIB
for use with network management protocols in the Internet community
In particular, it describes managed objects used for managing
Interfaces
This memo discusses the 'interfaces' group of MIB-II, especially
experience gained from the definition of numerous media-specific
modules for use in conjunction with the 'interfaces' group
managing various sub-layers beneath the internetwork-layer.
proposes clarifications to, and extensions of, the
issues within the current model used for the 'interfaces' group
This memo also includes a MIB module. As well as including new
definitions to support the architectural extensions, this MIB
also re-specifies the 'interfaces' group of MIB-II in a manner
is both compliant to the SNMPv2 SMI and semantically-identical to
existing SNMPv1-based definitions
2. The SNMPv2 Network Management
The SNMPv2 Network Management Framework consists of four
components. They are
o RFC 1442 which defines the SMI, the mechanisms used
describing and naming objects for the purpose of management
o STD 17, RFC 1213 defines MIB-II, the core set of
objects for the Internet suite of protocols
o RFC 1445 which defines the administrative and
architectural aspects of the framework
o RFC 1448 which defines the protocol used for network
to managed objects
The Framework permits new objects to be defined for the purpose
experimentation and evaluation
McCloghrie & Kastenholz [Page 2]
RFC 1573 Interfaces Group Evolution January 1994
2.1. Object
Managed objects are accessed via a virtual information store,
the Management Information Base or MIB. Objects in the MIB
defined using the subset of Abstract Syntax Notation One (ASN.1)
defined in the SMI. In particular, each object object type is
by an OBJECT IDENTIFIER, an administratively assigned name.
object type together with an object instance serves to
identify a specific instantiation of the object. For
convenience, we often use a textual string, termed the descriptor,
refer to the object type
3. Experience with the Interfaces
One of the strengths of internetwork-layer protocols such as IP [6]
is that they are designed to run over any network interface.
achieving this, IP considers any and all protocols it runs over as
single "network interface" layer. A similar view is taken by
internetwork-layer protocols. This concept is represented in MIB-
by the 'interfaces' group which defines a generic set of
objects such that any network interface can be managed in
interface-independent manner through these managed objects.
'interfaces' group provides the means for additional managed
specific to particular types of network interface (e.g., a
medium such as Ethernet) to be defined as extensions to
'interfaces' group for media-specific management. Since
standardization of MIB-II, many such media-specific MIB modules
been defined
Experience in defining these media-specific MIB modules has
that the model defined by MIB-II is too simplistic and/or static
some types of media-specific management. As a result, some of
media-specific MIB modules have assumed an evolution or loosening
the model. This memo is a proposal to document and standardize
evolution of the model and to fill in the gaps caused by
evolution
A previous effort to extend the interfaces group resulted in
publication of RFC 1229 [7]. As part of defining the evolution
the interfaces group, this memo applies that evolution to,
thereby incorporates, the RFC 1229 extensions
3.1. Areas of Clarification/
There are several areas for which experience indicates
clarification, revision, or extension of the model would be helpful
The next sections discuss these
McCloghrie & Kastenholz [Page 3]
RFC 1573 Interfaces Group Evolution January 1994
3.1.1. Interface
MIB-II defines an object, ifNumber, whose value represents
"The number of network interfaces (regardless of
current state) present on this system."
Each interface is identified by a unique value of the ifIndex object
and the description of ifIndex constrains its value as follows
"Its value ranges between 1 and the value of ifNumber.
value for each interface must remain constant at least
one re-initialization of the entity's network
system to the next re-initialization."
This constancy requirement on the value of ifIndex for a
interface is vital for efficient management. However, an
number of devices allow for the dynamic addition/removal of
interfaces. One example of this is a dynamic ability to
the use of SLIP/PPP over a character-oriented port. For such
additions/removals, the combination of the constancy requirement
the restriction that the value of ifIndex is less than ifNumber
problematic
3.1.2. Interface Sub-
Experience in defining media-specific management information
shown the need to distinguish between the multiple sub-layers
the internetwork-layer. In addition, there is a need to manage
sub-layers in devices (e.g., MAC-layer bridges) which are unaware
which, if any, internetwork protocols run over these sub-layers.
such, a model of having a single conceptual row in the
table (MIB-II's ifTable) represent a whole interface underneath
internetwork-layer, and having a single associated media-specific
module (referenced via the ifType object) is too simplistic.
further problem arises with the value of the ifType object which
enumerated values for each type of interface
Consider, for example, an interface with PPP running over an
link which uses a RS232-like connector. Each of these sub-layers
its own media-specific MIB module. If all of this is represented
a single conceptual row in the ifTable, then an enumerated value
ifType is needed for that specific combination which maps to
specific combination of media-specific MIBs. Furthermore, there
still a lack of a method to describe the relationship of all
sub-layers of the MIB stack
An associated problem is that of upward and downward multiplexing
McCloghrie & Kastenholz [Page 4]
RFC 1573 Interfaces Group Evolution January 1994
the sub-layers. An example of upward multiplexing is MLP (Multi
Link-Procedure) which provides load-sharing over several serial
by appearing as a single point-to-point link to the sub-layer(s
above. An example of downward multiplexing would be
instances of PPP, each framed within a separate X.25 virtual circuit
all of which run over one fractional T1 channel, concurrently
other uses of the T1 link. The current MIB structure does not
for these sorts of relationships to be described
3.1.3. Virtual
Several of the sub-layers for which media-specific MIB modules
been defined are connection oriented (e.g., Frame Relay, X.25).
Experience has shown that each effort to define such a MIB
revisits the question of whether separate conceptual rows in
ifTable are needed for each virtual circuit. Most, if not all,
these efforts to date have decided to have all virtual
reference a single conceptual row in the ifTable
3.1.4. Bit, Character, and Fixed-Length
RS-232 is an example of a character-oriented sub-layer over
(e.g., through use of PPP) IP datagrams can be sent. Due to
packet-based nature of many of the objects in the ifTable,
has shown that it is not appropriate to have a character-
sub-layer represented by a (whole) conceptual row in the ifTable
Experience has also shown that it is sometimes desirable to have
management information for bit-oriented interfaces, which
similarly difficult to represent by a (whole) conceptual row in
ifTable. For example, to manage the channels of a DS1 circuit,
only some of the channels are carrying packet-based data
A further complication is that some subnetwork technologies
data in fixed length transmission units. One example of such
technology is cell relay, and in particular Asynchronous
Mode (ATM), which transmits data in fixed-length cells.
such a interface as a packet-based interface produces
objects if the relationship between the number of packets and
number of octets in either direction is fixed by the size of
transmission unit (e.g., the size of a cell).
3.1.5. Counter
As the speed of network media increase, the minimum time in which
32 bit counter will wrap decreases. For example, on an Ethernet,
stream of back-to-back, full-size packets will cause ifInOctets
wrap in just over 57 minutes. For a T3 line, the minimum wrap-
McCloghrie & Kastenholz [Page 5]
RFC 1573 Interfaces Group Evolution January 1994
is just over 12 minutes. For FDDI, it will wrap in 5.7 minutes.
a 1-gigabit medium, the counter might wrap in as little as 34
seconds. Requiring that interfaces be polled frequently enough
to miss a counter wrap will be increasingly problematic
3.1.6. Interface
Network speeds are increasing. The range of ifSpeed is limited
reporting a maximum speed of (2**31)-1 bits/second, or
2.2Gbs. SONET defines an OC-48 interface, which is defined
operating at 48 times 51 Mbs, which is a speed in excess of 2.4gbits
Thus, ifSpeed will be of diminishing utility over the next
years
3.1.7. Multicast/Broadcast
The counters in the ifTable for packets addressed to a multicast
the broadcast address, are combined as counters of non-
packets. In contrast, the ifExtensions MIB [7] defines one set
counters for multicast, and a separate set for broadcast packets
With the separate counters, the original combined counters
redundant
3.1.8. Addition of New ifType
Over time new ifType enumerated values have been needed for
interface types. With the syntax of ifType being defined in a MIB
this requires the new MIB to be re-issued in order to define the
values. In the past, re-issuing of the MIB has occurred only
several years
3.1.9.
The original definition of the OBJECT IDENTIFIER value of
was not sufficently clear. As a result, different implementors
used it differently, and confusion has resulted.
implementations have the value of ifSpecific be the OBJECT
that defines the media-specific MIB, i.e., the "foo" of
foo OBJECT IDENTIFIER ::= { transmission xxx }
while others have it be the OBJECT IDENTIFIER of the table or
in the appropriate media-specific MIB (e.g. fooTable or fooEntry),
while still others have it be the OBJECT IDENTIFIER of the
object of the table's row, including instance identifier (e.g.,
fooIfIndex.ifIndex). A definition based on the latter would not
sufficient unless it also allowed for media-specific MIBs
include several tables, where each table has its own, different
McCloghrie & Kastenholz [Page 6]
RFC 1573 Interfaces Group Evolution January 1994
indexing
3.2. Clarifications/
The following clarifications and/or revisions are proposed
3.2.1. Interface
One solution to the interface numbering problem would be to
ifNumber to be the largest value of ifIndex, but the utility of
an object is questionable, and such a re-definition would
ifNumber to be deprecated. Thus, an improvement would be
deprecate ifNumber and not replace it. However, the deprecation
ifNumber would require a change to that portion of ifIndex'
definition which refers to ifNumber. So, since the definition
ifIndex must be changed anyway in order to solve the problem,
to ifNumber do not benefit the solution
The solution adopted in this memo is to delete the requirement
the value of ifIndex must be less than the value of ifNumber, and
retain ifNumber with its current definition. It could be argued
this is a change in the semantics of ifIndex; however, all
implementations conform to this new definition, and in the
of not requiring changes in existing implementations and in the
existing media-specific MIBs, it is proposed that this change
not require ifIndex to be deprecated
This solution also results in the possibility of "holes" in
ifTable (i.e., the ifIndex values of conceptual rows in the
are not necessarily contiguous), but SNMP's GetNext (and SNMPv2'
GetBulk) operation easily deals with such holes. The value
ifNumber still represents the number of conceptual rows,
increases/decreases as new interfaces are dynamically added/removed
The vital constancy requirement is met by requiring that after
interface is dynamically removed, its ifIndex value is not re-
(by a different dynamically added interface) until after
following re-initialization of the network management system.
avoids the need for a priori assignment of ifIndex values for
possible interfaces which might be added dynamically
The exact meaning of a "different" interface is hard to define,
there will be gray areas. One important criterion is that
management station, not noticing that an interface has gone away
another come into existence, should not be confused when
calculates the difference between the counter values retrieved
successive polls for a particular ifIndex value. However, any
definition in this document would likely to turn out to
inadequate. Instead, the following guidelines are offered to
McCloghrie & Kastenholz [Page 7]
RFC 1573 Interfaces Group Evolution January 1994
implementors to choose what "different" means in their
situation
A previously-unused value of ifIndex should be assigned to
dynamically added interface if
(1) the assignment of a previously-used ifIndex value to
interface could result in a discontinuity in the values
ifTable counters for that value of ifIndex; or
(2) an agent has no knowledge of whether the interface is
"same" or "different" from a previous interface incarnation
Because of the restriction of the value of ifIndex to be less
ifNumber, interfaces have been numbered with small integer values
This has led to the ability by humans to use the ifIndex values
(somewhat) user-friendly names for network interfaces (e.g.,
"interface number 3"). With the relaxation of the restriction on
value of ifIndex, there is now the possibility that ifIndex
could be assigned as very large numbers (e.g., memory addresses).
Such numbers would be much less user-friendly
Therefore, this memo recommends that ifIndex values still be
as (relatively) small integer values starting at 1, even though
values in use at any one time are not necessarily contiguous. (
that this makes remembering which values have been assigned easy
agents which dynamically add new interfaces.)
This proposed change introduces a new problem of its own
Previously, there usually was a simple, direct, mapping of
to the physical ports on systems. This mapping would be based on
ifIndex value. However, by removing the previous restrictions on
values allowed for ifIndex, along with the interface sub-
concept (see the following section), mapping from interfaces
physical ports becomes increasingly problematic
To address this issue, a new object, ifName, is added to the MIB
This object contains the device's name for the interface of which
relevant entry in the ifTable is a component. For example, if
router has an interface named wan1, which is composed of PPP
over an RS-232 port, the ifName objects for the corresponding PPP
RS-232 entries in the ifTable will contain the string "wan1".
3.2.2. Interface Sub-
One possible but not recommended solution to the problem
representing multiple sub-layers would be to retain the concept
one conceptual row for all the sub-layers of an interface and
McCloghrie & Kastenholz [Page 8]
RFC 1573 Interfaces Group Evolution January 1994
each media-specific MIB module identify its "superior"
"subordinate" sub-layers through OBJECT IDENTIFIER "pointers".
drawbacks of this scheme are: 1) the superior/subordinate
are contained in the media-specific MIB modules, and thus, a
could not learn the structure of an interface, without
multiple pointers in different MIB modules; this is overly
and only possible if the manager has knowledge of all the
media-specific MIB modules; 2) current MIB modules would all need
be retrofitted with these new "pointers"; 3) this scheme does
adequately address the problem of upward and downward multiplexing
and 4) enumerated values of ifType are needed for each combination
sub-layers
Another possible but not recommended scheme would be to retain
concept of one conceptual row for all the sub-layers of an
and have a new separate MIB table to identify the "superior"
"subordinate" sub-layers which contain OBJECT IDENTIFIER "pointers
to media-specific MIB module(s) for each sub-layer. Effectively,
conceptual row in the ifTable would represent each combination
sub-layers between the internetwork-layer and the wire. While
scheme has fewer drawbacks, it does not support
multiplexing, such as PPP over MLP; since MLP makes two (or more
serial lines appear to the layers above as a single
interface, PPP over MLP should appear to the internetwork-layer as
single interface. However, this scheme would result in two (or more
conceptual rows in the ifTable and the internetwork-layer would
over both of them. This scheme also requires enumerated values
ifType for each combination of sub-layers
The solution adopted in this memo is to have an individual
row in the ifTable to represent each sub-layer and have a
separate MIB table (the ifStackTable, see section 5 of this memo)
identify the "superior" and "subordinate" sub-layers through
"pointers" to the appropriate conceptual rows in the ifTable.
solution supports both upward and downward multiplexing. It
allows the IANAIfType to Media-Specific MIB mapping to identify
media-specific MIB module for each sub- layer. The new
(ifStackTable) need be referenced only to obtain information
layering. Enumerated values for ifType are required for each sub
layer only, not for combinations of them
However, this solution does require that the descriptions of
objects in the ifTable (specifically, ifType, ifPhysAddress
ifInUcastPkts, and ifOutUcastPkts) be generalized so as to apply
any sub-layer (rather than only to a sub-layer immediately
the network layer, as at present). It also requires that
objects (specifically, ifSpeed) need to have appropriate
identified for use when a generalized definition does not apply to
McCloghrie & Kastenholz [Page 9]
RFC 1573 Interfaces Group Evolution January 1994
particular sub-layer
In addition, this adopted solution makes no requirement that
device, in which a sub-layer is instrumented by a conceptual row
the ifTable, be aware of whether an internetwork protocol runs on
of (i.e., at some layer above) that sub-layer. In fact, the
of packets received on an interface are defined as counting
number "delivered to a higher-layer protocol". This meaning
"higher-layer" includes
(1) Delivery to a forwarding module which
packets/frames/octets and forwards them on at the
protocol layer. For example, for the purposes of
definition, the forwarding module of a MAC-layer bridge
considered as a "higher-layer" to the MAC-layer of each
on the bridge
(2) Delivery to a higher sub-layer within a interface stack.
example, for the purposes of this definition, if a PPP
operated directly over a serial interface, the PPP
would be considered the higher sub-layer to the
interface
(3) Delivery to a higher protocol layer which does not do
forwarding for sub-layers that are "at the top of"
interface stack. For example, for the purposes of
definition, the local IP module would be considered
higher layer to a SLIP serial interface
Similarly, for output, the counters of packets transmitted out
interface are defined as counting the number "that higher-
protocols requested to be transmitted". This meaning of "higher
layer" includes
(1) A forwarding module, at the same protocol layer,
transmits packets/frames/octets that were received on
different interface. For example, for the purposes of
definition, the forwarding module of a MAC-layer bridge
considered as a "higher-layer" to the MAC-layer of each
on the bridge
(2) The next higher sub-layer within an interface stack.
example, for the purposes of this definition, if a PPP
operated directly over a serial interface, the PPP
would be a "higher layer" to the serial interface
McCloghrie & Kastenholz [Page 10]
RFC 1573 Interfaces Group Evolution January 1994
(3) For sub-layers that are "at the top of" the interface stack
a higher element in the network protocol stack. For example
for the purposes of this definition, the local IP
would be considered the higher layer to an
interface
3.2.3. Guidance on Defining Sub-
The designer of a media-specific MIB must decide whether to
the interface into sub-layers, and if so, how to make the divisions
The following guidance is offered to assist the media-specific
designer in these decisions
In general, the number of entries in the ifTable should be kept
the minimum required for network management. In particular, a
of related interfaces should be treated as a single interface
one entry in the ifTable providing that
(1) None of the group of interfaces performs multiplexing for
other interface in the agent
(2) There is a meaningful and useful way for all of the ifTable'
information (e.g., the counters, and the status variables),
and all of the ifTable's capabilities (e.g., write access
ifAdminStatus), to apply to the group of interfaces as
whole
Under these circumstances, there should be one entry in the
for such a group of interfaces, and any internal structure
needs to be represented to network management should be captured in
MIB module specific to the particular type of interface
Note that application of bullet 2 above to the ifTable's
object requires that there is a meaningful media-specific MIB and
meaningful ifType value which apply to the group of interfaces as
whole. For example, it is not appropriate to treat an HDLC sub-
and an RS-232 sub-layer as a single ifTable entry when the media
specific MIBs and the ifType values for HDLC and RS-232 are
(rather than combined).
Note that the sub-layers of an interface on one device will
be different to the sub-layers of the interconnected interface
another device. A simple example of this is a frame-relay
interface which connects to a frameRelayService interface, where
DTE interface has a different ifType value and media-specific MIB
the DCE interface
Also note that a media-specific MIB may mandate that a
McCloghrie & Kastenholz [Page 11]
RFC 1573 Interfaces Group Evolution January 1994
ifTable counter does not apply and that its value must always be 0,
signifying that the applicable event can not and does not occur
that type of interface; for example, ifInMulticastPkts
ifOutMulticastPkts on an interface type which has no
capability. In other circumstances, an agent must not always
0 for any counter just because its implementation is incapable
detecting occurrences of the particular event; instead, it
return a noSuchName/noSuchObject error/exception when queried for
counter, even if this prevents the implementation from complying
the relevant MODULE-COMPLIANCE macro
These guidelines are just that - guidelines. The designer of
media-specific MIB is free to lay out the MIB in whatever
conformant manner is desired. However, in so doing, the media
specific MIB MUST completely specify the sub-layering model used
the MIB, and provide the assumptions, reasoning, and rationale
to develop that model
3.2.4. Virtual
This memo strongly recommends that connection-oriented sub-layers
not have a conceptual row in the ifTable for each virtual circuit
This avoids the proliferation of conceptual rows, especially
which have considerable redundant information. (Note, as
comparison, that connection-less sub-layers do not have
rows for each remote address.) There may, however, be
under which it is appropriate for a virtual circuit of a connection
oriented sub-layer to have its own conceptual row in the ifTable;
example of this might be PPP over an X.25 virtual circuit. The
in section 6 of this memo supports such circumstances
If a media-specific MIB wishes to assign an entry in the ifTable
each virtual circuit, the MIB designer must present the rationale
this decision in the media-specific MIB's specification
3.2.5. Bit, Character, and Fixed-Length
About half the objects in the ifTable are applicable to every type
interface: packet-oriented, character-oriented, and bit-oriented.
the other half, two are applicable to both character-oriented
packet-oriented interfaces, and the rest are applicable only
packet-oriented interfaces. Thus, while it is desirable
consistency to be able to represent any/all types of interfaces
the ifTable, it is not possible to implement the full ifTable
bit- and character-oriented sub-layers
One possible but not recommended solution to this problem would be
split the ifTable into two (or more) new MIB tables, one of
McCloghrie & Kastenholz [Page 12]
RFC 1573 Interfaces Group Evolution January 1994
would contain objects that are relevant only to packet-
interfaces (e.g., PPP), and another that may be used by
interfaces. This is highly undesirable since it would
changes in every agent implementing the ifTable (i.e., just
every existing SNMP agent).
The solution adopted in this memo builds upon the fact
compliance statements in SNMPv2 (in contrast to SNMPv1) refer
object groups, where object groups are explicitly defined by
the objects they contain. Thus, in SNMPv2, multiple
statements can be specified, one for all interfaces and
ones for specific types of interfaces. The separate
statements can be based on separate object groups, where the
group for all interfaces can contain only those objects from
ifTable which are appropriate for every type of interfaces.
this solution, every sub-layer can have its own conceptual row in
ifTable
Thus, section 6 of this memo contains definitions of the objects
the existing 'interfaces' group of MIB-II, in a manner which is
SNMPv2-compliant and semantically-equivalent to the existing MIB-
definitions. With equivalent semantics, and with the BER ("on
wire") encodings unchanged, these definitions retain the same
IDENTIFIER values as assigned by MIB-II. Thus, in general,
rewrite of existing agents which conform to MIB-II and
ifExtensions MIB is required
In addition, this memo defines several object groups for the
of defining which objects apply to which types of interface
(1) the ifGeneralGroup. This group contains those
applicable to all types of network interfaces,
bit-oriented interfaces
(2) the ifPacketGroup. This group contains those
applicable to packet-oriented network interfaces
(3) the ifFixedLengthGroup. This group contains the
applicable not only to character-oriented interfaces, such
RS-232, but also to those subnetwork technologies, such
cell-relay/ATM, which transmit data in fixed
transmission units. As well as the octet counters, there
also a few other counters (e.g., the error counters)
are useful for this type of interface, but are
defined as being packet-oriented. To accommodate this,
definitions of these counters are generalized to apply
character-oriented interfaces and fixed-length-
interfaces
McCloghrie & Kastenholz [Page 13]
RFC 1573 Interfaces Group Evolution January 1994
It should be noted that the octet counters in the ifTable
octet counts for unicast and non-unicast packets into a single
counter per direction (received/transmitted). Thus, with the
definition of fixed-length-transmission interfaces, where
interfaces which support non-unicast packets, separate counts
unicast and multicast/broadcast transmissions can only be
in a media-specific MIB module
3.2.6. Counter
Two approaches to addressing the shrinking minimum counter-wrap
problem were evaluated. Counters could be scaled, for example
ifInOctets could be changed to count received octets in, e.g., 1024
byte blocks. Alternatively, the size of the counter could
increased
Scaling the counters was rejected. While it provides
performance at high count rates, at low rates it suffers. If
is little traffic on an interface, there might be a
interval before enough counts occur to cause a counter to
incremented. Traffic would then appear to be very bursty, leading
incorrect conclusions of the network's performance
The alternative, which this memo adopts, is to provide expanded, 64
bit, counters. These counters are provided in new "high capacity
groups
The old, 32-bit, counters have not been deprecated. The 64-
counters are to be used only when the 32-bit counters do not
enough capacity; that is, the 32 bit counters could wrap too fast
For interfaces that operate at 20,000,000 (20 million) bits
second or less, 32-bit byte and packet counters MUST be used.
interfaces that operate faster than 20,000,000 bits/second,
slower than 650,000,000 bits/second, 32-bit packet counters MUST
used and 64-bit octet counters MUST be used. For interfaces
operate at 650,000,000 bits/second or faster, both 64-bit
counters AND 64-bit octet counters MUST be used
These speed steps were chosen as reasonable compromises based on
following
(1) The cost of maintaining 64-bit counters is relatively high
so minimizing the number of agents which must support them
desirable. Common interfaces (such as Ethernet) should
require them
McCloghrie & Kastenholz [Page 14]
RFC 1573 Interfaces Group Evolution January 1994
(2) 64-bit counters are a new feature, introduced in SNMPv2.
is reasonable to expect that support for them will be
for the immediate future. Thus, we wish to limit them to
few systems as possible. This, in effect, means that 64-
counters should be limited to higher speed interfaces
Ethernet (10,000,000 bps) and Token Ring (16,000,000 bps)
fairly wide-spread so it seems reasonable to not require 64-
bit counters for these interfaces
(3) The 32-bit octet counters will wrap in the following times
for the following interfaces (when transmitting maximum-
packets back-to-back):
- Ethernet: 57 minutes
- 16 megabit Token Ring: 36 minutes
- A US T3 line (45 megabits): 12 minutes
- FDDI: 5.7
(4) The 32-bit packet counters wraps in about 57 minutes
64-byte packets are transmitted back-to-back on a 650,000,000
bit/second link
As an aside, a 1-terabit (1,000 gigabits) link will cause
64 bit octet counter to wrap in just under 5 years
Conversely, an 81,000,000 terabit/second link is required
cause a 64-bit counter to wrap in 30 minutes. We
that, while technology rapidly marches forward, this
speed will not be achieved for at least several years
leaving sufficient time to evaluate the introduction of 96
bit counters
When 64-bit counters are in use, the 32-bit counters MUST still
available. They will report the low 32-bits of the associated 64-
count (e.g., ifInOctets will report the least significant 32 bits
ifHCInOctets). This enhances inter-operability with
implementations at a very minimal cost to agents
The new "high capacity" groups are
(1) the ifHCFixedLengthGroup for character-oriented/fixed-
interfaces, and the ifHCPacketGroup for packet-
interfaces; both of these groups include 64 bit counters
octets,
McCloghrie & Kastenholz [Page 15]
RFC 1573 Interfaces Group Evolution January 1994
(2) the ifVHCPacketGroup for packet-based interfaces; this
includes 64 bit counters for octets and packets
3.2.7. Interface
In order to deal with increasing interface speeds, we have added
ifHighSpeed object
This object reports the speed of the interface in 1,000,000 (1
million) bits/second units. Thus, the true speed of the
will be the value reported by this object, plus or minus 500,000
bits/second
Other alternatives considered were
(1) Making the interface speed a 64-bit gauge. This was
since the current SMI does not allow such a syntax
Furthermore, even if 64-bit gauges were available, their
would require additional complexity in agents due to
increased requirement for 64-bit operations
(2) We also considered making "high-32 bit" and "low-32-bit
objects which, when combined, would be a 64-bit value.
simply seemed overly complex for what we are trying to do
Furthermore, a full 64-bits of precision does not
necessary. The value of ifHighSpeed will be the only
of interface speed for interfaces that are faster
4,294,967,295 bits per second. At this speed,
granularity of ifHighSpeed will be 1,000,000 bits per second
thus the error will be 1/4294, or about 0.02%. This
reasonable
(3) Adding a "scale" object, which would define the units
ifSpeed's value is
This would require two additional objects; one for
scaling object, and one to replace the current ifSpeed.
later object is required since the semantics of ifSpeed
be significantly altered, and manager stations which do
understand the new semantics would be confused
3.2.8. Multicast/Broadcast
To avoid the redundancy of counting all non-unicast packets as
as having individual multicast and broadcast packet counters,
deprecate the use of the non-unicast counters, which can be
McCloghrie & Kastenholz [Page 16]
RFC 1573 Interfaces Group Evolution January 1994
from the values of the others
For the output broadcast and multicast counters defined in RFC 1229,
their definitions varied slightly from the packet counters in
ifTable, in that they did not count errors/discarded packets.
align the definitions better, the old counters are deprecated
replaced by new definitions. Counters with 64 bits of range are
needed, as explained above
3.2.9. Trap
In the multi-layer interface model, each sub-layer for which there
an entry in the ifTable can generate linkUp/Down Traps.
interface state changes would tend to propagate through the
(from top to bottom, or bottom to top), it is likely that
traps would be generated for each linkUp/Down occurrence
It is desirable to provide a mechanism for manager stations
control the generation of these traps. To this end,
ifLinkUpDownTrapEnable object has been added. This object
managers to limit generation of traps to just the sub-layers
interest
The default setting should limit the number of traps generated to
per interface per linkUp/Down event. Furthermore, it seems that
conditions that cause these state changes that are of most
to network managers occur at the lowest level of an interface stack
Therefore we specify that by default, only the lowest sub-layer
the interface generate traps
3.2.10. Addition of New ifType
The syntax of ifType is changed to be a textual convention, such
the enumerated integer values are now defined in the
convention, IANAifType, which can be re-specified (with
values) without issuing a new version of this document. The
Assigned Number Authority (IANA) is responsible for the assignment
all Internet numbers, including various SNMP-related numbers,
specifically, new ifType values. Thus, this document defines two
modules: one to define the MIB for the 'interfaces' group, and
second to define the first version of the IANAifType
convention. The latter will be periodically re-issued by the IANA
3.2.11. InterfaceIndex Textual
A new textual convention, InterfaceIndex, has been defined.
textual convention "contains" all of the semantics of the
object. This allows other mib modules to easily import the
McCloghrie & Kastenholz [Page 17]
RFC 1573 Interfaces Group Evolution January 1994
of ifIndex
3.2.12. IfAdminStatus and
A new state has been added to ifOperStatus: dormant. This
indicates that the relevant interface is not actually in a
to pass packets (i.e., up) but is in a "pending" state, waiting
some external event. For "on-demand" interfaces, this new
identifies the situation where the interface is waiting for events
place it in the up state. Examples of such events might be
(1) having packets to transmit before establishing a
to a remote system
(2) having a remote system establish a connection to
interface (e.g., dialing up to a slip-server).
The down state now has two meanings, depending on the value
ifAdminStatus
(1) If ifAdminStatus is not down and ifOperStatus is down, then
fault condition is presumed to exist on the interface
(2) If ifAdminStatus is down, then ifOperStatus will
also be down, i.e., there is not (necessarily) a
condition on the interface
Note that when ifAdminStatus transitions to down, ifOperStatus
normally also transition to down. In this situation, it is
that ifOperStatus's transition will not occur immediately, but
after a small time lag to complete certain operations before
"down"; for example, it might need to finish transmitting a packet
If a manager station finds that ifAdminStatus is down
ifOperStatus is not down for a particular interface, the
station should wait a short while and check again. If the
still exists only then should it raise an error indication
Naturally, it should also ensure that ifLastChange has not
during this interval
Whenever an interface table entry is created (usually as a result
system initialization), the relevant instance of ifAdminStatus is
to down, and presumably ifOperStatus will also be down
An interface may be enabled in two ways: either as a result
explicit management action (e.g., setting ifAdminStatus to up) or
a result of the managed system's initialization process.
ifAdminStatus changes to the up state, the related
should do one of the following
McCloghrie & Kastenholz [Page 18]
RFC 1573 Interfaces Group Evolution January 1994
(1) Change to the up state if and only if the interface is
to send and receive packets
(2) Change to the dormant state if and only if the interface
found to be operable, but the interface is waiting for other
external, events to occur before it can transmit or
packets. Presumably when the expected events occur,
interface will then transition to the up state
(3) Remain in the down state if an error or other fault
is detected on the interface
(4) Change to the unknown state if, for some reason, the state
the interface can not be ascertained
(5) Change to the testing state if some test(s) must be
on the interface. Presumably after completion of the test
the interface's state will change to up, dormant, or down,
appropriate
3.2.13.
The exact definition of when linkUp and linkDown traps are generated
has been changed to reflect the changes to ifAdminStatus
ifOperStatus
LinkUp and linkDown traps are generated just after
leaves, or just before it enters, the down state, respectively.
wording of the conditions under which a linkDown trap is
was explicitly chosen to allow a node with only one interface
transmit the linkDown trap before that interface goes down
Operational experience seems to indicate that manager stations
most concerned with an interface being in the down state and the
that this state may indicate a failure. It seemed most useful
instrument either transitions into/out of the up state or the
state
Instrumenting transitions into or out of the up state has
drawback that an on-demand interface might have many
between up and dormant, leading to many linkUp traps and no
traps. Furthermore, if a node's only interface is the on-
interface, then a transition to dormant will entail generation of
trap, necessitating bringing the link to the up state (and a
trap)!!
On the other hand, instrumenting transitions into or out of the
state has the advantages
McCloghrie & Kastenholz [Page 19]
RFC 1573 Interfaces Group Evolution January 1994
(1) A transition into the down state will occur when an error
detected on an interface. Error conditions are presumably
great interest to network managers
(2) Departing the down state generally indicates that
interface is going to either up or dormant, both of which
considered "healthy" states
Furthermore, it is believed that generarating traps on
into or out of the down state is generally consistent with
usage and interpretation of these traps by manager stations
Therefore, this memo defines that it is the transitions into/out
the down state which generate traps
Obviously, if a failure condition is present on a node with a
interface, the linkDown trap will probably not be
transmitted since the interface through which it must be
has failed
3.2.14.
The current definition of ifSpecific is not explicit enough.
only definition that can both be made explicit and can cover all
useful situations (see section 3.1.9) is to have ifSpecific be
most general value for the media-specific MIB module (the
example given section in 3.1.9). This effectively makes it
because it contains no more information than is provided by ifType
For this reason, ifSpecific has been deprecated
3.3. Media-Specific MIB
The exact use and semantics of many objects in this MIB are open
some interpretation. This is a result of the generic nature of
MIB. It is not always possible to come up with specific
unambiguous, text that covers all cases and yet preserve the
nature of the MIB
Therefore, it is incumbent upon a media-specific MIB designer to
wherever necessary, clarify the use of the objects in this MIB
respect to the media-specific MIB
Specific areas of clarification include
Layering
The media-specific MIB designer MUST completely
unambiguously specify the layering model used.
individual sub-layer must be identified
McCloghrie & Kastenholz [Page 20]
RFC 1573 Interfaces Group Evolution January 1994
Virtual
The media-specific MIB designer MUST specify whether
circuits are assigned entries in the ifTable or not. If
are, compelling rationale must be presented
The media-specific MIB designer MUST specify
applicability of the ifTestTable
The media-specific MIB designer MUST specify
applicability of the ifRcvAddressTable
For each of the ifType values to which the media-specific
applies, it must specify the mapping of ifType values
media-specific MIB module(s) and instances of MIB
within those modules
However, wherever this interface MIB is specific in the semantics
DESCRIPTION, or applicability of objects, the media-specific
designer MUST NOT change said semantics, DESCRIPTION,
applicability
4.
This MIB consists of 5 tables
This table is the ifTable from MIB-II
This table contains objects that have been added to
Interface MIB as a result of the Interface Evolution effort
or replacements for objects of the original, MIB-II,
that were deprecated because the semantics of said
have significantly changed. This table also contains
that were previously in the ifExtnsTable
This table contains objects that define the
among the sub-layers of an interface
This table contains objects that are used to perform tests
interfaces. This table is a generic table. The designers
media-specific MIBs must define exactly how this
applies to their specific MIB
McCloghrie & Kastenholz [Page 21]
RFC 1573 Interfaces Group Evolution January 1994
This table replaces the interface test table defined
RFC1229 [7]. The significant change is the replacement
the ifExtnsTestCommunity (and ifExtnsTestContext which
also have been required for SNMPv2) and
objects, by the new ifTestId, ifTestStatus, and
objects
This table contains objects that are used to define
media-level addresses which this interface will receive
This table is a generic table. The designers of media
specific MIBs must define exactly how this table applies
their specific MIB
5. IANAifType
IANAifType-MIB DEFINITIONS ::=
MODULE-IDENTITY, OBJECT-TYPE FROM SNMPv2-
TEXTUAL-CONVENTION FROM SNMPv2-TC
ianaifType MODULE-
LAST-UPDATED "9311082155Z
ORGANIZATION "IANA
CONTACT-
" Internet Assigned Numbers
Postal: USC/Information Sciences
4676 Admiralty Way, Marina del Rey, CA 90292
Tel: +1 310 822 1511
E-Mail: iana@isi.edu
"The MIB module which defines the IANAifType
convention, and thus the enumerated values of
ifType object defined in MIB-II's ifTable."
::= { mib-2 30 }
IANAifType ::= TEXTUAL-
STATUS
"This data type is used as the syntax of the
object in the (updated) definition of MIB-II'
ifTable
McCloghrie & Kastenholz [Page 22]
RFC 1573 Interfaces Group Evolution January 1994
The definition of this textual convention with
addition of newly assigned values is
periodically by the IANA, in either the
Numbers RFC, or some derivative of it specific
Internet Network Management number assignments. (
latest arrangements can be obtained by contacting
IANA.)
Requests for new values should be made to IANA
email (iana@isi.edu).
The relationship between the assignment of
values and of OIDs to particular media-specific
is solely the purview of IANA and is subject to
without notice. Quite often, a media-specific MIB'
OID-subtree assignment within MIB-II's 'transmission
subtree will be the same as its ifType value
However, in some circumstances this will not be
case, and implementors must not pre-assume
specific relationship between ifType values
transmission subtree OIDs."
SYNTAX INTEGER {
other(1), -- none of the
regular1822(2),
hdh1822(3),
ddnX25(4),
rfc877x25(5),
ethernetCsmacd(6),
iso88023Csmacd(7),
iso88024TokenBus(8),
iso88025TokenRing(9),
iso88026Man(10),
starLan(11),
proteon10Mbit(12),
proteon80Mbit(13),
hyperchannel(14),
fddi(15),
lapb(16),
sdlc(17),
ds1(18), -- DS1/E1 (RFC 1406)
e1(19), --
basicISDN(20),
primaryISDN(21),
propPointToPointSerial(22), -- proprietary
ppp(23),
softwareLoopback(24),
eon(25), -- CLNP over IP (RFC 1070)
ethernet3Mbit(26),
McCloghrie & Kastenholz [Page 23]
RFC 1573 Interfaces Group Evolution January 1994
nsip(27), -- XNS over
slip(28), -- generic
ultra(29), -- ULTRA
ds3(30), -- T-3
sip(31), --
frameRelay(32), -- DTE
rs232(33),
para(34), -- parallel-
arcnet(35), --
arcnetPlus(36), -- arcnet
atm(37), -- ATM
miox25(38),
sonet(39), -- SONET or
x25ple(40),
iso88022llc(41),
localTalk(42),
smdsDxi(43),
frameRelayService(44), -- Frame relay
v35(45),
hssi(46),
hippi(47),
modem(48), -- Generic
aal5(49), -- AAL5 over
sonetPath(50),
sonetVT(51),
smdsIcip(52), -- SMDS InterCarrier
propVirtual(53), -- proprietary virtual/
propMultiplexor(54) -- proprietary
}
6. Interfaces Group
IF-MIB DEFINITIONS ::=
MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32,
Integer32, TimeTicks
NOTIFICATION-TYPE FROM SNMPv2-
TEXTUAL-CONVENTION, DisplayString
PhysAddress, TruthValue, RowStatus
AutonomousType, TestAndIncr FROM SNMPv2-
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-
IANAifType FROM IANAifType-
interfaces FROM RFC-1213;
McCloghrie & Kastenholz [Page 24]
RFC 1573 Interfaces Group Evolution January 1994
ifMIB MODULE-
LAST-UPDATED "9311082155Z
ORGANIZATION "IETF Interfaces MIB Working Group
CONTACT-
" Keith
Postal: Hughes LAN
1225 Charleston Road, Mountain View, CA 94043
Tel: +1 415 966 7934
E-Mail: kzm@hls.
Frank
Postal: FTP
2 High Street, North Andover, MA 01845
Tel: +1 508 685 4000
E-Mail: kasten@ftp.com
"The MIB module to describe generic objects
network interface sub-layers. This MIB is an
version of MIB-II's ifTable, and incorporates
extensions defined in RFC 1229."
::= { mib-2 31 }
ifMIBObjects OBJECT IDENTIFIER ::= { ifMIB 1 }
-- OwnerString has the same semantics as used in RFC 1271
OwnerString ::= TEXTUAL-
DISPLAY-HINT "255a
STATUS
"This data type is used to model an
assigned name of the owner of a resource.
information is taken from the NVT ASCII character set
It is suggested that this name contain one or more
the following: ASCII form of the manager station'
transport address, management station name (e.g.,
domain name), network management personnel's name
location, or phone number. In some cases the
itself will be the owner of an entry. In these cases
this string shall be set to a string starting
'agent'."
SYNTAX OCTET STRING (SIZE(0..255))
McCloghrie & Kastenholz [Page 25]
RFC 1573 Interfaces Group Evolution January 1994
-- InterfaceIndex contains the semantics of ifIndex
-- should be used for any objects defined on other
-- modules that need these semantics
InterfaceIndex ::= TEXTUAL-
DISPLAY-HINT "d
STATUS
"A unique value, greater than zero, for each
or interface sub-layer in the managed system. It
recommended that values are assigned
starting from 1. The value for each interface sub
layer must remain constant at least from one re
initialization of the entity's network
system to the next re-initialization."
SYNTAX Integer32
ifNumber OBJECT-
SYNTAX Integer32
MAX-ACCESS read-
STATUS
"The number of network interfaces (regardless of
current state) present on this system."
::= { interfaces 1 }
-- the Interfaces
-- The Interfaces table contains information on the entity'
-- interfaces. Each sub-layer below the internetwork-
-- of a network interface is considered to be an interface
ifTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS
"A list of interface entries. The number of
is given by the value of ifNumber."
::= { interfaces 2 }
ifEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"An entry containing management information
McCloghrie & Kastenholz [Page 26]
RFC 1573 Interfaces Group Evolution January 1994
to a particular interface."
INDEX { ifIndex }
::= { ifTable 1 }
IfEntry ::=
SEQUENCE {
ifIndex InterfaceIndex
ifDescr DisplayString
ifType IANAifType
ifMtu Integer32,
ifSpeed Gauge32,
ifPhysAddress PhysAddress
ifAdminStatus INTEGER
ifOperStatus INTEGER
ifLastChange TimeTicks
ifInOctets Counter32,
ifInUcastPkts Counter32,
ifInNUcastPkts Counter32, --
ifInDiscards Counter32,
ifInErrors Counter32,
ifInUnknownProtos Counter32,
ifOutOctets Counter32,
ifOutUcastPkts Counter32,
ifOutNUcastPkts Counter32, --
ifOutDiscards Counter32,
ifOutErrors Counter32,
ifOutQLen Gauge32, --
ifSpecific OBJECT IDENTIFIER --
}
ifIndex OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"A unique value, greater than zero, for
interface. It is recommended that values are
contiguously starting from 1. The value for
interface sub-layer must remain constant at least
one re-initialization of the entity's
management system to the next re-initialization."
::= { ifEntry 1 }
ifDescr OBJECT-
SYNTAX DisplayString (SIZE (0..255))
MAX-ACCESS read-
STATUS
McCloghrie & Kastenholz [Page 27]
RFC 1573 Interfaces Group Evolution January 1994
"A textual string containing information about
interface. This string should include the name of
manufacturer, the product name and the version of
interface hardware/software."
::= { ifEntry 2 }
ifType OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The type of interface. Additional values for
are assigned by the Internet Assigned
Authority (IANA), through updating the syntax of
IANAifType textual convention."
::= { ifEntry 3 }
ifMtu OBJECT-
SYNTAX Integer32
MAX-ACCESS read-
STATUS
"The size of the largest packet which can
sent/received on the interface, specified in octets
For interfaces that are used for transmitting
datagrams, this is the size of the largest
datagram that can be sent on the interface."
::= { ifEntry 4 }
ifSpeed OBJECT-
SYNTAX Gauge32
MAX-ACCESS read-
STATUS
"An estimate of the interface's current bandwidth
bits per second. For interfaces which do not vary
bandwidth or for those where no accurate
can be made, this object should contain the
bandwidth. If the bandwidth of the interface
greater than the maximum value reportable by
object then this object should report its
value (4,294,967,295) and ifHighSpeed must be used
report the interace's speed. For a sub-layer
has no concept of bandwidth, this object should
zero."
::= { ifEntry 5 }
McCloghrie & Kastenholz [Page 28]
RFC 1573 Interfaces Group Evolution January 1994
ifPhysAddress OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The interface's address at its protocol sub-layer
The interface's media-specific MIB must define the
and byte ordering and format of the value contained
this object. For interfaces which do not have such
address (e.g., a serial line), this object
contain an octet string of zero length."
::= { ifEntry 6 }
ifAdminStatus OBJECT-
SYNTAX INTEGER {
up(1), -- ready to pass
down(2),
testing(3) -- in some test
}
MAX-ACCESS read-
STATUS
"The desired state of the interface. The testing(3)
state indicates that no operational packets can
passed. When a managed system initializes,
interfaces start with ifAdminStatus in the down(2)
state. As a result of either explicit
action or per configuration information retained
the managed system, ifAdminStatus is then changed
either the up(1) or testing(3) states (or remains
the down(2) state)."
::= { ifEntry 7 }
ifOperStatus OBJECT-
SYNTAX INTEGER {
up(1), -- ready to pass
down(2),
testing(3), -- in some test
unknown(4), -- status can not be
-- for some reason
dormant(5)
}
MAX-ACCESS read-
STATUS
"The current operational state of the interface.
testing(3) state indicates that no operational
can be passed. If ifAdminStatus is down(2)
McCloghrie & Kastenholz [Page 29]
RFC 1573 Interfaces Group Evolution January 1994
ifOperStatus should be down(2). If ifAdminStatus
changed to up(1) then ifOperStatus should change
up(1) if the interface is ready to transmit
receive ne