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] 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]