CMIP/CMIS - Object Oriented Network Management

With an Object Oriented Framework, CMIP/CMIS provides services to manage and observe objects throughout the Enterprise

This document shows several of the concepts involved in TMN including how the information is organized, how it is accessed, and the nature of some of the types of service areas included within TMN. As a foundation to the operation of a TMN, it is important to first develop an appreciation for the concepts applied to distributed object management systems and with the underlying CMIP/CMIS services.

Object Concepts

A central concept to understanding the operation of TMN is found in the area of object-oriented systems. For those of you come from a Computer Science background with significant exposure to object oriented systems, the concepts are very similar with some slight deviations in terminology. If you only have limited exposure to object oriented design and concepts, any foray into the world of TMN should probably be preceded with some study of object oriented design disciplines. A growing set of resources can be found in the literature. Information on Object Oriented design techniques is available from sources such as Booch, Rumbaugh and others. For getting a more complete description of the object oriented concepts as they apply to CMIP, Stalling's book on SNMP, SNMPv2 and CMIP contains a good section describing the nature of the concepts.

The OSI Management Information Structure (frequently referred to as the Structure of Managed Information, or SMI) is based on collections of objects, some defined in the ISO X.720 series of standards, others that can be found in the TMN M.3100 standards, along with application specific objects that describe the behavior and offer control points for the specific managed systems. Where the SNMP MIB consists solely of a collection of attributes, CMIP based MIBs are a collection of managed objects that contain attributes, exhibit some behaviors, can be created and deleted, and may optionally provide application specific actions that a manager can request. Each object can be viewed as possessing a certain set of behaviors, attributes, and actions. The behavior of an object is directly related to the resource that it represents. For example, a termination point may exhibit the behaviors associated with its relationship with other system components. Attributes contained in an object describe the state and condition of the objects behavior. Continuing with the termination point as an example, attributes can include references to other objects with which the termination point interacts such as a trail. Actions are services that the object can provide at the request of the management system. The templates for an objects behavior are defined with GDMO and ASN.1 for TMN. As objects are identified by the management system agent or manager, objects are instantiated (another term for created). Each class of objects defined in the MIB can be instantiated as many times as the equipment and environment warrant.

Object-oriented system concepts that are applied to the CMIP objects include containment, inheritance, and allomorphism. Containment refers to the characteristic of objects being a repository of other objects and or attributes. For example, a high-level object for a communications switch can contain several racks of equipment, each of which in turn can contain several slots for cards. Inheritance refers to the ability to define an object class that is used as the basis for deriving additional classes. For example, one might use the M.3100 base class for a circuit pack to define the general features of modules within a communications switch. Object classes can then in turn be defined to represent the specific modules. Items including line interface cards, switching elements and processors can be derived from the basic circuit pack definition. Each of these objects exhibits the behavior, actions, and attributes of both the derived classes and the base class. Allomorphism is a concept coined by the CMIP standards bodies to refer to the ability to interact with modules through a base set of interfaces, only to have the resulting behaviors coupled to the complete class definition. For example, disabling a power supply may have significantly different behavior than disabling a switching component.

Organizing the Objects - Multiple Relationships

As in any data intensive system, information must be maintained in some schema with which users (typically management systems) can access the information. Within the OSI management schema, there are three types of relationships between managed objects, including:

Inheritance Tree - defines the managed object class super and sub-classes, much as C++ base and derived classes are related. When a class is inherited from a super class, it possesses all of the characteristics of the super-class, with additional class specific extensions (additional attributes, behaviors and actions)
Containment Tree - defines which managed objects are contained in other managed objects. For example, a subnetwork can contain several Managed Elements (ME)
Naming Tree - defines the way in which individual objects are referenced within the constraints of the management architecture.

Each of these relationships play an important role in defining and implementing MIBS for TMN.

As in the case of other object-oriented systems, inheritance provides an ability to define general, common information in base classes, and define more specific behaviors and attributes in the derived classes. As shown in Figure 1, the case of the OSI SMI, all classes are derived from the highest level of object class referred to as top. Following this inheritance hierarchy, you can see that system is derived from X.721:top, with specific types of systems being derived from the managed object class "system." As each more specific class type is added to the inheritance tree, the derived class adds information more specific to the type of object represented. For example, a multi-point connection may add information describing the specific connection points being included in the connection.

Figure 1 - Top Level OSI MIB Inheritance

Containment

Containment is a feature that allows managed objects to "contain" other managed objects within the system. For example, a packet switch may contain several shelves of equipment, each of which in turn contains one or more circuit packs. The containment relationship is a convenient mechanism to segment the organization of the managed systems information. The containment mechanism is realized through the inclusion of the subordinate (contained) object's object identifier in the superior (containing) class. The object identifiers are stored as attributes within the superior class. Only one superior object can contain any single subordinate managed object, enforcing that the MIB containment be realized through a tree (MIT - Managed Information Tree) structure.

Naming

One of the challenges in implementing CMIP based systems is in the naming, or identification of the objects within the system. Objects can be referenced through a variety of names, a Relative Distinguished Name (RDN), a Distinguished Name (DN, sometimes referred to as the Full Distinguished Name, or FDN), and a Local Distinguished Name (LDN). The RDN, identifies the object within the constraints of its superior (containing object), uniquely identifying the object within the parent object. The DN (or FDN) is the sequence of the RDN starting at the top of the global system root. The DN uniquely identifies the object within the global containment tree. Finally, the LDN is expressed as a sequence of RDN starting at the local system's root.

Object Composition

Managed objects are composed of several items. Base classes are defined with the referenced class being "derived from" the parent classes. At the most basic level, each managed object can include the following:

Attributes - that contain values describing the state of the object, or that reference contained objects.
Behaviors - represent the types of behavior that the managed object will exhibit. This is currently expressed in the Guidelines for Definition of Managed Objects (GDMO) as text. The managed device will typically implement this in the manner appropriate to its role within the system.
Actions - services provided by the managed object that can be activated on the request of the management system.
Notifications - messages that can be originated by the managed object on the occurrence of system critical events.
Packages - collections of attributes, behaviors, actions, and notifications that can be grouped into one or more managed object class specifications.

When accessing managed objects, these parameters are the points of reference used by the CMIP managers. The mechanisms for accessing this information are described in more detail in the following sections.

CMIP - Common Management Information Protocol

Access to managed information in the managed objects is provided by the Common Management Information Service Element (CMISE) that uses CMIP to issue requests for management services. The management services provided by CMIP/CMISE can be organized into two distinct groups, management operation services initiated by a manager to request that an agent provide certain services or information, and notification services, used by the management agents to inform the managers that some event or set of events have occurred. Operations initiated by the manager include:

Figure 2 - Manager to Agent Relationship

CMIP Protocol Service Elements

M-CREATE - directs the agent to create new instance(s) of a managed object class or attributes within a managed object
M-DELETE - directs the agent to delete existing instances of managed object class(es) or attributes within a set contained in a managed object
M-GET - directs the agent to return attribute values from managed objects
M-SET - directs the agent to change the value of managed object attribute(s)
M-ACTION - directs the agent to cause one or more managed objects to execute an action
M-EVENT_REPORT - service is issued by an agent to send a notification to managers

Figure 3 - Detailed Manager to Agent Relationship

Scoping and Filtering

The CMISE makes use of the OSI Application layer service elements to complete the processing of these requests. The Association Control Service Element (ACSE) is used to establish application associations between managers and agents. The Remote Operations Service Element (ROSE) is used to frame the information requests and transfers, much as Remote Procedure Calls (RPC) are used on other systems.

CMISE applies some additional powerful features to the operations that help further distinguish CMISE from SNMP. The M-GET, M-SET, M-ACTION, and M-DELETE services can be applied to more than one managed object through the application of what are termed scoping, filtering, and synchronization.

Figure 4 - CMIP Protocol

CMISE requests can be scoped to apply to a range of managed objects. Four levels of scoping can be applied, with the request being applied to:

The base object (as identified by the Distinguished Name)
Objects at the nth level subordinate to the object. The base object is termed to be at level 0 for this type of scoping
The base object and all managed objects to (and including) the nth level
An entire subtree - the base object and all subordinate objects on the containment tree

Filtering is the application of a boolean expression to the request, with the request being applied to only those managed objects and attributes to which the expression is TRUE. The types of rules that can be applied to the request include equality, greater than or equal, less than or equal, and presence of an attribute. Other set and string based tests can be asserted, with combinations of the filters being grouped with the standard boolean terms of AND, OR, and NOT.

Once all of the requested objects have been identified (meeting both the scoping and filtering criteria), the performance of the request can be completed based on one of two synchronization schemes: atomic or best-effort. Atomic operations are only performed when all managed objects pertaining to the scoping/filtering are able to successfully complete the requested operation. Best-effort synchronization will direct the request to all applicable managed objects. The requested operation is completed by as many objects that can comply.