Network Working Group A. Pras
Internet-Draft University of Twente
Expires: January 21, 2003 J. Schoenwaelder
University of Osnabrueck
July 23, 2002
On the Difference between Information Models and Data Models
draft-irtf-nmrg-im-dm-00.txt
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.
This Internet-Draft will expire on January 21, 2003.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
There has been ongoing confusion about the differences between
Information Models and Data Models. This document explains the
differences between these terms by analyzing how existing network
management model specifications (from the IETF and other bodies such
as the ITU or the DMTF) fit into the universe of Information Models
and Data Models.
This memo documents the main results of the 8th workshop of the
Network Management Research Group (NMRG) of the Internet Research
Task Force (IRTF).
Pras & Schoenwaelder Expires January 21, 2003 [Page 1]
Internet-Draft Information Models vs. Data Models July 2002
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Information Models . . . . . . . . . . . . . . . . . . . . . . . 4
4. Data Models . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 9
Pras & Schoenwaelder Expires January 21, 2003 [Page 2]
Internet-Draft Information Models vs. Data Models July 2002
1. Introduction
Currently multiple "languages" exist to define "managed" objects.
Examples of such languages are the "Structure of Management
Information" (SMI) [1], the "Structure of Policy Provisioning
Information" (SPPI) [2] and, within the DMTF, the "Managed Object
Format" (MOF) [3]. Despite the fact that multiple languages exist,
there are still some feelings that none of these languages really
suites all needs. To discuss these feelings, the IETF organized for
example at its 48th meeting (summer 2000) a BoF meeting on "Network
Information Modeling" (NIM).
To understand the advantages and disadvantages, as well as the main
differences between the various languages, there have been many
discussions, also outside the IETF. Unfortunately these discussions
were not always fruitful, primarily because it appeared that people
had different understanding of main terms. In particularly the terms
"Information Model" (IM) and "Data Model" (DM) turned out to be
controversial.
In an attempt to stop this controversy and harmonize terminology, the
IRTF Network Management Research Group (NMRG) [11] organized in
December 2000 a special workshop. For this workshop the IRTF-NMRG
invited leading experts from the IETF, DMTF, ITU as well as the
academic world (see the acknowledgements section for a list of
participants). The workshop was quite successful and its outcome,
which is a better understanding of the terms "Information Model" and
"Data Model", as presented in this document.
Short definitions of both terms can also be found within other
documents (see for example RFC 3198 [4]). Compared to these other
documents this document also provides background information and
examples.
2. Overview
One of the interesting observations at the IRTF-NMRG workshop was
that IMs and DMs are different since they serve different purposes.
The purpose of an IM is to model managed objects at a high conceptual
level, which is easy to understand for the human designer or human
manager. In order to present the overall design as clear as
possible, IMs try to abstract from protocol and implementation
specific details. One important aspect of an IM is that it also
focuses on the relationships between managed objects.
Compared to IMs, DMs are defined at a lower level of abstraction and
with much more detail. DMs are more intended for implementors, and
include lower level and protocol specific constructs.
Pras & Schoenwaelder Expires January 21, 2003 [Page 3]
Internet-Draft Information Models vs. Data Models July 2002
IM --> conceptual / abstract model
| targeted to the designer and
+----------+---------+ human manager
| | |
DM DM DM --> concrete / detailed model
targeted to the implementor
The relationship between an IM and DM is shown in the Figure above.
Since conceptual models can be implemented in several different ways,
multiple DMs can be derived from the same IM.
Although IMs and DMs serve different purposes, it is not possible to
precisely define what details should be expressed in the IM and what
in the DM. Therefore no principle difference exists between both
models; in fact there is a grey area between both which makes it in
certain cases impossible to determine if something is an IM or a DM.
3. Information Models
An IM is primarily useful for designers and managers. The terms
"conceptual models" or "abstract models", which are often used in
literature, relate to IMs. An IM can be implemented in different
ways and mapped upon different protocols; IMs are therefore protocol
neutral. An important characteristic of an IM is that it specifies
the relationship between objects.
IMs can be defined in an informal way, using natural languages like
English. A good example of an IM is provided by RFC 3290: "An
Informal Management Model for Diffserv Routers" [5]. This RFC
describes a conceptual model of a Diffserv Router, including the
relationship between the components of such a router that need to be
managed. Within the IETF it is quite exceptional that an IM is
described within a separate RFC, however; in such cases the status of
such documents is usually "Informational" and not "Standards Track"
[6]. In general most RFCs that define a MIB module also include some
kind of informal description explaining the model behind that MIB
module. Such a model can be considered as an IM. A good example of
this is RFC 2863, which defines "The Interfaces Group MIB" [7]. Note
that most RFCs include just a rudimentary, incomplete description of
the underlying IM.
Optionally IMs can also be defined "formally", using some kind of
(semi) formal language. One of the possibilities to "formally"
specify IMs is to use UML class diagrams. Although such diagrams are
not standardized by the IETF, there are several other organizations
that use UML class diagrams for their IMs. Examples of such
organizations are the DMTF, the ITU-T SG 4, 3GPP SA5, TeleManagement
Forum, and the ATM Forum. An important advantage of UML class
Pras & Schoenwaelder Expires January 21, 2003 [Page 4]
Internet-Draft Information Models vs. Data Models July 2002
diagrams is that they represent objects and the relationship between
them in a graphical way. Because of this graphical representation,
designers and operators may find it easier to understand the
underlying management model. Although there are other techniques to
graphically represent objects and the relationship between them
(like, for example, entity-relationship diagrams), UML has the
advantage that it is widely accepted by the industry and
universities. Because of this, there are also many tools that
support the manipulation of UML diagrams. UML itself is standardized
by the Object Management Group (OMG) [8].
In general, it seems advisable to use object-oriented techniques to
describe an IM. In particular the notions of abstraction and
encapsulation, as well as the possibility that object definitions
include methods are considered to be important.
4. Data Models
Compared to IMs, DMs define managed objects at a lower level of
abstraction. They include implementation and protocol specific
details like, for example, rules that explain how to map managed
objects on lower level protocol constructs.
The MIB modules defined within the IETF are in fact DMs. The
language (syntax) used to define these DMs is called the "Structure
of Management Information" (SMI) [1], which in turn is based on ASN.1
[9].
Not only IETF MIBs, but also most other standardized management
models are DMs. Examples are:
o Policy Information Bases (PIBs), which are also developed within
the IETF. PIBs use as syntax the "Structure of Policy
Provisioning Information" (SPPI) [2], which is similar to the SMI
and is also based on ASN.1.
o Management Information Bases (MIBs), as originally defined by ISO
and nowadays maintained and enhanced by the ITU-T. These DMs use
the syntax as defined by the "Guidelines for the Definition of
Managed Objects" (GDMO) [10]. GDMO MIBs make use of object-
oriented principles.
o CIM Schemas, as developed within the DMTF. These DMs use the
syntax as defined by the "Managed Object Formats (MOFs)" [3]. The
DMTF publishes CIM Schemas in the form of graphical UML documents
in addition to this MOF syntax. Because of this graphical
notation, designers and managers may find it easier to understand
CIM Schemas than IETF MIBs. One could therefore argue that CIM
Pras & Schoenwaelder Expires January 21, 2003 [Page 5]
Internet-Draft Information Models vs. Data Models July 2002
Schemas are closer to IMs then IETF MIBs, which lack such
graphical notation. The UML diagrams can be downloaded from the
DMTF website in PDF as well as VISIO format. (VISIO is one of the
tools to draw UML class diagrams). Note that, in contrast to IETF
MIBS, CIM Schemas make use of object-oriented principles.
The Figure below shows these examples. The languages that are used
to define the DMs are shown between brackets.
IM --> IM
|
+----------+-------+-------+--------------+
| | | |
MIB PIB CIM schema OSI-MIBs --> DM
(SMI) (SPPI) (MOF) (GDMO)
To illustrate what details are included in a DM, let us consider the
example of IETF MIB modules. As opposed to IMs, IETF MIB modules
include details like OID assignments and indexing structures. The
"relationships" that existed at the IM level are now "implemented" in
terms of OID pointers and indexing relationships manifested in INDEX
clauses. Also many other implementation specific details are
included, like for example MAX-ACCESS and STATUS clauses and
conformance statements.
A special kind of DM language is the SMIng language designed by the
NMRG. This language was particularly designed at a higher conceptual
level then SMIv1/SMIv2 and SPPI. In fact one of the intentions
behind SMIng was to stop the proliferation of different DM languages
and harmonize the various models. As a result MIBs/PIBs defined in
SMIng can be mapped on different underlying protocols; there is a
mapping on SNMP and there is a mapping on COPS-PR. SMIng is
therefore more protocol neutral than other IETF approaches. SMIng
also supports some object-oriented principles and provides an
extension mechanism which allows to add more features such as support
for methods when the protocols support them without breaking SMIng
implementations. Still SMIng should be considered as a DM; to
express for example the relationship between managed objects,
techniques like UML or ER diagrams give still better results since
these diagrams are easier to understand.
It should be noted that the SMIng working group within the IETF
decided to not adapt the SMIng language defined by the NMRG.
Instead, the SMIng working group currently focusses resources on
developing a third version of the SMI (SMIv3) which is primarily
targeted towards SNMP and which only incorporates some of the ideas
developed within the NMRG.
Pras & Schoenwaelder Expires January 21, 2003 [Page 6]
Internet-Draft Information Models vs. Data Models July 2002
5. Acknowledgments
The authors would like to thank everyone who participated at the 8th
IRTF-NMRG meeting (in alphabetic order): Szabolcs Boros, Mark
Brunner, David Durham, Dave Harrington, Jean-Philippe Martin-Flatin,
George Pavlou, Robert Parhonyi, David Perkins, David Sidor, Andrea
Westerinen and Bert Wijnen.
References
[1] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M. and S. Waldbusser, "Structure of Management Information
Version 2 (SMIv2)", RFC 2578, STD 59, April 1999.
[2] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, S.,
Sahita, R., Smith, A. and F. Reichmeyer, "Structure of Policy
Provisioning Information (SPPI)", RFC 3159, August 2001.
[3] Distributed Management Task Force, "Common Information Model
(CIM) Specification Version 2.2", DSP 0004, June 1999.
[4] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S.
Waldbusser, "Terminology for Policy-Based Management", RFC
3198, November 2001.
[5] Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An Informal
Management Model for Diffserv Routers", RFC 3290, May 2002.
[6] Bradner, S., "The Internet Standards Process -- Revision 3",
RFC 2026, October 1996.
[7] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",
RFC 2863, June 2000.
[8] Object Management Group, "Unified Modeling Language (UML),
Version 1.4", formal/2001-09-67, September 2001.
[9] International Organization for Standardization, "Information
processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1)",
International Standard 8824, December 1987.
[10] International Telecommunication Union, "Information technology
- Open Systems Interconnection - Structure of Management
Information: Guidelines for the Definition of Managed
Objects", Recommendation X.722, 1992.
Pras & Schoenwaelder Expires January 21, 2003 [Page 7]
Internet-Draft Information Models vs. Data Models July 2002
[11] <http://www.irtf.org/>
Authors' Addresses
Aiko Pras
University of Twente
PO Box 217
7500 AE Enschede
The Netherlands
Phone: +31 53 4893778
EMail: pras@ctit.utwente.nl
Juergen Schoenwaelder
University of Osnabrueck
Albrechtstr. 28
49069 Osnabrueck
Germany
Phone: +49 541 969-2483
EMail: schoenw@informatik.uni-osnabrueck.de
Pras & Schoenwaelder Expires January 21, 2003 [Page 8]
Internet-Draft Information Models vs. Data Models July 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). 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.
Pras & Schoenwaelder Expires January 21, 2003 [Page 9]
