TMN cube

The three architectures described in TMN were introduced to show the perspective in the standards. A different view is provided in terms of three planes that form the TMN cube. The reason for this perspective is to show that physical architecture is realization of the components required to form the various planes. The logical plane corresponds to functional blocks such as OSF described earlier. The management functional plane includes the information architecture as well as the application functional component. The reason for combining these two concepts is to point out that the information architecture addresses both these areas: Management information is dependent on both the managed resource as well as the Management application function (e.g., performance monitoring of severely errored seconds for a subscriber termination). The third plane defines communications requirements for exchanging the management information in the function plane for the activities described in the logical plane. A physical realization of a TMN requires the three planes.

1. Logical Plane:

1.1. Distribution of Activities. The logical function blocks NEF, OSF, MF, WSF, and QAF described earlier may also be viewed as a distributed set of activities in support of TMN. In some cases, even if the same activity is performed by more than one function block, differences exist in the details of management information. Consider the activitygeneration of management information. A network element performing this activity will generate what is specific to itself such as a critical alarm in a circuit pack contained in the network element or collect traffic statistics for the number of blocked calls. A mediation device or a gateway network element that includes mediation capabilities may also support the generation capability. The difference in this case is the information may be derived from lower level information gathered either from the gateway NE itself or from other network elements connected to it. This is further illustrated in the next section. An analysis activity such as determining the root cause of multiple failures received from different Supplier network elements are more appropriately considered as an OS function. In recognition of the fact that multiple activities are performed in a TMN, the logical function blocks are further decomposed into various components. These are: Management application function (MAF), Information conversion function (ICF), Message communication function

(MCF), Workstation support function (WSSF), User interface support function (UISF),

Directory system function (DSF), Directory access function (DAF), and Security function (SF). Each of the logical function blocks identified earlier may have one or more of these functional components. The activity to generate management information is part of the management application function. Table 1.1 shows how these functional components may be distributed within TMN function blocks. It should be noted that to understand TMN fundamentals it is sufficient to note that the above components are required either explicitly or implicitly. For example, to establish communication between an OS and an NE, it is necessary to know the address information. This may be obtained by communicating first with the system that contains the directory information using the access and system functions (DAF and DSF) or may be stored in a local directory within the system initiating the connection. The Message communication function (MCF) addresses the communication of management information and is included as part of all the function blocks. The distinction between DCF and MCF is really in the actual activities. DCF is related primarily to communicating bits across a network of nodes that may do routing and relaying function. An example of DCF is using X.25 to communicate the information reliably between the end systems. MCF pertains to end system communication of the management information. Reporting an alarm on a line card is an example of MCF. In other words, DCF addresses those aspects that are required by any communicating application. MCF includes both DCF aspects in the end system as well as the communication of application specific information. The protocol conversions required when, for example, intermediate or gateway systems are present to bridge between TMN and non-TMN environments are considered within the scope of MCF.

TABLE : Distributions of Management Activities

Logical Function Block OSF NEF MF QAF

Possible Activities MAF, WSSF, ICF, DAF, DSF, SF MAF, DSF, DAF, SF MAF, ICF, WSSF, DSF, DAF, SF MAF, ICF, DSF, DAF, SF

1.2. Levels of Abstractions. In addition to decomposing the function blocks in terms of the components related to activities, the information managed by an OSF may be further separated into various levels of abstractions. These are sometimes referred to as layers as discussed earlier. This concept is best illustrated using examples. Consider the application in an OSF that receives alarms from resources such as circuit pack and customer end points. Information on the type of circuit pack, severity of the alarm, whether it is protected by another equivalent circuit pack, and which customer terminations are being affected because of the circuit pack failure are generated by the network element. This is elemental level (EL) information from the management perspective and is often determined by the architecture of the network element product. This level of abstraction is considered as part of the Element layer function. In order to support various telecommunication services, a network element is often managed by a management system. Management activities performed include provisioning the network element to offer telephony service, the type of signaling function code (e.g., two-wire loop start), assignment of cross connects between the time slot in a DS1/E1 to a switch and a binding post corresponding to a customer termination, receiving alarms and performance monitoring events from the network element. The information is managed at the elemental level. The level of abstraction for the element level information processed by the management system is referred to as element management layer (EML). Even though EL and EML abstractions define the management functionalities that are performed for each network element to support a service, the two levels do not form the complete picture when considering an end-to-end service offered by a provider. To support a service that allows a customer to make telephone calls within a geographic area, a collection of networks that support switching and transport aspects are required. The EML abstraction

provides the view relative to each network element. However, to understand network level impact, a higher level abstraction is required. An example is a fiber cut between NEs which impacts network level. In the above example, loss of signal alarm may be issued relative to various terminations that are associated with the cut fiber in the two network elements. Functions are required to correlate these various alarms and determine the root cause of the alarm, namely fiber cut. The information processing and determination of the root cause for the network failure is a level of abstraction referred to as network management level (NML). The network level abstraction makes visible the details of the components of the network. However, consider the case where a customer is only interested in the knowledge of whether the service is protected to guarantee service availability. The customer is not concerned about how this objective for the quality of service (say 99.999% availability) is met by the service provider. Hiding the details of the network level information and projecting a service perspective is referred to as service management level (SML). The highest level of abstraction is known as the business management level (BML). As the name implies, the information associated with this level of abstraction addresses enterprise objectives. TMN standards and implementations have defined specifications that are relevant to all the layers except the BML. This is to be expected because the management information is driven by market needs, enterprise specific considerations, and goals which are not subject to standardization. These levels of abstractions are typically shown in presentations using a pyramid-like figure where the highest point of the pyramid is BML. Although these five levels of abstractions are defined theoretically, these levels should not be equated to imply that management systems are separated according to these levels. Business management level information (BML) Service management level information (SML) Network management level information (NML) Elemental management level information (EML) Elemental level information (EL)

Figure : TMN levels of abstractions.

In addition, there are no strict boundaries specifically in the case of EML, NML, and SML abstractions. This can be illustrated by the following example. Consider provisioning of a service like Leased circuit service. Depending on the customer and how the provider defined the service offering, network level information may be made available when provisioning the service. A spectrum may exist in how a customer requests this service a circuit with a given quality of service is to be provisioned from point A to B at one end of the spectrum. At the other end, the customer may specify exactly the route to be taken (assuming the customer has leased services on these nodes) in provisioning the service in terms of the network nodes to be used. The latter may be triggered by business agreements the customer has with different providers that offer the service between A and B. The first case is an example where the information exchanged between the customer and the service provider may be considered as service level information. In the latter case, the exchange includes network level information. In other words to provision the service, information exchanged overlaps two levels.

1.2. Management Functions Plane

1.2.1. Functional Components. Given the logical partitioning of functions in terms of NEF, MF, OSF, and WSF, the information required for successful management for all levels of abstractions mentioned earlier are derived from another category of functions referred to as TMN function sets.12 These TMN function sets are grouped into five categories following the five areas of OSI management defined in ISO 7498 Part 4 (X.700). These are configuration, fault, performance, security, and accounting. The number of function sets within each area varies. These function sets are further divided into TMN functions that are atomic. As an example, alarm surveillance is a function set within the area of fault management and reporting alarm is a TMN function belonging to this function set. ITU recommendation M.340013 defines the TMN function sets and functions. Chapter 2 discusses these functions in detail. Table 1.2 provides a high-level view of the groups of TMN functions for each area of management. Even though many of the standards have been developed using these five categories, it should be noted that to avoid duplication a set of management functions are

defined (and continue to evolve). These are sometimes referred to as "common." An example of such a function is "controlling reporting events (irrespective of the functional area such as an alarm for fault and threshold crossing alert for performance) to specific destination according to a defined schedule."

1.2.2. Levels of Abstractions. Extending the discussions from Section 1.3.2.1, it is easy to see that the management functions in the five functional areas can address different levels of abstraction. Consider the function set Alarm surveillance. One of the lower level functions in this set is reporting alarms. Referring to the levels of abstraction in the logical plane, assume that a network element emits a notification when a circuit pack is disabled. The alarm is determined by the network element to be at a severity level of major because a switch to the protecting circuit pack took place after the alarm occurred. A report alarm message for this level of abstraction is likely to include the identity of the circuit pack, severity of the alarm, probable cause for the failure, and the identity of the protecting circuit pack. Let us now assume that a customer who has requested a high quality of service (determined by the availability) has a binding post associated with a termination in this circuit pack (channel unit). The result of the failure puts at risk the promised quality of service because the Protection function is no longer available until the failed card is replaced. An

TABLE : TMN Functional Components

Functional Area Fault Configuration Performance Security Accounting

Function Sets Alarm surveillance, fault isolation, and testing Provisioning, status and control, and installation Performance monitoring, traffic management, and quality of services Security of management and management of security Usage metering, billing

Alarm with the severity value of warning may then be issued to the customer relative to the possible degradation in the quality of service. A trouble ticket may be created so that

preventive maintenance is initiated. From the perspective of the TMN management function, the function performed is "reporting an alarm identifying the entity, severity, and cause of failure." However, the semantics of the information exchanged is tailored to the level of abstractionnamely elemental level versus service level. A 5 X 5 matrix results by combining the levels of abstractions in the logical plan and the five areas of management functions in this plane. However, it is obvious that not all areas of management functions will be applicable in all cases (alarm functions in a business management abstractions are not meaningful).

1.3. External Communications Plane

13.1. Infrastructure Components. The logical and functional planes together define how responsibilities, to meet the functional aspects of network management as an application, are partitioned among the various function blocks. Management by definition implies that system(s) in the managing role monitors and controls a set of resources in managed system(s). To perform these management activities it is to be expected that communication between the systems is required via an external interface. The third dimension addresses this requirement. The communication aspects may be further divided into two categories. Infrastructure components are required to convey the management information irrespective of resources being managed and the actual application (performance monitoring, alarm surveillance, etc.). These components define functions such as end-to-end integrity, segmenting, and retransmission of messages based on the size of the packets supported by the underlying network along with a well-defined structure for management information. The infrastructure requirements are dependent on the class of application. Two classes of applications have been defined to support the various TMN functions: interactive and file transfer. The interactive class of applications in most cases exchange information using a request/reply paradigm such as requesting the alarm status, remote inventory of equipment, and receiving a response. The file transfer application requires remote manipulation of files and bulk transfer of data such as software download. ITU Recommendations Q.811 and 812 define the requirements for the communication infrastructure. Different options are provided so that various networking protocols (SS7, ISDN, X.25) available in existing networks may be used.

13.2. Contents of Exchange. The infrastructure components define the fundamental communications requirements and are for the most part reusable across applications. TMN Architecture Using the structure for exchanging the management information, the content may vary based on the resource being managed and the TMN function. For example, the exchanged information to report an alarm from a synchronous digital hierarchy (SDH) virtual tributary (VT) termination point will differ from the request/response regarding the state information. In other words, as will be seen later, the content of the exchange is obtained by populating the common structure with resource and function specific information. For the interactive class of applications, the content is determined using information models that define the management views of the resource and the application function. For file transfer class, the structure of the file, and information in the records will define the contents. The levels of abstraction defined earlier also play a role in determining the content by identifying the type of resource being managed. For example, the element management level abstraction may be for the individual terminations in the network element, while the network management level abstraction may be relative to a circuit formed between terminations at two end points.

1.4. Physical Realization

All three planes are essential in completing the picture for TMN. The information and activities in each of these planes when implemented in products results in the physical realization of these concepts. One example of the physical architecture was shown in Figure 1.5. The logical plane is realized in terms of systems such as OS, NE, and MD. The functions supported by these systems when, for example, an OS implements alarm surveillance capabilities (receive alarm reports, retrieve alarm status), are a physical realization of the functional plane. The external communications capabilities are realized when, for example, an OS requests alarm information from an NE.