    Network Working Group                                      K. McCloghrie
    Request for Comments: 2864                                 Cisco Systems
    Category: Standards Track                                      G. Hanson
                                                      ADC Telecommunications
                                                                   June 2000

         The Inverted Stack Table Extension to the Interfaces Group MIB

    Status of this Memo

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

    Copyright Notice

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

    Table of Contents

       1 Introduction ..................................................  1
       2 The SNMP Network Management Framework .........................  1
       3 Interface Sub-Layers and the ifStackTable .....................  3
       4 Definitions ...................................................  4
       5 Acknowledgements ..............................................  7
       6 References ....................................................  7
       7 Security Considerations .......................................  8
       8 Authors' Addresses ............................................  9
       9 Notice on Intellectual Property ............................... 10
       10 Full Copyright Statement ..................................... 11

    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 which provide an inverted
       mapping of the interface stack table used for managing network
       interfaces.

    2.  The SNMP Network Management Framework

       The SNMP Management Framework presently consists of five major
       components:

    McCloghrie & Hanson         Standards Track                     [Page 1]

    RFC 2864              Inverted Stack Extension MIB             June 2000

        o An overall architecture, described in RFC 2571 [1].

        o Mechanisms for describing and naming objects and events for the
          purpose of management.  The first version of this Structure of
          Management Information (SMI) is called SMIv1 and described in STD
          16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4].  The
          second version, called SMIv2, is described in STD 58, which
          consists of RFC 2578 [5], RFC 2579 [6] and RFC 2580 [7].

        o Message protocols for transferring management information.  The
          first version of the SNMP message protocol is called SNMPv1 and
          described in STD 15, RFC 1157 [8].  A second version of the SNMP
          message protocol, which is not an Internet standards track
          protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC
          1906 [10].  The third version of the message protocol is called
          SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574
          [12].

        o Protocol operations for accessing management information.  The
          first set of protocol operations and associated PDU formats is
          described in STD 15, RFC 1157 [8].  A second set of protocol
          operations and associated PDU formats is described in RFC 1905
          [13].

        o A set of fundamental applications described in RFC 2573 [14] and
          the view-based access control mechanism described in RFC 2575
          [15].

       A more detailed introduction to the current SNMP Management Framework
       can be found in RFC 2570 [18].

       Managed objects are accessed via a virtual information store, termed
       the Management Information Base or MIB.  Objects in the MIB are
       defined using the mechanisms defined in the SMI.

       This memo specifies a MIB module that is compliant to the SMIv2.  A
       MIB conforming to the SMIv1 can be produced through the appropriate
       translations.  The resulting translated MIB must be semantically
       equivalent, except where objects or events are omitted because no
       translation is possible (e.g., use of Counter64).  Some machine
       readable information in SMIv2 will be converted into textual
       descriptions in SMIv1 during the translation process.  However, this
       loss of machine readable information is not considered to change the
       semantics of the MIB.

    McCloghrie & Hanson         Standards Track                     [Page 2]

    RFC 2864              Inverted Stack Extension MIB             June 2000

    3.  Interface Sub-Layers and the ifStackTable

       MIB-II [16] defines objects for managing network interfaces by
       providing a generic interface definition together with the ability to
       define media-specific extensions.  The generic objects are known as
       the 'interfaces' group.

       Experience in defining media-specific extensions showed the need to
       distinguish between the multiple sub-layers beneath the
       internetwork-layer.  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.

       The latest definition of the 'interfaces' group in the IF-MIB [17]
       satisfies this need by having each sub-layer be represented by its
       own conceptual row in the ifTable.  It also defines an additional MIB
       table, the ifStackTable, to identify the "superior" and "subordinate"
       sub-layers through ifIndex "pointers" to the appropriate conceptual
       rows in the ifTable.

       Each conceptual row in the ifStackTable represents a relationship
       between two interfaces, where this relationship is that the "higher-
       layer" interface runs "on top" of the "lower-layer" interface.  For
       example, if a PPP module operated directly over a serial interface,
       the PPP module would be a "higher layer" to the serial interface, and
       the serial interface would be a "lower layer" to the PPP module.
       This concept of "higher-layer" and "lower-layer" is the same as
       embodied in the definitions of the ifTable's packet counters.

       The ifStackTable is INDEX-ed by the ifIndex values of the two
       interfaces involved in the relationship.  By necessity, one of these
       ifIndex values must come first, and the IF-MIB chose to have the
       higher-layer interface first, and the lower-layer interface second.
       Due to this, it is straight-forward for a Network Management
       application to read a subset of the ifStackTable and thereby
       determine the interfaces which run underneath a particular interface.
       However, to determine which interfaces run on top of a particular
       interface, a Network Management application has no alternative but to
       read the whole table.  This is very inefficient when querying a
       device which has many interfaces, and many conceptual rows in its
       ifStackTable.

       This MIB provides an inverted Interfaces Stack Table, the
       ifInvStackTable.  While it contains no additional information beyond
       that already contained in the ifStackTable, the ifInvStackTable has
       the ifIndex values in its INDEX clause in the reverse order, i.e.,
       the lower-layer interface first, and the higher-layer interface
       second.  As a result, the ifInvStackTable is an inverted version of

    McCloghrie & Hanson         Standards Track                     [Page 3]

    RFC 2864              Inverted Stack Extension MIB             June 2000

       the same information contained in the ifStackTable.  Thus, the
       ifInvStackTable provides an efficient means for a Network Management
       application to read a subset of the ifStackTable and thereby
       determine which interfaces run on top of a particular interface.

    4.  Definitions

    IF-INVERTED-STACK-MIB DEFINITIONS ::= BEGIN

    IMPORTS
      MODULE-IDENTITY, OBJECT-TYPE, mib-2      FROM SNMPv2-SMI
      RowStatus                                FROM SNMPv2-TC
      MODULE-COMPLIANCE, OBJECT-GROUP          FROM SNMPv2-CONF
      ifStackGroup2,
      ifStackHigherLayer, ifStackLowerLayer    FROM IF-MIB;

    ifInvertedStackMIB MODULE-IDENTITY
      LAST-UPDATED "200006140000Z"
      ORGANIZATION "IETF Interfaces MIB Working Group"
      CONTACT-INFO
              "   Keith McCloghrie
                  Cisco Systems, Inc.
                  170 West Tasman Drive
                  San Jose, CA  95134-1706
                  US

                  408-526-5260
                  kzm@cisco.com"
      DESCRIPTION
              "The MIB module which provides the Inverted Stack Table for
              interface sub-layers."
      REVISION      "200006140000Z"
      DESCRIPTION
              "Initial revision, published as RFC 2864"
      ::= { mib-2 77 }

    ifInvMIBObjects OBJECT IDENTIFIER ::= { ifInvertedStackMIB 1 }

    --
    --           The Inverted Interface Stack Group
    --

    ifInvStackTable  OBJECT-TYPE
       SYNTAX        SEQUENCE OF IfInvStackEntry
       MAX-ACCESS    not-accessible
       STATUS        current
       DESCRIPTION
              "A table containing information on the relationships between

    McCloghrie & Hanson         Standards Track                     [Page 4]

    RFC 2864              Inverted Stack Extension MIB             June 2000

              the multiple sub-layers of network interfaces.  In
              particular, it contains information on which sub-layers run
              'underneath' which other sub-layers, where each sub-layer
              corresponds to a conceptual row in the ifTable.  For
              example, when the sub-layer with ifIndex value x runs
              underneath the sub-layer with ifIndex value y, then this
              table contains:

                ifInvStackStatus.x.y=active

              For each ifIndex value, z, which identifies an active
              interface, there are always at least two instantiated rows
              in this table associated with z.  For one of these rows, z
              is the value of ifStackHigherLayer; for the other, z is the
              value of ifStackLowerLayer.  (If z is not involved in
              multiplexing, then these are the only two rows associated
              with z.)

              For example, two rows exist even for an interface which has
              no others stacked on top or below it:

                ifInvStackStatus.z.0=active
                ifInvStackStatus.0.z=active

              This table contains exactly the same number of rows as the
              ifStackTable, but the rows appear in a different order."
       REFERENCE
              "ifStackTable of RFC 2863"
       ::= { ifInvMIBObjects 1 }

    ifInvStackEntry  OBJECT-TYPE
       SYNTAX        IfInvStackEntry
       MAX-ACCESS    not-accessible
       STATUS        current
       DESCRIPTION
              "Information on a particular relationship between two sub-
              layers, specifying that one sub-layer runs underneath the
              other sub-layer.  Each sub-layer corresponds to a conceptual
              row in the ifTable."
       INDEX { ifStackLowerLayer, ifStackHigherLayer }
       ::= { ifInvStackTable 1 }

    IfInvStackEntry ::=
      SEQUENCE {
          ifInvStackStatus       RowStatus
       }

    ifInvStackStatus  OBJECT-TYPE

    McCloghrie & Hanson         Standards Track                     [Page 5]

    RFC 2864              Inverted Stack Extension MIB             June 2000

      SYNTAX         RowStatus
      MAX-ACCESS     read-only
      STATUS         current
      DESCRIPTION
              "The status of the relationship between two sub-layers.

              An instance of this object exists for each instance of the
              ifStackStatus object, and vice versa.  For example, if the
              variable ifStackStatus.H.L exists, then the variable
              ifInvStackStatus.L.H must also exist, and vice versa.  In
              addition, the two variables always have the same value.

              However, unlike ifStackStatus, the ifInvStackStatus object
              is NOT write-able.  A network management application wishing
              to change a relationship between sub-layers H and L cannot
              do so by modifying the value of ifInvStackStatus.L.H, but
              must instead modify the value of ifStackStatus.H.L.  After
              the ifStackTable is modified, the change will be reflected
              in this table."
      ::= { ifInvStackEntry 1 }

    -- conformance information

    ifInvConformance OBJECT IDENTIFIER ::= { ifInvMIBObjects 2 }

    ifInvGroups      OBJECT IDENTIFIER ::= { ifInvConformance 1 }
    ifInvCompliances OBJECT IDENTIFIER ::= { ifInvConformance 2 }

    -- compliance statements

    ifInvCompliance MODULE-COMPLIANCE
      STATUS  current
      DESCRIPTION
              "The compliance statement for SNMP entities which provide
              inverted information on the layering of network interfaces."

      MODULE  -- this module
          MANDATORY-GROUPS { ifInvStackGroup }

          OBJECT       ifInvStackStatus
          SYNTAX       INTEGER { active(1) }
          DESCRIPTION
              "Support is only required for 'active'."

    McCloghrie & Hanson         Standards Track                     [Page 6]

    RFC 2864              Inverted Stack Extension MIB             June 2000

      MODULE  IF-MIB
          MANDATORY-GROUPS { ifStackGroup2 }

      ::= { ifInvCompliances 1 }

    -- units of conformance

    ifInvStackGroup    OBJECT-GROUP
      OBJECTS { ifInvStackStatus }
      STATUS  current
      DESCRIPTION
              "A collection of objects providing inverted information on
              the layering of MIB-II interfaces."
      ::= { ifInvGroups 1 }

    END

    5.  Acknowledgements

       This memo has been produced by the IETF's Interfaces MIB working-
       group.

    6.  References

       [1]  Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for
            Describing SNMP Management Frameworks", RFC 2571, January 1998.

       [2]  Rose, M. and K. McCloghrie, "Structure and Identification of
            Management Information for TCP/IP-based Internets", STD 16, RFC
            1155, May 1990.

       [3]  Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16,
            RFC 1212, March 1991.

       [4]  Rose, M., "A Convention for Defining Traps for use with the
            SNMP", RFC 1215, March 1991.

       [5]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
            M. and S. Waldbusser, "Structure of Management Information
            Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.

       [6]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
            M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58,
            RFC 2579, April 1999.

       [7]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
            M. and S. Waldbusser, "Conformance Statements for SMIv2", STD
            58, RFC 2580, April 1999.

    McCloghrie & Hanson         Standards Track                     [Page 7]

    RFC 2864              Inverted Stack Extension MIB             June 2000

       [8]  Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
            Network Management Protocol", STD 15, RFC 1157, May 1990.

       [9]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
            Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901,
            January 1996.

       [10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
            Waldbusser, "Transport Mappings for Version 2 of the Simple
            Network Management Protocol (SNMPv2)", RFC 1906, January 1996.

       [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message
            Processing and Dispatching for the Simple Network Management
            Protocol (SNMP)", RFC 2572, January 1998.

       [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
            for version 3 of the Simple Network Management Protocol
            (SNMPv3)", RFC 2574, January 1998.

       [13] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S.
            Waldbusser, "Protocol Operations for Version 2 of the Simple
            Network Management Protocol (SNMPv2)", RFC 1905, January 1996.

       [14] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC
            2573, January 1998.

       [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
            Control Model (VACM) for the Simple Network Management Protocol
            (SNMP)", RFC 2575, January 1998.

       [16] McCloghrie, K. and M. Rose, "Management Information Base for
            Network Management of TCP/IP-based internets - MIB-II", STD 17,
            RFC 1213, March 1991.

       [17] McCloghrie, K. and F. Kastenholz, "The Interface Group MIB", RFC
            2863, June 2000.

       [18] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction
            to Version 3 of the Internet-standard Network Management
            Framework", RFC 2570, April 1999.

    7.  Security Considerations

       There are no management objects defined in this MIB that have a MAX-
       ACCESS clause of read-write and/or read-create.  So, if this MIB is
       implemented correctly, then there is no risk that an intruder can
       alter or create any management objects of this MIB via direct SNMP
       SET operations.

    McCloghrie & Hanson         Standards Track                     [Page 8]

    RFC 2864              Inverted Stack Extension MIB             June 2000

       SNMPv1 by itself is not a secure environment.  Even if the network
       itself is secure (for example by using IPSec), even then, there is no
       control as to who on the secure network is allowed to access and
       GET/SET (read/change/create/delete) the objects in this MIB.

       It is recommended that the implementers consider the security
       features as provided by the SNMPv3 framework.  Specifically, the use
       of the User-based Security Model RFC 2574 [12] and the View- based
       Access Control Model RFC 2575 [15] is recommended.

       It is then a customer/user responsibility to ensure that the SNMP
       entity giving access to an instance of this MIB, is properly
       configured to give access to the objects only to those principals
       (users) that have legitimate rights to indeed GET or SET
       (change/create/delete) them.

    8.  Authors' Addresses

       Keith McCloghrie
       Cisco Systems, Inc.
       170 West Tasman Drive
       San Jose, CA  95134-1706

       Phone: 408-526-5260
       EMail: kzm@cisco.com

       Gary Hanson
       ADC Telecommunications
       14375 NW Science Park Drive
       Portland, Oregon, 97229

       Phone: (800)733-5511 x6333
       EMail: gary_hanson@adc.com

    McCloghrie & Hanson         Standards Track                     [Page 9]

    RFC 2864              Inverted Stack Extension MIB             June 2000

    9.  Notice on Intellectual Property

       The IETF takes no position regarding the validity or scope of any
       intellectual property or other rights that might be claimed to
       pertain to the implementation or use of the technology described in
       this document or the extent to which any license under such rights
       might or might not be available; neither does it represent that it
       has made any effort to identify any such rights.  Information on the
       IETF's procedures with respect to rights in standards-track and
       standards-related documentation can be found in BCP-11.  Copies of
       claims of rights made available for publication and any assurances of
       licenses to be made available, or the result of an attempt made to
       obtain a general license or permission for the use of such
       proprietary rights by implementors or users of this specification can
       be obtained from the IETF Secretariat.

       The IETF invites any interested party to bring to its attention any
       copyrights, patents or patent applications, or other proprietary
       rights which may cover technology that may be required to practice
       this standard.  Please address the information to the IETF Executive
       Director.

    McCloghrie & Hanson         Standards Track                    [Page 10]

    RFC 2864              Inverted Stack Extension MIB             June 2000

    10.  Full Copyright Statement

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

       This document and translations of it may be copied and furnished to
       others, and derivative works that comment on or otherwise explain it
       or assist in its implementation may be prepared, copied, published
       and distributed, in whole or in part, without restriction of any
       kind, provided that the above copyright notice and this paragraph are
       included on all such copies and derivative works.  However, this
       document itself may not be modified in any way, such as by removing
       the copyright notice or references to the Internet Society or other
       Internet organizations, except as needed for the purpose of
       developing Internet standards in which case the procedures for
       copyrights defined in the Internet Standards process must be
       followed, or as required to translate it into languages other than
       English.

       The limited permissions granted above are perpetual and will not be
       revoked by the Internet Society or its successors or assigns.

       This document and the information contained herein is provided on an
       "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
       TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
       BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
       HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
       MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

    Acknowledgement

       Funding for the RFC Editor function is currently provided by the
       Internet Society.

    McCloghrie & Hanson         Standards Track                    [Page 11]