rfc1573.txt

RFC 的详细文档！

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.