PROJECT : CORBA-TL1 Adapter

The Team :

• Rajesh Raina (Project Leader)
• Seema Gupta
• Bhaskar Bhar
• Hari Prasad
• Puneet Tutliani

Introduction:

Transaction Language 1(TL1) is used in the input and output messages that pass between Operating Systems (OSs) and Network Elements (NEs). Operation domains such as management and testing of the NE define and use TL1 messages to accomplish specific tasks.

Operation functions such as surveillance, memory administration, etc use short messages to cause specific actions at the NE. Transactions are the initiation, communication, and execution of these actions. TL1 is defined by restricting the features used in the message definitions and the form transmitted by each side of the OS/NE interface.

Transaction Language 1 (TL1) specifies four types of operations application messages:

• Input Command Message
• Acknowledgements
• Output Response messages
• Autonomous Messages

Object Management Group's (OMG) Common Object Request Broker Architechture (CORBA) specifies the architechture by which instances in an heterogenous environment can communicate with each other regardless of whether they are local or remote. This is an open standard for distributed computing. The Object Request Broker (ORB) is responsible for accepting requests from Clients, finding target object and its implementation, invoking the request on it and returning the result to the caller. The interface that the client sees is completely independent of where the object is located or what programming language it is implemented in.

The ORB maintains an Interface Repository, which is essentially meta information about the interfaces registered with the ORB and an Implementation Repository, which is information about where implementations of interfaces are located. When a client creates an instance, it receives a proxy in the form of an object reference, which is an opaque handle that uniquely identifies the remote instance. Any method invoked on an object reference will be forwarded to the remote instance and the result will be returned to the client.

Motivation:

The advances in Distributed Object Computing technology have led to their increasingly deployment in every sector. Network Management is one of them. There are a lot of groups working towards integration of CORBA with existing network management protocols. These groups have already come up some literature on this.

In this project, an attempt has been made to operate on NE using CORBA to acheive management and testing of the same.

Objective:

The objective of this project is to build a CORBA-TL1 adapter so that one can successfullly test and manage a NE with a remote CORBA client.

Design:

The solution addresses the issue of managing NEs with TL1 interface through CORBA in two steps. The first step is off-line and deals with visualizing and defining a NE TL1 interface in terms of managed objects. In the second step the definition of NE in terms of MOs is used by CORBA-TL1 adapter/Comm module to provide a CORBA IDL interface to management application, while issuing TL1 commands and interpreting responses from NE. This is done on-line.

All NE resources are modeled as Objects with some attributes and methods. Then for each object the user specifies how to get/set values of all attributes using TL1 commands. Also specified is the implementation of each method in terms of TL1 commands to be issued and expected responses. These Objects will contain attributes and operations. TL1 messages which are used to manage these objects are also specified along with.

The user defines these objects and their implementation using TL1 commands in a user friendly language described later in this document. Since NEs from different vendors may have different TL1 syntax and commands for the same functionality, the information is captured in Object Definition File (ODF) with common attributes and methods on resources. The rest of the information is captured in Network Element Transaction Language File (NETL) which specifies how to get/set attribute values and implements methods defined in the ODF file by issuing TL1 commands specific to NE. The off-line component includes a parser to convert these object definitions into IDL definitions. These IDL definitions provide the interface, which the server application uses to manage the NE resources. Similarly, parsers to convert the Object definitions into CMIP (OSI) and SNMP management models can be provided as an extension. The off-line parser also generates a Meta-information file, which is used by the on-line component for CORBA-TL1 translation.

The on-line component consists of server engine, which reads the parser generated Meta-information file at run-time to effect CORBA-TL1 translation. The on-line component provides a generic interface to the CORBA applications. This interface maps all the NE resource objects into a single generic class called "Gen Object". The "Gen object" is the only interface that the Comm module provides to the CORBA application.

Apart from mapping CORBA requests to TL1 commands and responses, the comm module provides some additional generic services which can ease the development of management application. The services supported are

• Naming service
• Cache management service
• Security management service
• Concurrency management service
• Log management service
• Connection management service
• Error handling service
• Autonomous event handling service

System Model

CORBA TL1 adapter is based on powerful CORBA Adapter Framework Architecture for building and integrating adapters for various Network Management platforms and technologies. It allows a network resource to be defined in a file. The product then reads the file and converts the data into an internal MIF format. This Meta information is used by the framework components to obtain data from the NE using any specified standard protocol and communicated to the CORBA client.

The main components of the system are:

1. The parser module which reads the resource files and creates the meta information objects.
2. The MIF interface which queries the meta information objects and deliver the requisite protocol context information.
3. The Server Engine which handles the interface with CORBA client and provides powerful features as cache management and multiple response handling.
4. The Communications module provides the most flexible POSIX threads based communication with the Network elements. Its multi threaded implemntaion makes the adapter system a highly efficient attachment to most Network Management systems.
5. The protocol specific analyser and builder module which does the reading of incomming data and forming of the outgoing data. This module requires customization for each protocol.

The CORBA TL1 adapter is built using Orbix as the CORBA bus. Following is the sequential list of the activities that CORBA-TL1 adapter performs:

• Parsing of Object Definition format (ODF) & Network Element Transaction language (NETL) files, Reading of NE configuration file for connections information.
• Creation of all the TL1 information data structures and commmands. Now we have all the information related to Tl1 commands and their respective user understandable commands.
• The adapter's CORBA client will send a request which will contain the NeId, ReId, attributes and the action(e.g set, get).
• This request comes to the CORBA server. CORBA server uses the server engine to do the rest of the processing with the request.
• Server engine uses the MIF ( Meta Information Format) interface and builder) to prepare the corresponding TL1 command.
• Server Engine sends this Tl1 command to the connection management module which further sends it to the NE and then waits on the thread for the response.
• When the response is received, it is communicated to the server engine by the communications module.
• The server engine parses the data with the help of MIF and analyser, and creates the data to be sent to the CORBA client.
• The data is then sent to the CORBA client using the CORBA bus.

The following diagram shows the system level view of the modules involved and interactions between them.

Object Model

The following diagram shows the Object Model of the design. The project liberally used the support of RogueWave tools.h++ library. The object model also shows some the relationship of classes designed in this project with RogueWave classes.

The design is broadly classified in four categories:

1. Server Engine
2. Analyser & Builder
3. Connection Manager
4. MIF(Meta Information File) Module.

Each of these modules have their own Object Model which clearly defines their implementation. A short description of each of these is given below:

Server Engine

This module consists of the following classes:

1. CB_ServerEngine
2. CB_CacheList
3. CB_IndexCtagList
4. CB_InBlock
5. RWHashDictionary

CB_ServerEngine is the heart of this implementation and is responsible for coordinating the various components in this implementation. This object is a single instance object and is called by interface object. It is the responsiblity of this to create other modules and pass on the data to them.

A Cache of retrived values is kept locally in CB_CacheList. Each entries are in the form of CB_GenObjRT containing resourse & network element type and identifier.

Other classes are used in the processing of the request and response.

Analyser & Builder

This module consists of the following classes:

1. PR_BaseParser
2. PR_TokenParser
3. PR_Analyser
4. PR_Builder
5. PR_MessageBuffer
6. PR_TL1ContextManager

While sending the request, Builder builds up the request with the help of MIF module. It gets the format of the request from MIF and populates that to make the request.

While analyzing the response, the same procedure is repeated. The MIF provides this module with the format of the response. The Analyser compares the response with the format to retrieve the values etc from it.

Connection Manager

This module consists of the following classes:

1. CM_ConnectionMgr
2. CM_ThreadMgt
3. CM_NeInfoHandle
4. CM_TL1MsgQueue

CB_ConnectionMgr is also a single instance object. This part of the implementation is multi-threaded and thus thread management is an inhereant responsibility of this module. There are two instances of the Class CM_TL1MsgQueue, forming send and receive Queue. Information about NEs are handled by CM_NeInfoHandle Class.

MIF Module

This module consists of following classes:

1. Entry classes
2. List classes
3. message classes
4. MIFInterface

The primary responsiblility of the parser is to read NEDL & ODF file, and fill up the entry & list objects. The other modules retrieve information from MIFInterface object, which serves as a wrapper on these and gives a defined interface.

Conclusion

The demonstration version of this product is fully implemented. This version does not support some of the intended features of the final product eg. event service. The present version's implementation is done and the product is in testing stage. The team would like to come up with final version in near future.

Acknowledgements

The team would like to thank Naveen Kulshretha who built a nice NE simulator for testing the product. The team is also indepted to the Managers, Sanjeev Kumar and Anupam Garg, for their able guidance and support throughout the project. Last but not least, the team would like to thank all the co-workers for their help and support.