 |
 |
 |
 |
|
|
|
|
The TMN Platform is described in terms of the services which are provided. These are sub-divided into the lower layer service (ISODE) and the upper layer services (OSIMIS). Background information to the development of the platform is also provided.
The development of TMN Management Applications requires a platform to provide a common infrastructure, enabling the various applications that constitute a TMN system to communicate and facilitate their development through common building blocks and generic facilities. The developed applications should be able to perform management functions on distributed real or simulated networks. Requirements for a specific ICM TMN platform were identified very early in the project, and were mainly influenced by the types of TMN functional blocks and interfaces that would be present in the ICM TMN system. It was emphasised that the ICM TMN Platform should provide support for:
After an evaluation of various technology bases as possible candidates, including the OSF DME (Distributed Management Environment) and ANSA (Advanced Network Systems Architecture), the OSIMIS/ISODE platform was chosen (OSI Management Information Service / ISO Development Environment) as it already provided a comprehensive set of the support services sought. A number of additional support services were identified and implemented in the second year of ICM and these are:
The following additional support services were identified and implemented during the third and fourth years of ICM:
ISODE (ISO Development Environment) is an upper layer OSI stack, providing a development environment for OSI applications and distributed systems, conforming fully to the relevant ISO/ITU recommendations. A few fundamental OSI applications also come with it. ISODE is implemented in the C programming language and runs on most versions of the Unix operating system. The services and applications provided which are related to management are described here.
The protocols and related services supported are the following:
The support tools include the following:
Finally there are the following applications:
OSIMIS (OSI Management Information Service) is a management platform for applications based on the OSI management model and also provides facilities for integrating elements with Internet management capabilities. OSIMIS provides an object-oriented infrastructure which hides the details of the underlying OSI management service and allows designers and implementors to concentrate on the management application intelligence. It also attempts to hide aspects of distributed access through location transparency and high level management information access mechanisms.
An important aspect of OSIMIS related to a TMN environment is that it was designed from the beginning with the target to support the easy integration of proprietary management facilities through proxy systems. This is important for the TMN Q-Adaptor blocks but it is fundamental for the hierarchical organisation of management systems through cascaded applications, which is the paradigm suggested by the TMN. OSIMIS is implemented in the C++ programming language and runs on most versions of the Unix operating system, in a similar fashion to ISODE. The OSIMIS services and applications are:
An implementation of the OSI Common Management Information Service / Protocol (CMIS/P) is provided, using the ISODE ACS, ROS and ASN.1 support. This may run either a full upper layer OSI stack or using the lightweight presentation layer directly on top of TCP, the approach known as CMOT (CMIP Over TCP/IP).
An implementation of the Internet Simple Network Management Protocol (SNMP) is also provided. This uses the User Datagram Protocol (UDP) as provided by the Unix operating system and the ISODE ASN.1 support. The Application Program Interface (API) for these services is different to the X/Open XMP as they were developed much before the latter. Also the ISODE ASN.1 API is different to XOM as already mentioned.
Management applications have very complex requirements of both external communications and internal alarm mechanisms for polling purposes. Furthermore, integration with user interface or other technologies which have their own co-ordination mechanism may be necessary. A possible solution is to use a concurrent execution thread mechanism but these are usually not portable or lightweight and also introduce the need for internal locking mechanisms.
OSIMIS provides an object-oriented co-ordination mechanism that assumes a fully event-driven execution paradigm that serialises both internal and external requests and takes them to completion on a "first-come-first-served" basis. This is particularly well suited for asynchronous remote execution paradigms, as the ones of both CMIS/P and SNMP. This mechanism also provides a suitable framework for the potential future introduction of a concurrent execution mechanism. Finally, it is very easy to integrate it with different user interface technologies (see Presentation Support Function).
The ISODE ASN.1 support, though valuable, still requires the explicit manipulation of data structures in terms of encoding, decoding, parsing from a string representation and printing. OSIMIS provides additional support that encapsulates the produced structures and adds behaviour that automates the functions described above. It also provides additional comparison and filtering capabilities. An extensible syntax database is used to support this automatic manipulation of ASN.1 syntaxes.
An ASN.1 compiler which uses the above high level syntax support is also provided to automate the required C++ classes that provide the encapsulation (see The Object-Oriented ASN.1 meta compiler).
The GMS is a fundamental aspect of OSIMIS as it provides support for building agents that offer the full functionality of the OSI management model, including scoping, filtering, linked replies and cancel-get. The OSIMIS GMS supports fully the Object Management, Event Reporting and Log Control Systems Management Functions (SMFs), the qualityofServiceAlarm notification of the Alarm Reporting one and partly the Access Control, Metric and Summarisation objects, all in a transparent fashion to the plugged-in managed objects.
The GMS provides different methods of access to real resources from the corresponding managed objects:
The real resources may be either “tightly-coupled” to the agent i.e. in local address space, in which case they are fully encapsulated by the relevant managed objects, or “loosely-coupled” in which case they are accessed through a remote operation, using any mechanism the remote resource supports. Such access is supported by the OSIMIS co-ordination mechanism and it enables the construction of proxy systems or hybrid-applications (manager/agents). The latter are particularly needed in a hierarchically structured environment such as the TMN.
The GMS is complemented by a compiler for the OSI formal managed object specification language known as GDMO (Guidelines for the Definition of Managed Objects). This is of fundamental importance as it produces stub managed objects in C++ which conform to the GMS API, covering almost every syntactic aspect and leaving only semantic aspects to be implemented i.e. the interaction to the associated real resources or subordinate agents. The GMS and the GDMO compiler provide essentially a managed object plug-in facility, where every object is almost unaware of the way it is accessed through the management service.
It should be added that the GDMO compiler is designed in such a way as to be platform-independent: a scripting language is provided which makes very easy the generation of code for any other target environment.
Programming manager applications using the CMIS API can be tedious. The RMIB support service offers a higher level API which provides the abstraction of an association object. This handles association establishment and release, hides object identifiers through friendly names, hides ASN.1 manipulation using the facilities described above, hides the complexity of CMIS distinguished names and filters through a string-based notation, assembles linked replies, provides a high level interface to event reporting which hides the manipulation of event discriminators and finally provides error handling at different levels.
The interface is synchronous in an RPC-like fashion and asynchronous through call-backs. The latter, of course, is imperative for realising complex TMN Workstations and Operations Systems.
Management Graphical User Interfaces (GUIs) may have really complex needs in terms of asynchronous event handling from both the keyboard and the network, in conjunction to internal polling alarms. The OSIMIS support for event-driven process organisation is designed in such a way as to facilitate the integration of other package co-ordination mechanisms, including those of graphical user interfaces.
This is exploited to integrate OSIMIS with the following user interface technologies:
The shared management knowledge (SMK) is the common knowledge between the application processes performing systems management. This includes:
In SMK, mechanisms are needed to provide support for an off-line (i.e. prior to the association establishment), dynamic acquisition of the knowledge (i.e. it happens at run-time), and the OSI Directory is used as the SMK repository. Every management process can update the Directory with management knowledge information pertaining to it and, thus, dynamically modify the SMK that is available to every process via the Directory service.
Location transparency is defined as "hiding the topological details" and also as "hiding the locations of servers from the clients that interact with them, and vice versa." In a generic TMN platform, location transparency provides a management application with a means of identifying which agent contains the managed objects that represent particular resources, as well as the location of the agent.
A comprehensive solution has been designed and implemented in ICM, using the ISODE DSA supporting the SMK and location transparency services.
The current industry standard for network element management is the Internet SNMP. This is a simplified version of the OSI CMIP and the same holds for the relevant information models, the OSI being fully object-oriented while the SNMP supporting a simple remote debugging paradigm. Application gateways between them are possible for specific Management Information Bases (MIBs) - in fact OSIMIS comprised such a gateway for the OSI version of the Internet MIB-II for the TCP/IP protocol family.
This non-generic approach though requires the realisation of a new gateway for every new MIB and as such is not a scaleable solution. A better approach is to define a generic set of rules for the conversion between the two information models and have a generic gateway which may operate for any MIB. Work for standards in this area was driven by the Network Management Forum (NMF) and ICM actively contributed to them. A generic gateway based on them was built and will constitute an openly available reference implementation.
This work involves a translator between Internet MIBs to equivalent GDMO ones and a special back-end for the GDMO compiler which produces run-time support for the generic gateway. That way the handling of any current or future MIBs is possible without the need to change a single line of code. The current implementation is based on SNMPv1 and there exists an upgrade path to extend to cover also SNMPv2.
Monitor metric objects are generic management support objects that can be instantiated within a remote managed system and be configured to monitor, at periodic intervals, an attribute of another object which models an underlying resource. The observed attribute should be a counter or gauge and the metric object either simply observes it or converts observed values to rates. Statistical smoothing of the observed values is also possible if desired. The main importance of this facility is the attachment of gauge thresholds and tide-marks to the resulting gauge which may trigger the qualityOfServiceAlarm and attributeValueChange notification respectively.
Metric objects thus offer the OSI management power through event reporting and logging even if managed objects do not support the above notifications. More importantly, they obviate the use of rates, thresholds and tide-marks in the information model in a way tied to specific managed objects but they allow the same flexibility and power dynamically, whenever a manager needs it. It is obvious that such a monitoring facility reduces the management traffic between applications. Their importance becomes even more pronounced if the generic CMIS to SNMP gateway facility is taken into account as it may result in substantial enhancement of the originally raw SNMP information model.
Summarisation objects are management support objects offering similar but complementary facilities to the metric objects. They may be instantiated within a remote managed system to monitor a number of attributes of potentially different objects, specified through CMIS scoping and filtering. The observed values may be raw ones modelling an underlying resource or enhanced values as observed by metric objects. Observed values can be statistically smoothed and reported either at every observation period or only after a number of observation periods (buffered scanning). The major importance of this facility is that a number of values that a manager needs can be specified once through scoping and filtering and then reported as mentioned, without the manager having to send complex CMIS requests periodically or to perform smoothing.
Another related facility not accruing from standards work but which emerged from the needs of the ICM information model is that of an intelligent managing summarizer. Such an object can be instructed to monitor periodically rate attributes of other objects in remote managed systems and produce a single value through a mathematical expression by putting signs and adding them, using a denominator etc. The resulting combined rate could be compared against thresholds and tide-marks in a similar fashion to metric objects. This is a preliminary facility towards objects that can be used to specify and execute arbitrary management policies.
The Generic Managed System agent infrastructure was described above as a generic agent engine that allows a plug-in facility for managed objects as supported by the GDMO compiler. Such a generic infrastructure should also support the OSI Systems Management Functions. The metric and summarisation functions as presented above are part of the GMS.
From the rest of the systems management functions, event reporting and logging are fundamental as they complement the management service CMIS/P; these will be brought up-to-date with the latest ISO/ITU standards. This means in particular the facility for filtering assertions on the contents of a potential event report in addition to the emitting class, instance, event type and time. Object and state management functions have been enhanced to completely hide from the managed object implementors the changes effected from the CMIS side. A friendlier API will also be incorporated for triggering the related notifications as a result of the underlying resource operation. Support for the naming of objects globally through the X.500 space is also implemented.
The ICM TMN operates on both real and simulated underlying broadband infrastructure and services. In the latter case, the management applications are still as they would be in reality but they need to schedule activities in simulated rather than real-time, as the two may have an arbitrary relationship, changing even throughout the duration of an experiment. An architecture has been devised whereby simulated time is propagated to management applications so that scheduling in simulated time can be effected.
This architecture is devised in such a way so that applications themselves do not need to know if they run on a real or simulated environment i.e. their logic needs not be concerned at all. In theory, if the information model for the real and simulated managed environments is exactly the same, the environment can be changed without the need to modify the applications at all. This facility is very important for the testing of management systems in a simulated environment as a first step of validating their policies.
While the Remote MIB offers an object-oriented abstraction of an association, its API is very CMIS-like. The Shadow MIB offers a much higher level API which is based on the Shadow Managed Object (SMO) abstraction i.e. an object in local address space which offers a shadow image of the actual remote managed object. Sophisticated cacheing mechanisms can be applied to maintain consistency between the two images and fast access, the two conflicting targets being timeliness of information and network utilisation. The user could be either shielded of details when prototyping or be given the opportunity to affect the update policies in order to achieve maximum performance.
One of the main advantages of such a technique, apart from the "standardised" local storage offered, is the possibility of offering APIs which are much less CMIS-like and possibly common with those of other management or distributed systems paradigms (e.g. SNMP, OMG CORBA etc.) Though such common high level APIs are possible, the semantic differences of the underlying mechanisms should not be hidden so that control for maximum real-time performance is possible. An in-depth research and initial design of the SMIB API has been conducted in ICM.
Interpreted mechanisms have all the well known advantages and disadvantages compared to compiled ones, the main advantage being quick development cycle. Through a CMIS-based interpreted scripting language, it would be possible to prototype small manager applications as scripts quickly, or even provide management shell type of facilities to human managers. An additional advantage is the possible integration of such a facility with interpreted graphical user interface mechanisms such as TCL/TK, SPOKE. In the latter case, the building of small applications with customised GUIs should be possible in a fraction of the time required with the existing compiled approaches. Such a language has been designed and implemented within ICM known as Tcl-MCMIS.
The X/Open XOM and XMP specifications define a CMIS API. The standardized API intends to keep management software independent of the implementation of the protocol stack.
Originally OSIMIS could only use the ISODE OSI stack over which it built its services. The ISODE ASN.1 and OSIMIS CMIS APIs are different from the current industry standard XOM/XMP as they were designed much before the latter. To make it possible to use other stacks than ISODE, an XMP support library was developed in ICM. The library uses the services of XOM/XMP, but the original interface to OSIMIS is preserved so that OSIMIS kernel and applications can use, without any changes, either an XMP stack or the ISODE stack. As several manufacturers provide protocol stacks with XOM/XMP API, it should be mentioned that different realizations of the API may be based on different versions of XOM/XMP specification. OSIMIS uses SunLink CMIP 8.1 or HP OpenView DM 4.01 CMIP.
A complex management system such as the TMN can be very difficult to start-up, maintain and shut down. Essentially, a management system for the management system itself is needed and the OSI model is rich enough to support this requirement. This type of management is typical in distributed systems contexts and the OSI management and directory models combined can provide a solution. This is an ongoing area of research within ICM, the target being a facility for the meta-management support in the TMN.
High level abstractions are used to provide the support for dealing with ASN.1 in such a way that hides the implementor from the actual abstract and transfer syntax of the ISODE ASN.1 support service, in the C language binding, encapsulating the behaviour in the data types determining how encoding and decoding should be performed (see High level ASN.1 support). Albeit this high level support, the implementor is still required to hand-code the encapsulation.
In ICM, an ASN.1 meta compiler has been designed and implemented, which can automate the production of the needed C++ objects by wrapping up the output of a common ISODE ASN.1 compiler with C structures corresponding to the supplied syntaxes with encode, decode, print, parse, and compare methods. The only minor problem with this approach is that automated mechanisms for the print and parse methods may produce "ugly" representations while sometimes the automatically produced compare method may be incorrect due to buried-in semantics. Hand-coded methods may simply overwrite the automatically produced ones, if necessary, in these cases.
In ICM, a comprehensive solution is provided to defeat the possible passive and active security threats, taking into account the order of magnitude of storage and processing requirements. In terms of processing, one must be very cautious not to impair the performance of a TMN when the security mechanisms are in use. For this reason, ICM chose to implement a set of lightweight security mechanisms addressing the threats mentioned above, and these are:
In the TMN, the transport mechanism to implement a reference point can be anything if the two communicating functional blocks reside in the same system while it should be an agreed OSI stack profile for remote communication i.e. the reference point becomes an interface. There are many cases in which two logical entities should reside at the same end system. For example, a generic CMIS/SNMP Q-Adaptor results in a qx rather than a q3 reference point, in which case a mediation function is needed to convert the former to q3 and the two functions should be at the same end system for performance reasons. The same may be true for two related Operation System Functions (OSFs) as it has been the case in the ICM VPCM system described below. Therefore, it is desirable to implement reference points locally using lightweight mechanisms while maintaining the full logical separation of function.
In ICM, an architecture has been designed and implemented where the local communication uses a shared address space as it provides the most efficiency. Considerations of domain sockets, TCP or RPC were abandoned as the cost of Unix interprocess communication is rather high. The solution relies on having two or more local functional blocks operating within the same Unix process, maintaining the CMIS API but avoiding to descend/ascend the OSI stack for local communication. The object-oriented nature of the OSIMIS infrastructure has enabled the introduction of such a facility with minimal only changes. The first performance measurements showed an order of magnitude reduction in the access times, compared to two local blocks communicating over a full interface.
There is a class of manager applications which are semantic-free i.e. they may operate for any Management Information Base without changes. These need to be driven by a human manager in order to perform a useful function but are nevertheless very important. OSIMIS provides a sophisticated MIB browser that allows one to browse through the management information tree of a remote agent, perform operations on managed objects and even monitor them either through periodic polling or event reporting.
There is also a set of applications that constitute a management shell, which allow any operation using the full CMIS power (e.g. scoping, filtering, synchronisation). Finally there are specialised applications to receive event reports and control logging.
OSIMIS is much more than a platform for implementing management agents. All the facilities described above make it suitable as a general vehicle for building distributed systems: the Action CMIS primitive is essentially a general object method i.e. any remote operation and the location transparency and high level object access mechanisms make possible to build distributed systems quickly and efficiently.
Realising a simple time-of-the-day server requires no more than 10 lines of C++ code, using the GMS and GDMO compiler. Accessing all these objects in a particular environment using the location transparency and the RMIB support services and printing the time requires about 20 lines of C++ code. Finally, the performance of OSIMIS-based systems is generally very high and experiments have shown that it is directly comparable, even for simple information access, to that of SNMP-based ones.
OSIMIS provides managed object persistency and in particular the facility to log information as records (special managed objects) and to fully control the behaviour of the logs containing them. The OSI management service offers the possibility to create, delete and retrieve logs and log records and also sophisticated searching facilities through scoping and filtering. Despite the fact that this was not the purpose of the OSI management model, its generality and richness make it suitable as a general distributed object-oriented database mechanism. OSIMIS does not provide yet transaction support which is very important as it may be particularly useful in the higher TMN layers e.g. for services, customers etc. This is issue is being investigated within ICM.