Sharon Chisholm Internet Draft Nortel Networks Steve Waldbusser Document: draft-chisholm-snmp-infomode-01.txt Expires: June 2004 December 2003 The SNMP Information Model Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [ ]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo attempts to capture the de facto information model of SNMP MIBs. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [ ]. Table of Contents 1. The Internet-Standard Management Framework 2 2. The SNMP Information Model 2 2.1 Introduction 2 2.2 Relationships between MIB Tables 3 2.3 The Core Models 3 2.3.1 The System 3 2.3.2 Physical Entities 4 2.3.3 Interfaces 5 2.3.4 IP 6 2.3.5 Applications 7 3. Security Considerations 7 4. Authors' Address 7 5. References 8 5.1 Normative 8 5.2 Informative References 9 6. Full Copyright Statement 9 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 2. The SNMP Information Model 2.1 Introduction An information model consists of three components: the objects, the attributes of the objects and its relationship with other objects. An information model can be thought of as a higher level of abstraction that either be used to create data models such as MIBs, or can be abstracted from existing definitions. This memo attempts to do the latter. The motivation for capturing the de facto information model that has been used in SNMP MIBs is to increase awareness of the model. Lack of awareness of the de facto information model used in SNMP MIBs can lead to poor design choices, which in turn can increase the costs or in some cases prevent the use of the MIBs in management solutions. 2.2 Relationships between MIB Tables While information in MIBs is organized into groups and tables, the definition of the group or table usually does not provide a direct mapping to the abstract object whose attributes are being captured. In practice, the definition of all attributes of an abstract object may span several tables and may even be spit between different MIB modules. Information in a table can be related to that in another table in a number of ways. While there isn't one single design pattern that has been used in designing MIBs, there are some general patterns that can be used as the starting point for abstracting out the SNMP Information Model. If a table shares an index with or is an augmentation of another table, and for each row in the first table there is a corresponding row in the second, then both of these tables can be considered to be defining attributes of the same object. If a table shares an index, or a copy of an index with another table and there are only rows in the second table for a subset of the rows in the first table, the second table can be thought of as a specialization of the general object whose attributes were defined in the first. This is often referred to as a sparse augmentation. Another common relationship is where an attribute in one table contains the index values of another table with different indexing. These tables are either defining attributes for different objects that are related or providing a mapping between attributes of the same object, but that are referenced in different ways. 2.3 The Core Models 2.3.1 The System A system consists of a collection of physical and logical components that will be managed as a single managed entity. It consists of the objects within the SystemGroup [RFC3418] as well as the objects defined in all other MIBs supported on the managed entity. +-----------------+ |System | +-----------------| |-----------------| +-----------------+ | | +-----------------+ | _ | | --------------|--------------------- | 0..* | | 0..* +-----------------+ | +-----------------+ |Physical Entity | | |Application | +-----------------| | +-----------------| |-----------------| | |-----------------| +-----------------+ | +-----------------+ | | | | | +-----------------+ | +-----------------+ | | 0..* +-----------------+ |Interface | +-----------------| |-----------------| +-----------------+ | ->Interface | | ->Interface | +-----------------+ 2.3.2 Physical Entities Physical entities can be thought of as a generalized object whose base attributes are defined in the Entity MIB[RFC2737]. Specializations of the physical entity include chassis, backplane, container, powerSupply, fan, sensor, module, port, and stack, as indicated by entPhysicalClass and the existence of sparsely augmented physical entity tables. The relationship between the interfaces and their physical entity is indicated by the entAliasMappingIdentifier[RFC2737], which is applicable only to port specializations. +-----------------+ |PhysicalEntity | +-----------------| |-----------------| +-----------------+ | | +-------*---------+ +------------+ / \ |Chassis | / \ +------------+ /--+--\ +------------+ +------------+ | |Fan | +------------+ | +------------+ | | | +------------+ | +------------+ +------------+ +------------+ +----------------+ | | | | +------------+ | +------------+ |Backplane +------------| +------------+ | +------------+ | +------------+ +------------+ | |Sensor | | | | +------------+ | | | +------------+ -------------- | +------------+ |---------------+ | +------------+ | | | |Container +------------+ +------------+ +------------+ | +------------+ | +------------+ | | | | +------------+ | | +----------------+Module | +------------+ | +------------+ +-------+------------+ +------------+ | | | +------------+ +------------+ | +---+--------+ | | | |powerSupply +----+ |Port | | | | +------------+ +------------+ | +------------+ +------------+ +------------+ | +------------+ +------------+ | | | | | | +------------+ | | |->Interface | +----+Stack | +------------+ +------------+ +------------+ +------------+ +------------+ | | | | +------------+ 2.3.3 Interfaces An interface can be thought of us a generalized object whose base attributes are defined in the Interfaces MIB [RFC2863]. Specializations of the interface include ATM, Frame Relay Services, SONET/SDH and other as indicated by the ifType and the existence of sparsely augmented interface tables. The base interface attributes are defined in the ifTable and ifXTable. The layering relationship between interfaces is defined in the ifStack table. +--------------+ | Port | +--------------+ +---------------+ +--------------+ | Interface |/ +--------------+ | *------------+ ->Interface | +---------------+\ +--------------+ +---------------+ |\+---------------+ -----+/X ->Interface | | / | ->Interface | | | | | +--/*\------/\--+ | / \ --+- | --+-- | +---+--------+ | +----++---+ |SonetSdh | | +ATM + +------------+ | +---------+ +------------+ | +---------+ +------------+ | +---------+ | | | | | +------------+ | +---------+ | | | +---------+-----------+ | FrameRelayServices | +---------------------+ +---------------------+ +---------------------+ | | | | +---------------------+ 2.3.4 IP A local IP address is associated with an interface via ipAddEntIfIndex [RFC2011]. Note that not all interfaces have Ip Address. An IP route is associated with an interface via either the ipCidrRouteIfIndex [RFC2096] or the ipROuteIfIndex [RFC1213], depending on which version of the route table used. UDP and TCP Connections are associated with local IP Addresses via udpLocalAddress [RFC2013] and tcpConnLocalAddress [RFC2012], respectively. +---------------+ | Interface | | | +---------------+ +---------------+ +----------------+ +---------------+ |UDPConnection | | ->Interface |/ +---------------+ +----------------+ | ->Interface *-----+LocalIpAddress | +----------------+ | |\ +---------------+/ +----------------+ +-----/X\-------- +---------------*---+->LocalIpAddress| / | \ +---------------+\ +----------------+ | |->Interface | | +--------/*\- --+ +----------------+ | / | \ |TCP Connection | | +---------+----------------+ | +----------------+ | +----------------+ | +---------------+ |->LocalIpAddress| +--------------+ IpRoute | +----------------+ +---------------+ +---------------+ +---------------+ | | |->Interface | +---------------+ 2.3.5 Applications This section will be addressed in an update to this memo. 3. Security Considerations There are no additional security considerations other than those normally associated with the use of SNMP. 4. Authors' Address Sharon Chisholm Nortel Networks PO Box 3511, Station C Ottawa, Ontario, K1Y 4H7 Canada Email: schishol@nortelnetworks.com Steven Waldbusser waldbusser@nextbeacon.com 5. References 5.1 Normative [RFC1213] Rose, M, McCloghrie, K., "Management Information Base for Network Management of TCP/IP-based internets", RFC 1213, March 1991 [RFC2011] McCloghrie, K., "SNMPv2 Management Information Base for the Internet Protocol using SMIv2", RFC 2011, November 1996. [RFC2012] McCloghrie, K., "SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2", RFC 2012, November 1996. [RFC2013] McCloghrie, K., "SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2", RFC 2013, November 1996. [RFC2096] Baker, F., "IP Forwarding Table MIB" RFC 2096, January 1997. [RFC2578] 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. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2737] McCloghrie, K., Bierman, A., "Entity MIB (Version 2)", December 1999. [RFC2863] McCloghrie, K., Kastenholz F.,?The Interfaces Group MIB?, RFC 2862, June 2000 [RFC3418] Presuhn, R., ?Management Information Base (MIB) for the Simple Network Management Protocol (SNMP).?, RFC 3418, December 2002 5.2 Informative References [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. 6. Full Copyright Statement Copyright (C) The Internet Society (2003). 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.