In the fine arts, the media that an artist uses has a great influence over the type of artwork that results. For instance, the character of a painting is different if the artist uses water colors, oil colors, crayons, or a pencil. The difference is even more dramatic if clay is used, resulting in a sculpture instead of a drawing or a painting. Of course, each medium can be used to model the same aspect of the real world, such as a person. The resulting "model" is called a portrait.
In network management, the specification language constitutes the raw material out of which MIB definitions are molded by the MIB artist—that is, designer. Just as in the fine arts, many different media—in this case, specification languages—can be used to create a valid model of the device being managed. Just as a watercolor of a dog looks different than a drawing of the same dog, the character of the model that results looks different depending on what metaschema is used. Figure 6-6 illustrates this.
Figure B-B Different Metaschemas, Different Characters of the Abstraction
The following subsections discuss what impact the characteristics of a metaschema have on the resulting model, and what types of metaschema tend to be popular for different purposes.
Without going into details of "real" metaschema, here are some examples of different types of specification means that different metaschemas offer.
One category of specification languages provides object-oriented constructs. This enables the designer of a schema to represent different aspects of the device as MO classes that can have attributes and that can emit notifications. Existing definitions can be reused and refined by allowing MO classes to be derived from other MO classes that are more general in nature. This corresponds to an object-oriented concept that is known as inheritance. The derived class is also called the subclass; the class that it is derived from is called the superclass. The subclass inherits the properties of the superclass and subsequently refines them. As an example, a Poodle class might be a subclass of a Dog class, which, in turn, would be a subclass of the Mammal class, and so on. Another example is an MO class that is used to represent ATM interfaces, which could inherit from a more general class to represent an interface generically—that is, any interface, not just ATM interfaces. Object orientation is the paradigm on which MOF and (in a different flavor) GDMO support are based.
A second category of specification languages enables users to specify MIB definitions in the form of tables and variables that can be grouped in certain ways. A table refers to one particular aspect of the device—a "class of MOs," so to speak, with the MO attributes represented by the table columns and instances by the table rows. Of course, tables are quite different from object classes— for example, they do not support inheritance. Their semantics are simpler and less powerful, but arguably more straightforward and simpler to implement on a device. This is the paradigm that SMI and SMIv2 provide. We examine SMI and SMIv2 more closely later in this chapter.
Other specification languages might simply model everything as commands and functions and their parameters without actually specifying much of an explicit model. This, of course, is the case for CLI, the command-line interface. Again, the way in which management information is represented is different from the object-oriented and table-based approaches. (As a side note, many people would not even consider CLI a management protocol, among other reasons precisely because it does not refer to a separate model and does not clearly distinguish between the management information and the functions used to access and manipulate it. CLI is discussed in greater detail in Chapter 8, "Common Management Protocols: Languages of Management.")
Each metaschema has its advantages and drawbacks; at this point, we do not get into these. It is important to note, however, that regardless of the metaschema chosen, the models that result can provide a management abstraction of the same underlying device. In practice, often several such models are provided simultaneously, each offering the capability to manage the device. In such a case, users can choose which type of model and associated management protocol works best for a particular purpose. For example, they could use SNMP for monitoring tasks that management applications perform, and use CLI with craft terminals that craft technicians operate.
In fact, just as artists prefer different media for different categories of subjects, such as using watercolors for landscapes instead of portraits, often different types of metaschema are used in conjunction with different categories of management information. Of course, this is a matter of not merely preference, but practicality: Some metaschemata lend themselves better than others to certain management tasks.
■ Generally, management information that management agents on network equipment provide tends to be based on relatively simple metaschemata. This has to do with the fact that corresponding management agents tend to be easy to develop and do not require many processing resources, an aspect that is important for devices that, in many cases, are processing constrained.
— State information is often modeled as tables and represented in SNMP MIBs because SNMP is the management protocol of choice for many monitoring applications.
— Logical configuration information is often managed using CLI, meaning that often it is modeled only in the form of parameters of CLI functions instead of a more explicit management information model.
— Historical information is often represented in proprietary formats, optimized for periodic retrieval in one large bulk file from a device.
■ When the management agent that provides the management information is not a network device, but a computer system, a managed application, or a management application itself (for example, in a management hierarchy in which one management application provides services for another management application at a higher management layer), support for object-oriented metaschemata and models such as MOF and CIM becomes a lot more common. In those cases, management agents are less constrained by computing resources, tilting the balance in favor of using metaschemas that might be more complex but also more powerful.
It is important to always remember that no matter what underlying metaschema is used, a MIB is always a view of a managed device. Accordingly, it is also possible to have multiple simultaneous views of the same device. For example, you could have the same management information accessible via an SNMP MIB and via a set of CLI functions. Each view, or each MIB, can be supported by its own management agent, each interacting with management applications through a different management protocol. The different management views that the various management agents provide can have a different scope—that is, they can cover different aspects of the same managed device. They can simply complement each other, they can overlap each other, or one can be a subset of another, as Figure 6-7 illustrates.
Figure 6-7 MIB Scopes
(a) Complementing scope
(a) Complementing scope
(b) Overlapping scope
(b) Overlapping scope
(c) Redundant scope
(c) Redundant scope
Was this article helpful?