doc: Add RFC documents

1 files changed, 3083 insertions, 0 deletions

diff --git a/doc/rfc/rfc1573.txt b/doc/rfc/rfc1573.txt
new file mode 100644
index 0000000..a60ab92
--- /dev/null
+++ b/doc/rfc/rfc1573.txt
@@ -0,0 +1,3083 @@
+
+
+
+
+
+
+Network Working Group                                      K. McCloghrie
+Request for Comments: 1573                            Hughes LAN Systems
+Obsoletes: 1229                                            F. Kastenholz
+Category: Standards Track                                   FTP Software
+                                                            January 1994
+
+
+              Evolution of the Interfaces Group of MIB-II
+
+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.
+
+Table of Contents
+
+   1. Introduction .............................................    2
+   2. The SNMPv2 Network Management Framework ..................    2
+   2.1 Object Definitions ......................................    3
+   3 Experience with the Interfaces Group ......................    3
+   3.1 Areas of Clarification/Revision .........................    3
+   3.1.1 Interface Numbering ...................................    4
+   3.1.2 Interface Sub-Layers ..................................    4
+   3.1.3 Virtual Circuits ......................................    5
+   3.1.4 Bit, Character, and Fixed-Length Interfaces ...........    5
+   3.1.5 Counter Size ..........................................    5
+   3.1.6 Interface Speed .......................................    6
+   3.1.7 Multicast/Broadcast Counters ..........................    6
+   3.1.8 Addition of New ifType values .........................    6
+   3.1.9 ifSpecific ............................................    6
+   3.2 Clarifications/Revisions ................................    7
+   3.2.1 Interface Numbering ...................................    7
+   3.2.2 Interface Sub-Layers ..................................    8
+   3.2.3 Guidance on Defining Sub-layers .......................   11
+   3.2.4 Virtual Circuits ......................................   12
+   3.2.5 Bit, Character, and Fixed-Length Interfaces ...........   12
+   3.2.6 Counter Size ..........................................   14
+   3.2.7 Interface Speed .......................................   16
+   3.2.8 Multicast/Broadcast Counters ..........................   16
+   3.2.9 Trap Enable ...........................................   17
+   3.2.10 Addition of New ifType values ........................   17
+   3.2.11 InterfaceIndex Textual Convention ....................   17
+   3.2.12 IfAdminStatus and IfOperStatus .......................   18
+   3.2.13 Traps ................................................   19
+   3.2.14 ifSpecific ...........................................   20
+
+
+
+McCloghrie & Kastenholz                                         [Page 1]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+   3.3 Media-Specific MIB Applicability ........................   20
+   4. Overview .................................................   21
+   5. IANAifType Definition ....................................   22
+   6. Interfaces Group Definitions .............................   24
+   7. Acknowledgements .........................................   53
+   8. References ...............................................   53
+   9. Security Considerations ..................................   55
+   10. Authors' Addresses.......................................   55
+
+1.  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, 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
+   proposes clarifications to, and extensions of, the architectural
+   issues within the current model used for the 'interfaces' group.
+
+   This memo also includes a MIB module.  As well as including new MIB
+   definitions to support the architectural extensions, this MIB module
+   also re-specifies the 'interfaces' group of MIB-II in a manner which
+   is both compliant to the SNMPv2 SMI and semantically-identical to the
+   existing SNMPv1-based definitions.
+
+2.  The SNMPv2 Network Management Framework
+
+   The SNMPv2 Network Management Framework consists of four major
+   components.  They are:
+
+      o    RFC 1442 which defines the SMI, the mechanisms used for
+           describing and naming objects for the purpose of management.
+
+      o    STD 17, RFC 1213 defines MIB-II, the core set of managed
+           objects for the Internet suite of protocols.
+
+      o    RFC 1445 which defines the administrative and other
+           architectural aspects of the framework.
+
+      o    RFC 1448 which defines the protocol used for network access
+           to managed objects.
+
+   The Framework permits new objects to be defined for the purpose of
+   experimentation and evaluation.
+
+
+
+McCloghrie & Kastenholz                                         [Page 2]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+2.1.  Object Definitions
+
+   Managed objects are accessed via a virtual information store, termed
+   the Management Information Base or MIB.  Objects in the MIB are
+   defined using the subset of Abstract Syntax Notation One (ASN.1)
+   defined in the SMI.  In particular, each object object type is named
+   by an OBJECT IDENTIFIER, an administratively assigned name.  The
+   object type together with an object instance serves to uniquely
+   identify a specific instantiation of the object.  For human
+   convenience, we often use a textual string, termed the descriptor, to
+   refer to the object type.
+
+3.  Experience with the Interfaces Group
+
+   One of the strengths of internetwork-layer protocols such as IP [6]
+   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 have assumed an evolution or loosening of
+   the model.  This memo is a proposal to document and standardize the
+   evolution of the model and to fill in the gaps caused by that
+   evolution.
+
+   A previous effort to extend the interfaces group resulted in the
+   publication of RFC 1229 [7].  As part of defining the evolution of
+   the interfaces group, this memo applies that evolution to, and
+   thereby incorporates, the RFC 1229 extensions.
+
+3.1.  Areas of Clarification/Revision
+
+   There are several areas for which experience indicates that
+   clarification, revision, or extension of the model would be helpful.
+   The next sections discuss these.
+
+
+
+
+McCloghrie & Kastenholz                                         [Page 3]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+3.1.1.  Interface 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."
+
+   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.
+
+3.1.2.  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, there is
+   still a lack of 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
+
+
+
+McCloghrie & Kastenholz                                         [Page 4]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+   the sub-layers.  An example of upward multiplexing is MLP (Multi-
+   Link-Procedure) which provides load-sharing over several serial 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,
+   all of which run over one fractional T1 channel, concurrently with
+   other uses of the T1 link.  The current MIB structure does not allow
+   for these sorts of relationships to be described.
+
+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.
+
+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.
+
+   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).
+
+3.1.5.  Counter Size
+
+   As the speed of network media increase, the minimum time in which a
+   32 bit counter will wrap decreases.  For example, on an Ethernet, a
+   stream of back-to-back, full-size packets will cause ifInOctets to
+   wrap in just over 57 minutes.  For a T3 line, the minimum wrap-time
+
+
+
+McCloghrie & Kastenholz                                         [Page 5]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+   is just over 12 minutes.  For FDDI, it will wrap in 5.7 minutes.  For
+   a 1-gigabit medium, the counter might wrap in as little as 34
+   seconds.  Requiring that interfaces be polled frequently enough not
+   to miss a counter wrap will be increasingly problematic.
+
+3.1.6.  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.4gbits.
+   Thus, ifSpeed will be of diminishing utility over the next several
+   years.
+
+3.1.7.  Multicast/Broadcast Counters
+
+   The counters in the ifTable for packets addressed to a multicast or
+   the broadcast address, are combined as counters of non-unicast
+   packets.  In contrast, the ifExtensions MIB [7] defines one set of
+   counters for multicast, and a separate set for broadcast packets.
+   With the separate counters, the original combined counters become
+   redundant.
+
+3.1.8.  Addition of New ifType values
+
+   Over time new ifType enumerated values have been needed for new
+   interface types.  With the syntax of ifType being defined in a MIB,
+   this requires the new MIB to be re-issued in order to define the new
+   values.  In the past, re-issuing of the MIB has occurred only after
+   several years.
+
+3.1.9.  ifSpecific
+
+   The original definition of the OBJECT IDENTIFIER value of ifSpecific
+   was not sufficently clear.  As a result, different implementors have
+   used it differently, and confusion has resulted.  Some
+   implementations have the value of ifSpecific be the OBJECT IDENTIFIER
+   that defines the media-specific MIB, i.e., the "foo" of:
+
+          foo OBJECT IDENTIFIER ::= { transmission xxx }
+
+   while others have it be the OBJECT IDENTIFIER of the table or entry
+   in the appropriate media-specific MIB (e.g. fooTable or fooEntry),
+   while still others have it be the OBJECT IDENTIFIER of the index
+   object of the table's row, including instance identifier (e.g.,
+   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,
+
+
+
+McCloghrie & Kastenholz                                         [Page 6]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+   indexing.
+
+3.2.  Clarifications/Revisions
+
+   The following clarifications and/or revisions are proposed.
+
+3.2.1.  Interface Numbering
+
+   One solution to the interface numbering problem would be to redefine
+   ifNumber to be the largest value of ifIndex, but the utility of such
+   an object is questionable, and such a re-definition would require
+   ifNumber to be deprecated.  Thus, an improvement would be to
+   deprecate ifNumber and not replace it.  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 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.  It could be argued that
+   this is a change in the semantics of ifIndex; however, all existing
+   implementations conform to this new definition, and in the interests
+   of not requiring changes in existing implementations and in the many
+   existing media-specific MIBs, it is proposed that this change does
+   not require ifIndex to be deprecated.
+
+   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 SNMPv2's
+   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 vital constancy requirement 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 a priori assignment of ifIndex values for all
+   possible interfaces which might be added dynamically.
+
+   The exact meaning of a "different" interface is hard to define, and
+   there will be gray areas.  One important criterion is that a
+   management station, not noticing that an interface has gone away and
+   another come into existence, should not be confused when it
+   calculates the difference between the counter values retrieved on
+   successive polls for a particular ifIndex value.  However, any firm
+   definition in this document would likely to turn out to be
+   inadequate.  Instead, the following guidelines are offered to allow
+
+
+
+McCloghrie & Kastenholz                                         [Page 7]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+   implementors to choose what "different" means in their particular
+   situation.
+
+   A previously-unused value of ifIndex should be assigned to a
+   dynamically added interface if:
+
+      (1)  the assignment of a previously-used ifIndex value to the
+           interface could result in a discontinuity in the values of
+           ifTable counters for that value of ifIndex; or,
+
+      (2)  an agent has no knowledge of whether the interface is the
+           "same" or "different" from a previous interface incarnation.
+
+   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.)
+
+   This proposed change introduces a new problem of its own.
+   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 removing the previous restrictions on the
+   values allowed for ifIndex, along with the interface sub-layer
+   concept (see the following section), mapping from interfaces to
+   physical ports becomes increasingly problematic.
+
+   To address this issue, a new object, ifName, is added to the MIB.
+   This object contains the device's name for the interface of which the
+   relevant entry in the ifTable is a component.  For example, if a
+   router has an interface named wan1, which is composed of PPP running
+   over an RS-232 port, the ifName objects for the corresponding PPP and
+   RS-232 entries in the ifTable will contain the string "wan1".
+
+3.2.2.  Interface Sub-Layers
+
+   One possible but not recommended solution to the problem of
+   representing multiple sub-layers would be to retain the concept of
+   one conceptual row for all the sub-layers of an interface and have
+
+
+
+McCloghrie & Kastenholz                                         [Page 8]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+   each media-specific MIB module identify its "superior" and
+   "subordinate" sub-layers through OBJECT IDENTIFIER "pointers".  The
+   drawbacks of this scheme are: 1) the superior/subordinate pointers
+   are contained in the media-specific MIB modules, and thus, a manager
+   could not learn the structure of an interface, without inspecting
+   multiple pointers in different MIB modules; this is overly complex
+   and only possible if the manager has knowledge of all the relevant
+   media-specific MIB modules; 2) current MIB modules would all need to
+   be retrofitted with these new "pointers"; 3) this scheme does not
+   adequately address the problem of upward and downward multiplexing;
+   and 4) enumerated values of ifType are needed for each combination of
+   sub-layers.
+
+   Another possible but not recommended scheme would be to retain the
+   concept of one conceptual row for all the sub-layers of an interface
+   and have a new separate MIB table to identify the "superior" and
+   "subordinate" sub-layers which contain OBJECT IDENTIFIER "pointers"
+   to media-specific MIB module(s) 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 does not support downward
+   multiplexing, such as PPP over MLP; since MLP makes two (or more)
+   serial lines appear to the layers above as a single physical
+   interface, PPP over MLP should appear to the internetwork-layer as a
+   single interface.  However, this scheme would result in two (or more)
+   conceptual rows in the ifTable and the internetwork-layer would run
+   over both of them.  This scheme also requires enumerated values of
+   ifType for each combination of sub-layers.
+
+   The solution adopted in 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 5 of this memo) 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.  It also
+   allows the IANAIfType to Media-Specific MIB mapping to identify the
+   media-specific MIB module for each sub- layer.  The new table
+   (ifStackTable) need be referenced only to obtain information about
+   layering.  Enumerated values for ifType are required for each sub-
+   layer only, not for combinations of them.
+
+   However, this solution does require that the descriptions of 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
+   the network layer, as at present).  It also requires that some
+   objects (specifically, ifSpeed) need to have appropriate values
+   identified for use when a generalized definition does not apply to a
+
+
+
+McCloghrie & Kastenholz                                         [Page 9]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+   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                                        [Page 10]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+      (3)  For sub-layers that are "at the top of" the interface stack,
+           a higher element in the network protocol stack.  For example,
+           for the purposes of this definition, the local IP module
+           would be considered the higher layer to an Ethernet
+           interface.
+
+3.2.3.  Guidance on Defining Sub-layers
+
+   The designer of a media-specific MIB must decide whether to divide
+   the interface into sub-layers, 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).
+
+   Note that the sub-layers of an interface on one device will sometimes
+   be different to the sub-layers of the interconnected interface of
+   another device.  A simple example of this is a frame-relay DTE
+   interface which connects to a frameRelayService interface, where the
+   DTE interface has a different ifType value and media-specific MIB to
+   the DCE interface.
+
+   Also note that a media-specific MIB may mandate that a particular
+
+
+
+McCloghrie & Kastenholz                                        [Page 11]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+   ifTable counter does not apply and that its value must always be 0,
+   signifying that the applicable event can not and does not occur for
+   that type of interface; for example, ifInMulticastPkts and
+   ifOutMulticastPkts on an interface type which has no multicast
+   capability.  In other circumstances, an agent must not always return
+   0 for any counter just because its implementation is incapable of
+   detecting occurrences of the particular event; instead, it must
+   return a noSuchName/noSuchObject error/exception when queried for the
+   counter, even if this prevents the implementation from complying with
+   the relevant MODULE-COMPLIANCE macro.
+
+   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 so doing, 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.2.4.  Virtual Circuits
+
+   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.2.5.  Bit, Character, and Fixed-Length Interfaces
+
+   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.
+
+   One possible but not recommended solution to this problem would be to
+   split the ifTable into two (or more) new MIB tables, one of which
+
+
+
+McCloghrie & Kastenholz                                        [Page 12]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+   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 SNMPv2 (in contrast to SNMPv1) refer to
+   object groups, where object groups are explicitly defined by listing
+   the objects they contain.  Thus, in SNMPv2, 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
+   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 ifGeneralGroup.  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.
+
+
+
+McCloghrie & Kastenholz                                        [Page 13]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+   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.2.6.  Counter Size
+
+   Two approaches to addressing the shrinking minimum counter-wrap time
+   problem were evaluated.  Counters could be scaled, for example,
+   ifInOctets could be changed to count received octets in, e.g., 1024
+   byte blocks.  Alternatively, the size of the counter could be
+   increased.
+
+   Scaling the counters was rejected.  While it provides acceptable
+   performance at high count rates, at low rates it suffers.  If there
+   is little traffic on an interface, there might be a significant
+   interval before enough counts occur to cause a counter to be
+   incremented.  Traffic would then appear to be very bursty, leading to
+   incorrect conclusions of the network's performance.
+
+   The alternative, which this memo adopts, is to provide expanded, 64
+   bit, counters.  These counters are provided in new "high capacity"
+   groups,
+
+   The old, 32-bit, counters have not been deprecated.  The 64-bit
+   counters are to be used only when the 32-bit counters do not provide
+   enough capacity; that is, 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 used.  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
+   used and 64-bit octet counters MUST be used.  For interfaces that
+   operate at 650,000,000 bits/second or faster, both 64-bit packet
+   counters AND 64-bit octet counters MUST be used.
+
+   These speed steps 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 Ethernet) should not
+           require them.
+
+
+
+
+
+McCloghrie & Kastenholz                                        [Page 14]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+      (2)  64-bit counters are a new feature, introduced in SNMPv2.  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):
+
+           -   Ethernet: 57 minutes,
+
+           -   16 megabit Token Ring: 36 minutes,
+
+           -   A US T3 line (45 megabits): 12 minutes,
+
+           -   FDDI: 5.7 minutes
+
+      (4)  The 32-bit packet counters wraps in about 57 minutes when
+           64-byte packets are transmitted back-to-back on a 650,000,000
+           bit/second link.
+
+           As an aside, a 1-terabit (1,000 gigabits) link will cause 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
+
+
+
+
+
+McCloghrie & Kastenholz                                        [Page 15]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+      (2)  the ifVHCPacketGroup for packet-based interfaces; this group
+           includes 64 bit counters for octets and packets.
+
+3.2.7.  Interface Speed
+
+   In order to deal with increasing interface speeds, we have added an
+   ifHighSpeed object.
+
+   This object reports the speed of the interface in 1,000,000 (1
+   million) bits/second units.  Thus, the true speed of the interface
+   will be the value reported by this object, plus or minus 500,000
+   bits/second.
+
+   Other alternatives considered were:
+
+      (1)  Making the interface speed a 64-bit gauge.  This was 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.
+
+      (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.2.8.  Multicast/Broadcast Counters
+
+   To avoid the redundancy of counting all non-unicast packets as well
+   as having individual multicast and broadcast packet counters, we
+   deprecate the use of the non-unicast counters, which can be derived
+
+
+
+McCloghrie & Kastenholz                                        [Page 16]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+   from the values of the others.
+
+   For the output broadcast and multicast counters defined in RFC 1229,
+   their definitions varied slightly from the packet counters in the
+   ifTable, in that they did not count errors/discarded packets.  To
+   align the definitions better, the old counters are deprecated and
+   replaced by new definitions.  Counters with 64 bits of range are also
+   needed, as explained above.
+
+3.2.9.  Trap Enable
+
+   In the multi-layer interface model, each sub-layer for which there is
+   an entry in the ifTable can generate linkUp/Down 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/Down 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.
+
+   The default setting should limit the number of traps generated to one
+   per interface per linkUp/Down event.  Furthermore, it seems that the
+   conditions that cause these state changes that are 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.2.10.  Addition of New ifType values
+
+   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, which can be re-specified (with additional
+   values) without issuing 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.  Thus, this document defines two MIB
+   modules: one to define the MIB for the 'interfaces' group, and a
+   second to define the first version of the IANAifType textual
+   convention.  The latter will be periodically re-issued by the IANA.
+
+3.2.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
+
+
+
+McCloghrie & Kastenholz                                        [Page 17]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+   of ifIndex.
+
+3.2.12.  IfAdminStatus and IfOperStatus
+
+   A new state has been added to ifOperStatus: dormant.  This state
+   indicates that the relevant interface is not actually in a condition
+   to pass packets (i.e., 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).
+
+   The down state 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, 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
+   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 presumably ifOperStatus will also be down.
+
+   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:
+
+
+
+McCloghrie & Kastenholz                                        [Page 18]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+      (1)  Change to the up state if and only if the interface is able
+           to send and receive packets.
+
+      (2)  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 transition to the up state.
+
+      (3)  Remain in the down state if an error or other fault condition
+           is detected on the interface.
+
+      (4)  Change to the unknown state if, for some reason, the state of
+           the interface can not be ascertained.
+
+      (5)  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.
+
+3.2.13.  Traps
+
+   The exact definition of when linkUp and linkDown traps are generated,
+   has been changed to reflect the changes to ifAdminStatus and
+   ifOperStatus.
+
+   LinkUp and linkDown traps are generated just after ifOperStatus
+   leaves, or just before it enters, the down state, respectively.  The
+   wording of the conditions under which a linkDown trap is generated
+   was explicitly chosen to allow a node with only one interface to
+   transmit the linkDown trap before that interface goes down.
+
+   Operational experience seems to indicate that manager stations are
+   most concerned with an interface being in the down state and the fact
+   that this state may indicate a failure.  It seemed most useful to
+   instrument either transitions into/out of the up state or the down
+   state.
+
+   Instrumenting transitions into or out of the up state has the
+   drawback that an on-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 on-demand
+   interface, then a transition to dormant will entail generation of a
+   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 has the advantages:
+
+
+
+McCloghrie & Kastenholz                                        [Page 19]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+      (1)  A transition into the down state will occur when an error is
+           detected on an interface.  Error conditions are presumably of
+           great interest to network managers.
+
+      (2)  Departing the down 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 generarating traps on transitions
+   into or out of the down state is generally consistent with current
+   usage and interpretation of these traps by manager stations.
+
+   Therefore, this memo defines that it is the transitions into/out of
+   the down state which generate traps.
+
+   Obviously, if a failure condition is present on a node with a single
+   interface, the linkDown trap will probably not be succesfully
+   transmitted since the interface through which it must be transmitted
+   has failed.
+
+3.2.14.  ifSpecific
+
+   The current definition of ifSpecific is not explicit enough.  The
+   only definition that can both be made explicit and can cover all the
+   useful situations (see section 3.1.9) is to have ifSpecific be the
+   most general value for the media-specific MIB module (the first
+   example given section in 3.1.9).  This effectively makes it redundant
+   because it contains no more information than is provided by ifType.
+   For this reason, ifSpecific has been deprecated.
+
+3.3.  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 preserve 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.
+
+   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.
+
+
+
+McCloghrie & Kastenholz                                        [Page 20]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+   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.
+
+   ifTestTable
+        The media-specific MIB designer MUST specify the
+        applicability of the ifTestTable.
+
+   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.
+
+   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.
+
+4.  Overview
+
+   This MIB consists of 5 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 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.
+
+   ifTestTable
+        This table contains objects that are used to perform tests on
+        interfaces.  This table is a generic table.  The designers of
+        media-specific MIBs must define exactly how this table
+        applies to their specific MIB.
+
+
+
+McCloghrie & Kastenholz                                        [Page 21]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+        This table replaces the interface test table defined in
+        RFC1229 [7].  The significant change is the replacement of
+        the ifExtnsTestCommunity (and ifExtnsTestContext which would
+        also have been required for SNMPv2) and ifExtnsTestRequestId
+        objects, by the new ifTestId, ifTestStatus, and ifTestOwner
+        objects.
+
+   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.
+
+5.  IANAifType Definition
+
+   IANAifType-MIB DEFINITIONS ::= BEGIN
+
+   IMPORTS
+       MODULE-IDENTITY, OBJECT-TYPE        FROM SNMPv2-SMI
+       TEXTUAL-CONVENTION                  FROM SNMPv2-TC;
+
+   ianaifType MODULE-IDENTITY
+       LAST-UPDATED "9311082155Z"
+       ORGANIZATION "IANA"
+       CONTACT-INFO
+
+                  "        Internet Assigned Numbers Authority
+
+                   Postal: USC/Information Sciences Institute
+                           4676 Admiralty Way, Marina del Rey, CA 90292
+
+                   Tel:    +1  310 822 1511
+                   E-Mail: iana@isi.edu"
+       DESCRIPTION
+               "The MIB module which defines the IANAifType textual
+               convention, and thus the enumerated values of the
+               ifType object defined in MIB-II's ifTable."
+       ::= { mib-2 30 }
+
+
+   IANAifType ::= TEXTUAL-CONVENTION
+       STATUS       current
+       DESCRIPTION
+               "This data type is used as the syntax of the ifType
+               object in the (updated) definition of MIB-II's
+               ifTable.
+
+
+
+
+McCloghrie & Kastenholz                                        [Page 22]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+               The definition of this textual convention with the
+               addition of newly assigned values is published
+               periodically by the IANA, in either the Assigned
+               Numbers RFC, or some derivative of it specific to
+               Internet Network Management number assignments.  (The
+               latest arrangements can be obtained by contacting the
+               IANA.)
+
+               Requests for new values should be made to IANA via
+               email (iana@isi.edu).
+
+               The relationship between the assignment of ifType
+               values and of OIDs to particular media-specific MIBs
+               is solely the purview of IANA and is subject to change
+               without notice.  Quite often, a media-specific MIB's
+               OID-subtree assignment within MIB-II's 'transmission'
+               subtree will be the same as its ifType value.
+               However, in some circumstances this will not be the
+               case, and implementors must not pre-assume any
+               specific relationship between ifType values and
+               transmission subtree OIDs."
+       SYNTAX  INTEGER {
+                   other(1),          -- none of the following
+                   regular1822(2),
+                   hdh1822(3),
+                   ddnX25(4),
+                   rfc877x25(5),
+                   ethernetCsmacd(6),
+                   iso88023Csmacd(7),
+                   iso88024TokenBus(8),
+                   iso88025TokenRing(9),
+                   iso88026Man(10),
+                   starLan(11),
+                   proteon10Mbit(12),
+                   proteon80Mbit(13),
+                   hyperchannel(14),
+                   fddi(15),
+                   lapb(16),
+                   sdlc(17),
+                   ds1(18),           -- DS1/E1 (RFC 1406)
+                   e1(19),            -- obsolete
+                   basicISDN(20),
+                   primaryISDN(21),
+                   propPointToPointSerial(22), -- proprietary serial
+                   ppp(23),
+                   softwareLoopback(24),
+                   eon(25),            -- CLNP over IP (RFC 1070)
+                   ethernet3Mbit(26),
+
+
+
+McCloghrie & Kastenholz                                        [Page 23]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+                   nsip(27),           -- XNS over IP
+                   slip(28),           -- generic SLIP
+                   ultra(29),          -- ULTRA technologies
+                   ds3(30),            -- T-3
+                   sip(31),            -- SMDS
+                   frameRelay(32),    -- DTE only
+                   rs232(33),
+                   para(34),           -- parallel-port
+                   arcnet(35),         -- arcnet
+                   arcnetPlus(36),     -- arcnet plus
+                   atm(37),            -- ATM cells
+                   miox25(38),
+                   sonet(39),          -- SONET or SDH
+                   x25ple(40),
+                   iso88022llc(41),
+                   localTalk(42),
+                   smdsDxi(43),
+                   frameRelayService(44),  -- Frame relay DCE
+                   v35(45),
+                   hssi(46),
+                   hippi(47),
+                   modem(48),          -- Generic modem
+                   aal5(49),           -- AAL5 over ATM
+                   sonetPath(50),
+                   sonetVT(51),
+                   smdsIcip(52),       -- SMDS InterCarrier Interface
+                   propVirtual(53),    -- proprietary virtual/internal
+                   propMultiplexor(54) -- proprietary multiplexing
+               }
+
+   END
+
+6.  Interfaces Group Definitions
+
+   IF-MIB DEFINITIONS ::= BEGIN
+
+   IMPORTS
+       MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32,
+       Integer32, TimeTicks,
+       NOTIFICATION-TYPE                        FROM SNMPv2-SMI
+       TEXTUAL-CONVENTION, DisplayString,
+       PhysAddress, TruthValue, RowStatus,
+       AutonomousType, TestAndIncr              FROM SNMPv2-TC
+       MODULE-COMPLIANCE, OBJECT-GROUP          FROM SNMPv2-CONF
+       IANAifType                               FROM IANAifType-MIB
+       interfaces                               FROM RFC-1213;
+
+
+
+
+
+McCloghrie & Kastenholz                                        [Page 24]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+   ifMIB MODULE-IDENTITY
+       LAST-UPDATED "9311082155Z"
+       ORGANIZATION "IETF Interfaces MIB Working Group"
+       CONTACT-INFO
+
+                  "        Keith McCloghrie
+
+                   Postal: Hughes LAN Systems
+                           1225 Charleston Road, Mountain View, CA 94043
+
+                   Tel:    +1 415 966 7934
+                   E-Mail: kzm@hls.com
+
+
+                           Frank Kastenholz
+
+                   Postal: FTP Software
+                           2 High Street, North Andover, MA 01845
+
+                   Tel:    +1 508 685 4000
+                   E-Mail: kasten@ftp.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."
+       ::= { mib-2 31 }
+
+   ifMIBObjects OBJECT IDENTIFIER ::= { ifMIB 1 }
+
+   -- OwnerString has the same semantics as used in RFC 1271
+
+   OwnerString ::= TEXTUAL-CONVENTION
+       DISPLAY-HINT "255a"
+       STATUS       current
+       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))
+
+
+
+McCloghrie & Kastenholz                                        [Page 25]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+   -- InterfaceIndex contains the semantics of ifIndex and
+   -- should be used for any objects defined on other mib
+   -- modules that need these semantics.
+
+   InterfaceIndex ::= TEXTUAL-CONVENTION
+       DISPLAY-HINT "d"
+       STATUS       current
+       DESCRIPTION
+               "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
+
+   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 }
+
+
+   -- the Interfaces table
+
+   -- The Interfaces table contains information on the entity's
+   -- 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
+
+
+
+McCloghrie & Kastenholz                                        [Page 26]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+               to a particular interface."
+       INDEX   { ifIndex }
+       ::= { ifTable 1 }
+
+   IfEntry ::=
+       SEQUENCE {
+           ifIndex                 InterfaceIndex,
+           ifDescr                 DisplayString,
+           ifType                  IANAifType,
+           ifMtu                   Integer32,
+           ifSpeed                 Gauge32,
+           ifPhysAddress           PhysAddress,
+           ifAdminStatus           INTEGER,
+           ifOperStatus            INTEGER,
+           ifLastChange            TimeTicks,
+           ifInOctets              Counter32,
+           ifInUcastPkts           Counter32,
+           ifInNUcastPkts          Counter32,  -- 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
+       }
+
+
+   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
+
+
+
+McCloghrie & Kastenholz                                        [Page 27]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+       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
+       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 }
+
+
+
+
+McCloghrie & Kastenholz                                        [Page 28]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+   ifPhysAddress OBJECT-TYPE
+       SYNTAX      PhysAddress
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "The interface's address at its protocol sub-layer.
+               The interface's media-specific MIB must define the bit
+               and byte ordering and format of the value contained by
+               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 }
+
+   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)
+               }
+       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
+
+
+
+McCloghrie & Kastenholz                                        [Page 29]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+               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
+               incomming connection); it should remain in the down(2)
+               state if and only if there is a fault that prevents if
+               from going to the up(1) state."
+       ::= { 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,
+               including framing characters."
+       ::= { 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."
+       ::= { ifEntry 11 }
+
+   ifInNUcastPkts OBJECT-TYPE
+       SYNTAX  Counter32
+       MAX-ACCESS  read-only
+       STATUS      deprecated
+       DESCRIPTION
+               "The number of packets, delivered by this sub-layer to
+
+
+
+McCloghrie & Kastenholz                                        [Page 30]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+               a higher (sub-)layer, which were addressed to a
+               multicast or broadcast address at this sub-layer.
+               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 their being deliverable to a higher-layer
+               protocol.  One possible reason for discarding such a
+               packet could be to free up buffer space."
+       ::= { 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."
+       ::= { 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 which
+               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 which does not support
+               protocol multiplexing, this counter will always be 0."
+       ::= { ifEntry 15 }
+
+
+
+
+McCloghrie & Kastenholz                                        [Page 31]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+   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."
+       ::= { 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."
+       ::= { 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.
+
+               This object is deprecated in favour of
+               ifOutMulticastPkts and ifOutBroadcastPkts."
+       ::= { ifEntry 18 }
+
+   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."
+       ::= { ifEntry 19 }
+
+
+
+McCloghrie & Kastenholz                                        [Page 32]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+   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."
+       ::= { 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 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
+               1443.  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
+
+
+
+McCloghrie & Kastenholz                                        [Page 33]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+       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,
+           ifHCInBroadcastPkts     Counter64,
+           ifHCOutOctets           Counter64,
+           ifHCOutUcastPkts        Counter64,
+           ifHCOutMulticastPkts    Counter64,
+           ifHCOutBroadcastPkts    Counter64,
+           ifLinkUpDownTrapEnable  INTEGER,
+           ifHighSpeed             Gauge32,
+           ifPromiscuousMode       TruthValue,
+           ifConnectorPresent      TruthValue
+       }
+
+
+   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
+
+
+
+McCloghrie & Kastenholz                                        [Page 34]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+               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.  If there is no local name, or this object is
+               otherwise not applicable, then this object contains a
+               0-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."
+       ::= { 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."
+       ::= { 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."
+       ::= { ifXEntry 4 }
+
+   ifOutBroadcastPkts OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+
+
+
+McCloghrie & Kastenholz                                        [Page 35]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+       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."
+       ::= { 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."
+       ::= { 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."
+       ::= { ifXEntry 7 }
+
+   ifHCInMulticastPkts 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
+               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
+
+
+
+McCloghrie & Kastenholz                                        [Page 36]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+               ifInMulticastPkts."
+       ::= { 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."
+       ::= { 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."
+       ::= { ifXEntry 10 }
+
+   ifHCOutUcastPkts 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 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."
+       ::= { 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
+
+
+
+McCloghrie & Kastenholz                                        [Page 37]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+               of ifOutMulticastPkts."
+       ::= { 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."
+       ::= { ifXEntry 13 }
+
+   ifLinkUpDownTrapEnable  OBJECT-TYPE
+       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
+
+
+
+McCloghrie & Kastenholz                                        [Page 38]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+       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
+       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 }
+
+
+   --           The Interface Stack Group
+   --
+   -- Implementation of this group is mandatory 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.  Each
+               sub-layer corresponds to a conceptual row in the
+               ifTable."
+        ::= { ifMIBObjects 2 }
+
+
+   ifStackEntry  OBJECT-TYPE
+        SYNTAX        IfStackEntry
+
+
+
+McCloghrie & Kastenholz                                        [Page 39]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+        MAX-ACCESS    not-accessible
+        STATUS        current
+        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  Integer32,
+           ifStackLowerLayer   Integer32,
+           ifStackStatus       RowStatus
+        }
+
+
+   ifStackHigherLayer  OBJECT-TYPE
+        SYNTAX        Integer32
+        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        Integer32
+        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
+
+
+
+McCloghrie & Kastenholz                                        [Page 40]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+       SYNTAX         RowStatus
+       MAX-ACCESS     read-write
+       STATUS         current
+       DESCRIPTION
+               "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 }
+
+
+   --
+   --    The Interface Test Table
+   --
+   -- This group of objects is optional.  However, a media-specific
+   -- 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      current
+       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.
+
+
+
+
+McCloghrie & Kastenholz                                        [Page 41]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+               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,
+                         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
+
+
+
+McCloghrie & Kastenholz                                        [Page 42]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+              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 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
+
+
+
+McCloghrie & Kastenholz                                        [Page 43]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+              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       current
+       DESCRIPTION
+               "An entry containing objects for invoking tests on an
+               interface."
+       AUGMENTS  { ifEntry }
+       ::= { ifTestTable 1 }
+
+   IfTestEntry ::=
+       SEQUENCE {
+           ifTestId           TestAndIncr,
+           ifTestStatus       INTEGER,
+           ifTestType         AutonomousType,
+           ifTestResult       INTEGER,
+           ifTestCode         OBJECT IDENTIFIER,
+           ifTestOwner        OwnerString
+       }
+
+   ifTestId         OBJECT-TYPE
+       SYNTAX       TestAndIncr
+       MAX-ACCESS   read-write
+       STATUS       current
+       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       current
+       DESCRIPTION
+
+
+
+McCloghrie & Kastenholz                                        [Page 44]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+               "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       current
+       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 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)
+                    }
+
+
+
+McCloghrie & Kastenholz                                        [Page 45]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+       MAX-ACCESS   read-only
+       STATUS       current
+       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       current
+       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
+               1443.  The identifier:
+
+                   testCodeUnknown  OBJECT IDENTIFIER ::= { 0 0 }
+
+               is defined for use if no additional result code is
+               available."
+       ::= { ifTestEntry 5 }
+
+   ifTestOwner      OBJECT-TYPE
+       SYNTAX       OwnerString
+       MAX-ACCESS   read-write
+       STATUS       current
+       DESCRIPTION
+               "The entity which currently has the 'ownership'
+               required to invoke a test on this interface."
+       ::= { ifTestEntry 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
+
+
+
+McCloghrie & Kastenholz                                        [Page 46]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+   -- 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.
+
+               - 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."
+       ::= { 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  read-create
+       STATUS      current
+       DESCRIPTION
+
+
+
+McCloghrie & Kastenholz                                        [Page 47]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+               "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-write
+       STATUS      current
+       DESCRIPTION
+               "This object is used to create and delete rows in the
+               ifRcvAddressTable."
+
+       ::= { ifRcvAddressEntry 2 }
+
+   ifRcvAddressType OBJECT-TYPE
+       SYNTAX      INTEGER {
+                       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 SNMPv2 entity,
+               acting in an agent role, has detected that the
+               ifOperStatus object for one of its communication links
+
+
+
+McCloghrie & Kastenholz                                        [Page 48]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+               is about to transition into the down state."
+       ::= { snmpTraps 3 }
+
+   linkUp NOTIFICATION-TYPE
+       OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
+       STATUS  current
+       DESCRIPTION
+               "A linkUp trap signifies that the SNMPv2 entity,
+               acting in an agent role, has detected that the
+               ifOperStatus object for one of its communication links
+               has transitioned out of the down state."
+       ::= { snmpTraps 4 }
+
+
+   -- conformance information
+
+   ifConformance OBJECT IDENTIFIER ::= { ifMIB 2 }
+
+   ifGroups      OBJECT IDENTIFIER ::= { ifConformance 1 }
+   ifCompliances OBJECT IDENTIFIER ::= { ifConformance 2 }
+
+
+   -- compliance statements
+
+   ifCompliance MODULE-COMPLIANCE
+       STATUS  current
+       DESCRIPTION
+               "The compliance statement for SNMPv2 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
+
+
+
+McCloghrie & Kastenholz                                        [Page 49]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+           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 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
+
+
+
+McCloghrie & Kastenholz                                        [Page 50]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+               value testing(3)."
+       ::= { ifCompliances 1 }
+
+
+   -- units of conformance
+
+   ifGeneralGroup    OBJECT-GROUP
+       OBJECTS { ifDescr, ifType, ifSpeed, ifPhysAddress,
+                 ifAdminStatus, ifOperStatus, ifLastChange,
+                 ifLinkUpDownTrapEnable, ifConnectorPresent,
+                 ifHighSpeed, ifName }
+       STATUS  current
+       DESCRIPTION
+               "A collection of objects providing information
+               applicable to all network interfaces."
+       ::= { ifGroups 1 }
+
+   -- 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, character-oriented or
+               fixed-length-transmission network interfaces.  (Non-
+               high speed interfaces transmit and receive at speeds
+               less than or equal to 20,000,000 bits/second.)"
+       ::= { ifGroups 2 }
+
+   ifHCFixedLengthGroup    OBJECT-GROUP
+       OBJECTS { ifHCInOctets, ifHCOutOctets,
+                 ifInOctets, ifOutOctets, ifInUnknownProtos,
+                 ifInErrors, ifOutErrors }
+       STATUS  current
+       DESCRIPTION
+               "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,
+
+
+
+McCloghrie & Kastenholz                                        [Page 51]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+                 ifInBroadcastPkts, ifInDiscards,
+                 ifOutUcastPkts, ifOutMulticastPkts,
+                 ifOutBroadcastPkts, ifOutDiscards,
+                 ifPromiscuousMode }
+       STATUS  current
+       DESCRIPTION
+               "A collection of objects providing information
+               specific to non-high speed, packet-oriented network
+               interfaces.  (Non-high speed interfaces transmit and
+               receive at speeds less than or equal to 20,000,000
+               bits/second.)"
+       ::= { 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,
+                 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 }
+
+
+
+McCloghrie & Kastenholz                                        [Page 52]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+   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 }
+
+   ifTestGroup    OBJECT-GROUP
+       OBJECTS { ifTestId, ifTestStatus, ifTestType,
+                 ifTestResult, ifTestCode, ifTestOwner }
+       STATUS  current
+       DESCRIPTION
+               "A collection of objects providing the ability to
+               invoke tests on an interface."
+       ::= { ifGroups 8 }
+
+   ifStackGroup    OBJECT-GROUP
+       OBJECTS { ifStackStatus }
+       STATUS  current
+       DESCRIPTION
+               "A collection of objects providing information on the
+               layering of MIB-II interfaces."
+       ::= { ifGroups 9 }
+
+   END
+
+7.  Acknowledgements
+
+   This memo has been produced by the IETF's Interfaces MIB Working
+   Group.
+
+   The initial proposal to the working group was the result of
+   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] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure
+       of Management Information for version 2 of the Simple Network
+       Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc.,
+       Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
+       University, April 1993.
+
+   [2] Galvin, J., and K. McCloghrie, "Administrative Model for version
+       2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445,
+       Trusted Information Systems, Hughes LAN Systems, April 1993.
+
+
+
+McCloghrie & Kastenholz                                        [Page 53]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+   [3] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
+       Operations for version 2 of the Simple Network Management
+       Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN
+       Systems, Dover Beach Consulting, Inc., Carnegie Mellon
+       University, April 1993.
+
+   [4] McCloghrie, K., and M. Rose, "Management Information Base for
+       Network Management of TCP/IP-based internets - MIB-II", STD 17,
+       RFC 1213, Hughes LAN Systems, Performance Systems International,
+       March 1991.
+
+   [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
+       Network Management Protocol", RFC 1157, SNMP Research,
+       Performance Systems International, Performance Systems
+       International, MIT Laboratory for Computer Science, May 1990.
+
+   [6] Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information
+       Sciences Institute, September 1981.
+
+   [7] McCloghrie, K., "Extensions to the Generic-Interface MIB", RFC
+       1229, Hughes LAN Systems, May 1991.
+
+   [8] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual
+       Conventions for version 2 of the Simple Network Management
+       Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN
+       Systems, Dover Beach Consulting, Inc., Carnegie Mellon
+       University, April 1993.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McCloghrie & Kastenholz                                        [Page 54]
+
+RFC 1573               Interfaces Group Evolution           January 1994
+
+
+9.  Security Considerations
+
+   Security issues are not discussed in this memo.
+
+10.  Authors' Addresses
+
+   Keith McCloghrie
+   Hughes LAN Systems
+   1225 Charleston Rd,
+   Mountain View, Ca 94043
+
+   Phone: 415-966-7934
+   EMail: kzm@hls.com
+
+
+   Frank Kastenholz
+   FTP Software
+   2 High Street
+   North Andover, Mass. USA 01845
+
+   Phone: (508)685-4000
+   EMail: kasten@ftp.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McCloghrie & Kastenholz                                        [Page 55]
+
\ No newline at end of file