rfc2233.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,402 行 · 第 1/5 页

Network Working Group                                      K. McCloghrie
Request for Comments: 2233                                 Cisco Systems
Obsoletes: 1573                                            F. Kastenholz
Category: Standards Track                                   FTP Software
                                                           November 1997


                  The Interfaces Group MIB using SMIv2


Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1997).  All Rights Reserved.

Table of Contents

   1 Introduction ..............................................    2
   2 The SNMP Network Management Framework .....................    2
   2.1 Object Definitions ......................................    3
   3 Experience with the Interfaces Group ......................    3
   3.1 Clarifications/Revisions ................................    3
   3.1.1 Interface Sub-Layers ..................................    4
   3.1.2 Guidance on Defining Sub-layers .......................    6
   3.1.3 Virtual Circuits ......................................    8
   3.1.4 Bit, Character, and Fixed-Length Interfaces ...........    8
   3.1.5 Interface Numbering ...................................   10
   3.1.6 Counter Size ..........................................   14
   3.1.7 Interface Speed .......................................   16
   3.1.8 Multicast/Broadcast Counters ..........................   17
   3.1.9 Trap Enable ...........................................   18
   3.1.10 Addition of New ifType values ........................   18
   3.1.11 InterfaceIndex Textual Convention ....................   18
   3.1.12 New states for IfOperStatus ..........................   19
   3.1.13 IfAdminStatus and IfOperStatus .......................   20
   3.1.14 IfOperStatus in an Interface Stack ...................   21
   3.1.15 Traps ................................................   21
   3.1.16 ifSpecific ...........................................   23
   3.1.17 Creation/Deletion of Interfaces ......................   24
   3.1.18 All Values Must be Known .............................   24
   4 Media-Specific MIB Applicability ..........................   25



McCloghrie & Kastenholz     Standards Track                     [Page 1]

RFC 2233            Interfaces Group MIB using SMIv2       November 1997


   5 Overview ..................................................   26
   6 Interfaces Group Definitions ..............................   26
   7 Acknowledgements ..........................................   64
   8 References ................................................   64
   9 Security Considerations ...................................   65
   10 Authors' Addresses .......................................   65
   11 Full Copyright Statement .................................   66

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
   specifies clarifications to, and extensions of, the architectural
   issues within the previous 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 that is both compliant to the SNMPv2 SMI and semantically-
   identical to the existing SNMPv1-based definitions.

   The key words "MUST" and "MUST NOT" in this document are to be
   interpreted as described in RFC 2119 [10].

2.  The SNMP Network Management Framework

   The SNMP Network Management Framework presently consists of three
   major components.  They are:

   o    RFC 1902 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    STD 15, RFC 1157 and RFC 1905 which define two versions of
        the protocol used for network access to managed objects.







McCloghrie & Kastenholz     Standards Track                     [Page 2]

RFC 2233            Interfaces Group MIB using SMIv2       November 1997


   The Framework permits new objects to be defined for the purpose of
   experimentation and evaluation.

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 assume an evolution or loosening
   of the model.  This memo documents and standardizes that evolution
   of the model and fills in the gaps caused by that evolution.  This
   memo also incorporates the interfaces group extensions documented
   in RFC 1229 [7].

3.1.  Clarifications/Revisions

   There are several areas for which experience has indicated that
   clarification, revision, or extension of the model would be
   helpful.  The following sections discuss the changes in the
   interfaces group adopted by this memo in each of these areas.




McCloghrie & Kastenholz     Standards Track                     [Page 3]

RFC 2233            Interfaces Group MIB using SMIv2       November 1997


   In some sections, one or more paragraphs contain discussion of
   rejected alternatives to the model adopted in this memo.  Readers
   not familiar with the MIB-II model and not interested in the
   rationale behind the new model may want to skip these paragraphs.

3.1.1.  Interface Sub-Layers

   Experience in defining media-specific management information has
   shown the need to distinguish between the multiple sub-layers
   beneath the internetwork-layer.  In addition, there is a need to
   manage these sub-layers in devices (e.g., MAC-layer bridges) which
   are unaware of which, if any, internetwork protocols run over
   these sub-layers.  As such, a model of having a single conceptual
   row in the interfaces table (MIB-II's ifTable) represent a whole
   interface underneath the internetwork-layer, and having a single
   associated media-specific MIB module (referenced via the ifType
   object) is too simplistic.  A further problem arises with the
   value of the ifType object which has enumerated values for each
   type of interface.

   Consider, for example, an interface with PPP running over an HDLC
   link which uses a RS232-like connector.  Each of these sub-layers
   has its own media-specific MIB module.  If all of this is
   represented by a single conceptual row in the ifTable, then an
   enumerated value for ifType is needed for that specific
   combination which maps to the specific combination of media-
   specific MIBs.  Furthermore, such a model still lacks a method to
   describe the relationship of all the sub-layers of the MIB stack.

   An associated problem is that of upward and downward multiplexing
   of the sub-layers.  An example of upward multiplexing is MLP
   (Multi-Link-Procedure) which provides load-sharing over several
   serial lines by appearing as a single point-to-point link to the
   sub-layer(s) above.  An example of downward multiplexing would be
   several instances of PPP, each framed within a separate X.25
   virtual circuit, all of which run over one fractional T1 channel,
   concurrently with other uses of the T1 link.  The MIB structure
   must allow these sorts of relationships to be described.

   Several solutions for representing multiple sub-layers were
   rejected.  One was to retain the concept of one conceptual row for
   all the sub-layers of an interface and have each media-specific
   MIB module identify its "superior" and "subordinate" sub-layers
   through OBJECT IDENTIFIER "pointers".  This scheme would have
   several drawbacks: the superior/subordinate pointers would be
   contained in the media-specific MIB modules; thus, a manager could
   not learn the structure of an interface without inspecting
   multiple pointers in different MIB modules; this would be overly



McCloghrie & Kastenholz     Standards Track                     [Page 4]

RFC 2233            Interfaces Group MIB using SMIv2       November 1997


   complex and only possible if the manager had knowledge of all the
   relevant media-specific MIB modules; MIB modules would all need to
   be retrofitted with these new "pointers"; this scheme would not
   adequately address the problem of upward and downward
   multiplexing; and finally, enumerated values of ifType would be
   needed for each combination of sub-layers.  Another rejected
   solution also retained the concept of one conceptual row for all
   the sub-layers of an interface but had a new separate MIB table to
   identify the "superior" and "subordinate" sub-layers and to
   contain OBJECT IDENTIFIER "pointers" to the media-specific MIB
   module for each sub-layer.  Effectively, one conceptual row in the
   ifTable would represent each combination of sub-layers between the
   internetwork-layer and the wire.  While this scheme has fewer
   drawbacks, it still would not support downward multiplexing, such
   as PPP over MLP: observe that MLP makes two (or more) serial
   lines appear to the layers above as a single physical interface,
   and thus PPP over MLP should appear to the internetwork-layer as a
   single interface; in contrast, this scheme would result in two (or
   more) conceptual rows in the ifTable, both of which the
   internetwork-layer would run over.  This scheme would also require
   enumerated values of ifType for each combination of sub-layers.

   The solution adopted by this memo is to have an individual
   conceptual row in the ifTable to represent each sub-layer, and
   have a new separate MIB table (the ifStackTable, see section 6
   below) to identify the "superior" and "subordinate" sub-layers
   through INTEGER "pointers" to the appropriate conceptual rows in
   the ifTable.  This solution supports both upward and downward
   multiplexing, allows the IANAifType to Media-Specific MIB mapping
   to identify the media-specific MIB module for that sub-layer, such
   that the new table need only be referenced to obtain information
   about layering, and it only requires enumerated values of ifType
   for each sub-layer, not for combinations of them.  However, it
   does require that the descriptions of some objects in the ifTable
   (specifically, ifType, ifPhysAddress, ifInUcastPkts, and
   ifOutUcastPkts) be generalized so as to apply to any sub-layer
   (rather than only to a sub-layer immediately beneath the network
   layer as previously), plus some (specifically, ifSpeed) which need
   to have appropriate values identified for use when a generalized
   definition does not apply to a particular sub-layer.

   In addition, this adopted solution makes no requirement that a
   device, in which a sub-layer is instrumented by a conceptual row
   of the ifTable, be aware of whether an internetwork protocol runs
   on top of (i.e., at some layer above) that sub-layer.  In fact,
   the counters of packets received on an interface are defined as
   counting the number "delivered to a higher-layer protocol".  This
   meaning of "higher-layer" includes: