13.2. Information Models

It was stated earlier that telecommunications management is about configuring, monitoring, and trouble-shooting telecommunication services and equipment. Given that there is a plethora of different types of telecommunications equipment and services, any approach for standardizing the management process needs to start with a basic model of the equipment or the service to be managed. Such models are typically referred to as information models. These models in the past have been associated with specific management protocols. The trend in recent years has been to separate these models from particular management protocols and to describe them in a protocol-independent manner.

Almost all current approaches to describing these management information models are based on object-oriented terminology used in software design [Meyer97]. In addition, there is an abundance of formalism contained in the ITU-T recommendations [ITU-T92b]. In the following, we give an overview of these information modeling concepts and the key object models.

13.2.1. Managed Objects

A managed object is a representation of a real world entity that is being managed. More formally, telecommunications management information is structured in terms of managed objects, their attributes, the management operations performed upon them, and the notifications they emit [ITU-T92c]. The internal structure and operation of a managed object is hidden, and one cannot make assumptions about the implementation of the object. This is generally referred to as encapsulation.

As an example, consider an SDH regenerator section (SONET section) layer signal. As an object, its attributes include block error counts, background block error counts, and various other performance data (see Chapter 2). Besides the general administration of the signal (e.g., putting it in or out of service), management operations would include setting the section trace string and the expected section trace string. Notifications that may be emitted by this object include the Loss of Frame (LOF) alarm and a section trace mismatch notification. Figure 13-2 depicts a possible Unified Modeling Language^[1] (UML) [Douglass98] diagram representing this section layer signal.

^[1] UML is an object-oriented modeling language specified by the Object Management Group (OMG). Its specification can be obtained at www.omg.org.

The data structure representing the set of all managed objects within a system or area of interest is referred to as a Management Information Base (MIB).

13.2.1.1. RELATIONSHIPS

Relationships between managed objects is defined in ITU-T recommendation X.732 [ITU-T92d] as follows:

A relationship is defined by a set of rules that describe how the operation of one part of a system affects the operation of other parts of the system. A relationship is said to exist among managed objects when the operation of one managed object affects the operation of the other managed objects.

It is essential to understand the dependency, ownership, or other types of relationships among managed objects. For example a SDH VC3 (Trail Termination Point, TTP, see Chapter 5) has a relationship with a corresponding SDH AU3 (connection termination point, CTP). The AU-3 consists of the VC-3 plus an AU pointer, which indicates the phase alignment of the VC-3 with respect to the STM-N frame. A VC3 cross-connect terminates the AU3, extracts the VC3, and without modifying any of its contents, adapts it to a new AU-3 for transport in an outgoing STM-N frame. Hence, the VC3 (TTP) has a dependency relationship with both of these AU3 signals. In particular, if on reception of the AU3 a loss of pointer (LOP) is experienced, then this will have a deleterious effect on the VC3. The UML diagram shown in Figure 13-3 portrays this relationship.

13.2.1.2. CONTAINMENT

Containment is a strong form of dependency between managed objects. In this relationship, one managed object contains one or more other managed objects.

A typical containment diagram is shown in Figure 13-4. Here, we see that a network consists of managed elements, which encompass various equipment, which in turn contains equipment holders (slots), circuit packs, and software [ITU-T95b].

Another important example of containment arises from the multiplex structures common in the optical world. For example, an SDH multiplex section (MS) layer signal (trail) transports a number (up to N) of AU-4 connections (the server layer for a VC-4 trail). Note that the fate of these AU-4s and their VC4 clients are intertwined with that of the SDH MS trail that contains them. This relationship is shown in Figure 13-5.

Containment relationships between managed objects are also used in their identification. In particular, managed objects are usually named relative to the objects that contain them. The general principles for naming are laid out in reference [ITU-T92b] in which relative distinguished names (RDNs) are defined. Naming in general is rather straightforward. For instance, a specific AU-4 signal can be precisely identified in relation to an SDH MS signal, which in turn can be identified by the particular port, line card, shelf, and equipment that terminates the signal.

13.2.1.3. INHERITANCE

The broad type of a managed object is also referred to as its class. For example, a 4-port OC-48 (STM-16) line card can be considered as a class, many instances of which can be used in a given system. Classes are partitioned into related groups to form a hierarchy. The more general classes appear at the top of the hierarchy, and the more specific or specialized classes appear at the bottom. A class, which is related to another further up in the hierarchy, is said to have an inheritance relationship with the latter. In particular, a specialized class is derived from a more general class by defining extensions to the latter. Defining new operations, attributes, and/or notifications constitute such an extension. A general class, however, cannot be “extended” by deleting any of its attributes, operations, or notifications.

As an example, let us examine how inheritance is used in dealing with SONET/SDH current data performance monitoring objects. Figure 13-6 depicts a UML diagram representing certain interesting SDH performance monitoring classes. To understand the functionality of the classes at the bottom of this hierarchy, it is necessary to first understand the functionality of the classes at the upper levels of the hierarchy (as the former classes inherit this functionality).

At the very top of the inheritance hierarchy is the class Top. This class has two attributes: (a) ObjectClass, which gives the name of the class, and (b) NameBinding which gives the name of the object (of this class) and, if appropriate, the name of an object that may contain this object. This is somewhat similar to the functionality one finds in the Java programming language's Object class [Cornell+97], and it allows the determination of the type of object and its name. The Scanner class directly inherits the properties of the Top class [ITU-T94a]. The Scanner class represents data that are periodically collected, that is, scanned. The attribute, granularityPeriod, indicates the time interval between scans. Note that Scanner has both administrative and operations states, that is, the collection of data can be turned on and off and an indication as to whether data collection is working can be obtained. The next class down the hierarchy is the CurrentData class, which builds on the functionality of the Scanner class [ITU-T94a]. The CurrentData class adds the following attributes: elapsedTime, which indicates the time since the collection started; historyRetention, which indicates how many CurrentData objects should be kept as part of a history mechanism; and suspectIntervalFlag, which flags the potential corruption of data due to some unforeseen occurrence during the collection interval. Directly inheriting the currentData class are the SDH CurrentData [ITU-T01e] and SDH Current Data Unidirectional [ITU-T01f] classes. One important property of these classes is that they require a granularity period (from the Scanner class) to be able to take on the values of 15 minutes and 24 hours, respectively. Finally, layer-specific performance monitoring classes based on B1, B2, B3, M0/M1, and pointer events are derived from these classes. These are the rsCurrentData, msCurrentDataNearEnd, pathCurrentDataNearEnd, msCurrentDataFarEnd, and msAdaptation CurrentData classes.

Two points should be noted from this example. First, object-oriented information models utilizing hierarchy are quite general and extensible. Second, it can be a lot of work to decipher these models. In general, the deeper the inheritance hierarchy, the more work it takes to determine how the classes at the bottom behave. The designer of object-oriented software is usually advised not to create hierarchies that are too deep or wide [Meyer97, Booch96]. But the development of information models used in standards efforts is often distributed over time, and it becomes difficult to control the depth or breadth of the inheritance hierarchies. Actual software implementations of these models, however, tend to “optimize” by merging many levels of the hierarchy together.

13.2.2. State

The state of an object is given by the values assumed by all its attributes (both externally visible and internal). When dealing with certain types of managed objects, it is useful to refine this notion. In particular, reference [ITU-T92e] distinguishes between operational, usage, and administrative states, and defines attributes that describe these states.

The operational state attribute has two possible values, disabled and enabled. It describes whether the underlying resource is physically installed and working.

The usage state attribute has three possible values: idle, active, and busy. This describes whether the underlying resource is actively in use and, if so, whether there is spare capacity for additional users at a specific instant.

The administration of a managed object is independent of its operability and usage. The administrative state attribute has three values: locked, unlocked, and shutting down. The administrative state is used to permit or deny access to a resource. Note that the state of a managed object does not affect its ability to respond to management operations.

In addition to these attributes, there are also a number of status attributes that give further information on the state of an object [ITU-T92e]. These status attributes include alarm status, procedural status, availability status, control status, and standby status. The most important of these is the alarm status. This attribute can take on one or more of the following values: under repair, critical, major, minor, and/or alarm outstanding. The meaning of the levels of alarm severity is discussed in section 13.2.3.1.

13.2.3. Events and Notifications

A notification is information emitted by a managed object about an internal event. Important aspects of notifications include their targets and how they are controlled under different conditions. The notion of notification in telecommunications information models corresponds to object-oriented software interaction known as the publish-subscribe paradigm. Before delving into the control of notifications, it is instructive to examine one of the most important types of notifications in telecommunications management.

13.2.3.1. ALARMS

Alarms are specific types of notifications concerning faults or other abnormal conditions occurring within objects. Key ingredients of an alarm notification are the type of event that occurred, the perceived severity, and the probable cause. Other relevant information pertains to the time the event occurred and identification of the notification/alarm.

The following levels of alarm severity are defined in [ITU-T92f]:

• Cleared: Indicates the clearing of one or more previously reported alarms.

• Indeterminate: Indicates that the severity level cannot be determined.

• Critical: Indicates that a service-affecting condition has occurred and an immediate corrective action is required. This severity level may be reported when the underlying resource goes completely out of service and its capability must be restored.

• Major: Indicates that a service-affecting condition has developed and an urgent corrective action is required. This severity level may be reported when there is a severe degradation in the capability of the underlying resource and its full capability must be restored.

• Minor: Indicates the existence of a non-service-affecting fault condition and that corrective action should be taken in order to prevent a more serious (service-affecting) fault. This severity level may be reported when the detected alarm condition is not currently degrading the capabilities of the underlying resource.

• Warning: Indicates the detection of a potential or impending service-affecting fault before any significant effects have been felt. Action should be taken to further diagnose and correct the problem in order to prevent it from becoming more serious.

Table 13-1. Alarm Notification Types

Alarm Type	Definition
Communications	Concerned with the processes required to convey information from one point to another, e.g., loss of signal, loss of frame, etc.
Quality of service	Concerned with a degradation in the quality of a service, e.g., BER above a given threshold.
Processing error	Concerned with software related faults.
Equipment	Concerned with equipment faults, e.g., line card failure.
Environmental	Concerned with a condition relating to an enclosure in which the equipment resides, e.g., excessive heat, humidity, etc.

Table 13-1 lists the standardized alarm types [ITU-T92f].

A partial UML diagram corresponding to the formal alarm record object and its inheritance hierarchy is shown in Figure 13-7. A lengthy list of standardized probable cause values can be found in reference [ITU-T92f] and includes such items as loss of frame, fire detected, flood detected, and so on.

13.2.3.2. EVENT REPORTING CONTROL

In addition to alarms, there are a number of other notifications that can be sent. In particular, object creation, object deletion, and attribute change notifications would be more common than alarms if a control plane is used for provisioning. As an example, consider the creation of a cross-connect. If the cross-connect utilizes a previously idle connection termination point on a SONET line, a usage state change message (from idle to in-use) would be generated for the corresponding object.

When dealing with telecommunication managed objects, it is useful to go beyond a simple publish-subscribe paradigm under which a recipient must directly subscribe to receive notifications from the generator. Figure 13-8 shows a system containing a number of managed objects. External entities, shown as notification subscribers, register to receive notifications via an event forwarding discriminator, rather than directly “subscribing” to receive notifications from individual managed objects [ITU-T92g].

This approach has a number of advantages over the publish-subscribe method. First, it is not necessary to deal with a potentially feature-rich external interface when implementing a managed object. Second, this model allows subscribers to receive broad classes of events. For example, an event forwarding discriminator can allow a particular management system to receive all communication alarms of severity greater than minor from all SONET section and line layer objects within a given piece of equipment. Third, given the large number of possible notifications that may be generated and their differing importance, an event forwarding discriminator can be used to prioritize notifications, control their rate, and provide different services such as confirmed and unconfirmed delivery. This turns out to be an important function, because a single fault may result in multiple notifications with varying levels of importance. Such an event, if left uncontrolled, can cause “alarm storms” during which the control network is flooded with alarms. In this case, many ancillary alarms may cause a main alarm to be lost or delayed.

13.2.3.3. EVENT LOGS

Given the importance of alarms in telecommunications management, it is clear that any system that performs a significant communications function must support notifications. With more sophisticated equipment, it may be important to keep a log of events that aid in understanding system usage, failure modes, or other functions. It is possible to implement such a log when a system supports persistent storage such as a hard disk, flash memory, or battery-backed memory. These system logs can be the equivalent of a commercial jet's flight data recorder (black box) in that they allow the operator to piece together what may have caused an incident to happen.

What kind of information goes into a log? As per the information models in the ITU-T recommendations, the following record classes inherit from the generic event log record class [ITU-T92h]: alarm records [ITU-T92f], object creation, deletion, and attribute change records [ITU-T92i], security audit trail records [ITU-T92j], state change records [ITU-T92e], and security alarm report records [ITU-T92k]. There can be vendor specific records in addition to these, for example, software debugging records.

These records may be stored in many different logs rather than in a single event log. This allows some logs to have different access or modification privileges. This also eliminates the need to browse through a number of (irrelevant) records to find a specific type of information. For example, software debugging records would most likely be kept in a separate log since they would be meaningful only to the equipment vendor and not to the user of the equipment. Security audit trail records would most likely be kept in a log with restricted access privileges.

Figure 13-9 depicts a UML diagram illustrating log objects and their system context. Attributes of an individual log include the type of records held and the managed objects that these come from. This picture is similar to the one depicted in Figure 13-8 except that logs keep information entirely within the system.

A log is a managed object by itself [ITU-T92h]. It has a unique identifier, an administrative state (enabled or disabled), and an operational state. A log is further characterized by the type of information to be logged and its behavior when maximum capacity is reached, for example, does it wrap around, stop logging new info, emit a notification, and so on.