Chapter 5: CIM and mof

The Concept of a Model

Creating a language to express their ideas has been a challenge to scientists and engineers since the beginning of time ”the Romans were handicapped in their use of arithmetic by having a nonpositional number system unable to express zero. Because their representation was poor, they were held back in expressing their ideas.

We need to select a language in which to express the concepts for managing devices and services. The language must be rich enough to include the complex and abstract relationships between items, but be simple enough for software to handle efficiently . The idea of a position-based number system with a zero evolved gradually and, similarly, our languages for expressing management models are also changing and refining.

Rather than expressing arithmetic, our linguistic aim is to define a model of the devices and services we intend to manage. In this book I have studiously used the term "model" to refer to the description of the things being managed. You may be familiar with the terms "data model" and "information model." I have avoided these because the distinction between them is, at best, the source of quasireligious debate: in January 2003 the Internet Engineering Task Force (IETF) even issued a Request For Comment (RFC) ”number 3444 ”entitled "On the Difference between Information Models and Data Models." The preface to that document reads:

There have been many discussions to understand the advantages and disadvantages, as well as the main differences, between various languages. For instance, the IETF organized a BoF ^[1] on "Network Information Modeling" (NIM) at its 48th meeting in 2000. During these discussions, it turned out that people had a different understanding of the main terms, which caused confusion and long arguments. In particular, the meaning of the terms "Information Model" (IM) and "Data Model" (DM) turned out to be controversial .

In an attempt to address this issue, the IETF Network Management Research Group (NMRG) dedicated its 8th workshop (Austin, December 2000) to harmonizing the terminology used in information and data modeling. Attendees included experts from the IETF, DMTF, and ITU, as well as academics who do research in this field. The main outcome of this successful workshop - a better understanding of the terms "Information Model" and "Data Model" - is presented in this document.

Having read the document several times, I confess to feeling that I still do not understand the difference but that, luckily, it probably does not matter.

So, what do I mean by a model? Figure 5.1 illustrates the concept: somewhere is stored the actual information which makes a device operate correctly. This is shown on the right-hand side of Figure 5.1 and it may be stored in registers in an integrated circuit, in computer memory, etc. It may be stored in one place or be distributed.

Figure 5.1: The Role of the Model

On the left-hand side of Figure 5.1 I have shown a number of different operators. They have different mental models of the device that they are managing, and it may be appropriate for the management system to reflect their particular mental model even if it is wrong or incomplete. I have spent my life working with software; my wife has not. When the software running on her computer displays an event on the screen (e.g., when Netscape has failed yet again), she immediately and unwillingly becomes a management operator. It is important that the message she receives fits with her mental model of what is happening inside the computer. Unfortunately, most software having been written by people like me, it rarely does. This increases the chances that she will react inappropriately to the message ”perhaps powering the computer off and on again, compounding the original problem by corrupting the file system.

If the operator is in the business of scheduling the repainting of telecommunications street cabinets , then his or her mental model of the device is of a metal cabinet of a certain colour, last repainted on a certain date. The interior of the cabinet is probably irrelevant. If, on the other hand, the operator's responsibility is to configure and operate the IP router within the cabinet, then he or she probably never pictures the cabinet, let alone its colour.

The model stands between these different operators' mental models and the normally messy, real representation of the information. It tries to be sufficiently abstract and consistent to support different viewpoints, while being sufficiently close to the real devices to be efficient. In general:

• The model should be expressed in a formal language so that it can be manipulated by a computer. Preferably it should also have a graphical representation to allow humans to understand it more easily.

• The model must be able to meet the needs of all potential management operators ”in the previous example it must encompass both the colour of the cabinet and the IP addresses of the router. In this case, the management system will probably need to confine a particular operator to one part of the model; it might not be appropriate for the painter to be able to read or change the IP addresses or for a bored IP operator to schedule the cabinet to be repainted. This involves providing different windows onto the same information: the operators can then choose the window through which they look.

• The model must be able to express high-level (service) abstractions. An operator configuring an end-to-end service (such as a Virtual Private Network ^[2] ) need not be exposed to the internal details of every port on every device ”the model should support the concept of a Virtual Private Network and allow the operator to work with this abstraction, the translation to ports on devices being done within the management system.

• The model should allow an operator's workstation to enquire about and manipulate the structure of the model itself. Management workstations can be simpler if they can ask the model not only for details of particular entities ("is port 27 on card 11 in service?"), but also for details of the model itself ("with what types of thing is port 27 associated?"). This allows the management workstation to find out what it can ask the device ”it does not need to know this a priori ”enabling the development of more generic management workstation software.

  Another advantage of this self-describing model is realised if its structure can be changed by an approved operator while the system is running: an operator can change not only the status of a port from disabled to enabled, but also the linkages in the model relating to the port (which modules need to be informed when it fails, etc.). This could, for example, allow a company which buys and distributes devices to tailor management features for a particular market without involving the original manufacturer. The concept of the "approved operator" is essential here: a malicious operator could do great damage to a system if given this level of control: the system needs to address questions of operator authentication (are the operators who they say they are?) and authorisation (what may these operators do?).

• The model should support the modelling of collections of entities and associations between entities where these are relevant to the application. An end-to-end link in a network, for example, might be modelled as a collection of point-to-point links. For some applications it might be more consistent with the operator's mental model to work with the end-to-end link.

^[1] Birds of a Feather Meeting: i.e., a meeting of people interested in the topic, but not forming part of the standardisation process.

^[2] A self-contained network dedicated to one customer and using a subset of the resources of a real network.