Chapter 2 - Object-oriented Principles and MWFM NMOS

Table Of Contents

Object-oriented Principles and MWFM NMOS

MWFM Fundamentals

Principles of Object-oriented Programming

Summary of Object-oriented Concepts

Active Object Classes

What do the AOCs Contain?

The Containment Model

The Architecture of MWFM NMOS

How MWFM NMOS Components Interact

Conclusion

Object-oriented Principles and MWFM NMOS

---

This chapter provides an introduction to object-oriented principles and the Active Object Classes, the basis for the rest of this guide. This chapter also provides an overview of the MWFM Network Management Operating System (NMOS) which is the foundation for the Cisco product suite and fundamental to the operation of Cisco Mobile Wireless Fault Mediator .

MWFM Fundamentals

This chapter is designed as an introduction to object-oriented principles which are fundamental to understanding the operation of MWFM. It also introduces the Active Object Classes (AOCs) and the Containment Model, which MWFM NMOS uses to manage network devices, and provides an overview of the architecture of MWFM NMOS and how its components interact with each other to provide an underlying layer for Cisco Mobile Wireless Fault Mediator.

Principles of Object-oriented Programming

Cisco Mobile Wireless Fault Mediator follows the conceptual principles of object-oriented programming, which is organized around objects rather than a series of rules or actions. In network management terms, objects are devices or entities (pieces of hardware) on the network. These include routers, switches, hubs, chassis, interfaces, cards, ports, etc.

---

Note The terms object and device are used loosely in this guide. This is because some objects represent actual devices while others represent interfaces and connections. There are also abstract objects such as containers, which are introduced shortly.

---

These objects are grouped into classes, organized into a hierarchical structure, and managed on the basis of their location within the structure. A class of objects is simply a group of objects that can be managed the same way because of common attributes.Grouping objects into classes introduces a hierarchical structure, which ranks classes into levels of subordination based on how many attributes are shared on each level. This type of structure also invokes a principle called inheritance.

Inheritance means that any object classes located lower in the hierarchical structure assume the characteristics (or management policies) of those object classes superior to it. The accepted means of referring to object classes is as a parent-child relationship; the child class (or sub-class) inherits characteristics from its parent, the parent class (or super-class). Any management policies defined in a parent class are adopted by the child class without having to specify them again. Figure 2-1 demonstrates the concept of a hierarchical structure.

Figure 2-1 Arranging network entities into a hierarchical structure

The illustration shows that all classes inherit from a single root, the class called Core. Consider a
Cisco 7500 router class; this type of router has unique characteristics that distinguish it from a Cisco 4500 class router. For instance, it may have more sensitive environmental characteristics that need to be managed differently; thus, it is necessary to have a series of management policies dedicated to the Cisco 7500 router class. However, both the Cisco 4500 and 7500 are manufactured by Cisco and would therefore share vendor-specific MIB information. This common information could be specified in the Cisco Router class. Additionally, both are routers and therefore part of the Router class, which may contain management policies dedicated to handling general routing table information. Finally, all routers are in turn child classes of the Core class. Management policies in the Core class are inherited by all network entities and typically include generic policies. For example, to ensure the integrity of the network it may be necessary to check the availability of all network devices every 60 seconds via a ping poll. This type of action could be defined in the Core class and inherited by all other devices.

Finally each object in a class is referred to as an instance of that class. Devices such as routers, switches, cards, etc. are objects and thus, all instances of object classes. In the example shown in Figure 2-1, any Cisco 7500 router is an instance of the object class "Cisco 7500".

Summary of Object-oriented Concepts

The following list provides a summary of the most important object-oriented concepts to grasp.

•All devices/entities are objects.

•Classes are groupings of objects based on predefined criteria.

•Classes are arranged into a hierarchical tree structure which has a single root. The principles of inheritance apply to this structure; thus, descendents of a class inherit the management policies associated with the parent class.

•Every object is an instance of a class.

An extension to the concepts of objects and classes is that of Active Object Classes, which is the next topic for discussion.

Active Object Classes

A key feature of MWFM NMOS and Cisco Mobile Wireless Fault Mediator is the use of Active Object Classes (AOCs). AOCs are based on the concepts of object classes and object modelling, but the object classes in the hierarchy are active, which means that upon instantiation of an object to a class the properties, behavior and management policies contained in the relevant AOC are automatically applied to the object without configuration by the user.

---

Note Instantiation is the act of creating a new instance of an object class and applying the properties, behavior, and management policies associated with that class of object.

---

What do the AOCs Contain?

The AOCs are fundamental to the operation of MWFM NMOS and Cisco Mobile Wireless Fault Mediator, so it is important to have an understanding of their content. This section lists the contents of the AOCs and introduces some of the components and terminology which are expanded upon in more detail later in this guide. An AOC contains the following:

•The name of the object class.

•The parent class (or super-class) of the AOC.

•The rules to instantiate a device to an AOC, i.e., how the system determines the class to which an object belongs.

•A reference to the appropriate Data dictionary(s). The data dictionary is like a library. It contains all of the ASN.1 descriptions of all of the datatypes used by the Active Object Class.

•The extensions, which are network management application-specific policies. Cisco Mobile Wireless Fault Mediator has a series of extensions associated with it that include:

–The poll definitions (see "Polling—The Event Generation Process")

–The event correlation methods (see "The Event Management Process")

–The menu methods

•The visual menus for MWFM NMOS.

The Containment Model

In networking terms, containers are objects that can "hold" a collection of other objects or entities, some of which may themselves be containers. The MWFM NMOS Containment Model reflects the real world topology of the network that is being modelled in both a physical and a logical sense. Figure 2-2 shows two ways of applying this containment principle, a physical hierarchy and a logical hierarchy.

Figure 2-2 The Containment Principle using Network Objects

The physical hierarchical Containment Model shows that a switch chassis can "contain" network interface cards, power supplies, and software relating to the internal operating system. The cards in turn can "contain" ports.

The logical hierarchical Containment Model shows that a network also contains VLANs, which contain ports. Logical containment is particularly useful in root-cause analysis. For example, if Port 10 on
Card 1 is associated with a central server, the failure of this server will affect a user connected to
Port 6. Without the ability to incorporate this logical aspect it would be time-consuming to determine that the failure of the central server was also the cause of the problems experienced by the user connected to Port 6 (particularly if they are in different geographical locations).

The Architecture of MWFM NMOS

The concepts described in the first part of this chapter form the basis of MWFM NMOS, which in turn forms the foundation of the MWFM network management suite. With MWFM NMOS installed, other applications or tools can be integrated to form a complete network management solution.

MWFM NMOS is made of eight components which interact to enable all devices on a network to be discovered and an accurate network topology model developed. Table 2-1 provides an introduction to each MWFM NMOS component, as well as a description of its function.

Table 2-1 Synopsis of MWFM NMOS components

MWFM NMOS component and executable name	Function
AUTH (riv_auth)	The authentication engine. AUTH monitors user security privileges and ensures no unauthorized transactions take place within MWFM NMOS.
CLASS (riv_class)	The Active Object Class management and distribution system. CLASS is a dynamic library that manages the AOCs, which contain the criteria for instantiation of network devices and any management policies associated with these devices.
CTRL (riv_ctrl)	The process controller. CTRL initiates and monitors the status of all MWFM NMOS components.
DISCO (riv_disco)	The auto-discovery process controller. DISCO discovers device existence and connectivity via a series of Finders, Discovery Agents and Helpers. The retrieved information is knitted together to form an accurate network topology model by processes called Stitchers.
DIST (riv_dist)	The distribution engine. DIST enables MWFM NMOS to communicate with third party applications and the distribution of MWFM NMOS into multiple domains.
MODEL (riv_model)	The network topology distributor. MODEL is both the repository for the discovered network topology, and the distributor for any application that requires it.
MONITOR (riv_monitor)	The polling process controller. MONITOR is responsible for monitoring the status of devices within the discovered network topology. MONITOR uses a series of Polling Agents—whose polling methodology information is held in the AOCs—to poll the network periodically to determine whether there have been any state changes; as a result of discovering such changes, an event stream is generated which can be sent to other processes for correlation.
STORE (riv_store)	The persistent storage engine and historical archive. STORE qualifies events as topology updates or those generated by the Polling Agents and stores them in a central repository for distribution to other components if required.
OQL (riv_oql)	The Object Query Language service provider and command line interpreter. OQL can communicate with and interrogate the databases of MWFM NMOS.

How MWFM NMOS Components Interact

The components of the MWFM NMOS described in Table 2-1 each perform specific functions to provide a complete network management solution, as in Figure 2-3.

Figure 2-3 The Components of MWFM NMOS

In order to provide a full network management system, the components must share information. At the end of the discovery process conducted by DISCO using Finders, Discovery Agents, Helpers and Stitchers (to resolve device connectivity), a completed network topology is created and transferred to MODEL. MODEL then consults the AOCs through CLASS and each device on the network is instantiated to a particular object class based on the AOCs' criteria. MODEL stores the final topology in a database for distribution to other MWFM NMOS components.

MONITOR can then poll the network for state and information changes via a series of Polling Agents using the network topology from MODEL and the polling strategy for each device class from the AOCs, via CLASS. MONITOR sends the polling strategy to the Polling Agents, who then poll the network for information. The information retrieved by the Polling Agents is sent to MONITOR, which uses it to generate a series of events (depending on how the poll definitions have been configured) and distribute this event stream to any network management applications running on top of the NMOS platform (for instance, Cisco Mobile Wireless Fault Mediator).

STORE can be configured to listen to all information such as events and alerts generated by the interaction of other NMOS components. These events can be created by state changes of devices, determined by MONITOR, or by state changes in topology, through information received from MODEL. This information is placed in a series of databases so that it is available in other NMOS sessions.

To enable MWFM NMOS components to communicate with third-party applications such as help desk or trouble ticketing systems, or even other MWFM NMOS domains, DIST can use a series of configurable listeners to filter information to the particular application.

---

Note A MWFM NMOS domain is not an internet domain. It is a name assigned to a particular view of the network. When MWFM NMOS starts, a domain is always specified.

---

CTRL is the master process run before all other processes; it is used to manage the function and operation of all other MWFM NMOS components.

Policing the communications between all of these processes is AUTH, which supervises all transactions to ensure that the current user has the required access and user privileges to manage and manipulate the network.

Conclusion

This chapter has explored the fundamentals of object-oriented programming principles, the AOCs, the Containment Model, and MWFM NMOS. You have also seen the architecture of the NMOS and how its components share information amongst themselves, other Cisco applications, or even third-party applications. Cisco Mobile Wireless Fault Mediator makes extensive use of the NMOS' functions for fulfilling its tasks, and how it does so is explored in "Introduction to Mobile Wireless Fault Mediator."