Table Of Contents

Active Objects

Introduction

The principles of object modelling

Grouping objects

Hierarchies

Inheritance

Object modelling

Object classes

The Containment Model

Applying object modelling principles to network management

Network objects

Network containers

Object class hierarchy

Active Classes vs. Passive Classes

Active Object Class files (AOC files)

Advantages of AOCs from a business perspective

Active Object Classes: Scalability and Extensibility

Conclusion

Active Objects

---

This section describes the concepts of object modelling, the containment data model and inheritance. It also introduces the concept of network management using Active Object Classes.

Introduction

You will often find reference to object modelling in the modern world of computing. Indeed, object modelling is the one of the principles behind MWFM NMOS; the other is the use of the Containment Model. MWFM NMOS utilizes the concept of Active Objects to understand and manage the devices on a network.

MWFM NMOS is designed around a class hierarchy containing Active Object Classes (AOCs), which describes the characteristics and behavior of devices and defines their management policies (i.e., the rules that specify how MWFM NMOS treats a device).

Before explaining how Cisco implemented these concepts in the NMOS, it is worth gathering an understanding of the methodology behind object modelling and the containment model.

The principles of object modelling

Grouping objects

We will use the example of vertebrates from the animal kingdom to demonstrate the concept of grouping objects.

Figure 4-1 Grouping animals into vertebrates

Vertebrates can be divided into two groups, warm-blooded and cold-blooded. The warm-blooded animals can be split into mammals and birds. The cold-blooded group can be split into reptiles, amphibians and fish.

Mammals can be categorized into many groups including wild, farm and domestic animals. Domestic mammals can be split into dog and cat. The nature of this grouping is that it creates a hierarchical structure.

Hierarchies

This hierarchy is an example of how using simple groupings can produce complex, detailed maps of relationships covering a wide range of related entities (in this case, vertebrates). From the example above, we can infer that all dogs nurse their young using mammary glands, have a constant body temperature and have a backbone. Similarly, families of domestic animals will have other shared characteristics inherent in their being warm-blooded mammals. We would expect dogs and fish to be much more different than a dog and cat because the first pairing's only common factor is that they are vertebrates.

Inheritance

Inheritance is a familiar idea. A dog, for example, will produce offspring. The offspring will share many characteristics with their parents but may have some unique features. The characteristics in common with the parent group have been inherited. The offspring, being a descendant of a dog, will also belong to the domestic group, which belongs to the mammal group, which happens to be a member of the warm-blooded group, and of course belongs to the root group, `vertebrates'. Therefore, inheritance allows classes to be described in a hierarchical manner, with each class inheriting the properties of those higher in the hierarchy.

---

Note The class or group that is at the beginning of a class hierarchy is called the root class. The class directly above a class is called its parent class.

---

Each offspring is said to be an instance of a dog. An instance is not a new class in the hierarchy, rather it is an object based on the class template. This is true at every stage in the hierarchy, so that a cold-blooded parent will always have cold-blooded offspring, for instance.

Figure 4-2 Inheritance for animals

Object modelling

Object modelling is the process by which an inheritance hierarchy is developed, and attributes or behaviors are assigned to levels within that hierarchy. Ideally, the nearer the root of the hierarchy you are, the more general the characteristics. Relating back to the previous example, if we needed to include information on the number of limbs, we would avoid saying that all vertebrates have two legs (since fish and snakes, for example, do not have any).

There are many different ways of organizing a hierarchy, all of which may be correct (though some may be inefficient or impractical). It takes a skilled designer to create the best model of any particular system. For example, if we were studying limbs, we might wish to categories all living things by whether they have limbs or not instead of whether they are cold-blooded or warm-blooded.

---

Note You can group objects into a hierarchy of attributes in any way you desire; how you decide to do so will be dependent on what you intend to do with the hierarchy.

---

Object classes

Once the object hierarchy has been decided and the properties and behaviors of the entities at each level in the hierarchy have been assigned, you can create classes. Each level within the hierarchy will be a new class and each class will extend the parent class. For example, we could make a `Dog' class that extends the `Domestic' class.

In writing the new class, you only need to say how a `Dog' is different or more specialized than a generic `Domestic Animal'. For example, a dog may possess an inherent property of having hair, which is common to all mammals, but has its own specific behavior of fetching a ball on demand.

Other types of domestic mammals will have hair but will not fetch a ball on demand. Therefore, when developing the `Dog' class, all that is required from you is the definition of the ball-fetching behavior.

One of the key reasons for using an object-based hierarchical structure (and hence object modelling), is that it automatically has `economy of description' for whatever problem domain you find yourself in, because you are not required to continually repeat or duplicate information among classes.

The Containment Model

In very broad terms, a Container may be likened to a cabinet, as shown in Figure 4-3 below.

Figure 4-3 Analogy of the Containment Mode

Folders are Containers, which are contained within the drawers. The drawers are Containers and are contained within the cabinet. Therefore, you can put any object within a Container and mix different objects within the same Container (e.g, you can put your lunch, your pens and your files in the same drawer). In computer systems, however, there is no need for concern about what will fit into a Container or the size/shape problems of real world scenarios. Containers provide an efficient, versatile and structured storage method.

Applying object modelling principles to network management

Network objects

If we wish to define a set of classes for modelling a network, we must produce an object model for the network first, which might look like the figure below.

Figure 4-4 Network object groupings

This network hierarchy is another example of how simple groupings can produce a complex relationship map. We can deduce from the hierarchy that all Cisco routers will have the attribute of a network address, as will other routers that contain characteristics inherent in their existence as `network entities'.

Network containers

From a computing perspective, Containers are objects that can `hold' a collection of other objects or entities (some of which may or may not be Containers themselves). The NMOS hierarchical Containment Model can reflect the real world topology of the network that is being modelled, in a physical, logical or business-oriented sense. For example, Figure 4-5 shows two types of hierarchical Containment Models—a physical hierarchy and a logical hierarchy.

Figure 4-5 The containment principle using network objects

The physical hierarchical Containment Model shows that a chassis can contain network interface cards, power supplies, and software relating to the internal operating system. In turn, the cards can contain individual chips and ports, etc. The logical hierarchical Containment Model shows that a network can contain VLANs and ports; the VLANs can contain ports.

Dependencies are defined by the Containment Model. The object is dependent upon the objects within the Container it holds. For example, VLAN1 is dependent upon everything inside the VLAN1 container, such as the cards and ports. An object is generally dependent upon the things it contains.

---

Note When one entity in a system cannot meaningfully exist without another entity it is said to be dependent.

---

Object class hierarchy

MWFM NMOS uses a class hierarchy to manage network devices, which is analogous to the example where we subdivided vertebrates into endothermic and ectothermic animals, and further subdivided ectothermic animals into amphibians, reptiles and fish.

We can do the same for network devices, as depicted in Figure 4-6 below.

Figure 4-6 Class hierarchy of network devices

In the example of network devices, the attributes you specify using the class hierarchy are management policies, i.e. how to treat instances of devices, what to do with them, what kind of notifications to send in certain situations, etc. In the example shown in Figure 4-6, you may specify that you want to poll all discovered devices once every minute. This is accomplished by making the specification a management policy of the root class `core'. Any class that is located under the `core' will automatically inherit this policy unless specifically overridden in its class file.

One sub-class of `core' is `router', in which you specify the management policies for a generic router, one of which would logically be `look for a routing table'. Further down the hierarchy, you can classify routers by manufacturer and assign manufacturer-specific policies (e.g., for Cisco routers `look at the value of the IOSrev MIB variable'). The Cisco class can be specialized even further by specifying the policies for managing Cisco 7500 routers. This implies that if a Cisco 7500 router is found, the following policies will be carried out:

1. It will be pinged once every minute (inherited from `core').

2. It will have a routing table (inherited from the `router' sub-class).

3. The MIB variable IOSrev will be examined (inherited from the Cisco sub-class).

4. Any other management policy specific to the Cisco 7500 class will be performed.

The advantage of the class hierarchy approach is that it allows you to share among all routers common routing tasks that you might want to perform for network management, and to specialist some tasks for various instances of routers. MWFM NMOS, however, does not permit multiple inheritance, which is the ability of a new class to inherit characteristics from more than one class. The reason for this is that as the class hierarchy grows, you will not be faced with a situation where the classes cannot be effectively managed because of poorly designed interrelationships between classes.

Active Classes vs. Passive Classes

A key feature of MWFM NMOS is that the object classes specified in the class hierarchy are active, i.e., the class description contains the actions that should be taken upon instantiation of an object class.

Therefore, if MWFM NMOS comes across a real Cisco 7500 router in the network topology, the Cisco 7500 class file description can tell the system what to start doing to the 7500 upon instantiation. In contrast, a passive class can be defined as a situation where the system has to be told what class the object belongs to before it applies the actions and methods associated with the object class.

---

Note The act of creating a new object with the methods and behaviors contained within a class template.

---

The use of active classes implies that, upon the discovery of a Cisco 7500 router, the system looks at the class file for a description of what to action to take in regards to the router, e.g., the polling methodology and frequency to use for the 7500.

Another key feature of the AOCs is that they are dynamic, i.e., alterations to the class descriptions are detected and implemented as soon as they occur. Such actions are taken by the use of the MWFM NMOS AOC management system CLASS.

The use of AOCs enables MWFM NMOS to provide dynamic self-adapting network management because, as the NMOS sees devices appearing and disappearing, it turns on and off their associated management policies.

Active Object Class files (AOC files)

An AOC file will contain:

•A name and description of the class.

•The parent class of the AOC.

•Rules to instantiate a device (how the system determines to which class a device belongs).

•What to do with a device once it has been detected.

•How to handle a device.

•Polling methodology.

•Reference to the appropriate Data Dictionaries).

•Network management application-specific policies called extensions.

---

Note The Data Dictionary: The Data Dictionary contains all the ASN.1 descriptions of all the data types that will be encountered in the device class, so that the system knows how to treat each data type.

---

Advantages of AOCs from a business perspective

The AOCs hierarchy allows you to create class divisions based on whatever criteria you choose. For example, an ISP (Internet Service Provider) may choose to subdivide further the instances of a Cisco 4500 router class on a ports per customer basis as shown on the next page.

Figure 4-7 AOCs from a business perspective: ports per customer

Such control means that you are not restricted (by AOCs) to grouping only by device object classes but can also apply specific management policy rules on a business case; in fact, on any case you wish.

Active Object Classes: Scalability and Extensibility

Also inherent in the AOCs is the ability to bolt on behaviors relevant to other applications that share the use of the MWFM NMOS base system. This is done by using application-specific extensions, listed below:

•Fault extensions for fault management and root cause analysis.

•Configuration extensions for configuration management and policy assurance.

•Accounting extensions for the accounting aspect of network management.

•Performance extensions for monitoring and analyzing a network's performance.

•Security extensions for managing a network's security.

This extensibility allows MWFM NMOS true integration with other products. With MWFM NMOS providing the topology and class description, it is possible to use this system to perform any or all aspects of network management by simply adding the relevant extensions, which encapsulate all specific policies to the AOCs.

Conclusion

This chapter has shown the fundamental principles of MWFM NMOS and has illustrated the flexibility of the AOCs. The next chapter introduces the workings of the MWFM NMOS component responsible for managing and distributing the AOCs, which is CLASS.