summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2864.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2864.txt')
-rw-r--r--doc/rfc/rfc2864.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc2864.txt b/doc/rfc/rfc2864.txt
new file mode 100644
index 0000000..c8b9023
--- /dev/null
+++ b/doc/rfc/rfc2864.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+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]
+