Last update
PvD
4 TMN Concepts
Overview
TMN uses Object Oriented techniques to define management (functions and) interfaces. This chapter discusses those concepts in TMN terminology. These management concepts are borrowed from the definitions for management of Open Systems Interconnect (OSI, open data networks and their management: X.7xx-series).
- Managed Object
- Information Model
- Management Information Base
- Agent Functionality
- Manager Functionality
- Management Application Function
- Shared Management Knowledge
- Manager/Agent Relationship
- Cascading
- Peer to Peer
- Summary
Managed Object
A Managed Object (MO) is the abstraction of a network resource (physical or functional), representing its properties as seen by –and for the purpose of– management. So, a managed object is defined by: [M.3010]
- the attributes visible at its boundary;
- the (management) operations which may be applied to it {in O.O. terminology: 'methods'};
- the behaviour exhibited by it in response to management operations or in reaction to other types of stimuli. These can be internal (e.g. threshold crossing) or external (e.g. interaction with other objects);
- the notifications emitted by it.
This fully conforms to the object oriented approach in information technology.
Note that:
- The resources represented by a managed object can be physical or functional (logical);
- A managed object may represent functional resources of the TMN (rather than resources of the telecommunications network);
- There is not necessarily a one-to-one mapping between a managed object and a actual resource;
- A managed object may also represent a relationship between resources or a combination of resources (e.g. a network);
- A resource may be represented by one or more objects. In that case each of those objects provides a different abstract view of the resource;
- If a resource is not represented by a managed object {so it is not visible for the management system}, it cannot be managed across the management interface.
Also:
- A managed object may provide an abstract view of resources that are represented by other managed objects {an object may represent multiple lower level objects, so to obtain a higher level abstraction};
- Managed objects can be embedded, i.e. a managed object may represent larger resources that contain resources themselves modelled as sub-entities of the larger object {high level object and low level object can both be visible externally}.
Examples:
- Objects representing physical resources: an exchange (Network Element), a subscriber module, racks, boards, etc.
- Objects representing logical resources: a subscriber (profile), a connection, etc.
Information Model
[M.3010]: The managements Information Model (IM) presents an abstraction of the management aspects of network resources and the related support management activities. The model determines the scope of the information that can be exchanged in a standardized manner.
This activity to support the information model takes place at the application level and involves a variety of management application functions such as storing, retrieving and processing information. The functions involved at this level are referred to a 'TMN function blocks'.
The collection of objects –with all attributes, methods and behaviours– representing the network is the Information Model. That is, the network is modelled into a set of managed object classes. An Information Model is a 'reference point' for TMN, as objects and transactions are defined.
Recommendation [M.3100] defines a Generic Network Information Model (GNIM). Variants of this Information Model are required to specify specific networks (e.g. X25, ISDN, SDH). Also higher level abstractions are required for SML, and lower level abstractions for specific Network Elements are required.
Management Information Base
[X.700]: The set of Managed Objects within a system, together with their attributes, constitutes that system's Management Information Base (MIB).
An Information Model (IM) will vary with (the type of network and) the abstraction level of the network. This is similar to the architectural layers, but not identical as there can be hierarchies within the same architectural layer.
The MIB is an instantiation of a particular IM. The IM defines potential objects (object classes) and potential relationships; the MIB describes actual values, typically multiple instances of the same object class.
The IM defines building blocks, the MIB describes a particular construction and represents actual network resources. The distinction is comparable to type definitions and variable definitions in conventional programming languages.
See section Components.MIB for details.
Agent Functionality
As described above, a managed object is defined by its attributes visible at the boundary, operations which may be applied to it, its exhibited behaviour and the notifications (responses and spontaneous messages) emitted by it. The object represents a physical resource or a functional resource (abstraction of a lower level object).
The management interface to such an object is handled by an Agent, i.e. the Agent will perform the management operations (directives, transactions), and signal changes (notifications) of these objects. This allows standardisation of operations and notifications, without defining implementation.
Note that when the Resource is an actual network resource, it is not part of the TMN but of the managed network (NEL). When the above mentioned resource is an abstraction/representation of a lower level managed object, then it will ultimately perform management operations on the lower level objects presented by it.
Manager Functionality
A management function sees through the Information Model the abstract representation of resources (i.e. Managed Objects). It may take action on its own accord to manage the resources, or the action may be instigated by higher level functions (other managers or humans).
Management Application Function
When the Managed Object is an abstraction of a lower level object, i.e. there is an Information Model for the lower level object, it will include a Manager function to translate operations on the Managed Object to manage meant operations on the lower level object, and to interpret lower level notifications in the Managed Object corresponding behaviour.
The combination of Agent, Managed Object and Manager allows to translate one Information Model into another one: this is called a Management Application Function (MAF).
A collection of such MAFs can be used to implement a Logical Layer in the hierarchical architecture. TMN only defines particular interfaces through IMs; these are the standard reference points.
Such a configuration allows standardization of management operations by defining the transactions on an object and its behaviour, independent of implementation.
Note that an Agent may interface to (represent) multiple objects; each object has basically a single Manager to interface to lower level objects.
Shared Management Knowledge
The management function in a TMN system is build using functional blocks called Management Application Functions (MAFs). Such a MAF manages 'managed objects' through operations via an agent. To effectively manage objects, the Manager function must know actual values of objects, i.e. the MIB. However, it should not copy the MIB as object values may change dynamically reflecting changes in lower level objects/resources represented by the MIB. It should manage remotely, i.e. interrogate the MIB and issue directives. This implies that it will have some minimal {and temporary ?} information on Managed Objects: this is called Shared Management Knowledge (SMK).
Of course, the SMK includes the IM.
Manager/Agent Relationship
A management process will take one of two possible roles: [X.701]
- Manager role
- issuing management directives, and receiving notifications;
- Agent role
- respond to management directives, provide a view on managed objects and emit notifications reflecting the behaviour of these objects.
The role may vary depending on the current association {i.e. which side of the MAF is used}. Also it is clear that the Manager/Agent relationship is asymmetric.
Interaction between Manager, Agent and object
The Manager/Agent relationship is basically a many-to-many relationship: multiple Managers can be associated with multiple Agents. In practice the Manager/Agent relationship is typically one-to-one or one-to-many.
The Manager/Agent relationship is a client/server relationship: the client tells the server what to do, and never the other way around. However, the Agent may deny a Manager's directive for several reasons (e.g. security, consistency, etc.). If the Agent wants something done, it can send a notification to the Manager; the Manager will decide to act on it or not.
The Manager/Agent relationship is commonly hierarchical, but not necessarily always so; it can be peer-to-peer (or client/server). As an Agent may have multiple Managers, it is never master/slave.
Synchronisation
The responsibility for synchronization (manager and agent having identical dynamic data) can be with the Manager (typically when there is only a single Manager for multiple Agents) or with the Agent (typically when there are multiple Managers). The Manager can request information, and the Agent can issue Notifications to achieve synchronisation.
Cascading
The Manager/Agent relationship in MAFs are commonly related in a hierarchy. This hierarchy of MAFs (superior/subordinate MAF) is not identical to the Logical Layered Architecture (TMN layers BML/SML/NML/EML/NEL); multiple MAF layers can be present within a single Logical Layer.
Note that such cascading of Manager/Agents can also be used to adapt the Information Model, i.e. not with the purpose to obtain higher level of abstraction, but to manage a foreign system with a slightly different Information Model. Then it is not 'layering' but 'serializing'.
Peer to Peer
One may have a peer-to-peer relationship between MAFs.
This suggest symmetry, but that is usually not the case.
There are two opposing Manager/Agent relationships where the shared management knowledge usually is asymmetric. Such an interface consists of two Information Models (reference points) in opposing directions ('anti-parallel'). [X.701 fig 5]
Summary
The following concepts were defined:
- MO
- Managed Object provides an abstract view on physical or functional (network) resources (OO: object instantiation).
- IM
- Information Model provides a generic abstract view on (the management aspects of network) resources, and is the reference point for standardization (OO: object 'class').
- MIB
- Management Information Base is the instantiation of the IM and contains actual Managed Objects with actual values (i.e. catalogue of Managed Object instances; OO: collection of object instances).
- Manager
- Makes decisions on its own, issues management directives, and receives notifications.
- Agent
- Responds to management directives, provides a view on managed objects and emits notifications reflecting the behaviour of these objects. It will never make (management) decisions on its own (but can only suggest such to the Manager via notifications). The Agent may refuse commands.
- Relationship
- The Manager/Agent relationship is a client/server-relationship, commonly hierarchical, but not necessarily so. The relationship can be peer-to-peer ('anti-parallel' Information Models), is basically many-to-many, and is never master/slave.
- SMK
- Shared Management Knowledge is the information shared between Manager and Agent (includes an IM).
- MAF
- Management Application Function, the combination of Agent, Managed Objects and Manager(s) maps one Information Model to another, and forms a generic managed object. Note that:
multiple MAF (layers) can be present in a single layer of the Logical Layered Architecture, or
MAFs can be serialized (cascaded) to adapt a foreign Information Model.
=O=
