idnits 2.17.1 draft-ietf-ifmib-invstackmib-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (16 July 1998) is 9388 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2271 (ref. '1') (Obsoleted by RFC 2571) ** Downref: Normative reference to an Informational RFC: RFC 1215 (ref. '4') ** Obsolete normative reference: RFC 1902 (ref. '5') (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (ref. '6') (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (ref. '7') (Obsoleted by RFC 2580) ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '8') ** Downref: Normative reference to an Historic RFC: RFC 1901 (ref. '9') ** Obsolete normative reference: RFC 1906 (ref. '10') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2272 (ref. '11') (Obsoleted by RFC 2572) ** Obsolete normative reference: RFC 2274 (ref. '12') (Obsoleted by RFC 2574) ** Obsolete normative reference: RFC 1905 (ref. '13') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2273 (ref. '14') (Obsoleted by RFC 2573) ** Obsolete normative reference: RFC 2275 (ref. '15') (Obsoleted by RFC 2575) -- Possible downref: Non-RFC (?) normative reference: ref. '17' Summary: 22 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Keith McCloghrie 2 Internet Draft Cisco Systems 3 Gary Hanson 4 ADC Kentrox 5 16 July 1998 7 The Inverted Stack Table Extension 8 to the Interfaces Group MIB 10 draft-ietf-ifmib-invstackmib-00.txt 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, and 16 its working groups. Note that other groups may also distribute working 17 documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference material 22 or to cite them other than as ``work in progress.'' 24 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 26 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 27 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 29 Copyright Notice 31 Copyright (C) The Internet Society (1998). All Rights Reserved. 33 1. Introduction 35 This memo defines a portion of the Management Information Base (MIB) for 36 use with network management protocols in the Internet community. In 37 particular, it describes managed objects which provide an inverted 38 mapping of the interface stack table used for managing network 39 interfaces. 41 2. The SNMP Network Management Framework 43 The SNMP Management Framework presently consists of five major 44 components: 46 o An overall architecture, described in RFC 2271 [1]. 48 o Mechanisms for describing and naming objects and events for the 49 purpose of management. The first version of this Structure of 50 Management Information (SMI) is called SMIv1 and described in RFC 51 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version, 52 called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 53 1904 [7]. 55 o Message protocols for transferring management information. The 56 first version of the SNMP message protocol is called SNMPv1 and 57 described in RFC 1157 [8]. A second version of the SNMP message 58 protocol, which is not an Internet standards track protocol, is 59 called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. 60 The third version of the message protocol is called SNMPv3 and 61 described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. 63 o Protocol operations for accessing management information. The 64 first set of protocol operations and associated PDU formats is 65 described in RFC 1157 [8]. A second set of protocol operations and 66 associated PDU formats is described in RFC 1905 [13]. 68 o A set of fundamental applications described in RFC 2273 [14] and 69 the view-based access control mechanism described in RFC 2275 [15]. 71 Managed objects are accessed via a virtual information store, termed the 72 Management Information Base or MIB. Objects in the MIB are defined 73 using the mechanisms defined in the SMI. 75 This memo specifies a MIB module that is compliant to the SMIv2. A MIB 76 conforming to the SMIv1 can be produced through the appropriate 77 translations. The resulting translated MIB must be semantically 78 equivalent, except where objects or events are omitted because no 79 translation is possible (e.g., use of Counter64). Some machine readable 80 information in SMIv2 will be converted into textual descriptions in 81 SMIv1 during the translation process. However, this loss of machine 82 readable information is not considered to change the semantics of the 83 MIB. 85 3. Interface Sub-Layers and the ifStackTable 87 MIB-II [16] defines objects for managing network interfaces by providing 88 a generic interface definition together with the ability to define 89 media-specific extensions. The generic objects are known as the 90 'interfaces' group. 92 Experience in defining media-specific extensions showed the need to 93 distinguish between the multiple sub-layers beneath the internetwork- 94 layer. Consider, for example, an interface with PPP running over an 95 HDLC link which uses a RS232-like connector. Each of these sub-layers 96 has its own media-specific MIB module. 98 RFC xxxx [17], the latest definition of the 'interfaces' group, 99 satisfies this need by having each sub-layer be represented by its own 100 conceptual row in the ifTable. It also defines an additional MIB table, 101 the ifStackTable, to identify the "superior" and "subordinate" sub- 102 layers through ifIndex "pointers" to the appropriate conceptual rows in 103 the ifTable. 105 Each conceptual row in the ifStackTable represents a relationship 106 between two interfaces, where this relationship is that the "higher- 107 layer" interface runs "on top" of the "lower-layer" interface. For 108 example, if a PPP module operated directly over a serial interface, the 109 PPP module would be a "higher layer" to the serial interface, and the 110 serial interface would be a "lower layer" to the PPP module. This 111 concept of "higher-layer" and "lower-layer" is the same as embodied in 112 the definitions of the ifTable's packet counters. 114 The ifStackTable is INDEX-ed by the ifIndex values of the two interfaces 115 involved in the relationship. By necessity, one of these ifIndex values 116 must come first, and RFC xxxx chose to have the higher-layer interface 117 first, and the lower-layer interface second. Due to this, it is 118 straight-forward for a Network Management application to read a subset 119 of the ifStackTable and thereby determine the interfaces which run 120 underneath a particular interface. However, to determine which 121 interfaces run on top of a particular interface, a Network Management 122 application has no alternative but to read the whole table. This is 123 very inefficient when querying a device which has many interfaces, and 124 many conceptual rows in its ifStackTable. 126 This MIB provides an inverted Interfaces Stack Table, the 127 ifInvStackTable. While it contains no additional information beyond 128 that already contained in the ifStackTable, the ifInvStackTable has the 129 ifIndex values in its INDEX clause in the reverse order, i.e., the 130 lower-layer interface first, and the higher-layer interface second. As 131 a result, the ifInvStackTable is an inverted version of the same 132 information contained in the ifStackTable. Thus, the ifInvStackTable 133 provides an efficient means for a Network Management application to read 134 a subset of the ifStackTable and thereby determine which interfaces run 135 on top of a particular interface. 137 4. Definitions 139 IF-INVERTED-STACK-MIB DEFINITIONS ::= BEGIN 141 IMPORTS 142 MODULE-IDENTITY, OBJECT-TYPE, mib-2 FROM SNMPv2-SMI 143 RowStatus FROM SNMPv2-TC 144 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 145 ifStackHigherLayer, ifStackLowerLayer FROM IF-MIB; 147 ifInvertedStackMIB MODULE-IDENTITY 148 LAST-UPDATED "9807161200Z" 149 ORGANIZATION "IETF Interfaces MIB Working Group" 150 CONTACT-INFO 151 " Keith McCloghrie 152 Cisco Systems, Inc. 153 170 West Tasman Drive 154 San Jose, CA 95134-1706 155 US 157 408-526-5260 158 kzm@cisco.com" 159 DESCRIPTION 160 "The MIB module which provides the Inverted Stack Table for 161 interface sub-layers." 162 REVISION "9807161200Z" 163 DESCRIPTION 164 "Initial revision." 165 ::= { mib-2 xx } 167 ifInvMIBObjects OBJECT IDENTIFIER ::= { ifInvertedStackMIB 1 } 168 -- 169 -- The Inverted Interface Stack Group 170 -- 172 ifInvStackTable OBJECT-TYPE 173 SYNTAX SEQUENCE OF IfInvStackEntry 174 MAX-ACCESS not-accessible 175 STATUS current 176 DESCRIPTION 177 "A table containing information on the relationships between 178 the multiple sub-layers of network interfaces. In 179 particular, it contains information on which sub-layers run 180 'underneath' which other sub-layers, where each sub-layer 181 corresponds to a conceptual row in the ifTable. For 182 example, when the sub-layer with ifIndex value x runs 183 underneath the sub-layer with ifIndex value y, then this 184 table contains: 186 ifInvStackStatus.x.y=active 188 For each ifIndex value, I, which identifies an active 189 interface, there are always at least two instantiated rows 190 in this table associated with I. For one of these rows, I 191 is the value of ifStackHigherLayer; for the other, I is the 192 value of ifStackLowerLayer. (If I is not involved in 193 multiplexing, then these are the only two rows associated 194 with I.) 196 For example, two rows exist even for an interface which has 197 no others stacked on top or below it: 199 ifStackStatus.x.0=active 200 ifStackStatus.0.x=active 202 This table contains exactly the same number of rows as the 203 ifStackTable, but the rows appear in a different order." 204 REFERENCE 205 "ifStackTable of RFC xxxx" 206 ::= { ifInvMIBObjects 1 } 208 ifInvStackEntry OBJECT-TYPE 209 SYNTAX IfInvStackEntry 210 MAX-ACCESS not-accessible 211 STATUS current 212 DESCRIPTION 213 "Information on a particular relationship between two sub- 214 layers, specifying that one sub-layer runs underneath the 215 other sub-layer. Each sub-layer corresponds to a conceptual 216 row in the ifTable." 217 INDEX { ifStackLowerLayer, ifStackHigherLayer } 218 ::= { ifInvStackTable 1 } 220 IfInvStackEntry ::= 221 SEQUENCE { 222 ifInvStackStatus RowStatus 223 } 225 ifInvStackStatus OBJECT-TYPE 226 SYNTAX RowStatus 227 MAX-ACCESS read-only 228 STATUS current 229 DESCRIPTION 230 "The status of the relationship between two sub-layers. 232 An instance of this object exists for each instance of the 233 ifStackStatus object, and vice versa. For example, if the 234 variable ifStackStatus.H.L exists, then the variable 235 ifInvStackStatus.L.H must also exist, and vice versa. In 236 addition, the two variables always have the same value. 238 However, unlike ifStackStatus, the ifInvStackStatus object 239 is NOT write-able. A network management application wishing 240 to change a relationship between sub-layers H and L cannot 241 do so by modifying the value of ifInvStackStatus.L.H, but 242 must instead modify the value of ifStackStatus.H.L. After 243 the ifStackTable is modified, the change will be reflected 244 in this table." 245 ::= { ifInvStackEntry 1 } 247 -- conformance information 249 ifInvConformance OBJECT IDENTIFIER ::= { ifInvMIBObjects 2 } 251 ifInvGroups OBJECT IDENTIFIER ::= { ifInvConformance 1 } 252 ifInvCompliances OBJECT IDENTIFIER ::= { ifInvConformance 2 } 254 -- compliance statements 256 ifInvCompliance MODULE-COMPLIANCE 257 STATUS current 258 DESCRIPTION 259 "The compliance statement for SNMPv2 entities which provide 260 inverted information on the layering of network interfaces." 262 MODULE -- this module 263 MANDATORY-GROUPS { ifInvStackGroup } 265 ::= { ifInvCompliances 1 } 267 -- units of conformance 269 ifInvStackGroup OBJECT-GROUP 270 OBJECTS { ifInvStackStatus } 271 STATUS current 272 DESCRIPTION 273 "A collection of objects providing inverted information on 274 the layering of MIB-II interfaces." 275 ::= { ifInvGroups 1 } 277 END 278 5. Acknowledgements 280 This memo has been produced by the IETF's Interfaces MIB working-group. 282 6. References 284 [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 285 Describing SNMP Management Frameworks", RFC 2271, Cabletron 286 Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, 287 January 1998 289 [2] Rose, M., and K. McCloghrie, "Structure and Identification of 290 Management Information for TCP/IP-based Internets", RFC 1155, 291 Performance Systems International, Hughes LAN Systems, May 1990 293 [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, 294 Performance Systems International, Hughes LAN Systems, March 1991 296 [4] M. Rose, "A Convention for Defining Traps for use with the SNMP", 297 RFC 1215, Performance Systems International, March 1991 299 [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 300 Waldbusser, "Structure of Management Information for Version 2 of 301 the Simple Network Management Protocol (SNMPv2)", RFC 1902, SNMP 302 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 303 International Network Services, January 1996. 305 [6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 306 Waldbusser, "Textual Conventions for Version 2 of the Simple 307 Network Management Protocol (SNMPv2)", RFC 1903, SNMP Research, 308 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 309 International Network Services, January 1996. 311 [7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 312 Waldbusser, "Conformance Statements for Version 2 of the Simple 313 Network Management Protocol (SNMPv2)", RFC 1904, SNMP Research, 314 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 315 International Network Services, January 1996. 317 [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 318 Management Protocol", RFC 1157, SNMP Research, Performance Systems 319 International, Performance Systems International, MIT Laboratory 320 for Computer Science, May 1990. 322 [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 323 Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, 324 SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, 325 Inc., International Network Services, January 1996. 327 [10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 328 Waldbusser, "Transport Mappings for Version 2 of the Simple Network 329 Management Protocol (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco 330 Systems, Inc., Dover Beach Consulting, Inc., International Network 331 Services, January 1996. 333 [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 334 Processing and Dispatching for the Simple Network Management 335 Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems, 336 Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. 338 [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for 339 version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 340 2274, IBM T. J. Watson Research, January 1998. 342 [13] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 343 Waldbusser, "Protocol Operations for Version 2 of the Simple 344 Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research, 345 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 346 International Network Services, January 1996. 348 [14] Levi, D., Meyer, P., and B. Stewart, MPv3 Applications", RFC 2273, 349 SNMP Research, Inc., Secure Computing Corporation, Cisco Systems, 350 January 1998. 352 [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access 353 Control Model (VACM) for the Simple Network Management Protocol 354 (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., 355 Cisco Systems, Inc., January 1998. 357 [16] McCloghrie, K., and M. Rose, "Management Information Base for 358 Network Management of TCP/IP-based internets - MIB-II", RFC 1213, 359 Hughes LAN Systems, Performance Systems International, March 1991. 361 [17] McCloghrie, K., and F. Kastenholz, "The Interface Group MIB", 362 Internet Draft, Cisco Systems, Argon Networks, July 1998. 364 7. Security Considerations 366 This MIB contains only readable objects whose values provide little 367 information of value to a would-be attacker. 369 8. Authors' Addresses 371 Keith McCloghrie 372 Cisco Systems, Inc. 373 170 West Tasman Drive 374 San Jose, CA 95134-1706 376 Phone: 408-526-5260 377 Email: kzm@cisco.com" 379 Gary Hanson 380 ADC Kentrox 381 14375 NW Science Park Drive 382 Portland, Oregon, 97229 384 Phone: (800)733-5511 x6333 385 Email: gary@kentrox.com 387 9. Full Copyright Statement 389 Copyright (C) The Internet Society (1998). All Rights Reserved. 391 This document and translations of it may be copied and furnished to 392 others, and derivative works that comment on or otherwise explain it or 393 assist in its implmentation may be prepared, copied, published and 394 distributed, in whole or in part, without restriction of any kind, 395 provided that the above copyright notice and this paragraph are included 396 on all such copies and derivative works. However, this document itself 397 may not be modified in any way, such as by removing the copyright notice 398 or references to the Internet Society or other Internet organizations, 399 except as needed for the purpose of developing Internet standards in 400 which case the procedures for copyrights defined in the Internet 401 Standards process must be followed, or as required to translate it into 402 languages other than English. 404 The limited permissions granted above are perpetual and will not be 405 revoked by the Internet Society or its successors or assigns. 407 This document and the information contained herein is provided on an "AS 408 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 409 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 410 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 411 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 412 FITNESS FOR A PARTICULAR PURPOSE." 413 Table of Contents 415 1 Introduction .................................................... 2 416 2 The SNMP Network Management Framework ........................... 2 417 3 Interface Sub-Layers and the ifStackTable ....................... 3 418 4 Definitions ..................................................... 5 419 5 Acknowledgements ................................................ 9 420 6 References ...................................................... 9 421 7 Security Considerations ......................................... 11 422 8 Authors' Addresses .............................................. 11 423 9 Full Copyright Statement ........................................ 12