Internet DRAFT - draft-chisholm-snmp-infomode
draft-chisholm-snmp-infomode
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.
