doc: Add RFC documents

1 files changed, 3867 insertions, 0 deletions

diff --git a/doc/rfc/rfc2863.txt b/doc/rfc/rfc2863.txt
new file mode 100644
index 0000000..f2aef10
--- /dev/null
+++ b/doc/rfc/rfc2863.txt
@@ -0,0 +1,3867 @@
+
+
+
+
+
+
+Network Working Group                                      K. McCloghrie
+Request for Comments: 2863                                 Cisco Systems
+Obsoletes: 2233                                            F. Kastenholz
+Category: Standards Track                                 Argon Networks
+                                                               June 2000
+
+
+                        The Interfaces Group MIB
+
+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 (2000).  All Rights Reserved.
+
+Table of Contents
+
+   1 Introduction .................................................    2
+   2 The SNMP Network Management Framework ........................    2
+   3 Experience with the Interfaces Group .........................    3
+   3.1 Clarifications/Revisions ...................................    4
+   3.1.1 Interface Sub-Layers .....................................    4
+   3.1.2 Guidance on Defining Sub-layers ..........................    7
+   3.1.3 Virtual Circuits .........................................    8
+   3.1.4 Bit, Character, and Fixed-Length Interfaces ..............    8
+   3.1.5 Interface Numbering ......................................   10
+   3.1.6 Counter Size .............................................   14
+   3.1.7 Interface Speed ..........................................   16
+   3.1.8 Multicast/Broadcast Counters .............................   17
+   3.1.9 Trap Enable ..............................................   17
+   3.1.10 Addition of New ifType values ...........................   18
+   3.1.11 InterfaceIndex Textual Convention .......................   18
+   3.1.12 New states for IfOperStatus .............................   18
+   3.1.13 IfAdminStatus and IfOperStatus ..........................   19
+   3.1.14 IfOperStatus in an Interface Stack ......................   21
+   3.1.15 Traps ...................................................   21
+   3.1.16 ifSpecific ..............................................   23
+   3.1.17 Creation/Deletion of Interfaces .........................   23
+   3.1.18 All Values Must be Known ................................   24
+   4 Media-Specific MIB Applicability .............................   24
+   5 Overview .....................................................   25
+   6 Interfaces Group Definitions .................................   26
+
+
+
+McCloghrie & Kastenholz     Standards Track                     [Page 1]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+   7 Acknowledgements .............................................   64
+   8 References ...................................................   64
+   9 Security Considerations ......................................   66
+   10 Authors' Addresses ..........................................   67
+   11 Changes from RFC 2233 .......................................   67
+   12 Notice on Intellectual Property .............................   68
+   13 Full Copyright Statement ....................................   69
+
+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 describes managed objects used for managing Network
+   Interfaces.  This memo discusses the 'interfaces' group of MIB-II
+   [17], especially the experience gained from the definition of
+   numerous media-specific MIB modules for use in conjunction with the '
+   interfaces' group for managing various sub-layers beneath the
+   internetwork-layer.  It specifies clarifications to, and extensions
+   of, the architectural issues within the MIB-II model of the '
+   interfaces' group.  This memo obsoletes RFC 2233, the previous
+   version of the Interfaces Group MIB.
+
+   The key words "MUST" and "MUST NOT" in this document are to be
+   interpreted as described in RFC 2119 [16].
+
+2.  The SNMP Network Management Framework
+
+   The SNMP Management Framework presently consists of five major
+   components:
+
+      o  An overall architecture, described in RFC 2571 [1].
+
+      o  Mechanisms for describing and naming objects and events for the
+         purpose of management.  The first version of this Structure of
+         Management Information (SMI) is called SMIv1 and described in
+         STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4].
+         The second version, called SMIv2, is described in STD 58, which
+         consists of RFC 2578 [5], RFC 2579 [6] and RFC 2580 [7].
+
+      o  Message protocols for transferring management information.  The
+         first version of the SNMP message protocol is called SNMPv1 and
+         described in STD 15, RFC 1157 [8].  A second version of the
+         SNMP message protocol, which is not an Internet standards track
+         protocol, is called SNMPv2c and described in RFC 1901 [9] and
+         RFC 1906 [10].  The third version of the message protocol is
+         called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and
+         RFC 2574 [12].
+
+
+
+
+McCloghrie & Kastenholz     Standards Track                     [Page 2]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+      o  Protocol operations for accessing management information.  The
+         first set of protocol operations and associated PDU formats is
+         described in STD 15, RFC 1157 [8].  A second set of protocol
+         operations and associated PDU formats is described in RFC 1905
+         [13].
+
+      o  A set of fundamental applications described in RFC 2573 [14]
+         and the view-based access control mechanism described in RFC
+         2575 [15].
+
+   A more detailed introduction to the current SNMP Management Framework
+   can be found in RFC 2570 [22].
+
+   Managed objects are accessed via a virtual information store, termed
+   the Management Information Base or MIB.  Objects in the MIB are
+   defined using the mechanisms defined in the SMI.
+
+   This memo specifies a MIB module that is compliant to the SMIv2.  A
+   MIB conforming to the SMIv1 can be produced through the appropriate
+   translations.  The resulting translated MIB must be semantically
+   equivalent, except where objects or events are omitted because no
+   translation is possible (e.g., use of Counter64).  Some machine
+   readable information in SMIv2 will be converted into textual
+   descriptions in SMIv1 during the translation process.  However, this
+   loss of machine readable information is not considered to change the
+   semantics of the MIB.
+
+3.  Experience with the Interfaces Group
+
+   One of the strengths of internetwork-layer protocols such as IP [18]
+   is that they are designed to run over any network interface.  In
+   achieving this, IP considers any and all protocols it runs over as a
+   single "network interface" layer.  A similar view is taken by other
+   internetwork-layer protocols.  This concept is represented in MIB-II
+   by the 'interfaces' group which defines a generic set of managed
+   objects such that any network interface can be managed in an
+   interface-independent manner through these managed objects.  The '
+   interfaces' group provides the means for additional managed objects
+   specific to particular types of network interface (e.g., a specific
+   medium such as Ethernet) to be defined as extensions to the '
+   interfaces' group for media-specific management.  Since the
+   standardization of MIB-II, many such media-specific MIB modules have
+   been defined.
+
+   Experience in defining these media-specific MIB modules has shown
+   that the model defined by MIB-II is too simplistic and/or static for
+   some types of media-specific management.  As a result, some of these
+   media-specific MIB modules assume an evolution or loosening of the
+
+
+
+McCloghrie & Kastenholz     Standards Track                     [Page 3]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+   model.  This memo documents and standardizes that evolution of the
+   model and fills in the gaps caused by that evolution.  This memo also
+   incorporates the interfaces group extensions documented in RFC 1229
+   [19].
+
+3.1.  Clarifications/Revisions
+
+   There are several areas for which experience has indicated that
+   clarification, revision, or extension of the model would be helpful.
+   The following sections discuss the changes in the interfaces group
+   adopted by this memo in each of these areas.
+
+   In some sections, one or more paragraphs contain discussion of
+   rejected alternatives to the model adopted in this memo.  Readers not
+   familiar with the MIB-II model and not interested in the rationale
+   behind the new model may want to skip these paragraphs.
+
+3.1.1.  Interface Sub-Layers
+
+   Experience in defining media-specific management information has
+   shown the need to distinguish between the multiple sub-layers beneath
+   the internetwork-layer.  In addition, there is a need to manage these
+   sub-layers in devices (e.g., MAC-layer bridges) which are unaware of
+   which, if any, internetwork protocols run over these sub-layers.  As
+   such, a model of having a single conceptual row in the interfaces
+   table (MIB-II's ifTable) represent a whole interface underneath the
+   internetwork-layer, and having a single associated media-specific MIB
+   module (referenced via the ifType object) is too simplistic.  A
+   further problem arises with the value of the ifType object which has
+   enumerated values for each type of interface.
+
+   Consider, for example, an interface with PPP running over an HDLC
+   link which uses a RS232-like connector.  Each of these sub-layers has
+   its own media-specific MIB module.  If all of this is represented by
+   a single conceptual row in the ifTable, then an enumerated value for
+   ifType is needed for that specific combination which maps to the
+   specific combination of media-specific MIBs.  Furthermore, such a
+   model still lacks a method to describe the relationship of all the
+   sub-layers of the MIB stack.
+
+   An associated problem is that of upward and downward multiplexing of
+   the sub-layers.  An example of upward multiplexing is MLP (Multi-
+   Link-Procedure) which provides load-sharing over several serial lines
+   by appearing as a single point-to-point link to the sub-layer(s)
+   above.  An example of downward multiplexing would be several
+   instances of PPP, each framed within a separate X.25 virtual circuit,
+
+
+
+
+
+McCloghrie & Kastenholz     Standards Track                     [Page 4]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+   all of which run over one fractional T1 channel, concurrently with
+   other uses of the T1 link.  The MIB structure must allow these sorts
+   of relationships to be described.
+
+   Several solutions for representing multiple sub-layers were rejected.
+   One was to retain the concept of one conceptual row for all the sub-
+   layers of an interface and have each media-specific MIB module
+   identify its "superior" and "subordinate" sub-layers through OBJECT
+   IDENTIFIER "pointers".  This scheme would have several drawbacks: the
+   superior/subordinate pointers would be contained in the media-
+   specific MIB modules; thus, a manager could not learn the structure
+   of an interface without inspecting multiple pointers in different MIB
+   modules; this would be overly complex and only possible if the
+   manager had knowledge of all the relevant media-specific MIB modules;
+   MIB modules would all need to be retrofitted with these new
+   "pointers"; this scheme would not adequately address the problem of
+   upward and downward multiplexing; and finally, enumerated values of
+   ifType would be needed for each combination of sub-layers.  Another
+   rejected solution also retained the concept of one conceptual row for
+   all the sub-layers of an interface but had a new separate MIB table
+   to identify the "superior" and "subordinate" sub-layers and to
+   contain OBJECT IDENTIFIER "pointers" to the media-specific MIB module
+   for each sub-layer.  Effectively, one conceptual row in the ifTable
+   would represent each combination of sub-layers between the
+   internetwork-layer and the wire.  While this scheme has fewer
+   drawbacks, it still would not support downward multiplexing, such as
+   PPP over MLP: observe that MLP makes two (or more) serial lines
+   appear to the layers above as a single physical interface, and thus
+   PPP over MLP should appear to the internetwork-layer as a single
+   interface; in contrast, this scheme would result in two (or more)
+   conceptual rows in the ifTable, both of which the internetwork-layer
+   would run over.  This scheme would also require enumerated values of
+   ifType for each combination of sub-layers.
+
+   The solution adopted by this memo is to have an individual conceptual
+   row in the ifTable to represent each sub-layer, and have a new
+   separate MIB table (the ifStackTable, see section 6 below) to
+   identify the "superior" and "subordinate" sub-layers through INTEGER
+   "pointers" to the appropriate conceptual rows in the ifTable.  This
+   solution supports both upward and downward multiplexing, allows the
+   IANAifType to Media-Specific MIB mapping to identify the media-
+   specific MIB module for that sub-layer, such that the new table need
+   only be referenced to obtain information about layering, and it only
+   requires enumerated values of ifType for each sub-layer, not for
+   combinations of them.  However, it does require that the descriptions
+   of some objects in the ifTable (specifically, ifType, ifPhysAddress,
+   ifInUcastPkts, and ifOutUcastPkts) be generalized so as to apply to
+   any sub-layer (rather than only to a sub-layer immediately beneath
+
+
+
+McCloghrie & Kastenholz     Standards Track                     [Page 5]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+   the network layer as previously), plus some (specifically, ifSpeed)
+   which need to have appropriate values identified for use when a
+   generalized definition does not apply to a particular sub-layer.
+
+   In addition, this adopted solution makes no requirement that a
+   device, in which a sub-layer is instrumented by a conceptual row of
+   the ifTable, be aware of whether an internetwork protocol runs on top
+   of (i.e., at some layer above) that sub-layer.  In fact, the counters
+   of packets received on an interface are defined as counting the
+   number "delivered to a higher-layer protocol".  This meaning of
+   "higher-layer" includes:
+
+   (1)   Delivery to a forwarding module which accepts
+         packets/frames/octets and forwards them on at the same protocol
+         layer.  For example, for the purposes of this definition, the
+         forwarding module of a MAC-layer bridge is considered as a
+         "higher-layer" to the MAC-layer of each port on the bridge.
+
+   (2)   Delivery to a higher sub-layer within a interface stack.  For
+         example, for the purposes of this definition, if a PPP module
+         operated directly over a serial interface, the PPP module would
+         be considered the higher sub-layer to the serial interface.
+
+   (3)   Delivery to a higher protocol layer which does not do packet
+         forwarding for sub-layers that are "at the top of" the
+         interface stack.  For example, for the purposes of this
+         definition, the local IP module would be considered the higher
+         layer to a SLIP serial interface.
+
+   Similarly, for output, the counters of packets transmitted out an
+   interface are defined as counting the number "that higher-level
+   protocols requested to be transmitted".  This meaning of "higher-
+   layer" includes:
+
+   (1)   A forwarding module, at the same protocol layer, which
+         transmits packets/frames/octets that were received on an
+         different interface.  For example, for the purposes of this
+         definition, the forwarding module of a MAC-layer bridge is
+         considered as a "higher-layer" to the MAC-layer of each port on
+         the bridge.
+
+   (2)   The next higher sub-layer within an interface stack.  For
+         example, for the purposes of this definition, if a PPP module
+         operated directly over a serial interface, the PPP module would
+         be a "higher layer" to the serial interface.
+
+
+
+
+
+
+McCloghrie & Kastenholz     Standards Track                     [Page 6]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+   (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 module would be
+         considered the higher layer to an Ethernet interface.
+
+3.1.2.  Guidance on Defining Sub-layers
+
+   The designer of a media-specific MIB must decide whether to divide
+   the interface into sub-layers or not, and if so, how to make the
+   divisions.  The following guidance is offered to assist the media-
+   specific MIB designer in these decisions.
+
+   In general, the number of entries in the ifTable should be kept to
+   the minimum required for network management.  In particular, a group
+   of related interfaces should be treated as a single interface with
+   one entry in the ifTable providing that:
+
+   (1)   None of the group of interfaces performs multiplexing for any
+         other interface in the agent,
+
+   (2)   There is a meaningful and useful way for all of the ifTable's
+         information (e.g., the counters, and the status variables), and
+         all of the ifTable's capabilities (e.g., write access to
+         ifAdminStatus), to apply to the group of interfaces as a whole.
+
+   Under these circumstances, there should be one entry in the ifTable
+   for such a group of interfaces, and any internal structure which
+   needs to be represented to network management should be captured in a
+   MIB module specific to the particular type of interface.
+
+   Note that application of bullet 2 above to the ifTable's ifType
+   object requires that there is a meaningful media-specific MIB and a
+   meaningful ifType value which apply to the group of interfaces as a
+   whole.  For example, it is not appropriate to treat an HDLC sub-layer
+   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 separate
+   (rather than combined).
+
+   Subject to the above, it is appropriate to assign an ifIndex value to
+   any interface that can occur in an interface stack (in the
+   ifStackTable) where the bottom of the stack is a physical interface
+   (ifConnectorPresent has the value 'true') and there is a layer-3 or
+   other application that "points down" to the top of this stack.  An
+   example of an application that points down to the top of the stack is
+   the Character MIB [21].
+
+
+
+
+
+
+McCloghrie & Kastenholz     Standards Track                     [Page 7]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+   Note that the sub-layers of an interface on one device will sometimes
+   be different from the sub-layers of the interconnected interface of
+   another device; for example, for a frame-relay DTE interface
+   connected a frameRelayService interface, the inter-connected DTE and
+   DCE interfaces have different ifType values and media-specific MIBs.
+
+   These guidelines are just that, guidelines.  The designer of a
+   media-specific MIB is free to lay out the MIB in whatever SMI
+   conformant manner is desired.  However, in doing so, the media-
+   specific MIB MUST completely specify the sub-layering model used for
+   the MIB, and provide the assumptions, reasoning, and rationale used
+   to develop that model.
+
+3.1.3.  Virtual Circuits
+
+   Several of the sub-layers for which media-specific MIB modules have
+   been defined are connection oriented (e.g., Frame Relay, X.25).
+   Experience has shown that each effort to define such a MIB module
+   revisits the question of whether separate conceptual rows in the
+   ifTable are needed for each virtual circuit.  Most, if not all, of
+   these efforts to date have decided to have all virtual circuits
+   reference a single conceptual row in the ifTable.
+
+   This memo strongly recommends that connection-oriented sub-layers do
+   not have a conceptual row in the ifTable for each virtual circuit.
+   This avoids the proliferation of conceptual rows, especially those
+   which have considerable redundant information.  (Note, as a
+   comparison, that connection-less sub-layers do not have conceptual
+   rows for each remote address.)  There may, however, be circumstances
+   under which it is appropriate for a virtual circuit of a connection-
+   oriented sub-layer to have its own conceptual row in the ifTable; an
+   example of this might be PPP over an X.25 virtual circuit.  The MIB
+   in section 6 of this memo supports such circumstances.
+
+   If a media-specific MIB wishes to assign an entry in the ifTable to
+   each virtual circuit, the MIB designer must present the rationale for
+   this decision in the media-specific MIB's specification.
+
+3.1.4.  Bit, Character, and Fixed-Length Interfaces
+
+   RS-232 is an example of a character-oriented sub-layer over which
+   (e.g., through use of PPP) IP datagrams can be sent.  Due to the
+   packet-based nature of many of the objects in the ifTable, experience
+   has shown that it is not appropriate to have a character-oriented
+   sub-layer represented by a whole conceptual row in the ifTable.
+
+
+
+
+
+
+McCloghrie & Kastenholz     Standards Track                     [Page 8]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+   Experience has also shown that it is sometimes desirable to have some
+   management information for bit-oriented interfaces, which are
+   similarly difficult to represent by a whole conceptual row in the
+   ifTable.  For example, to manage the channels of a DS1 circuit, where
+   only some of the channels are carrying packet-based data.
+
+   A further complication is that some subnetwork technologies transmit
+   data in fixed length transmission units.  One example of such a
+   technology is cell relay, and in particular Asynchronous Transfer
+   Mode (ATM), which transmits data in fixed-length cells.  Representing
+   such a interface as a packet-based interface produces redundant
+   objects if the relationship between the number of packets and the
+   number of octets in either direction is fixed by the size of the
+   transmission unit (e.g., the size of a cell).
+
+   About half the objects in the ifTable are applicable to every type of
+   interface: packet-oriented, character-oriented, and bit-oriented.  Of
+   the other half, two are applicable to both character-oriented and
+   packet-oriented interfaces, and the rest are applicable only to
+   packet-oriented interfaces.  Thus, while it is desirable for
+   consistency to be able to represent any/all types of interfaces in
+   the ifTable, it is not possible to implement the full ifTable for
+   bit- and character-oriented sub-layers.
+
+   A rejected solution to this problem would be to split the ifTable
+   into two (or more) new MIB tables, one of which would contain objects
+   that are relevant only to packet-oriented interfaces (e.g., PPP), and
+   another that may be used by all interfaces.  This is highly
+   undesirable since it would require changes in every agent
+   implementing the ifTable (i.e., just about every existing SNMP
+   agent).
+
+   The solution adopted in this memo builds upon the fact that
+   compliance statements in SMIv2 (in contrast to SMIv1) refer to object
+   groups, where object groups are explicitly defined by listing the
+   objects they contain.  Thus, with SMIv2, multiple compliance
+   statements can be specified, one for all interfaces and additional
+   ones for specific types of interfaces.  The separate compliance
+   statements can be based on separate object groups, where the object
+   group for all interfaces can contain only those objects from the
+   ifTable which are appropriate for every type of interfaces.  Using
+   this solution, every sub-layer can have its own conceptual row in the
+   ifTable.
+
+   Thus, section 6 of this memo contains definitions of the objects of
+   the existing 'interfaces' group of MIB-II, in a manner which is both
+   SNMPv2-compliant and semantically-equivalent to the existing MIB-II
+   definitions.  With equivalent semantics, and with the BER ("on the
+
+
+
+McCloghrie & Kastenholz     Standards Track                     [Page 9]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+   wire") encodings unchanged, these definitions retain the same OBJECT
+   IDENTIFIER values as assigned by MIB-II.  Thus, in general, no
+   rewrite of existing agents which conform to MIB-II and the
+   ifExtensions MIB is required.
+
+   In addition, this memo defines several object groups for the purposes
+   of defining which objects apply to which types of interface:
+
+   (1)   the ifGeneralInformationGroup.  This group contains those
+         objects applicable to all types of network interfaces,
+         including bit-oriented interfaces.
+
+   (2)   the ifPacketGroup.  This group contains those objects
+         applicable to packet-oriented network interfaces.
+
+   (3)   the ifFixedLengthGroup.  This group contains the objects
+         applicable not only to character-oriented interfaces, such as
+         RS-232, but also to those subnetwork technologies, such as
+         cell-relay/ATM, which transmit data in fixed length
+         transmission units.  As well as the octet counters, there are
+         also a few other counters (e.g., the error counters) which are
+         useful for this type of interface, but are currently defined as
+         being packet-oriented.  To accommodate this, the definitions of
+         these counters are generalized to apply to character-oriented
+         interfaces and fixed-length-transmission interfaces.
+
+   It should be noted that the octet counters in the ifTable aggregate
+   octet counts for unicast and non-unicast packets into a single octet
+   counter per direction (received/transmitted).  Thus, with the above
+   definition of fixed-length-transmission interfaces, where such
+   interfaces which support non-unicast packets, separate counts of
+   unicast and multicast/broadcast transmissions can only be maintained
+   in a media-specific MIB module.
+
+3.1.5.  Interface Numbering
+
+   MIB-II defines an object, ifNumber, whose value represents:
+
+      "The number of network interfaces (regardless of their
+      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.  The
+      value for each interface must remain constant at least from
+      one re-initialization of the entity's network management
+      system to the next re-initialization."
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 10]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+   This constancy requirement on the value of ifIndex for a particular
+   interface is vital for efficient management.  However, an increasing
+   number of devices allow for the dynamic addition/removal of network
+   interfaces.  One example of this is a dynamic ability to configure
+   the use of SLIP/PPP over a character-oriented port.  For such dynamic
+   additions/removals, the combination of the constancy requirement and
+   the restriction that the value of ifIndex is less than ifNumber is
+   problematic.
+
+   Redefining ifNumber to be the largest value of ifIndex was rejected
+   since it would not help.  Such a re-definition would require ifNumber
+   to be deprecated and the utility of the redefined object would be
+   questionable.  Alternatively, ifNumber could be deprecated and not
+   replaced.  However, the deprecation of ifNumber would require a
+   change to that portion of ifIndex's definition which refers to
+   ifNumber.  So, since the definition of ifIndex must be changed anyway
+   in order to solve the problem, changes to ifNumber do not benefit the
+   solution.
+
+   The solution adopted in this memo is just to delete the requirement
+   that the value of ifIndex must be less than the value of ifNumber,
+   and to retain ifNumber with its current definition.  This is a minor
+   change in the semantics of ifIndex; however, all existing agent
+   implementations conform to this new definition, and in the interests
+   of not requiring changes to existing agent implementations and to the
+   many existing media-specific MIBs, this memo assumes that this change
+   does not require ifIndex to be deprecated.  Experience indicates that
+   this assumption does "break" a few management applications, but this
+   is considered preferable to breaking all agent implementations.
+
+   This solution also results in the possibility of "holes" in the
+   ifTable, i.e., the ifIndex values of conceptual rows in the ifTable
+   are not necessarily contiguous, but SNMP's GetNext (and GetBulk)
+   operation easily deals with such holes.  The value of ifNumber still
+   represents the number of conceptual rows, which increases/decreases
+   as new interfaces are dynamically added/removed.
+
+   The requirement for constancy (between re-initializations) of an
+   interface's ifIndex value is met by requiring that after an interface
+   is dynamically removed, its ifIndex value is not re-used by a
+   *different* dynamically added interface until after the following
+   re-initialization of the network management system.  This avoids the
+   need for assignment (in advance) of ifIndex values for all possible
+   interfaces that might be added dynamically.  The exact meaning of a
+   "different" interface is hard to define, and there will be gray
+   areas.  Any firm definition in this document would likely turn out to
+   be inadequate.  Instead, implementors must choose what it means in
+   their particular situation, subject to the following rules:
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 11]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+   (1)   a previously-unused value of ifIndex must be assigned to a
+         dynamically added interface if an agent has no knowledge of
+         whether the interface is the "same" or "different" to a
+         previously incarnated interface.
+
+   (2)   a management station, not noticing that an interface has gone
+         away and another has come into existence, must not be confused
+         when calculating the difference between the counter values
+         retrieved on successive polls for a particular ifIndex value.
+
+   When the new interface is the same as an old interface, but a
+   discontinuity in the value of the interface's counters cannot be
+   avoided, the ifTable has (until now) required that a new ifIndex
+   value be assigned to the returning interface.  That is, either all
+   counter values have had to be retained during the absence of an
+   interface in order to use the same ifIndex value on that interface's
+   return, or else a new ifIndex value has had to be assigned to the
+   returning interface.  Both alternatives have proved to be burdensome
+   to some implementations:
+
+   (1)   maintaining the counter values may not be possible (e.g., if
+         they are maintained on removable hardware),
+
+   (2)   using a new ifIndex value presents extra work for management
+         applications.  While the potential need for such extra work is
+         unavoidable on agent re-initializations, it is desirable to
+         avoid it between re-initializations.
+
+   To address this, a new object, ifCounterDiscontinuityTime, has been
+   defined to record the time of the last discontinuity in an
+   interface's counters.  By monitoring the value of this new object, a
+   management application can now detect counter discontinuities without
+   the ifIndex value of the interface being changed.  Thus, an agent
+   which implements this new object should, when a new interface is the
+   same as an old interface, retain that interface's ifIndex value and
+   update if necessary the interface's value of
+   ifCounterDiscontinuityTime.  With this new object, a management
+   application must, when calculating differences between counter values
+   retrieved on successive polls, discard any calculated difference for
+   which the value of ifCounterDiscontinuityTime is different for the
+   two polls.  (Note that this test must be performed in addition to the
+   normal checking of sysUpTime to detect an agent re-initialization.)
+   Since such discards are a waste of network management processing and
+   bandwidth, an agent should not update the value of
+   ifCounterDiscontinuityTime unless absolutely necessary.
+
+   While defining this new object is a change in the semantics of the
+   ifTable counter objects, it is impractical to deprecate and redefine
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 12]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+   all these counters because of their wide deployment and importance.
+   Also, a survey of implementations indicates that many agents and
+   management applications do not correctly implement this aspect of the
+   current semantics (because of the burdensome issues mentioned above),
+   such that the practical implications of such a change is small.
+   Thus, this breach of the SMI's rules is considered to be acceptable.
+
+   Note, however, that the addition of ifCounterDiscontinuityTime does
+   not change the fact that:
+
+      it is necessary at certain times for the assignment of
+      ifIndex values to change on a re-initialization of the agent
+      (such as a reboot).
+
+   The possibility of ifIndex value re-assignment must be accommodated
+   by a management application whenever the value of sysUpTime is reset
+   to zero.
+
+   Note also that some agents support multiple "naming scopes", e.g.,
+   for an SNMPv1 agent, multiple values of the SNMPv1 community string.
+   For such an agent (e.g., a CNM agent which supports a different
+   subset of interfaces for different customers), there is no required
+   relationship between the ifIndex values which identify interfaces in
+   one naming scope and those which identify interfaces in another
+   naming scope.  It is the agent's choice as to whether the same or
+   different ifIndex values identify the same or different interfaces in
+   different naming scopes.
+
+   Because of the restriction of the value of ifIndex to be less than
+   ifNumber, interfaces have been numbered with small integer values.
+   This has led to the ability by humans to use the ifIndex values as
+   (somewhat) user-friendly names for network interfaces (e.g.,
+   "interface number 3").  With the relaxation of the restriction on the
+   value of ifIndex, there is now the possibility that ifIndex values
+   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 assigned as (relatively)
+   small integer values starting at 1, even though the values in use at
+   any one time are not necessarily contiguous.  (Note that this makes
+   remembering which values have been assigned easy for agents which
+   dynamically add new interfaces)
+
+   A new problem is introduced by representing each sub-layer as an
+   ifTable entry.  Previously, there usually was a simple, direct,
+   mapping of interfaces to the physical ports on systems.  This mapping
+   would be based on the ifIndex value.  However, by having an ifTable
+   entry for each interface sub-layer, mapping from interfaces to
+   physical ports becomes increasingly problematic.
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 13]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+   To address this issue, a new object, ifName, is added to the MIB.
+   This object contains the device's local name (e.g., the name used at
+   the device's local console) for the interface of which the relevant
+   entry in the ifTable is a component.  For example, consider a router
+   having an interface composed of PPP running over an RS-232 port.  If
+   the router uses the name "wan1" for the (combined) interface, then
+   the ifName objects for the corresponding PPP and RS-232 entries in
+   the ifTable would both have the value "wan1".  On the other hand, if
+   the router uses the name "wan1.1" for the PPP interface and "wan1.2"
+   for the RS-232 port, then the ifName objects for the corresponding
+   PPP and RS-232 entries in the ifTable would have the values "wan1.1"
+   and "wan1.2", respectively.  As an another example, consider an agent
+   which responds to SNMP queries concerning an interface on some other
+   (proxied) device:  if such a proxied device associates a particular
+   identifier with an interface, then it is appropriate to use this
+   identifier as the value of the interface's ifName, since the local
+   console in this case is that of the proxied device.
+
+   In contrast, the existing ifDescr object is intended to contain a
+   description of an interface, whereas another new object, ifAlias,
+   provides a location in which a network management application can
+   store a non-volatile interface-naming value of its own choice.  The
+   ifAlias object allows a network manager to give one or more
+   interfaces their own unique names, irrespective of any interface-
+   stack relationship.  Further, the ifAlias name is non-volatile, and
+   thus an interface must retain its assigned ifAlias value across
+   reboots, even if an agent chooses a new ifIndex value for the
+   interface.
+
+3.1.6.  Counter Size
+
+   As the speed of network media increase, the minimum time in which a
+   32 bit counter will wrap decreases.  For example, a 10Mbs stream of
+   back-to-back, full-size packets causes ifInOctets to wrap in just
+   over 57 minutes; at 100Mbs, the minimum wrap time is 5.7 minutes, and
+   at 1Gbs, the minimum is 34 seconds.  Requiring that interfaces be
+   polled frequently enough not to miss a counter wrap is increasingly
+   problematic.
+
+   A rejected solution to this problem was to scale the counters; for
+   example, ifInOctets could be changed to count received octets in,
+   say, 1024 byte blocks.  While it would provide acceptable
+   functionality at high rates of the counted-events, at low rates it
+   suffers.  If there is little traffic on an interface, there might be
+   a significant interval before enough of the counted-events occur to
+   cause the scaled counter to be incremented.  Traffic would then
+   appear to be very bursty, leading to incorrect conclusions of the
+   network's performance.
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 14]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+   Instead, this memo adopts expanded, 64 bit, counters.  These counters
+   are provided in new "high capacity" groups.  The old, 32-bit,
+   counters have not been deprecated.  The 64-bit counters are to be
+   used only when the 32-bit counters do not provide enough capacity;
+   that is, when the 32 bit counters could wrap too fast.
+
+   For interfaces that operate at 20,000,000 (20 million) bits per
+   second or less, 32-bit byte and packet counters MUST be supported.
+   For interfaces that operate faster than 20,000,000 bits/second, and
+   slower than 650,000,000 bits/second, 32-bit packet counters MUST be
+   supported and 64-bit octet counters MUST be supported.  For
+   interfaces that operate at 650,000,000 bits/second or faster, 64-bit
+   packet counters AND 64-bit octet counters MUST be supported.
+
+   These speed thresholds were chosen as reasonable compromises based on
+   the following:
+
+   (1)   The cost of maintaining 64-bit counters is relatively high, so
+         minimizing the number of agents which must support them is
+         desirable.  Common interfaces (such as 10Mbs Ethernet) should
+         not require them.
+
+   (2)   64-bit counters are a new feature, introduced in the SMIv2.  It
+         is reasonable to expect that support for them will be spotty
+         for the immediate future.  Thus, we wish to limit them to as
+         few systems as possible.  This, in effect, means that 64-bit
+         counters should be limited to higher speed interfaces.
+         Ethernet (10,000,000 bps) and Token Ring (16,000,000 bps) are
+         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-sized
+         packets back-to-back):
+
+         -   10Mbs Ethernet: 57 minutes,
+
+         -   16Mbs Token Ring: 36 minutes,
+
+         -   a US T3 line (45 megabits): 12 minutes,
+
+         -   FDDI: 5.7 minutes
+
+   (4)   The 32-bit packet counters wrap in about 57 minutes when 64-
+         byte packets are transmitted back-to-back on a 650,000,000
+         bit/second link.
+
+
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 15]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+   As an aside, a 1-terabit/second (1,000 Gbs) link will cause a 64 bit
+   octet counter to wrap in just under 5 years.  Conversely, an
+   81,000,000 terabit/second link is required to cause a 64-bit counter
+   to wrap in 30 minutes.  We believe that, while technology rapidly
+   marches forward, this link 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 be
+   available.  They will report the low 32-bits of the associated 64-bit
+   count (e.g., ifInOctets will report the least significant 32 bits of
+   ifHCInOctets).  This enhances inter-operability with existing
+   implementations at a very minimal cost to agents.
+
+   The new "high capacity" groups are:
+
+   (1)   the ifHCFixedLengthGroup for character-oriented/fixed-length
+         interfaces, and the ifHCPacketGroup for packet-based
+         interfaces; both of these groups include 64 bit counters for
+         octets, and
+
+   (2)   the ifVHCPacketGroup for packet-based interfaces; this group
+         includes 64 bit counters for octets and packets.
+
+3.1.7.  Interface Speed
+
+   Network speeds are increasing.  The range of ifSpeed is limited to
+   reporting a maximum speed of (2**31)-1 bits/second, or approximately
+   2.2Gbs.  SONET defines an OC-48 interface, which is defined at
+   operating at 48 times 51 Mbs, which is a speed in excess of 2.4Gbs.
+   Thus, ifSpeed is insufficient for the future, and this memo defines
+   an additional object: ifHighSpeed.
+
+   The ifHighSpeed object reports the speed of the interface in
+   1,000,000 (1 million) bits/second units.  Thus, the true speed of the
+   interface will be the value reported by this object, plus or minus
+   500,000 bits/second.
+
+   Other alternatives considered (but rejected) were:
+
+   (1)   Making the interface speed a 64-bit gauge.  This was rejected
+         since the current SMI does not allow such a syntax.
+
+      Furthermore, even if 64-bit gauges were available, their use would
+      require additional complexity in agents due to an increased
+      requirement for 64-bit operations.
+
+
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 16]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+   (2)   We also considered making "high-32 bit" and "low-32-bit"
+         objects which, when combined, would be a 64-bit value.  This
+         simply seemed overly complex for what we are trying to do.
+
+      Furthermore, a full 64-bits of precision does not seem necessary.
+      The value of ifHighSpeed will be the only report of interface
+      speed for interfaces that are faster than 4,294,967,295 bits per
+      second.  At this speed, the granularity of ifHighSpeed will be
+      1,000,000 bits per second, thus the error will be 1/4294, or about
+      0.02%.  This seems reasonable.
+
+   (3)   Adding a "scale" object, which would define the units which
+         ifSpeed's value is.
+
+      This would require two additional objects; one for the scaling
+      object, and one to replace the current ifSpeed.  This later object
+      is required since the semantics of ifSpeed would be significantly
+      altered, and manager stations which do not understand the new
+      semantics would be confused.
+
+3.1.8.  Multicast/Broadcast Counters
+
+   In MIB-II, the ifTable counters for multicast and broadcast packets
+   are combined as counters of non-unicast packets.  In contrast, the
+   ifExtensions MIB [19] defined one set of counters for multicast, and
+   a separate set for broadcast packets.  With the separate counters,
+   the original combined counters become redundant.  To avoid this
+   redundancy, the non-unicast counters are deprecated.
+
+   For the output broadcast and multicast counters defined in RFC 1229,
+   their definitions varied slightly from the packet counters in the
+   ifTable, in that they did not count errors/discarded packets.  Thus,
+   this memo defines new objects with better aligned definitions.
+   Counters with 64 bits of range are also needed, as explained above.
+
+3.1.9.  Trap Enable
+
+   In the multi-layer interface model, each sub-layer for which there is
+   an entry in the ifTable can generate linkUp/linkDown Traps.  Since
+   interface state changes would tend to propagate through the interface
+   (from top to bottom, or bottom to top), it is likely that several
+   traps would be generated for each linkUp/linkDown occurrence.
+
+   It is desirable to provide a mechanism for manager stations to
+   control the generation of these traps.  To this end, the
+   ifLinkUpDownTrapEnable object has been added.  This object allows
+   managers to limit generation of traps to just the sub-layers of
+   interest.
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 17]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+   The default setting should limit the number of traps generated to one
+   per interface per linkUp/linkDown event.  Furthermore, it seems that
+   the state changes of most interest to network managers occur at the
+   lowest level of an interface stack.  Therefore we specify that by
+   default, only the lowest sub-layer of the interface generate traps.
+
+3.1.10.  Addition of New ifType values
+
+   Over time, there is the need to add new ifType enumerated values for
+   new interface types.  If the syntax of ifType were defined in the MIB
+   in section 6, then a new version of this MIB would have to be re-
+   issued in order to define new values.  In the past, re-issuing of a
+   MIB has occurred only after several years.
+
+   Therefore, the syntax of ifType is changed to be a textual
+   convention, such that the enumerated integer values are now defined
+   in the textual convention, IANAifType, defined in a different
+   document.  This allows additional values to be documented without
+   having to re-issue a new version of this document.  The Internet
+   Assigned Number Authority (IANA) is responsible for the assignment of
+   all Internet numbers, including various SNMP-related numbers, and
+   specifically, new ifType values.
+
+3.1.11.  InterfaceIndex Textual Convention
+
+   A new textual convention, InterfaceIndex, has been defined.  This
+   textual convention "contains" all of the semantics of the ifIndex
+   object.  This allows other MIB modules to easily import the semantics
+   of ifIndex.
+
+3.1.12.  New states for IfOperStatus
+
+   Three new states have been added to ifOperStatus: 'dormant',
+   'notPresent', and 'lowerLayerDown'.
+
+   The dormant state indicates that the relevant interface is not
+   actually in a condition to pass packets (i.e., it is not 'up') but is
+   in a "pending" state, waiting for some external event.  For "on-
+   demand" interfaces, this new state identifies the situation where the
+   interface is waiting for events to place it in the up state.
+   Examples of such events might be:
+
+   (1)   having packets to transmit before establishing a connection to
+         a remote system;
+
+   (2)   having a remote system establish a connection to the interface
+         (e.g. dialing up to a slip-server).
+
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 18]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+   The notPresent state is a refinement on the down state which
+   indicates that the relevant interface is down specifically because
+   some component (typically, a hardware component) is not present in
+   the managed system.  Examples of use of the notPresent state are:
+
+   (1)   to allow an interface's conceptual row including its counter
+         values to be retained across a "hot swap" of a card/module,
+         and/or
+
+   (2)   to allow an interface's conceptual row to be created, and
+         thereby enable interfaces to be pre-configured prior to
+         installation of the hardware needed to make the interface
+         operational.
+
+   Agents are not required to support interfaces in the notPresent
+   state.  However, from a conceptual viewpoint, when a row in the
+   ifTable is created, it first enters the notPresent state and then
+   subsequently transitions into the down state; similarly, when a row
+   in the ifTable is deleted, it first enters the notPresent state and
+   then subsequently the object instances are deleted.  For an agent
+   with no support for notPresent, both of these transitions (from the
+   notPresent state to the down state, and from the notPresent state to
+   the instances being removed) are immediate, i.e., the transition does
+   not last long enough to be recorded by ifOperStatus.  Even for those
+   agents which do support interfaces in the notPresent state, the
+   length of time and conditions under which an interface stays in the
+   notPresent state is implementation-specific.
+
+   The lowerLayerDown state is also a refinement on the down state.
+   This new state indicates that this interface runs "on top of" one or
+   more other interfaces (see ifStackTable) and that this interface is
+   down specifically because one or more of these lower-layer interfaces
+   are down.
+
+3.1.13.  IfAdminStatus and IfOperStatus
+
+   The down state of ifOperStatus now has two meanings, depending on the
+   value of ifAdminStatus.
+
+   (1)   if ifAdminStatus is not down and ifOperStatus is down then a
+         fault condition is presumed to exist on the interface.
+
+   (2)   if ifAdminStatus is down, then ifOperStatus will normally also
+         be down (or notPresent) i.e., there is not (necessarily) a
+         fault condition on the interface.
+
+   Note that when ifAdminStatus transitions to down, ifOperStatus will
+   normally also transition to down.  In this situation, it is possible
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 19]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+   that ifOperStatus's transition will not occur immediately, but rather
+   after a small time lag to complete certain operations before going
+   "down"; for example, it might need to finish transmitting a packet.
+   If a manager station finds that ifAdminStatus is down and
+   ifOperStatus is not down for a particular interface, the manager
+   station should wait a short while and check again.  If the condition
+   still exists, only then should it raise an error indication.
+   Naturally, it should also ensure that ifLastChange has not changed
+   during this interval.
+
+   Whenever an interface table entry is created (usually as a result of
+   system initialization), the relevant instance of ifAdminStatus is set
+   to down, and ifOperStatus will be down or notPresent.
+
+   An interface may be enabled in two ways: either as a result of
+   explicit management action (e.g. setting ifAdminStatus to up) or as a
+   result of the managed system's initialization process.  When
+   ifAdminStatus changes to the up state, the related ifOperStatus
+   should do one of the following:
+
+   (1)   Change to the up state if and only if the interface is able to
+         send and receive packets.
+
+   (2)   Change to the lowerLayerDown state if and only if the interface
+         is prevented from entering the up state because of the state of
+         one or more of the interfaces beneath it in the interface
+         stack.
+
+   (3)   Change to the dormant state if and only if the interface is
+         found to be operable, but the interface is waiting for other,
+         external, events to occur before it can transmit or receive
+         packets.  Presumably when the expected events occur, the
+         interface will then change to the up state.
+
+   (4)   Remain in the down state if an error or other fault condition
+         is detected on the interface.
+
+   (5)   Change to the unknown state if, for some reason, the state of
+         the interface can not be ascertained.
+
+   (6)   Change to the testing state if some test(s) must be performed
+         on the interface. Presumably after completion of the test, the
+         interface's state will change to up, dormant, or down, as
+         appropriate.
+
+   (7)   Remain in the notPresent state if interface components are
+         missing.
+
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 20]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+3.1.14.  IfOperStatus in an Interface Stack
+
+   When an interface is a part of an interface-stack, but is not the
+   lowest interface in the stack, then:
+
+   (1)   ifOperStatus has the value 'up' if it is able to pass packets
+         due to one or more interfaces below it in the stack being 'up',
+         irrespective of whether other interfaces below it are 'down', '
+         dormant', 'notPresent', 'lowerLayerDown', 'unknown' or '
+         testing'.
+
+   (2)   ifOperStatus may have the value 'up' or 'dormant' if one or
+         more interfaces below it in the stack are 'dormant', and all
+         others below it are either 'down', 'dormant', 'notPresent', '
+         lowerLayerDown', 'unknown' or 'testing'.
+
+   (3)   ifOperStatus has the value 'lowerLayerDown' while all
+         interfaces below it in the stack are either 'down', '
+         notPresent', 'lowerLayerDown', or 'testing'.
+
+3.1.15.  Traps
+
+   The exact definition of when linkUp and linkDown traps are generated
+   has been changed to reflect the changes to ifAdminStatus and
+   ifOperStatus.  Operational experience indicates that management
+   stations are most concerned with an interface being in the down state
+   and the fact that this state may indicate a failure.  Thus, it is
+   most useful to instrument transitions into/out of either the up state
+   or the down state.
+
+   Instrumenting transitions into or out of the up state was rejected
+   since it would have the drawback that a demand interface might have
+   many transitions between up and dormant, leading to many linkUp traps
+   and no linkDown traps.  Furthermore, if a node's only interface is
+   the demand interface, then a transition to dormant would entail
+   generation of a linkDown trap, necessitating bringing the link to the
+   up state (and a linkUp trap)!!
+
+   On the other hand, instrumenting transitions into or out of the down
+   state (to/from all other states except notPresent) has the
+   advantages:
+
+   (1)   A transition into the down state (from a state other than
+         notPresent) will occur when an error is detected on an
+         interface.  Error conditions are presumably of great interest
+         to network managers.
+
+
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 21]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+   (2)   Departing the down state (to a state other than the notPresent
+         state) generally indicates that the interface is going to
+         either up or dormant, both of which are considered "healthy"
+         states.
+
+   Furthermore, it is believed that generating traps on transitions into
+   or out of the down state (except to/from the notPresent state) is
+   generally consistent with current usage and interpretation of these
+   traps by manager stations.
+
+   Transitions to/from the notPresent state are concerned with the
+   insertion and removal of hardware, and are outside the scope of these
+   traps.
+
+   Therefore, this memo defines that LinkUp and linkDown traps are
+   generated just after ifOperStatus leaves, or just before it enters,
+   the down state, respectively; except that LinkUp and linkDown traps
+   are never generated on transitions to/from the notPresent state.  For
+   the purpose of deciding when these traps occur, the lowerLayerDown
+   state and the down state are considered to be equivalent, i.e., there
+   is no trap on transition from lowerLayerDown into down, and there is
+   a trap on transition from any other state except down (and
+   notPresent) into lowerLayerDown.
+
+   Note that this definition allows a node with only one interface to
+   transmit a linkDown trap before that interface goes down.  (Of
+   course, when the interface is going down because of a failure
+   condition, the linkDown trap probably cannot be successfully
+   transmitted anyway.)
+
+   Some interfaces perform a link "training" function when trying to
+   bring the interface up.  In the event that such an interface were
+   defective, then the training function would fail and the interface
+   would remain down, and the training function might be repeated at
+   appropriate intervals.  If the interface, while performing this
+   training function, were considered to the in the testing state, then
+   linkUp and linkDown traps would be generated for each start and end
+   of the training function.  This is not the intent of the linkUp and
+   linkDown traps, and therefore, while performing such a training
+   function, the interface's state should be represented as down.
+
+   An exception to the above generation of linkUp/linkDown traps on
+   changes in ifOperStatus, occurs when an interface is "flapping",
+   i.e., when it is rapidly oscillating between the up and down states.
+   If traps were generated for each such oscillation, the network and
+   the network management system would be flooded with unnecessary
+   traps.  In such a situation, the agent should limit the rate at which
+   it generates traps.
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 22]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+3.1.16.  ifSpecific
+
+   The original definition of the OBJECT IDENTIFIER value of ifSpecific
+   was not sufficiently clear.  As a result, different implementors used
+   it differently, and confusion resulted.  Some implementations set the
+   value of ifSpecific to the OBJECT IDENTIFIER that defines the media-
+   specific MIB, i.e., the "foo" of:
+                foo OBJECT IDENTIFIER ::= { transmission xxx }
+
+   while others set it to be OBJECT IDENTIFIER of the specific table or
+   entry in the appropriate media-specific MIB (i.e., fooTable or
+   fooEntry), while still others set it be the OBJECT IDENTIFIER of the
+   index object of the table's row, including instance identifier,
+   (i.e., fooIfIndex.ifIndex).  A definition based on the latter would
+   not be sufficient unless it also allowed for media-specific MIBs
+   which include several tables, where each table has its own
+   (different) indexing.
+
+   The only definition that can both be made explicit and can cover all
+   the useful situations is to have ifSpecific be the most general value
+   for the media-specific MIB module (the first example given above).
+   This effectively makes it redundant because it contains no more
+   information than is provided by ifType.  Thus, ifSpecific has been
+   deprecated.
+
+3.1.17.  Creation/Deletion of Interfaces
+
+   While some interfaces, for example, most physical interfaces, cannot
+   be created via network management, other interfaces such as logical
+   interfaces sometimes can be.  The ifTable contains only generic
+   information about an interface.  Almost all 'create-able' interfaces
+   have other, media-specific, information through which configuration
+   parameters may be supplied prior to creating such an interface.
+   Thus, the ifTable does not itself support the creation or deletion of
+   an interface (specifically, it has no RowStatus [6] column).  Rather,
+   if a particular interface type supports the dynamic creation and/or
+   deletion of an interface of that type, then that media-specific MIB
+   should include an appropriate RowStatus object (see the ATM LAN-
+   Emulation Client MIB [20] for an example of a MIB which does this).
+   Typically, when such a RowStatus object is created/deleted, then the
+   conceptual row in the ifTable appears/disappears as a by-product, and
+   an ifIndex value (chosen by the agent) is stored in an appropriate
+   object in the media-specific MIB.
+
+
+
+
+
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 23]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+3.1.18.  All Values Must be Known
+
+   There are a number of situations where an agent does not know the
+   value of one or more objects for a particular interface.  In all such
+   circumstances, an agent MUST NOT instantiate an object with an
+   incorrect value; rather, it MUST respond with the appropriate
+   error/exception condition (e.g., noSuchInstance or noSuchName).
+
+   One example is where an agent is unable to count the occurrences
+   defined by one (or more) of the ifTable counters.  In this
+   circumstance, the agent MUST NOT instantiate the particular counter
+   with a value of, say, zero.  To do so would be to provide mis-
+   information to a network management application reading the zero
+   value, and thereby assuming that there have been no occurrences of
+   the event (e.g., no input errors because ifInErrors is always zero).
+
+   Sometimes the lack of knowledge of an object's value is temporary.
+   For example, when the MTU of an interface is a configured value and a
+   device dynamically learns the configured value through (after)
+   exchanging messages over the interface (e.g., ATM LAN-Emulation
+   [20]).  In such a case, the value is not known until after the
+   ifTable entry has already been created.  In such a case, the ifTable
+   entry should be created without an instance of the object whose value
+   is unknown; later, when the value becomes known, the missing object
+   can then be instantiated (e.g., the instance of ifMtu is only
+   instantiated once the interface's MTU becomes known).
+
+   As a result of this "known values" rule, management applications MUST
+   be able to cope with the responses to retrieving the object instances
+   within a conceptual row of the ifTable revealing that some of the
+   row's columnar objects are missing/not available.
+
+4.  Media-Specific MIB Applicability
+
+   The exact use and semantics of many objects in this MIB are open to
+   some interpretation.  This is a result of the generic nature of this
+   MIB.  It is not always possible to come up with specific,
+   unambiguous, text that covers all cases and yet preserves the generic
+   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 with
+   respect to the media-specific MIB.
+
+
+
+
+
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 24]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+   Specific areas of clarification include
+
+   Layering Model
+      The media-specific MIB designer MUST completely and unambiguously
+      specify the layering model used.  Each individual sub-layer must
+      be identified, as must the ifStackTable's portrayal of the
+      relationship(s) between the sub-layers.
+
+   Virtual Circuits
+      The media-specific MIB designer MUST specify whether virtual
+      circuits are assigned entries in the ifTable or not.  If they are,
+      compelling rationale must be presented.
+
+   ifRcvAddressTable
+      The media-specific MIB designer MUST specify the applicability of
+      the ifRcvAddressTable.
+
+   ifType
+      For each of the ifType values to which the media-specific MIB
+      applies, it must specify the mapping of ifType values to media-
+      specific MIB module(s) and instances of MIB objects within those
+      modules.
+
+   ifXxxOctets
+      The definitions of ifInOctets and ifOutOctets (and similarly,
+      ifHCInOctets and ifHCOutOctets) specify that their values include
+      framing characters.  The media-specific MIB designer MUST specify
+      any special conditions of the media concerning the inclusion of
+      framing characters, especially with respect to frames with errors.
+
+   However, wherever this interface MIB is specific in the semantics,
+   DESCRIPTION, or applicability of objects, the media-specific MIB
+   designer MUST NOT change said semantics, DESCRIPTION, or
+   applicability.
+
+5.  Overview
+
+   This MIB consists of 4 tables:
+
+   ifTable
+      This table is the ifTable from MIB-II.
+
+   ifXTable
+      This table contains objects that have been added to the Interface
+      MIB as a result of the Interface Evolution effort, or replacements
+      for objects of the original (MIB-II) ifTable that were deprecated
+
+
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 25]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+      because the semantics of said objects have significantly changed.
+      This table also contains objects that were previously in the
+      ifExtnsTable.
+
+   ifStackTable
+      This table contains objects that define the relationships among
+      the sub-layers of an interface.
+
+   ifRcvAddressTable
+      This table contains objects that are used to define the 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 to their specific MIB.
+
+6.  Interfaces Group Definitions
+
+IF-MIB DEFINITIONS ::= BEGIN
+
+IMPORTS
+    MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32, Counter64,
+    Integer32, TimeTicks, mib-2,
+    NOTIFICATION-TYPE                        FROM SNMPv2-SMI
+    TEXTUAL-CONVENTION, DisplayString,
+    PhysAddress, TruthValue, RowStatus,
+    TimeStamp, AutonomousType, TestAndIncr   FROM SNMPv2-TC
+    MODULE-COMPLIANCE, OBJECT-GROUP,
+    NOTIFICATION-GROUP                       FROM SNMPv2-CONF
+    snmpTraps                                FROM SNMPv2-MIB
+    IANAifType                               FROM IANAifType-MIB;
+
+
+ifMIB MODULE-IDENTITY
+    LAST-UPDATED "200006140000Z"
+    ORGANIZATION "IETF Interfaces MIB Working Group"
+    CONTACT-INFO
+            "   Keith McCloghrie
+                Cisco Systems, Inc.
+                170 West Tasman Drive
+                San Jose, CA  95134-1706
+                US
+
+                408-526-5260
+                kzm@cisco.com"
+    DESCRIPTION
+            "The MIB module to describe generic objects for network
+            interface sub-layers.  This MIB is an updated version of
+            MIB-II's ifTable, and incorporates the extensions defined in
+            RFC 1229."
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 26]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+    REVISION      "200006140000Z"
+    DESCRIPTION
+            "Clarifications agreed upon by the Interfaces MIB WG, and
+            published as RFC 2863."
+    REVISION      "199602282155Z"
+    DESCRIPTION
+            "Revisions made by the Interfaces MIB WG, and published in
+            RFC 2233."
+    REVISION      "199311082155Z"
+    DESCRIPTION
+            "Initial revision, published as part of RFC 1573."
+    ::= { mib-2 31 }
+
+
+ifMIBObjects OBJECT IDENTIFIER ::= { ifMIB 1 }
+
+interfaces   OBJECT IDENTIFIER ::= { mib-2 2 }
+
+--
+-- Textual Conventions
+--
+
+
+-- OwnerString has the same semantics as used in RFC 1271
+
+OwnerString ::= TEXTUAL-CONVENTION
+    DISPLAY-HINT "255a"
+    STATUS       deprecated
+    DESCRIPTION
+            "This data type is used to model an administratively
+            assigned name of the owner of a resource.  This information
+            is taken from the NVT ASCII character set.  It is suggested
+            that this name contain one or more of the following: ASCII
+            form of the manager station's transport address, management
+            station name (e.g., domain name), network management
+            personnel's name, location, or phone number.  In some cases
+            the agent itself will be the owner of an entry.  In these
+            cases, this string shall be set to a string starting with
+            'agent'."
+    SYNTAX       OCTET STRING (SIZE(0..255))
+
+-- InterfaceIndex contains the semantics of ifIndex and should be used
+-- for any objects defined in other MIB modules that need these semantics.
+
+InterfaceIndex ::= TEXTUAL-CONVENTION
+    DISPLAY-HINT "d"
+    STATUS       current
+    DESCRIPTION
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 27]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+            "A unique value, greater than zero, for each interface or
+            interface sub-layer in the managed system.  It is
+            recommended that values are assigned contiguously starting
+            from 1.  The value for each interface sub-layer must remain
+            constant at least from one re-initialization of the entity's
+            network management system to the next re-initialization."
+    SYNTAX       Integer32 (1..2147483647)
+
+InterfaceIndexOrZero ::= TEXTUAL-CONVENTION
+    DISPLAY-HINT "d"
+    STATUS       current
+    DESCRIPTION
+            "This textual convention is an extension of the
+            InterfaceIndex convention.  The latter defines a greater
+            than zero value used to identify an interface or interface
+            sub-layer in the managed system.  This extension permits the
+            additional value of zero.  the value zero is object-specific
+            and must therefore be defined as part of the description of
+            any object which uses this syntax.  Examples of the usage of
+            zero might include situations where interface was unknown,
+            or when none or all interfaces need to be referenced."
+    SYNTAX       Integer32 (0..2147483647)
+
+ifNumber  OBJECT-TYPE
+    SYNTAX      Integer32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "The number of network interfaces (regardless of their
+            current state) present on this system."
+    ::= { interfaces 1 }
+
+ifTableLastChange  OBJECT-TYPE
+    SYNTAX      TimeTicks
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "The value of sysUpTime at the time of the last creation or
+            deletion of an entry in the ifTable.  If the number of
+            entries has been unchanged since the last re-initialization
+            of the local network management subsystem, then this object
+            contains a zero value."
+    ::= { ifMIBObjects 5 }
+
+
+-- the Interfaces table
+
+-- The Interfaces table contains information on the entity's
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 28]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+-- interfaces.  Each sub-layer below the internetwork-layer
+-- of a network interface is considered to be an interface.
+
+ifTable OBJECT-TYPE
+    SYNTAX      SEQUENCE OF IfEntry
+    MAX-ACCESS  not-accessible
+    STATUS      current
+    DESCRIPTION
+            "A list of interface entries.  The number of entries is
+            given by the value of ifNumber."
+    ::= { interfaces 2 }
+
+ifEntry OBJECT-TYPE
+    SYNTAX      IfEntry
+    MAX-ACCESS  not-accessible
+    STATUS      current
+    DESCRIPTION
+            "An entry containing management information applicable 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,  -- deprecated
+        ifInDiscards            Counter32,
+        ifInErrors              Counter32,
+        ifInUnknownProtos       Counter32,
+        ifOutOctets             Counter32,
+        ifOutUcastPkts          Counter32,
+        ifOutNUcastPkts         Counter32,  -- deprecated
+        ifOutDiscards           Counter32,
+        ifOutErrors             Counter32,
+        ifOutQLen               Gauge32,    -- deprecated
+        ifSpecific              OBJECT IDENTIFIER -- deprecated
+    }
+
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 29]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+ifIndex OBJECT-TYPE
+    SYNTAX      InterfaceIndex
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "A unique value, greater than zero, for each interface.  It
+            is recommended that values are assigned contiguously
+            starting from 1.  The value for each interface sub-layer
+            must remain constant at least from one re-initialization of
+            the entity's network management system to the next re-
+            initialization."
+    ::= { ifEntry 1 }
+
+ifDescr OBJECT-TYPE
+    SYNTAX      DisplayString (SIZE (0..255))
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "A textual string containing information about the
+            interface.  This string should include the name of the
+            manufacturer, the product name and the version of the
+            interface hardware/software."
+    ::= { ifEntry 2 }
+
+ifType OBJECT-TYPE
+    SYNTAX      IANAifType
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "The type of interface.  Additional values for ifType are
+            assigned by the Internet Assigned Numbers Authority (IANA),
+            through updating the syntax of the IANAifType textual
+            convention."
+    ::= { ifEntry 3 }
+
+ifMtu OBJECT-TYPE
+    SYNTAX      Integer32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "The size of the largest packet which can be sent/received
+            on the interface, specified in octets.  For interfaces that
+            are used for transmitting network datagrams, this is the
+            size of the largest network datagram that can be sent on the
+            interface."
+    ::= { ifEntry 4 }
+
+ifSpeed OBJECT-TYPE
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 30]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+    SYNTAX      Gauge32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "An estimate of the interface's current bandwidth in bits
+            per second.  For interfaces which do not vary in bandwidth
+            or for those where no accurate estimation can be made, this
+            object should contain the nominal bandwidth.  If the
+            bandwidth of the interface is greater than the maximum value
+            reportable by this object then this object should report its
+            maximum value (4,294,967,295) and ifHighSpeed must be used
+            to report the interace's speed.  For a sub-layer which has
+            no concept of bandwidth, this object should be zero."
+    ::= { ifEntry 5 }
+
+ifPhysAddress OBJECT-TYPE
+    SYNTAX      PhysAddress
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "The interface's address at its protocol sub-layer.  For
+            example, for an 802.x interface, this object normally
+            contains a MAC address.  The interface's media-specific MIB
+            must define the bit and byte ordering and the format of the
+            value of this object.  For interfaces which do not have such
+            an address (e.g., a serial line), this object should contain
+            an octet string of zero length."
+    ::= { ifEntry 6 }
+
+ifAdminStatus OBJECT-TYPE
+    SYNTAX  INTEGER {
+                up(1),       -- ready to pass packets
+                down(2),
+                testing(3)   -- in some test mode
+            }
+    MAX-ACCESS  read-write
+    STATUS      current
+    DESCRIPTION
+            "The desired state of the interface.  The testing(3) state
+            indicates that no operational packets can be passed.  When a
+            managed system initializes, all interfaces start with
+            ifAdminStatus in the down(2) state.  As a result of either
+            explicit management action or per configuration information
+            retained by the managed system, ifAdminStatus is then
+            changed to either the up(1) or testing(3) states (or remains
+            in the down(2) state)."
+    ::= { ifEntry 7 }
+
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 31]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+ifOperStatus OBJECT-TYPE
+    SYNTAX  INTEGER {
+                up(1),        -- ready to pass packets
+                down(2),
+                testing(3),   -- in some test mode
+                unknown(4),   -- status can not be determined
+                              -- for some reason.
+                dormant(5),
+                notPresent(6),    -- some component is missing
+                lowerLayerDown(7) -- down due to state of
+                                  -- lower-layer interface(s)
+            }
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "The current operational state of the interface.  The
+            testing(3) state indicates that no operational packets can
+            be passed.  If ifAdminStatus is down(2) then ifOperStatus
+            should be down(2).  If ifAdminStatus is changed to up(1)
+            then ifOperStatus should change to up(1) if the interface is
+            ready to transmit and receive network traffic; it should
+            change to dormant(5) if the interface is waiting for
+            external actions (such as a serial line waiting for an
+            incoming connection); it should remain in the down(2) state
+            if and only if there is a fault that prevents it from going
+            to the up(1) state; it should remain in the notPresent(6)
+            state if the interface has missing (typically, hardware)
+            components."
+    ::= { ifEntry 8 }
+
+ifLastChange OBJECT-TYPE
+    SYNTAX      TimeTicks
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "The value of sysUpTime at the time the interface entered
+            its current operational state.  If the current state was
+            entered prior to the last re-initialization of the local
+            network management subsystem, then this object contains a
+            zero value."
+    ::= { ifEntry 9 }
+
+ifInOctets OBJECT-TYPE
+    SYNTAX      Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "The total number of octets received on the interface,
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 32]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+            including framing characters.
+
+            Discontinuities in the value of this counter can occur at
+            re-initialization of the management system, and at other
+            times as indicated by the value of
+            ifCounterDiscontinuityTime."
+    ::= { ifEntry 10 }
+
+ifInUcastPkts OBJECT-TYPE
+    SYNTAX      Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "The number of packets, delivered by this sub-layer to a
+            higher (sub-)layer, which were not addressed to a multicast
+            or broadcast address at this sub-layer.
+
+            Discontinuities in the value of this counter can occur at
+            re-initialization of the management system, and at other
+            times as indicated by the value of
+            ifCounterDiscontinuityTime."
+    ::= { ifEntry 11 }
+
+ifInNUcastPkts OBJECT-TYPE
+    SYNTAX  Counter32
+    MAX-ACCESS  read-only
+    STATUS      deprecated
+    DESCRIPTION
+            "The number of packets, delivered by this sub-layer to a
+            higher (sub-)layer, which were addressed to a multicast or
+            broadcast address at this sub-layer.
+
+            Discontinuities in the value of this counter can occur at
+            re-initialization of the management system, and at other
+            times as indicated by the value of
+            ifCounterDiscontinuityTime.
+
+            This object is deprecated in favour of ifInMulticastPkts and
+            ifInBroadcastPkts."
+    ::= { ifEntry 12 }
+
+ifInDiscards OBJECT-TYPE
+    SYNTAX      Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "The number of inbound packets which were chosen to be
+            discarded even though no errors had been detected to prevent
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 33]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+            their being deliverable to a higher-layer protocol.  One
+            possible reason for discarding such a packet could be to
+            free up buffer space.
+
+            Discontinuities in the value of this counter can occur at
+            re-initialization of the management system, and at other
+            times as indicated by the value of
+            ifCounterDiscontinuityTime."
+    ::= { ifEntry 13 }
+
+ifInErrors OBJECT-TYPE
+    SYNTAX      Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "For packet-oriented interfaces, the number of inbound
+            packets that contained errors preventing them from being
+            deliverable to a higher-layer protocol.  For character-
+            oriented or fixed-length interfaces, the number of inbound
+            transmission units that contained errors preventing them
+            from being deliverable to a higher-layer protocol.
+
+            Discontinuities in the value of this counter can occur at
+            re-initialization of the management system, and at other
+            times as indicated by the value of
+            ifCounterDiscontinuityTime."
+    ::= { ifEntry 14 }
+
+ifInUnknownProtos OBJECT-TYPE
+    SYNTAX      Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "For packet-oriented interfaces, the number of packets
+            received via the interface which were discarded because of
+            an unknown or unsupported protocol.  For character-oriented
+            or fixed-length interfaces that support protocol
+            multiplexing the number of transmission units received via
+            the interface which were discarded because of an unknown or
+            unsupported protocol.  For any interface that does not
+            support protocol multiplexing, this counter will always be
+            0.
+
+            Discontinuities in the value of this counter can occur at
+            re-initialization of the management system, and at other
+            times as indicated by the value of
+            ifCounterDiscontinuityTime."
+    ::= { ifEntry 15 }
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 34]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+ifOutOctets OBJECT-TYPE
+    SYNTAX      Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "The total number of octets transmitted out of the
+            interface, including framing characters.
+
+            Discontinuities in the value of this counter can occur at
+            re-initialization of the management system, and at other
+            times as indicated by the value of
+            ifCounterDiscontinuityTime."
+    ::= { ifEntry 16 }
+
+ifOutUcastPkts OBJECT-TYPE
+    SYNTAX      Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "The total number of packets that higher-level protocols
+            requested be transmitted, and which were not addressed to a
+            multicast or broadcast address at this sub-layer, including
+            those that were discarded or not sent.
+
+            Discontinuities in the value of this counter can occur at
+            re-initialization of the management system, and at other
+            times as indicated by the value of
+            ifCounterDiscontinuityTime."
+    ::= { ifEntry 17 }
+
+ifOutNUcastPkts OBJECT-TYPE
+    SYNTAX      Counter32
+    MAX-ACCESS  read-only
+    STATUS      deprecated
+    DESCRIPTION
+            "The total number of packets that higher-level protocols
+            requested be transmitted, and which were addressed to a
+            multicast or broadcast address at this sub-layer, including
+            those that were discarded or not sent.
+
+            Discontinuities in the value of this counter can occur at
+            re-initialization of the management system, and at other
+            times as indicated by the value of
+            ifCounterDiscontinuityTime.
+
+            This object is deprecated in favour of ifOutMulticastPkts
+            and ifOutBroadcastPkts."
+    ::= { ifEntry 18 }
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 35]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+ifOutDiscards OBJECT-TYPE
+    SYNTAX      Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "The number of outbound packets which were chosen to be
+            discarded even though no errors had been detected to prevent
+            their being transmitted.  One possible reason for discarding
+            such a packet could be to free up buffer space.
+
+            Discontinuities in the value of this counter can occur at
+            re-initialization of the management system, and at other
+            times as indicated by the value of
+            ifCounterDiscontinuityTime."
+    ::= { ifEntry 19 }
+
+ifOutErrors OBJECT-TYPE
+    SYNTAX      Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "For packet-oriented interfaces, the number of outbound
+            packets that could not be transmitted because of errors.
+            For character-oriented or fixed-length interfaces, the
+            number of outbound transmission units that could not be
+            transmitted because of errors.
+
+            Discontinuities in the value of this counter can occur at
+            re-initialization of the management system, and at other
+            times as indicated by the value of
+            ifCounterDiscontinuityTime."
+    ::= { ifEntry 20 }
+
+ifOutQLen OBJECT-TYPE
+    SYNTAX      Gauge32
+    MAX-ACCESS  read-only
+    STATUS      deprecated
+    DESCRIPTION
+            "The length of the output packet queue (in packets)."
+    ::= { ifEntry 21 }
+
+ifSpecific OBJECT-TYPE
+    SYNTAX      OBJECT IDENTIFIER
+    MAX-ACCESS  read-only
+    STATUS      deprecated
+    DESCRIPTION
+            "A reference to MIB definitions specific to the particular
+            media being used to realize the interface.  It is
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 36]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+            recommended that this value point to an instance of a MIB
+            object in the media-specific MIB, i.e., that this object
+            have the semantics associated with the InstancePointer
+            textual convention defined in RFC 2579.  In fact, it is
+            recommended that the media-specific MIB specify what value
+            ifSpecific should/can take for values of ifType.  If no MIB
+            definitions specific to the particular media are available,
+            the value should be set to the OBJECT IDENTIFIER { 0 0 }."
+    ::= { ifEntry 22 }
+
+
+
+--
+--   Extension to the interface table
+--
+-- This table replaces the ifExtnsTable table.
+--
+
+ifXTable        OBJECT-TYPE
+    SYNTAX      SEQUENCE OF IfXEntry
+    MAX-ACCESS  not-accessible
+    STATUS      current
+    DESCRIPTION
+            "A list of interface entries.  The number of entries is
+            given by the value of ifNumber.  This table contains
+            additional objects for the interface table."
+    ::= { ifMIBObjects 1 }
+
+ifXEntry        OBJECT-TYPE
+    SYNTAX      IfXEntry
+    MAX-ACCESS  not-accessible
+    STATUS      current
+    DESCRIPTION
+            "An entry containing additional management information
+            applicable to a particular interface."
+    AUGMENTS    { ifEntry }
+    ::= { ifXTable 1 }
+
+IfXEntry ::=
+    SEQUENCE {
+        ifName                  DisplayString,
+        ifInMulticastPkts       Counter32,
+        ifInBroadcastPkts       Counter32,
+        ifOutMulticastPkts      Counter32,
+        ifOutBroadcastPkts      Counter32,
+        ifHCInOctets            Counter64,
+        ifHCInUcastPkts         Counter64,
+        ifHCInMulticastPkts     Counter64,
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 37]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+        ifHCInBroadcastPkts     Counter64,
+        ifHCOutOctets           Counter64,
+        ifHCOutUcastPkts        Counter64,
+        ifHCOutMulticastPkts    Counter64,
+        ifHCOutBroadcastPkts    Counter64,
+        ifLinkUpDownTrapEnable  INTEGER,
+        ifHighSpeed             Gauge32,
+        ifPromiscuousMode       TruthValue,
+        ifConnectorPresent      TruthValue,
+        ifAlias                 DisplayString,
+        ifCounterDiscontinuityTime TimeStamp
+    }
+
+
+ifName OBJECT-TYPE
+    SYNTAX      DisplayString
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "The textual name of the interface.  The value of this
+            object should be the name of the interface as assigned by
+            the local device and should be suitable for use in commands
+            entered at the device's `console'.  This might be a text
+            name, such as `le0' or a simple port number, such as `1',
+            depending on the interface naming syntax of the device.  If
+            several entries in the ifTable together represent a single
+            interface as named by the device, then each will have the
+            same value of ifName.  Note that for an agent which responds
+            to SNMP queries concerning an interface on some other
+            (proxied) device, then the value of ifName for such an
+            interface is the proxied device's local name for it.
+
+            If there is no local name, or this object is otherwise not
+            applicable, then this object contains a zero-length string."
+    ::= { ifXEntry 1 }
+
+ifInMulticastPkts OBJECT-TYPE
+    SYNTAX      Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "The number of packets, delivered by this sub-layer to a
+            higher (sub-)layer, which were addressed to a multicast
+            address at this sub-layer.  For a MAC layer protocol, this
+            includes both Group and Functional addresses.
+
+            Discontinuities in the value of this counter can occur at
+            re-initialization of the management system, and at other
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 38]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+            times as indicated by the value of
+            ifCounterDiscontinuityTime."
+    ::= { ifXEntry 2 }
+
+ifInBroadcastPkts OBJECT-TYPE
+    SYNTAX      Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "The number of packets, delivered by this sub-layer to a
+            higher (sub-)layer, which were addressed to a broadcast
+            address at this sub-layer.
+
+            Discontinuities in the value of this counter can occur at
+            re-initialization of the management system, and at other
+            times as indicated by the value of
+            ifCounterDiscontinuityTime."
+    ::= { ifXEntry 3 }
+
+ifOutMulticastPkts OBJECT-TYPE
+    SYNTAX      Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "The total number of packets that higher-level protocols
+            requested be transmitted, and which were addressed to a
+            multicast address at this sub-layer, including those that
+            were discarded or not sent.  For a MAC layer protocol, this
+            includes both Group and Functional addresses.
+
+            Discontinuities in the value of this counter can occur at
+            re-initialization of the management system, and at other
+            times as indicated by the value of
+            ifCounterDiscontinuityTime."
+    ::= { ifXEntry 4 }
+
+ifOutBroadcastPkts OBJECT-TYPE
+    SYNTAX      Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "The total number of packets that higher-level protocols
+            requested be transmitted, and which were addressed to a
+            broadcast address at this sub-layer, including those that
+            were discarded or not sent.
+
+            Discontinuities in the value of this counter can occur at
+            re-initialization of the management system, and at other
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 39]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+            times as indicated by the value of
+            ifCounterDiscontinuityTime."
+    ::= { ifXEntry 5 }
+
+--
+-- High Capacity Counter objects.  These objects are all
+-- 64 bit versions of the "basic" ifTable counters.  These
+-- objects all have the same basic semantics as their 32-bit
+-- counterparts, however, their syntax has been extended
+-- to 64 bits.
+--
+
+ifHCInOctets OBJECT-TYPE
+    SYNTAX      Counter64
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "The total number of octets received on the interface,
+            including framing characters.  This object is a 64-bit
+            version of ifInOctets.
+
+            Discontinuities in the value of this counter can occur at
+            re-initialization of the management system, and at other
+            times as indicated by the value of
+            ifCounterDiscontinuityTime."
+    ::= { ifXEntry 6 }
+
+ifHCInUcastPkts OBJECT-TYPE
+    SYNTAX      Counter64
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "The number of packets, delivered by this sub-layer to a
+            higher (sub-)layer, which were not addressed to a multicast
+            or broadcast address at this sub-layer.  This object is a
+            64-bit version of ifInUcastPkts.
+
+            Discontinuities in the value of this counter can occur at
+            re-initialization of the management system, and at other
+            times as indicated by the value of
+            ifCounterDiscontinuityTime."
+    ::= { ifXEntry 7 }
+
+ifHCInMulticastPkts OBJECT-TYPE
+    SYNTAX      Counter64
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 40]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+            "The number of packets, delivered by this sub-layer to a
+            higher (sub-)layer, which were addressed to a multicast
+            address at this sub-layer.  For a MAC layer protocol, this
+            includes both Group and Functional addresses.  This object
+            is a 64-bit version of ifInMulticastPkts.
+
+            Discontinuities in the value of this counter can occur at
+            re-initialization of the management system, and at other
+            times as indicated by the value of
+            ifCounterDiscontinuityTime."
+    ::= { ifXEntry 8 }
+
+ifHCInBroadcastPkts OBJECT-TYPE
+    SYNTAX      Counter64
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "The number of packets, delivered by this sub-layer to a
+            higher (sub-)layer, which were addressed to a broadcast
+            address at this sub-layer.  This object is a 64-bit version
+            of ifInBroadcastPkts.
+
+            Discontinuities in the value of this counter can occur at
+            re-initialization of the management system, and at other
+            times as indicated by the value of
+            ifCounterDiscontinuityTime."
+    ::= { ifXEntry 9 }
+
+ifHCOutOctets OBJECT-TYPE
+    SYNTAX      Counter64
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "The total number of octets transmitted out of the
+            interface, including framing characters.  This object is a
+            64-bit version of ifOutOctets.
+
+            Discontinuities in the value of this counter can occur at
+            re-initialization of the management system, and at other
+            times as indicated by the value of
+            ifCounterDiscontinuityTime."
+    ::= { ifXEntry 10 }
+
+ifHCOutUcastPkts OBJECT-TYPE
+    SYNTAX      Counter64
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 41]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+            "The total number of packets that higher-level protocols
+            requested be transmitted, and which were not addressed to a
+            multicast or broadcast address at this sub-layer, including
+            those that were discarded or not sent.  This object is a
+            64-bit version of ifOutUcastPkts.
+
+            Discontinuities in the value of this counter can occur at
+            re-initialization of the management system, and at other
+            times as indicated by the value of
+            ifCounterDiscontinuityTime."
+    ::= { ifXEntry 11 }
+
+ifHCOutMulticastPkts OBJECT-TYPE
+    SYNTAX      Counter64
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "The total number of packets that higher-level protocols
+            requested be transmitted, and which were addressed to a
+            multicast address at this sub-layer, including those that
+            were discarded or not sent.  For a MAC layer protocol, this
+            includes both Group and Functional addresses.  This object
+            is a 64-bit version of ifOutMulticastPkts.
+
+            Discontinuities in the value of this counter can occur at
+            re-initialization of the management system, and at other
+            times as indicated by the value of
+            ifCounterDiscontinuityTime."
+    ::= { ifXEntry 12 }
+
+ifHCOutBroadcastPkts OBJECT-TYPE
+    SYNTAX      Counter64
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "The total number of packets that higher-level protocols
+            requested be transmitted, and which were addressed to a
+            broadcast address at this sub-layer, including those that
+            were discarded or not sent.  This object is a 64-bit version
+            of ifOutBroadcastPkts.
+
+            Discontinuities in the value of this counter can occur at
+            re-initialization of the management system, and at other
+            times as indicated by the value of
+            ifCounterDiscontinuityTime."
+    ::= { ifXEntry 13 }
+
+ifLinkUpDownTrapEnable  OBJECT-TYPE
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 42]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+    SYNTAX      INTEGER { enabled(1), disabled(2) }
+    MAX-ACCESS  read-write
+    STATUS      current
+    DESCRIPTION
+            "Indicates whether linkUp/linkDown traps should be generated
+            for this interface.
+
+            By default, this object should have the value enabled(1) for
+            interfaces which do not operate on 'top' of any other
+            interface (as defined in the ifStackTable), and disabled(2)
+            otherwise."
+    ::= { ifXEntry 14 }
+
+ifHighSpeed OBJECT-TYPE
+    SYNTAX      Gauge32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "An estimate of the interface's current bandwidth in units
+            of 1,000,000 bits per second.  If this object reports a
+            value of `n' then the speed of the interface is somewhere in
+            the range of `n-500,000' to `n+499,999'.  For interfaces
+            which do not vary in bandwidth or for those where no
+            accurate estimation can be made, this object should contain
+            the nominal bandwidth.  For a sub-layer which has no concept
+            of bandwidth, this object should be zero."
+    ::= { ifXEntry 15 }
+
+ifPromiscuousMode  OBJECT-TYPE
+    SYNTAX      TruthValue
+    MAX-ACCESS  read-write
+    STATUS      current
+    DESCRIPTION
+            "This object has a value of false(2) if this interface only
+            accepts packets/frames that are addressed to this station.
+            This object has a value of true(1) when the station accepts
+            all packets/frames transmitted on the media.  The value
+            true(1) is only legal on certain types of media.  If legal,
+            setting this object to a value of true(1) may require the
+            interface to be reset before becoming effective.
+
+            The value of ifPromiscuousMode does not affect the reception
+            of broadcast and multicast packets/frames by the interface."
+    ::= { ifXEntry 16 }
+
+ifConnectorPresent   OBJECT-TYPE
+    SYNTAX      TruthValue
+    MAX-ACCESS  read-only
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 43]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+    STATUS      current
+    DESCRIPTION
+            "This object has the value 'true(1)' if the interface
+            sublayer has a physical connector and the value 'false(2)'
+            otherwise."
+    ::= { ifXEntry 17 }
+
+ifAlias   OBJECT-TYPE
+    SYNTAX      DisplayString (SIZE(0..64))
+    MAX-ACCESS  read-write
+    STATUS      current
+    DESCRIPTION
+            "This object is an 'alias' name for the interface as
+            specified by a network manager, and provides a non-volatile
+            'handle' for the interface.
+
+            On the first instantiation of an interface, the value of
+            ifAlias associated with that interface is the zero-length
+            string.  As and when a value is written into an instance of
+            ifAlias through a network management set operation, then the
+            agent must retain the supplied value in the ifAlias instance
+            associated with the same interface for as long as that
+            interface remains instantiated, including across all re-
+            initializations/reboots of the network management system,
+            including those which result in a change of the interface's
+            ifIndex value.
+
+            An example of the value which a network manager might store
+            in this object for a WAN interface is the (Telco's) circuit
+            number/identifier of the interface.
+
+            Some agents may support write-access only for interfaces
+            having particular values of ifType.  An agent which supports
+            write access to this object is required to keep the value in
+            non-volatile storage, but it may limit the length of new
+            values depending on how much storage is already occupied by
+            the current values for other interfaces."
+    ::= { ifXEntry 18 }
+
+ifCounterDiscontinuityTime OBJECT-TYPE
+    SYNTAX      TimeStamp
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+            "The value of sysUpTime on the most recent occasion at which
+            any one or more of this interface's counters suffered a
+            discontinuity.  The relevant counters are the specific
+            instances associated with this interface of any Counter32 or
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 44]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+            Counter64 object contained in the ifTable or ifXTable.  If
+            no such discontinuities have occurred since the last re-
+            initialization of the local management subsystem, then this
+            object contains a zero value."
+    ::= { ifXEntry 19 }
+
+--           The Interface Stack Group
+--
+-- Implementation of this group is optional, but strongly recommended
+-- for all systems
+--
+
+ifStackTable  OBJECT-TYPE
+     SYNTAX        SEQUENCE OF IfStackEntry
+     MAX-ACCESS    not-accessible
+     STATUS        current
+     DESCRIPTION
+            "The table containing information on the relationships
+            between the multiple sub-layers of network interfaces.  In
+            particular, it contains information on which sub-layers run
+            'on top of' which other sub-layers, where each sub-layer
+            corresponds to a conceptual row in the ifTable.  For
+            example, when the sub-layer with ifIndex value x runs over
+            the sub-layer with ifIndex value y, then this table
+            contains:
+
+              ifStackStatus.x.y=active
+
+            For each ifIndex value, I, which identifies an active
+            interface, there are always at least two instantiated rows
+            in this table associated with I.  For one of these rows, I
+            is the value of ifStackHigherLayer; for the other, I is the
+            value of ifStackLowerLayer.  (If I is not involved in
+            multiplexing, then these are the only two rows associated
+            with I.)
+
+            For example, two rows exist even for an interface which has
+            no others stacked on top or below it:
+
+              ifStackStatus.0.x=active
+              ifStackStatus.x.0=active "
+     ::= { ifMIBObjects 2 }
+
+
+ifStackEntry  OBJECT-TYPE
+     SYNTAX        IfStackEntry
+     MAX-ACCESS    not-accessible
+     STATUS        current
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 45]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+     DESCRIPTION
+            "Information on a particular relationship between two sub-
+            layers, specifying that one sub-layer runs on 'top' of the
+            other sub-layer.  Each sub-layer corresponds to a conceptual
+            row in the ifTable."
+     INDEX { ifStackHigherLayer, ifStackLowerLayer }
+     ::= { ifStackTable 1 }
+
+
+IfStackEntry ::=
+    SEQUENCE {
+        ifStackHigherLayer  InterfaceIndexOrZero,
+        ifStackLowerLayer   InterfaceIndexOrZero,
+        ifStackStatus       RowStatus
+     }
+
+
+ifStackHigherLayer  OBJECT-TYPE
+     SYNTAX        InterfaceIndexOrZero
+     MAX-ACCESS    not-accessible
+     STATUS        current
+     DESCRIPTION
+            "The value of ifIndex corresponding to the higher sub-layer
+            of the relationship, i.e., the sub-layer which runs on 'top'
+            of the sub-layer identified by the corresponding instance of
+            ifStackLowerLayer.  If there is no higher sub-layer (below
+            the internetwork layer), then this object has the value 0."
+     ::= { ifStackEntry 1 }
+
+
+ifStackLowerLayer  OBJECT-TYPE
+     SYNTAX        InterfaceIndexOrZero
+     MAX-ACCESS    not-accessible
+     STATUS        current
+     DESCRIPTION
+            "The value of ifIndex corresponding to the lower sub-layer
+            of the relationship, i.e., the sub-layer which runs 'below'
+            the sub-layer identified by the corresponding instance of
+            ifStackHigherLayer.  If there is no lower sub-layer, then
+            this object has the value 0."
+     ::= { ifStackEntry 2 }
+
+
+ifStackStatus  OBJECT-TYPE
+    SYNTAX         RowStatus
+    MAX-ACCESS     read-create
+    STATUS         current
+    DESCRIPTION
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 46]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+            "The status of the relationship between two sub-layers.
+
+            Changing the value of this object from 'active' to
+            'notInService' or 'destroy' will likely have consequences up
+            and down the interface stack.  Thus, write access to this
+            object is likely to be inappropriate for some types of
+            interfaces, and many implementations will choose not to
+            support write-access for any type of interface."
+    ::= { ifStackEntry 3 }
+
+ifStackLastChange OBJECT-TYPE
+    SYNTAX         TimeTicks
+    MAX-ACCESS     read-only
+    STATUS         current
+    DESCRIPTION
+            "The value of sysUpTime at the time of the last change of
+            the (whole) interface stack.  A change of the interface
+            stack is defined to be any creation, deletion, or change in
+            value of any instance of ifStackStatus.  If the interface
+            stack has been unchanged since the last re-initialization of
+            the local network management subsystem, then this object
+            contains a zero value."
+    ::= { ifMIBObjects 6 }
+
+
+--   Generic Receive Address Table
+--
+-- This group of objects is mandatory for all types of
+-- interfaces which can receive packets/frames addressed to
+-- more than one address.
+--
+-- This table replaces the ifExtnsRcvAddr table.  The main
+-- difference is that this table makes use of the RowStatus
+-- textual convention, while ifExtnsRcvAddr did not.
+
+ifRcvAddressTable  OBJECT-TYPE
+    SYNTAX      SEQUENCE OF IfRcvAddressEntry
+    MAX-ACCESS  not-accessible
+    STATUS      current
+    DESCRIPTION
+            "This table contains an entry for each address (broadcast,
+            multicast, or uni-cast) for which the system will receive
+            packets/frames on a particular interface, except as follows:
+
+            - for an interface operating in promiscuous mode, entries
+            are only required for those addresses for which the system
+            would receive frames were it not operating in promiscuous
+            mode.
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 47]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+            - for 802.5 functional addresses, only one entry is
+            required, for the address which has the functional address
+            bit ANDed with the bit mask of all functional addresses for
+            which the interface will accept frames.
+
+            A system is normally able to use any unicast address which
+            corresponds to an entry in this table as a source address."
+    ::= { ifMIBObjects 4 }
+
+ifRcvAddressEntry  OBJECT-TYPE
+    SYNTAX      IfRcvAddressEntry
+    MAX-ACCESS  not-accessible
+    STATUS      current
+    DESCRIPTION
+            "A list of objects identifying an address for which the
+            system will accept packets/frames on the particular
+            interface identified by the index value ifIndex."
+    INDEX  { ifIndex, ifRcvAddressAddress }
+    ::= { ifRcvAddressTable 1 }
+
+IfRcvAddressEntry ::=
+    SEQUENCE {
+        ifRcvAddressAddress   PhysAddress,
+        ifRcvAddressStatus    RowStatus,
+        ifRcvAddressType      INTEGER
+    }
+
+ifRcvAddressAddress OBJECT-TYPE
+    SYNTAX      PhysAddress
+    MAX-ACCESS  not-accessible
+    STATUS      current
+    DESCRIPTION
+            "An address for which the system will accept packets/frames
+            on this entry's interface."
+    ::= { ifRcvAddressEntry 1 }
+
+ifRcvAddressStatus OBJECT-TYPE
+    SYNTAX      RowStatus
+    MAX-ACCESS  read-create
+    STATUS      current
+    DESCRIPTION
+            "This object is used to create and delete rows in the
+            ifRcvAddressTable."
+
+    ::= { ifRcvAddressEntry 2 }
+
+ifRcvAddressType OBJECT-TYPE
+    SYNTAX      INTEGER {
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 48]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+                    other(1),
+                    volatile(2),
+                    nonVolatile(3)
+                }
+
+    MAX-ACCESS  read-create
+    STATUS      current
+    DESCRIPTION
+            "This object has the value nonVolatile(3) for those entries
+            in the table which are valid and will not be deleted by the
+            next restart of the managed system.  Entries having the
+            value volatile(2) are valid and exist, but have not been
+            saved, so that will not exist after the next restart of the
+            managed system.  Entries having the value other(1) are valid
+            and exist but are not classified as to whether they will
+            continue to exist after the next restart."
+
+    DEFVAL  { volatile }
+    ::= { ifRcvAddressEntry 3 }
+
+-- definition of interface-related traps.
+
+linkDown NOTIFICATION-TYPE
+    OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
+    STATUS  current
+    DESCRIPTION
+            "A linkDown trap signifies that the SNMP entity, acting in
+            an agent role, has detected that the ifOperStatus object for
+            one of its communication links is about to enter the down
+            state from some other state (but not from the notPresent
+            state).  This other state is indicated by the included value
+            of ifOperStatus."
+    ::= { snmpTraps 3 }
+
+linkUp NOTIFICATION-TYPE
+    OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
+    STATUS  current
+    DESCRIPTION
+            "A linkUp trap signifies that the SNMP entity, acting in an
+            agent role, has detected that the ifOperStatus object for
+            one of its communication links left the down state and
+            transitioned into some other state (but not into the
+            notPresent state).  This other state is indicated by the
+            included value of ifOperStatus."
+    ::= { snmpTraps 4 }
+
+-- conformance information
+
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 49]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+ifConformance OBJECT IDENTIFIER ::= { ifMIB 2 }
+
+ifGroups      OBJECT IDENTIFIER ::= { ifConformance 1 }
+ifCompliances OBJECT IDENTIFIER ::= { ifConformance 2 }
+
+
+-- compliance statements
+
+ifCompliance3 MODULE-COMPLIANCE
+    STATUS  current
+    DESCRIPTION
+            "The compliance statement for SNMP entities which have
+            network interfaces."
+
+    MODULE  -- this module
+        MANDATORY-GROUPS { ifGeneralInformationGroup,
+                           linkUpDownNotificationsGroup }
+
+-- The groups:
+--        ifFixedLengthGroup
+--        ifHCFixedLengthGroup
+--        ifPacketGroup
+--        ifHCPacketGroup
+--        ifVHCPacketGroup
+-- are mutually exclusive; at most one of these groups is implemented
+-- for a particular interface.  When any of these groups is implemented
+-- for a particular interface, then ifCounterDiscontinuityGroup must
+-- also be implemented for that interface.
+
+
+        GROUP       ifFixedLengthGroup
+        DESCRIPTION
+            "This group is mandatory for those network interfaces which
+            are character-oriented or transmit data in fixed-length
+            transmission units, and for which the value of the
+            corresponding instance of ifSpeed is less than or equal to
+            20,000,000 bits/second."
+
+        GROUP       ifHCFixedLengthGroup
+        DESCRIPTION
+            "This group is mandatory for those network interfaces which
+            are character-oriented or transmit data in fixed-length
+            transmission units, and for which the value of the
+            corresponding instance of ifSpeed is greater than 20,000,000
+            bits/second."
+
+        GROUP       ifPacketGroup
+        DESCRIPTION
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 50]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+            "This group is mandatory for those network interfaces which
+            are packet-oriented, and for which the value of the
+            corresponding instance of ifSpeed is less than or equal to
+            20,000,000 bits/second."
+
+        GROUP       ifHCPacketGroup
+        DESCRIPTION
+            "This group is mandatory only for those network interfaces
+            which are packet-oriented and for which the value of the
+            corresponding instance of ifSpeed is greater than 20,000,000
+            bits/second but less than or equal to 650,000,000
+            bits/second."
+
+        GROUP       ifVHCPacketGroup
+        DESCRIPTION
+            "This group is mandatory only for those network interfaces
+            which are packet-oriented and for which the value of the
+            corresponding instance of ifSpeed is greater than
+            650,000,000 bits/second."
+
+
+        GROUP       ifCounterDiscontinuityGroup
+        DESCRIPTION
+            "This group is mandatory for those network interfaces that
+            are required to maintain counters (i.e., those for which one
+            of the ifFixedLengthGroup, ifHCFixedLengthGroup,
+            ifPacketGroup, ifHCPacketGroup, or ifVHCPacketGroup is
+            mandatory)."
+
+
+        GROUP       ifRcvAddressGroup
+        DESCRIPTION
+            "The applicability of this group MUST be defined by the
+            media-specific MIBs.  Media-specific MIBs must define the
+            exact meaning, use, and semantics of the addresses in this
+            group."
+
+        OBJECT      ifLinkUpDownTrapEnable
+        MIN-ACCESS  read-only
+        DESCRIPTION
+            "Write access is not required."
+
+        OBJECT      ifPromiscuousMode
+        MIN-ACCESS  read-only
+        DESCRIPTION
+            "Write access is not required."
+
+        OBJECT       ifAdminStatus
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 51]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+        SYNTAX       INTEGER { up(1), down(2) }
+        MIN-ACCESS   read-only
+        DESCRIPTION
+            "Write access is not required, nor is support for the value
+            testing(3)."
+
+        OBJECT       ifAlias
+        MIN-ACCESS   read-only
+        DESCRIPTION
+            "Write access is not required."
+
+    ::= { ifCompliances 3 }
+
+-- units of conformance
+
+ifGeneralInformationGroup    OBJECT-GROUP
+    OBJECTS { ifIndex, ifDescr, ifType, ifSpeed, ifPhysAddress,
+              ifAdminStatus, ifOperStatus, ifLastChange,
+              ifLinkUpDownTrapEnable, ifConnectorPresent,
+              ifHighSpeed, ifName, ifNumber, ifAlias,
+              ifTableLastChange }
+    STATUS  current
+    DESCRIPTION
+            "A collection of objects providing information applicable to
+            all network interfaces."
+    ::= { ifGroups 10 }
+
+-- the following five groups are mutually exclusive; at most
+-- one of these groups is implemented for any interface
+
+ifFixedLengthGroup    OBJECT-GROUP
+    OBJECTS { ifInOctets, ifOutOctets, ifInUnknownProtos,
+              ifInErrors, ifOutErrors }
+    STATUS  current
+    DESCRIPTION
+            "A collection of objects providing information specific to
+            non-high speed (non-high speed interfaces transmit and
+            receive at speeds less than or equal to 20,000,000
+            bits/second) character-oriented or fixed-length-transmission
+            network interfaces."
+    ::= { ifGroups 2 }
+
+ifHCFixedLengthGroup    OBJECT-GROUP
+    OBJECTS { ifHCInOctets, ifHCOutOctets,
+              ifInOctets, ifOutOctets, ifInUnknownProtos,
+              ifInErrors, ifOutErrors }
+    STATUS  current
+    DESCRIPTION
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 52]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+            "A collection of objects providing information specific to
+            high speed (greater than 20,000,000 bits/second) character-
+            oriented or fixed-length-transmission network interfaces."
+    ::= { ifGroups 3 }
+
+ifPacketGroup    OBJECT-GROUP
+    OBJECTS { ifInOctets, ifOutOctets, ifInUnknownProtos,
+              ifInErrors, ifOutErrors,
+              ifMtu, ifInUcastPkts, ifInMulticastPkts,
+              ifInBroadcastPkts, ifInDiscards,
+              ifOutUcastPkts, ifOutMulticastPkts,
+              ifOutBroadcastPkts, ifOutDiscards,
+              ifPromiscuousMode }
+    STATUS  current
+    DESCRIPTION
+            "A collection of objects providing information specific to
+            non-high speed (non-high speed interfaces transmit and
+            receive at speeds less than or equal to 20,000,000
+            bits/second) packet-oriented network interfaces."
+    ::= { ifGroups 4 }
+
+ifHCPacketGroup    OBJECT-GROUP
+    OBJECTS { ifHCInOctets, ifHCOutOctets,
+              ifInOctets, ifOutOctets, ifInUnknownProtos,
+              ifInErrors, ifOutErrors,
+              ifMtu, ifInUcastPkts, ifInMulticastPkts,
+              ifInBroadcastPkts, ifInDiscards,
+              ifOutUcastPkts, ifOutMulticastPkts,
+              ifOutBroadcastPkts, ifOutDiscards,
+              ifPromiscuousMode }
+    STATUS  current
+    DESCRIPTION
+            "A collection of objects providing information specific to
+            high speed (greater than 20,000,000 bits/second but less
+            than or equal to 650,000,000 bits/second) packet-oriented
+            network interfaces."
+    ::= { ifGroups 5 }
+
+ifVHCPacketGroup    OBJECT-GROUP
+    OBJECTS { ifHCInUcastPkts, ifHCInMulticastPkts,
+              ifHCInBroadcastPkts, ifHCOutUcastPkts,
+              ifHCOutMulticastPkts, ifHCOutBroadcastPkts,
+              ifHCInOctets, ifHCOutOctets,
+              ifInOctets, ifOutOctets, ifInUnknownProtos,
+              ifInErrors, ifOutErrors,
+              ifMtu, ifInUcastPkts, ifInMulticastPkts,
+              ifInBroadcastPkts, ifInDiscards,
+              ifOutUcastPkts, ifOutMulticastPkts,
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 53]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+              ifOutBroadcastPkts, ifOutDiscards,
+              ifPromiscuousMode }
+    STATUS  current
+    DESCRIPTION
+            "A collection of objects providing information specific to
+            higher speed (greater than 650,000,000 bits/second) packet-
+            oriented network interfaces."
+    ::= { ifGroups 6 }
+
+ifRcvAddressGroup    OBJECT-GROUP
+    OBJECTS { ifRcvAddressStatus, ifRcvAddressType }
+    STATUS  current
+    DESCRIPTION
+            "A collection of objects providing information on the
+            multiple addresses which an interface receives."
+    ::= { ifGroups 7 }
+
+ifStackGroup2    OBJECT-GROUP
+    OBJECTS { ifStackStatus, ifStackLastChange }
+    STATUS  current
+    DESCRIPTION
+            "A collection of objects providing information on the
+            layering of MIB-II interfaces."
+    ::= { ifGroups 11 }
+
+ifCounterDiscontinuityGroup  OBJECT-GROUP
+    OBJECTS { ifCounterDiscontinuityTime }
+    STATUS  current
+    DESCRIPTION
+            "A collection of objects providing information specific to
+            interface counter discontinuities."
+    ::= { ifGroups 13 }
+
+linkUpDownNotificationsGroup  NOTIFICATION-GROUP
+    NOTIFICATIONS { linkUp, linkDown }
+    STATUS  current
+    DESCRIPTION
+            "The notifications which indicate specific changes in the
+            value of ifOperStatus."
+    ::= { ifGroups 14 }
+
+-- Deprecated Definitions - Objects
+
+
+--
+--    The Interface Test Table
+--
+-- This group of objects is optional.  However, a media-specific
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 54]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+-- MIB may make implementation of this group mandatory.
+--
+-- This table replaces the ifExtnsTestTable
+--
+
+ifTestTable   OBJECT-TYPE
+    SYNTAX      SEQUENCE OF IfTestEntry
+    MAX-ACCESS  not-accessible
+    STATUS      deprecated
+    DESCRIPTION
+            "This table contains one entry per interface.  It defines
+            objects which allow a network manager to instruct an agent
+            to test an interface for various faults.  Tests for an
+            interface are defined in the media-specific MIB for that
+            interface.  After invoking a test, the object ifTestResult
+            can be read to determine the outcome.  If an agent can not
+            perform the test, ifTestResult is set to so indicate.  The
+            object ifTestCode can be used to provide further test-
+            specific or interface-specific (or even enterprise-specific)
+            information concerning the outcome of the test.  Only one
+            test can be in progress on each interface at any one time.
+            If one test is in progress when another test is invoked, the
+            second test is rejected.  Some agents may reject a test when
+            a prior test is active on another interface.
+
+            Before starting a test, a manager-station must first obtain
+            'ownership' of the entry in the ifTestTable for the
+            interface to be tested.  This is accomplished with the
+            ifTestId and ifTestStatus objects as follows:
+
+          try_again:
+              get (ifTestId, ifTestStatus)
+              while (ifTestStatus != notInUse)
+                  /*
+                   * Loop while a test is running or some other
+                   * manager is configuring a test.
+                   */
+                  short delay
+                  get (ifTestId, ifTestStatus)
+              }
+
+              /*
+               * Is not being used right now -- let's compete
+               * to see who gets it.
+               */
+              lock_value = ifTestId
+
+              if ( set(ifTestId = lock_value, ifTestStatus = inUse,
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 55]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+                       ifTestOwner = 'my-IP-address') == FAILURE)
+                  /*
+                   * Another manager got the ifTestEntry -- go
+                   * try again
+                   */
+                  goto try_again;
+
+              /*
+               * I have the lock
+               */
+              set up any test parameters.
+
+              /*
+               * This starts the test
+               */
+              set(ifTestType = test_to_run);
+
+              wait for test completion by polling ifTestResult
+
+              when test completes, agent sets ifTestResult
+                   agent also sets ifTestStatus = 'notInUse'
+
+              retrieve any additional test results, and ifTestId
+
+              if (ifTestId == lock_value+1) results are valid
+
+            A manager station first retrieves the value of the
+            appropriate ifTestId and ifTestStatus objects, periodically
+            repeating the retrieval if necessary, until the value of
+            ifTestStatus is 'notInUse'.  The manager station then tries
+            to set the same ifTestId object to the value it just
+            retrieved, the same ifTestStatus object to 'inUse', and the
+            corresponding ifTestOwner object to a value indicating
+            itself.  If the set operation succeeds then the manager has
+            obtained ownership of the ifTestEntry, and the value of the
+            ifTestId object is incremented by the agent (per the
+            semantics of TestAndIncr).  Failure of the set operation
+            indicates that some other manager has obtained ownership of
+            the ifTestEntry.
+
+            Once ownership is obtained, any test parameters can be
+            setup, and then the test is initiated by setting ifTestType.
+            On completion of the test, the agent sets ifTestStatus to
+            'notInUse'.  Once this occurs, the manager can retrieve the
+            results.  In the (rare) event that the invocation of tests
+            by two network managers were to overlap, then there would be
+            a possibility that the first test's results might be
+            overwritten by the second test's results prior to the first
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 56]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+            results being read.  This unlikely circumstance can be
+            detected by a network manager retrieving ifTestId at the
+            same time as retrieving the test results, and ensuring that
+            the results are for the desired request.
+
+            If ifTestType is not set within an abnormally long period of
+            time after ownership is obtained, the agent should time-out
+            the manager, and reset the value of the ifTestStatus object
+            back to 'notInUse'.  It is suggested that this time-out
+            period be 5 minutes.
+
+            In general, a management station must not retransmit a
+            request to invoke a test for which it does not receive a
+            response; instead, it properly inspects an agent's MIB to
+            determine if the invocation was successful.  Only if the
+            invocation was unsuccessful, is the invocation request
+            retransmitted.
+
+            Some tests may require the interface to be taken off-line in
+            order to execute them, or may even require the agent to
+            reboot after completion of the test.  In these
+            circumstances, communication with the management station
+            invoking the test may be lost until after completion of the
+            test.  An agent is not required to support such tests.
+            However, if such tests are supported, then the agent should
+            make every effort to transmit a response to the request
+            which invoked the test prior to losing communication.  When
+            the agent is restored to normal service, the results of the
+            test are properly made available in the appropriate objects.
+            Note that this requires that the ifIndex value assigned to
+            an interface must be unchanged even if the test causes a
+            reboot.  An agent must reject any test for which it cannot,
+            perhaps due to resource constraints, make available at least
+            the minimum amount of information after that test
+            completes."
+    ::= { ifMIBObjects 3 }
+
+ifTestEntry OBJECT-TYPE
+    SYNTAX       IfTestEntry
+    MAX-ACCESS   not-accessible
+    STATUS       deprecated
+    DESCRIPTION
+            "An entry containing objects for invoking tests on an
+            interface."
+    AUGMENTS  { ifEntry }
+    ::= { ifTestTable 1 }
+
+IfTestEntry ::=
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 57]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+    SEQUENCE {
+        ifTestId           TestAndIncr,
+        ifTestStatus       INTEGER,
+        ifTestType         AutonomousType,
+        ifTestResult       INTEGER,
+        ifTestCode         OBJECT IDENTIFIER,
+        ifTestOwner        OwnerString
+    }
+
+ifTestId         OBJECT-TYPE
+    SYNTAX       TestAndIncr
+    MAX-ACCESS   read-write
+    STATUS       deprecated
+    DESCRIPTION
+            "This object identifies the current invocation of the
+            interface's test."
+    ::= { ifTestEntry 1 }
+
+ifTestStatus     OBJECT-TYPE
+    SYNTAX       INTEGER { notInUse(1), inUse(2) }
+    MAX-ACCESS   read-write
+    STATUS       deprecated
+    DESCRIPTION
+            "This object indicates whether or not some manager currently
+            has the necessary 'ownership' required to invoke a test on
+            this interface.  A write to this object is only successful
+            when it changes its value from 'notInUse(1)' to 'inUse(2)'.
+            After completion of a test, the agent resets the value back
+            to 'notInUse(1)'."
+    ::= { ifTestEntry 2 }
+
+ifTestType       OBJECT-TYPE
+    SYNTAX       AutonomousType
+    MAX-ACCESS   read-write
+    STATUS       deprecated
+    DESCRIPTION
+            "A control variable used to start and stop operator-
+            initiated interface tests.  Most OBJECT IDENTIFIER values
+            assigned to tests are defined elsewhere, in association with
+            specific types of interface.  However, this document assigns
+            a value for a full-duplex loopback test, and defines the
+            special meanings of the subject identifier:
+
+                noTest  OBJECT IDENTIFIER ::= { 0 0 }
+
+            When the value noTest is written to this object, no action
+            is taken unless a test is in progress, in which case the
+            test is aborted.  Writing any other value to this object is
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 58]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+            only valid when no test is currently in progress, in which
+            case the indicated test is initiated.
+
+            When read, this object always returns the most recent value
+            that ifTestType was set to.  If it has not been set since
+            the last initialization of the network management subsystem
+            on the agent, a value of noTest is returned."
+    ::= { ifTestEntry 3 }
+
+ifTestResult  OBJECT-TYPE
+    SYNTAX       INTEGER {
+                     none(1),          -- no test yet requested
+                     success(2),
+                     inProgress(3),
+                     notSupported(4),
+                     unAbleToRun(5),   -- due to state of system
+                     aborted(6),
+                     failed(7)
+                 }
+    MAX-ACCESS   read-only
+    STATUS       deprecated
+    DESCRIPTION
+            "This object contains the result of the most recently
+            requested test, or the value none(1) if no tests have been
+            requested since the last reset.  Note that this facility
+            provides no provision for saving the results of one test
+            when starting another, as could be required if used by
+            multiple managers concurrently."
+    ::= { ifTestEntry 4 }
+
+ifTestCode  OBJECT-TYPE
+    SYNTAX       OBJECT IDENTIFIER
+    MAX-ACCESS   read-only
+    STATUS       deprecated
+    DESCRIPTION
+            "This object contains a code which contains more specific
+            information on the test result, for example an error-code
+            after a failed test.  Error codes and other values this
+            object may take are specific to the type of interface and/or
+            test.  The value may have the semantics of either the
+            AutonomousType or InstancePointer textual conventions as
+            defined in RFC 2579.  The identifier:
+
+                testCodeUnknown  OBJECT IDENTIFIER ::= { 0 0 }
+
+            is defined for use if no additional result code is
+            available."
+    ::= { ifTestEntry 5 }
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 59]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+ifTestOwner      OBJECT-TYPE
+    SYNTAX       OwnerString
+    MAX-ACCESS   read-write
+    STATUS       deprecated
+    DESCRIPTION
+            "The entity which currently has the 'ownership' required to
+            invoke a test on this interface."
+    ::= { ifTestEntry 6 }
+
+-- Deprecated Definitions - Groups
+
+
+ifGeneralGroup    OBJECT-GROUP
+    OBJECTS { ifDescr, ifType, ifSpeed, ifPhysAddress,
+              ifAdminStatus, ifOperStatus, ifLastChange,
+              ifLinkUpDownTrapEnable, ifConnectorPresent,
+              ifHighSpeed, ifName }
+    STATUS  deprecated
+    DESCRIPTION
+            "A collection of objects deprecated in favour of
+            ifGeneralInformationGroup."
+    ::= { ifGroups 1 }
+
+
+ifTestGroup    OBJECT-GROUP
+    OBJECTS { ifTestId, ifTestStatus, ifTestType,
+              ifTestResult, ifTestCode, ifTestOwner }
+    STATUS  deprecated
+    DESCRIPTION
+            "A collection of objects providing the ability to invoke
+            tests on an interface."
+    ::= { ifGroups 8 }
+
+
+ifStackGroup    OBJECT-GROUP
+    OBJECTS { ifStackStatus }
+    STATUS  deprecated
+    DESCRIPTION
+            "The previous collection of objects providing information on
+            the layering of MIB-II interfaces."
+    ::= { ifGroups 9 }
+
+
+ifOldObjectsGroup    OBJECT-GROUP
+    OBJECTS { ifInNUcastPkts, ifOutNUcastPkts,
+              ifOutQLen, ifSpecific }
+    STATUS  deprecated
+    DESCRIPTION
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 60]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+            "The collection of objects deprecated from the original MIB-
+            II interfaces group."
+    ::= { ifGroups 12 }
+
+-- Deprecated Definitions - Compliance
+
+ifCompliance MODULE-COMPLIANCE
+    STATUS  deprecated
+    DESCRIPTION
+            "A compliance statement defined in a previous version of
+            this MIB module, for SNMP entities which have network
+            interfaces."
+
+    MODULE  -- this module
+        MANDATORY-GROUPS { ifGeneralGroup, ifStackGroup }
+
+        GROUP       ifFixedLengthGroup
+        DESCRIPTION
+            "This group is mandatory for all network interfaces which
+            are character-oriented or transmit data in fixed-length
+            transmission units."
+
+        GROUP       ifHCFixedLengthGroup
+        DESCRIPTION
+            "This group is mandatory only for those network interfaces
+            which are character-oriented or transmit data in fixed-
+            length transmission units, and for which the value of the
+            corresponding instance of ifSpeed is greater than 20,000,000
+            bits/second."
+
+        GROUP       ifPacketGroup
+        DESCRIPTION
+            "This group is mandatory for all network interfaces which
+            are packet-oriented."
+
+        GROUP       ifHCPacketGroup
+        DESCRIPTION
+            "This group is mandatory only for those network interfaces
+            which are packet-oriented and for which the value of the
+            corresponding instance of ifSpeed is greater than
+            650,000,000 bits/second."
+
+        GROUP       ifTestGroup
+        DESCRIPTION
+            "This group is optional.  Media-specific MIBs which require
+            interface tests are strongly encouraged to use this group
+            for invoking tests and reporting results.  A medium specific
+            MIB which has mandatory tests may make implementation of
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 61]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+            this group mandatory."
+
+        GROUP       ifRcvAddressGroup
+        DESCRIPTION
+            "The applicability of this group MUST be defined by the
+            media-specific MIBs.  Media-specific MIBs must define the
+            exact meaning, use, and semantics of the addresses in this
+            group."
+
+        OBJECT      ifLinkUpDownTrapEnable
+        MIN-ACCESS  read-only
+        DESCRIPTION
+            "Write access is not required."
+
+        OBJECT      ifPromiscuousMode
+        MIN-ACCESS  read-only
+        DESCRIPTION
+            "Write access is not required."
+
+        OBJECT      ifStackStatus
+        SYNTAX      INTEGER { active(1) } -- subset of RowStatus
+        MIN-ACCESS  read-only
+        DESCRIPTION
+            "Write access is not required, and only one of the six
+            enumerated values for the RowStatus textual convention need
+            be supported, specifically: active(1)."
+
+        OBJECT       ifAdminStatus
+        SYNTAX       INTEGER { up(1), down(2) }
+        MIN-ACCESS   read-only
+        DESCRIPTION
+            "Write access is not required, nor is support for the value
+            testing(3)."
+    ::= { ifCompliances 1 }
+
+ifCompliance2 MODULE-COMPLIANCE
+    STATUS      deprecated
+    DESCRIPTION
+            "A compliance statement defined in a previous version of
+            this MIB module, for SNMP entities which have network
+            interfaces."
+
+    MODULE  -- this module
+        MANDATORY-GROUPS { ifGeneralInformationGroup, ifStackGroup2,
+                           ifCounterDiscontinuityGroup }
+
+        GROUP       ifFixedLengthGroup
+        DESCRIPTION
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 62]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+            "This group is mandatory for all network interfaces which
+            are character-oriented or transmit data in fixed-length
+            transmission units."
+
+        GROUP       ifHCFixedLengthGroup
+        DESCRIPTION
+            "This group is mandatory only for those network interfaces
+            which are character-oriented or transmit data in fixed-
+            length transmission units, and for which the value of the
+            corresponding instance of ifSpeed is greater than 20,000,000
+            bits/second."
+
+        GROUP       ifPacketGroup
+        DESCRIPTION
+            "This group is mandatory for all network interfaces which
+            are packet-oriented."
+
+        GROUP       ifHCPacketGroup
+        DESCRIPTION
+            "This group is mandatory only for those network interfaces
+            which are packet-oriented and for which the value of the
+            corresponding instance of ifSpeed is greater than
+            650,000,000 bits/second."
+
+        GROUP       ifRcvAddressGroup
+        DESCRIPTION
+            "The applicability of this group MUST be defined by the
+            media-specific MIBs.  Media-specific MIBs must define the
+            exact meaning, use, and semantics of the addresses in this
+            group."
+
+        OBJECT      ifLinkUpDownTrapEnable
+        MIN-ACCESS  read-only
+        DESCRIPTION
+            "Write access is not required."
+
+        OBJECT      ifPromiscuousMode
+        MIN-ACCESS  read-only
+        DESCRIPTION
+            "Write access is not required."
+
+        OBJECT      ifStackStatus
+        SYNTAX      INTEGER { active(1) } -- subset of RowStatus
+        MIN-ACCESS  read-only
+        DESCRIPTION
+            "Write access is not required, and only one of the six
+            enumerated values for the RowStatus textual convention need
+            be supported, specifically: active(1)."
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 63]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+        OBJECT       ifAdminStatus
+        SYNTAX       INTEGER { up(1), down(2) }
+        MIN-ACCESS   read-only
+        DESCRIPTION
+            "Write access is not required, nor is support for the value
+            testing(3)."
+
+        OBJECT       ifAlias
+        MIN-ACCESS   read-only
+        DESCRIPTION
+            "Write access is not required."
+
+    ::= { ifCompliances 2 }
+
+END
+
+7.  Acknowledgements
+
+   This memo has been produced by the IETF's Interfaces MIB working-
+   group.
+
+   The original proposal evolved from conversations and discussions with
+   many people, including at least the following: Fred Baker, Ted
+   Brunner, Chuck Davin, Jeremy Greene, Marshall Rose, Kaj Tesink, and
+   Dean Throop.
+
+8.  References
+
+   [1]  Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for
+        Describing SNMP Management Frameworks", RFC 2571, April 1999.
+
+   [2]  Rose, M. and K. McCloghrie, "Structure and Identification of
+        Management Information for TCP/IP-based Internets", STD 16, RFC
+        1155, May 1990.
+
+   [3]  Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16,
+        RFC 1212, March 1991.
+
+   [4]  Rose, M., "A Convention for Defining Traps for use with the
+        SNMP", RFC 1215, March 1991.
+
+   [5]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
+        M.  and S. Waldbusser, "Structure of Management Information
+        Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
+
+   [6]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
+        M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58,
+        RFC 2579, April 1999.
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 64]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+   [7]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
+        M.  and S. Waldbusser, "Conformance Statements for SMIv2", STD
+        58, RFC 2580, April 1999.
+
+   [8]  Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
+        Network Management Protocol", STD 15, RFC 1157, May 1990.
+
+   [9]  Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
+        "Introduction to Community-based SNMPv2", RFC 1901, January
+        1996.
+
+   [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport
+        Mappings for Version 2 of the Simple Network Management Protocol
+        (SNMPv2)", RFC 1906, January 1996.
+
+   [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message
+        Processing and Dispatching for the Simple Network Management
+        Protocol (SNMP)", RFC 2572, January 1998.
+
+   [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
+        for version 3 of the Simple Network Management Protocol
+        (SNMPv3)", RFC 2574, January 1998.
+
+   [13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol
+        Operations for Version 2 of the Simple Network Management
+        Protocol (SNMPv2)", RFC 1905, January 1996.
+
+   [14] Levi, D., Meyer, P. and B. Stewart, "SMPv3 Applications", RFC
+        2573, January 1998.
+
+   [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
+        Control Model (VACM) for the Simple Network Management Protocol
+        (SNMP)", RFC 2575, January 1998.
+
+   [16] Bradner, S., "Key words for use in RFCs to Indicate Requirements
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [17] McCloghrie, K. and M. Rose, "Management Information Base for
+        Network Management of TCP/IP-based internets - MIB-II", STD 17.
+        RFC 1213, March 1991.
+
+   [18] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
+
+   [19] McCloghrie, K., "Extensions to the Generic-Interface MIB", RFC
+        1229, May 1991.
+
+
+
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 65]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+   [20] ATM Forum Technical Committee, "LAN Emulation Client Management:
+        Version 1.0 Specification", af-lane-0044.000, ATM Forum,
+        September 1995.
+
+   [21] Stewart, B., "Definitions of Managed Objects for Character
+        Stream Devices using SMIv2", RFC 1658, July 1994.
+
+   [22] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction
+        to Version 3 of the Internet-standard Network Management
+        Framework", RFC 2570, April 1999.
+
+   [23] McCloghrie, K. and F. Kastenholz, "Evolution of the Interfaces
+        Group of MIB-II", RFC 1573, January 1994.
+
+   [24] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB
+        using SMIv2", RFC 2233, November 1997.
+
+9.  Security Considerations
+
+   There are a number of management objects defined in this MIB that
+   have a MAX-ACCESS clause of read-write and/or read-create.  Such
+   objects may be considered sensitive or vulnerable in some network
+   environments.  The support for SET operations in a non-secure
+   environment without proper protection can have a negative effect on
+   network operations.
+
+   In particular, write-able objects allow an administrator to control
+   the interfaces and to perform tests on the interfaces, and
+   unauthorized access to these could cause a denial of service, or in
+   combination with other (e.g., physical) security breaches, could
+   cause unauthorized connectivity to a device.
+
+   SNMPv1 by itself is not a secure environment.  Even if the network
+   itself is secure (for example by using IPSec), even then, there is no
+   control as to who on the secure network is allowed to access and
+   GET/SET (read/change/create/delete) the objects in this MIB.
+
+   It is recommended that the implementers consider the security
+   features as provided by the SNMPv3 framework.  Specifically, the use
+   of the User-based Security Model RFC 2574 [12] and the View- based
+   Access Control Model RFC 2575 [15] is recommended.
+
+   It is then a customer/user responsibility to ensure that the SNMP
+   entity giving access to an instance of this MIB, is properly
+   configured to give access to the objects only to those principals
+   (users) that have legitimate rights to indeed GET or SET
+   (change/create/delete) them.
+
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 66]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+10.  Authors' Addresses
+
+   Keith McCloghrie
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA  95134-1706
+
+   Phone: 408-526-5260
+   EMail: kzm@cisco.com"
+
+
+   Frank Kastenholz
+   Argon Networks
+   25 Porter Rd
+   Littleton Ma 01460
+
+   Phone: (508)685-4000
+   EMail: kasten@argon.com
+
+11.  Changes from RFC 2233
+
+   Added linkUpDownNotificationsGroup.
+
+   Changed the status of the definition of OwnerString in this MIB to be
+   deprecated, because it is only used by ifTestOwner, which is now
+   deprecated, and because other MIBs should import OwnerString from RFC
+   1757 or its successors.
+
+   Added ifCompliance3 as a replacement for ifCompliance2 to omit the
+   ifStackGroup2 group, and add linkUpDownNotificationsGroup.  Also,
+   corrected the omission of ifVHCPacketGroup, and typos in the
+   DESCRIPTIONs of ifHCPacketGroup and ifFixedLengthGroup.  Obsoleted
+   ifCompliance2.
+
+   Modified syntax of ifStackHigherLayer and ifStackLowerLayer to be
+   InterfaceIndexOrZero.
+
+   Added requirement that media-specific MIB designers specify any
+   special conditions concerning the counting of framing characters in
+   ifInOctets and ifOutOctets.
+
+   Corrected a typo in the DESCRIPTION of the linkUp notification.
+
+   Modified the introductory SNMP Network Management Framework
+   boilerplate text.
+
+
+
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 67]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+12.  Notice on Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 68]
+
+RFC 2863                The Interfaces Group MIB               June 2000
+
+
+13.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McCloghrie & Kastenholz     Standards Track                    [Page 69]
+