Evaluation and implementation of protocols for configuration data export from IMA

(1)

Andreas Wallström

Evaluation and implementation of protocols for configuration data export from IMA

2000:284

MASTER'S THESIS

Civilingenjörsprogrammet Datateknik Institutionen för Systemteknik Avdelningen för Programvaruteknik

(2)

Evaluation and implementation of protocols for configuration data export from IMA

Andreas Wallstr¨om November 28, 2000

(3)

Abstract

This master thesis describes the evaluation of different techniques to export configuration data from the network management system IMA (Integrated Man- agement Applications). In order for IMA to interact with other network management systems in a standardized way, interfaces called Integration Reference Points (IRP) should be supported. In this particular case, when exporting configuration data, the two IRPs called Inventory and Topology IRP and No- tification IRP are important. The techniques evaluated as possible candidates for IRP implementation are: SNMP, XML, LDAP and CORBA. Both technical and economical issues are considered, including the differences and limitations of the protocols and third party software based on the demands of both IMA and higher-level management systems.

The conclusion drawn from the evaluation is that XML is the most suitable alternative.

A prototype application, made by the author, demonstrating the protocol’s usefulness in the IMA environment is also described.

(4)

Preface

This thesis was made at Ericsson Erisoft AB, department L/IA, from April 2000 to September 2000.

The product forming the basis of this thesis is IMA. It is developed at L/IA and stands for Integrated Management Applications. It is well proven concept and product family that enables integration at a low cost and includes the functionality required to operate and maintain Transmission Networks. IMA is based on Windows NT and has been sold to more than 50 operators in more than 30 countries. More than 400 systems have been delivered since 1996.

Although this thesis might seem rather telecom-specific at first glance, I think it could be interesting for anyone looking into ways to export data over the Internet. Another thing worth mentioning is that the rather stiff style of this thesis can be considered challenging (perhaps the author has been under the influence of the telecom business while writing).

“And if you gaze for long into the abyss, the abyss gazes also into you”

- F. Nietzsche I would like to thank Erland Isaksson, my supervisor at Ericsson Erisoft AB, as well as Johnny Wid´en, examiner at Lule˚a University of Technology.

Lule˚a, September 2000 Andreas Wallstr¨om

(5)

Chapter 1 Introduction

1.1 Background

Integration Reference Points (IRP) are interfaces for network information exchange currently under development within Ericsson. These interfaces are the technical enablers that achieve interoperability between Telecom-management applications and systems. The purpose of each IRP is automation of one specific task. This can, for example, be how various alarms from objects in the network shall be reported or how configuration data for those objects is exported.

Each IRP consists of a protocol-independent model (the IRP Information Model) and several protocol-dependent models (IRP Solution Sets). These So- lution Sets are the actual realization of the information model and is implemented using different techniques (SNMP, WBEM etc.) to suit the needs of various environments. The Information Model and a Solution Set together provide a standardized way to communicate for systems managing the network.

The Inventory and Topology IRP [1] and the Notification IRP [2] are two IRPs, specifying how inventory and topology data are to be exported as well as how network events will be handled.

Integrated Management Applications (IMA) is a Windows NT based system for network management developed at Ericsson Erisoft. It can act in different management roles. For example:

• As a Network Management system providing management of certain network wide functions such as Fault Management, Circuit Management, Performance Management, Security Management, System Management and so on.

• As an Element Management System, managing specific equipment.

• As a Common Workplace to IMA and other management systems, making surveillance information visible from any client in the management network.

• As a Mediation Device/Gateway, integrating management systems and forwarding data to other systems.

In order for IMA to work in an environment based on the IRP concept, the Inventory and Topology IRP as well as the Notification IRP has to be supported

(8)

during export of the network configuration and topology data to higher-level Management Systems. This might happen, for instance, when IMA acts as a mediation device/gateway.

1.2 Goal

The goal of this thesis is to evaluate a number of different techniques for implementation of the IRPs: XML, LDAP, SNMP and CORBA from both technical and economical perspectives considering the differences and limitations of the protocols and third party software. Based on the demands of these IRPs, IMA and higher-level management systems, the best technique was to be chosen as a basis for a prototype application demonstrating it’s usefulness.

The application will provide IMA with the capability to export network information in a standardized and automatic way giving other management systems the ability to process the data further.

1.3 Limitations and assumptions

The main limitation is that the implementation of the Notification IRP was skipped altogether. This is because of two reasons (1) the time schedule simply wouldn’t allow it and (2) IMA does not provide any reasonable way to find out whether the database has changed.

The IMA topology database was not considered important enough to be included in the prototype, but should be easy to incorporate in later versions of the program.

Since no Solution Set for the Inventory and Topology IRP existed during the work with this thesis, a number of problems, supposed to be solved by the Solution Set, have been simplified to save time. This includes the mapping between the IRP MIM and CIM and the mapping of IRP operations to CIM over HTTP operations.

(9)

Chapter 2 Technology Overview

2.1 CIM

The Common Information Model (CIM) is an object-oriented information model defined by the Distributed Management Task Force (DMTF). It provides a con- ceptual framework for describing management data. Put in another way, CIM is an architecture designed to eliminate the issue of interoperability between different management systems by unifying multivendor management data through a single interface.

CIM consists of two parts: The CIM Specification and the CIM Schema. The CIM Specification describes the language, naming, Meta Schema and mapping techniques to other management models such as SNMP MIBs.

The Meta Schema is a formal definition of the model. It defines the terms used to express the model and their usage and semantics. The elements of the Meta Schema are Classes, Properties, and Methods. The Meta Schema also supports Associations as types of Classes and References as types of Properties.

The Unified Modeling Language (UML) is used to define the structure of the meta schema.

The CIM Schema provides the actual model descriptions and supplies a set of classes with properties and associations, including models for Systems, Applications, Networks (LAN) and Devices. It is divided into two separate layers:

• Core Model

- An information model that captures notions that are applicable to all areas of management.

• Common Model

- An information model that captures notions that are common to particular management areas, but independent of a particular technology or implementation.

There also exist “Extension Schemas” which are technology specific extensions to the Common Model.

(10)

The CIM schema will enable applications from different developers on different platforms to describe management data in a standard format so that it can be shared among a variety of management applications.

More information about CIM can be found in [8].

2.2 SNMP

The Simple Network Management Protocol (SNMP) is a communication protocol that has been widely used since 1993 as a method of managing TCP/IP networks, including individual network devices. SNMP was developed by the IETF (Internet Engineering Task Force), and is applicable to any TCP/IP network, as well as other types of networks.

SNMP defines a client/server relationship. The client program (called the network manager) makes virtual connections to a server program (called the SNMP agent) which executes on a remote network device, and serves information to the manager regarding the device’s status. The database, controlled by the SNMP agent, is referred to as the SNMP Management Information Base (MIB), and is a standard set of statistical and control values. SNMP addi- tionally allows the extension of these standard values with values specific to a particular agent through the use of private MIBs.

Through the use of private MIB variables, SNMP agents can handle a large variety of devices, such as network bridges, gateways, and routers. The defi- nitions of MIB variables supported by a particular agent are incorporated in descriptor files, written in Abstract Syntax Notation (ASN.1) format.

More information about SNMP can be found in [5].

2.3 XML/WBEM

The Extensible Markup Language (XML) is a subset of the Standardized Gen- eralized Markup Language (SGML) and is used for representing structured data in textual form.

An XML document can optionally have a description of its grammar at- tached. The grammar for an XML document is described using a mechanism known as “Document Type Definition” (DTD). The DTD describes the allow- able elements in the XML document and describes the structure of those elements.

Extensible Stylesheet Language (XSL) style sheets can be used to to transform XML documents into other formats. This includes actual graphical rendering of the document since XML documents do not carry information on how they shall be visualized.

Web-Based Enterprise Management (WBEM) is a set of management and Internet standard technologies developed to unify the management of enterprise computing environments. The core of WBEM includes a data model, the Common Information Model (CIM) standard; an encoding specification, xml- CIM Encoding Specification; and a transport mechanism, CIM Operations over HTTP.

The xmlCIM Encoding Specification defines XML elements, written in Doc- ument Type Definition (DTD), which can be used to represent CIM classes and

(11)

instances. The CIM Operations over HTTP specification defines a mapping of CIM operations onto HTTP that allows implementations of CIM to interoperate in an open, standardized manner and completes the technologies that support WBEM.

2.4 LDAP

The Lightweight Directory Access Protocol (LDAP) is a protocol that runs over TCP and is used for accessing directory services.

In LDAP, data is organized hierarchically, starting at the root directory and branching down into individual entries. Each entry is uniquely identified by a distinguished name.

LDAP is actually more than a protocol; it is also an API and a Uniform Resource Locator (URL) system. The LDAP protocol defines operations that clients can use to search and update directories. It also provides a simple method for authentication. The LDAP API consists of a set of functions that developers can use to build LDAP client-side applications; these include such functions as the capability to connect to LDAP servers and the ability to search, retrieve, add, and update entries. For adding or modifying entries to an LDAP server, the LDAP specification outlines a data format called LDIF (LDAP Data Interchange Format). LDIF is an ASCII text representation of the directory database and its entries.

More information about LDAP can be found in [6].

2.5 CORBA

CORBA is a specification defining a set of conventions and protocols that must be followed by CORBA implementations. It is left to vendors and developers to translate this specification into a working implementation.

With CORBA, developers can easily connect processes running on different machines, with different operating systems, and with code written in different languages. CORBA allows objects across a heterogeneous computing environment to talk to one another without the programmer being concerned exactly where an object resides on the network or how it is implemented. Programmers need only know about the object’s public interface. It allows an object residing on system A to invoke a method of an object residing on system B where A and B can be completely different systems and the objects may be implemented in different languages.

Fundamental to CORBA is the Object Request Broker (ORB). An ORB is a software component whose purpose is to facilitate communication between objects. It does so by providing a number of capabilities, one of which is to locate a remote object, given an object reference. The ORB basically handles inter process communication for objects communicating locally and remote procedure calls for objects residing in applications across a network. Objects are also able to communicate across ORBs implemented by different vendors via the Internet InterORB Protocol (IIOP).

Another fundamental piece of the CORBA architecture is the use of the Interface Definition Language (IDL). IDL, which specifies interfaces between

(12)

CORBA objects, ensures CORBA’s language independence. Because interfaces described in IDL can be mapped to any programming language, CORBA applications and components are independent of the language(s) used to implement them.

(13)

Chapter 3 Evaluation of protocols

3.1 Evaluation basis

3.1.1 Evaluation criteria

The criteria used for the evaluation are divided into the following groups:

1. Data transport

- How suitable is the protocol for data transfer? This includes how well the IMA databases can be represented using the protocol.

2. Flexibility

- How easy is the protocol to extend and customize? Can the solution be easily adapted to changes in the client and server (databases, output format etc.)?

3. Third party software

- How good is the price/performance ratio? What are the possibili- ties/limitations? Is the protocol accepted as an industry standard?

Are there any APIs available?

4. Notifications

- Can the solution handle notifications? How difficult will it be to implement this?

5. Technical qualities

- Is the protocol fast, simple and secure?

6. IRP compliance

- How close will a solution based on the protocol be able to follow the IRP? Will there be trade-offs between implementation time and IRP compliance?

(14)

3.1.2 Inventory And Topology IRP

Introduction

The Inventory and Topology IRP has two main purposes: (1) to define an interface for inventory/topology information retrieval, and (2) to define a Manage- ment Information Model (MIM) from which other resource models can inherit.

As indicated in figure 3.1, the IRP need to be complemented with the Noti- fication IRP to allow Actor to subscribe to notifications issued by System.

System

Actor

NEM or mediator

NE NE

Inventory and Topology IRP Product-Specific MIM (optional) Notification IRP

Figure 3.1: Inventory And Topology system overview

It should be pointed out that the Inventory and Topology IRP is in a prelim- inary state and is subject to change. No Solution Sets are currently available.

IRP structure

The IRP is structured in (1) an Information Model that specifies the interface in a protocol neutral manner, and (2) a number of Solution Sets that provide the actual realization of the operations and notifications defined in the Information Model for each protocol environment. The structure of the IRP is shown in figure 3.2.

The Interface Service

This is a specification of the operations and notifications visible over the IRP.

These operations are mapped to a specific application protocol by each Solution Set and can be divided into mandatory and optional operations. Mandatory operations shall be present in all Solution Sets while the optional only where it is technically possible.

Table 3.1 and 3.2 show the mandatory operations and notifications (the complete list can be found in [1]).

The Management Information Model

This is a specification of Managed Object classes that can be retrieved and ma- nipulated over the interface. These classes are consistent with standard models

(15)

Inventory and Topology IRP: information model

- Managament Information Model (MIM) – inventory resource model with MO classes (UML) consistent with TMF, ITU-T, ETSI, IETF and DMTF standards.

- Interface Service – operations and notifications visible over the IRP.

Figure 3.2: Inventory And Topology IRP structure

like M.3100 from IUT-T and Common Information Model (CIM) from DMTF.

Each Solution Set provides an implementation of this resource model with (1) references to standard models that are applicable for the corresponding protocol environment, and (2) extensions to these standard models for the parts of the MIM that are not covered.

Figure 3.3 shows the containment/naming hierarchy of the MO classes defined by this IRP.

For more information concerning MIM consult [1].

3.1.3 Notification IRP

Introduction

The purpose of the Notification IRP is to define an interface through which an Actor can subscribe to System for receiving network events. It also specifies generic attributes carried in the network events. Attributes specific to a particular event category are not part of this specification.

Information Model

The Object Model describes objects implementing this IRP. This model specification includes operations, Notifications and their parameters. It is protocol environment neutral.

(16)

Operation Input parameters Output parameters

setDNPrefix DNprefix status

getMO baseObjectInstance managedObjectClass

scope attributeList

filter status

setMO managedObjectInstance status

attributeName attributeValue

setInventoryIRPVersion versionNumber versionNumberList status

Table 3.1: Mandatory operations

Table 3.3 shows the mandatory operations (the complete list can be found in [2]).

3.1.4 IMA databases

The configuration and topology information in IMA is divided into two separate databases. The database containing the configuration data of the network elements is a proprietary database implemented in C. It is hierarchically structured and accessible via OPC. The topology data is contained in a relational SQL database.

Figure 3.4 shows an overview of the system.

3.1.5 Network Management System

Introduction

Network Management System (NMS) is the primary target of interest to IMA.

During the evaluation, most effort should be put into getting these systems to work together as seamlessly as possible. Other management systems are of less concern, though important.

IMA/NMS interaction

NMS uses a Data Synchronization Module (DSM) to automate the configuration and synchronization of network elements exported from a network element manager (IMA etc.). As shown in figure 3.5 DSM takes a text file as input.

The dashed line in figure 3.5 represents the protocol used for transporting the inventory and topology information from IMA to NMS. In the future the DSM will probably use IRPs. This is of no concern for IMA at the moment. NMS runs on a UNIX system, demanding the solution to be platform independent.

3.2 SNMP

Data transport In order for SNMP to be as simple as possible, the smallest possible communication stack has been chosen. The idea is that the management

(17)

Notification Input parameters notifyObjectDeletion notificationId

eventTime eventType systemDN

managedObjectClass managedObjectInstance notifyStateChange notificationId

managedObjectClass managedObjectInstance stateChangeDefinition notifyAttributeValueChange notificationId

managedObjectClass managedObjectInstance

attributeValueChangeDefinition notifyTopologyChange notificationId

baseObjectInstance Table 3.2: Mandatory notifications

application, and not the transport service, should decide upon the desired level of reliability thus minimizing the stress on the managed nodes [5].

SNMPv1 uses a connectionless approach with UDP making it unsuitable for large data transfers [12]. SNMPv2 and v3 can use other protocols such as IPX and OSI but UDP is still recommended.

Representing the IMA Databases in ASN.1 might present some problems.

A well known problem is that SNMP can not accurately describe relationships between managed object[13]. The MIB is a hierarchical structure which might be a problem when representing the IMA relational database in SNMP.

Flexibility By using ASN.1 it is possible to extend the MIB with vendor specific branches supporting the functions needed but SNMPv1 is considered too simple for representation of detailed and well-organized data [15]. This is partly fixed in later versions of the protocol. These versions (v2 and v3) are not as widely spread as v1. Version 2 did not become very popular and exist in a number of different variations (v2u, v2*, v2c) which few vendors support. It is meant to be replaced with version 3 which basically is a security add-on to SNMPv2 (or v1).

(18)

* IRP L i n k

( fr om M anage d Object C lass es)

* 1

* Co n ta i n s 1

IRP T e rm i n a ti o n P o i n t ( from M anaged Object C lasses)

IRP E qu i p m e n t ( fr om M a nag ed Obj ect C lass es) *

1

* Co n ta i n s 1

IRP S o ftwa re (from M anaged Object C lasses)

* 1

* Co n ta i n s

1

*

1

* Co n ta i n s

IRP Ne two rk ( from M anaged Object C lasses) 1

*

1 Co n ta i n s

*

1

* 1

* Co n ta i n s

IRP M a n a g e d Fu n cti o n (from M anaged Object C lasses) IRP Ma n a g e d E l e m e n t

( from M anaged Object C lasses) 1

* 1

* Co n ta i n s

1

* 1

* Co n ta i n s 1

* 1

* Co n ta i n s 1

* 1

Co n ta i n s *

*

1 Co n ta i n s

1

Figure 3.3: MIM Containment/Naming hierarchy

Operation Input parameter Output parameters Subscribe ActorReference SubscriptionId

Status

Unsubscribe SubscriptionId Status

SetNotificationIRPVersion VersionNumber VersionNumberlist Status

GetSubscriptionStatus SubscriptionId NotificationCategoryTypes FilterInEffect

SubscriptionStatus Table 3.3: Mandatory operations

Third party software SNMP is a popular and widely used protocol. An SNMP agent is already included in IMA and can be extended with an extension agent. In addition, there are several SDKs for both clients and agents.

Notifications SNMP capable devices are able to notify managers via traps.

This is a ‘built-in’ feature in SNMP so there is no need for extra development time to implement this. SNMP does not provide any way to filter the incoming traps.

Technical qualities SNMPv1 and SNMPv2 are incompatible with each other and cannot coexist without conversion of MIB documents, mapping of notification parameters etc. SNMPv1 has minimal security capability. SNMPv3 addresses the security problems but is more difficult and expensive to set up

(19)

IMA-EM

C

IMA-ERION SNM

SQL OPCAPI

IMAAPI

OPC

ADO

SQL IMA Server

Discovery Appl.

UNIX

Figure 3.4: IMA Databases overview

and administer [12]. SNMP is very simple and does not provide any means of data filtering.

IRP compliance Since the Inventory and Topology IRP’s resource model is built upon an object-oriented basis problems might be encountered when trying to represent this model in SNMP. There is a finished Notification IRP solution- set for SNMP that uses the standard MIB-modules SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB specified in RFC-2573 [4].

DSM NMS

Text file IMA

Export client Export server

protocol

Figure 3.5: IMA/NMS interaction

(20)

3.2.2 Evaluation summary

Advantages

• SNMP is flexible. The MIBs are easily expandable.

• SNMP is popular. There are many third party solutions available and extension agents are already used in IMA.

• SNMP supports traps for asynchronous notifications from managed objects.

• There is a finished Notification IRP solution-set for SNMP.

Disadvantages

• SNMP is not suitable for transporting large quantities of data due to it’s use of UDP.

• SNMP has security gaps which is supposed to be fixed in v2 and v3.

• SNMP is very simple with no filter capability.

• SNMP is not object oriented and is therefor not suitable for CIM modeling.

IMA DB SNMP agent SNMP client

Extension agent

IMA DB to MIB mapping IRP operations over SNMP

Figure 3.6: SNMP solution overview

3.3 XML/WBEM

Data transport Using HTTP for large data transfers is proven to work well, however, one drawback is that HTTP does not reuse TCP connections [16].

(21)

XML has a tree structure which does not fit directly into relational database tables such the IMA database over network topology [19]. Object databases and hierarchical databases like the proprietary IMA C database are more suitable for XML representation.

Flexibility XML is extremely flexible and can be used to represent any kind of structured data. XSL style-sheets can be used to transform XML to other representations and to filter results of searches [18]. This makes the XML solution attractive for applications using text files as input, like NMS.

Third party software XML is rapidly being accepted as the industry standard portable data format [19]. WMI is Microsoft’s WBEM solution which unfortunately only supports communication via DCOM making it tightly tied to Windows. If XML is transported using HTTP, IMA will be able to use the webserver Microsoft Internet Information Server included in Windows NT. This provides a cost efficient solution. In addition to this, parsers and XSL engines are needed. These can often be found free of charge (ex. MSXML).

Notifications HTTP was not designed to receive asynchronous data so there is no self-evident way to provide notifications. Implementing notifications using HTTP will probably result in extra work compared to other approaches.

Technical qualities Since XML is just payload, all security features, like HTTPS, can be used. This will also have the effect that problems to pass firewalls, which can happen when CORBA is used, are minimized. The drawbacks of using HTTP are that it does not reuse TCP connections thus wasting band- width, and provides no means of receiving asynchronous data [14]. XML is easier to learn and implement than CORBA and DCOM [19].

Since WBEM uses CIM some of the considered shortcomings should be mentioned. For example, CIM relies on mapping which might result in information loss. CIM does not provide any common set of APIs and does not specify anything about the underklying database structure.

IRP compliance The DMTF has specified how to map CIM to XML and how CIM operations are to be transported over HTTP making XML suitable for implementing the Inventory and Topology IRP.

XML/HTTP is not considered a good alternative for implementation of the Notification IRP.

Advantages

• XML is object oriented.

• XML is easier to learn and implement than CORBA and DCOM.

• XML over HTTP is easily transmitted via webservers and result in less firewall problems than CORBA.

(22)

• XML is very flexible. Together with XSL, the output format can easily be changed. This is suitable for the NMS text file input.

• There is an existing CIM to XML mapping.

• There are many third party solutions including free parsers and XSL engines. Microsoft Internet Information Server can be used as the HTTP server.

• Security is provided via HTTPS.

Disadvantages

• XML over HTTP is not suitable for bi-directional communication (i.e.

notifications).

• XML is not suitable for representation of relational databases.

IMA DB HTTP server HTTP client

Internet Server Application ASP

IMA DB to CIM mapping CIM to XML mapping CIM operations over HTTP IRP operations over CIM

Figure 3.7: XML/WBEM solution overview

3.4 LDAP

Data transport LDAP uses TCP/IP for transportation which, with it’s con- nection oriented approach, is suitable for large data transfers.

LDAP has a hierarchical structure making it ideal for representing the IMA proprietary database [22]. The IMA relational database will be more problem- atic since there is no way of doing an exact representation of this in LDAP.

(23)

Flexibility LDAP uses a text format called LDIF to import and export data to and from LDAP servers. This allows you to write scripts that convert other data sources to LDIF.

LDAPv3 is extensible via three methods: LDAP extended operations, LDAP controls and Simple Authentication and Security Layer (SASL).

LDAP extended operation makes it possible to define new operations without changing the LDAP core. LDAP controls makes it possible to alter the behaviour of an existing operation by providing extra information. SASL is a framework for supporting multiple authentication methods [6].

Third party software Netscape and Novell, among others, offer powerful directory servers meeting the requirements of IMA. Both of these are $1000+ solutions. A cheaper alternative would be Microsoft Active Directory and Metadi- rectory Services, but these are only included in Windows 2000, a platform currently not supported by IMA.

Notifications LDAP has no built-in support for notifications. This issue can be solved using Persistent Search Control, which is described in an Internet Draft [20]. The use of controls demands LDAPv3 support.

Technical qualities LDAP is an ‘all-in-one’ solution. It can be viewed as a data retrieval protocol, an application service protocol, an interapplication data exchange interface and a system service protocol [21]. LDAP specifies an API simplifying the development process.

IRP compliance There are fundamental differences between LDAP and CIM concerning object naming, associations and aggregation [22]. Anyhow, there is a mapping between CIM core and LDAPv3 from DMTF. Numerous differences from the original CIM core model can be seen.

LDAP’s native support for query filtering makes this part of the IRP easy to implement.

The Persistent Search Control together with Java JNDI makes it possible to subscribe to notifications just the way that the Notification IRP specifies.

There is no C++ counterpart to this, so some manual labour probably has to be done.

Advantages

• LDAP is object oriented.

• LDAP is a ‘all-in-one’ solution, both a directory access protocol and a stand-alone distributed directory service.

• LDAP supports notifications using Persistent Search Control (Internet Draft).

• LDAP supports filtering.

(24)

Disadvantages

• The third party solutions are expensive (Netscape and Novell). The Win2k Active Directory and Microsoft Metadirectory Services are currently not options for IMA.

• Mapping between CIM and LDAP is a hard task. Not all of CIM core can be implemented in LDAP.

• LDAP is a hierarchical structure not suitable for representation of relational databases.

• LDAP has security gaps. These have been considered in LDAPv3.

IMA DB LDAP server LDAP client

Database plug-in

IMA DB to CIM mapping CIM to LDAP mapping IRP operations over LDAP

Figure 3.8: LDAP solution overview

3.5 CORBA

Data transport The Internet InterORB Protocol (IIOP) runs over TCP/IP making it suitable for large data transfers.

Representing the IMA databases in CORBA’s native object-oriented model should be fairly easy. CORBA provides CORBAservices, a set of utilities, to aid developers. The database services include relationship and query services used to construct relationships between objects and to find object within collections.

Flexibility CORBA is highly flexible because of its platform and language independence.

(25)

Third party software There are many commercial as well as free ORBs.

Powerful commercial ORBs like Orbix or Visibroker support C++ and can be extended with more services using plug-ins. A free ORB is, for example, included in Java2 from Sun.

Notifications By using callbacks in CORBA it is possible to give clients op- portunity to subscribe to notifications from the server. The notifications can be one-way to reduce network traffic [7]. Callbacks are easily implemented.

Technical qualities The complexity and high learning threshold of CORBA might prolong the development time compared to simpler and less powerful solutions. CORBA can be considered a more robust and faster solution than XML/HTTP if the ‘native’ object model is used, while using XML with CORBA will result in less efficient applications [23]. Currently, effort is being put into making XML a datatype in CORBA [19].

No standard resource models exist for CORBA yet and CORBA might also have problems passing firewalls, which lead some ORBs to use HTTP tunneling [24].

IRP compliance There is a finished Notification IRP solution-set for CORBA that uses Event and Notification Services [3]. Representing CIM in CORBA’s object oriented model should not present any major difficulties. There are no finished mappings though, so this process will probably be time consuming.

Since CORBA has no standard operations Ericsson has defined an interface called “Management over CORBA”.

Advantages

• CORBA is object oriented.

• CORBA has push capability and is therefor suitable for notifications.

• XML will be a built-in data type in CORBA.

• There is a finished Notification IRP solutions-set for CORBA. This demands that the ORB supports both Event- and Notification Services.

• There are many third party ORBs. Plug-ins are often demanded for No- tification Service support.

Disadvantages

• There might be problems with CORBA and firewalls.

• CORBA is a more complex way to transport XML than HTTP. Even if CORBA’s native object model is used CORBA’s complexity might prolong the implementation phase.

• CORBA has no standard resource model.

(26)

CORBA client

ORB A

ORB B

CORBA server

IMA DB

IIOP

Figure 3.9: CORBA solution overview

3.6 Conclusions

Sadly, there is no clear winner in this evaluation. Which protocol to choose for the prototype implementation will all be a matter of compromises since no one is right on target.

LDAP is the protocol most closely matching the IRP specifications and is an

‘all-in-one’ solution. Using LDAP should therefor result in shorter development time compared to the other protocols.

NMS is about to choose LDAP as the protocol to access the upcoming common Topology Database solution. According to [11] this will not affect the DSM and the text file input so there is no need to use LDAP for this reason.

The primary argument against using LDAP is the third party software. The directory servers are big, powerful and expensive. It seems like overkill to use such solutions solely for this rather small purpose of exporting configuration data. This could be economically justifiable if, for example, the IMA databases were to migrate from their current form into a directory structure. This scenario is currently not an issue for IMA.

A more practical way would be to use a server already included in IMA such as SNMP. SNMP can not be recommended for this task for a number of reasons.

First, SNMP is not object-oriented and can therefor not be used to represent CIM, the preferred object model that will be used by NMS [11]. Second, no textual representation of the data can be easily extracted as input to the DSM.

The use of UDP makes it unsuitable for transportation of large quantities of

(27)

data and SNMP is also considered to be too simple. Doing workarounds for these shortcomings would be like reinventing the wheel since other protocols already provide the lacking features.

CORBA and XML/HTTP might seem to be in the same situation as LDAP, but there are a few differences. CORBA is likely to be used to export alarm information from IMA and an ORB will most certainly be included in the IMA package in the future. If XML is to be transported over HTTP, the server is already included in Windows NT giving a solution free of cost. The same objection raised for LDAP is of concern here: the large overhead of an entire HTTP server for this purpose only. The one difference is that it is more probable to find future use for the HTTP server in IMA.

Using XML gives some advantages compared to other protocols. The fact that mappings from CIM to XML are specified by DMTF and the relatively ease of conversion of the XML documents between various text formats are two of these. Especially the latter is important in the NMS case because of the textual input.

The actual transport of the XML data is another matter. DMTF specifies HTTP as the way to go in the WBEM technology. One serious drawback is the lack of notification capability. This is partly remedied by the less complexity of this solution compared to CORBA, probably resulting in fewer hours of development for both server and client. If CORBA is used for XML transportation the complexity of especially the client will increase because of the demand of both an ORB and an XML/XSL parser. In the HTTP case the XML/XSL parser included in most modern web browsers will suffice. If the CORBA native model is used the need for parsers disappear, but we will then face the problems of textual export and CIM to CORBA mapping making this approach less appealing.

The best way to go concerning the notification problem will probably be to split the data export and the notifications in two different solutions. Since the alarm export is likely to use CORBA, the notifications should use the same method. Currently there is no efficient way for IMA to notify on changes in the databases.

From the discussion above some conclusions can be drawn. LDAP might be good for a prototype implementation because of the short development time.

There are finished CIM to LDAP mappings and trial versions of directory servers such as Netscape can be downloaded free of cost. However, before a final implementation is made using LDAP a more thorough economical evaluation should be done. SNMP, on the other hand, is not considered to be a good choice for this particular task.

Given that CIM is going to be used, XML over HTTP is good for faster prototype implementations while XML over CORBA should be considered as a more robust long-term solution, especially if the client already uses an ORB.

(28)

Chapter 4 Protocol implementation

4.1 Modeling the databases in CIM

4.1.1 The logical structure of the IMA database

The proprietary C database in IMA consist of four different objects; the Network Element, the Subnetwork, the Adaptation and the Manageable Object. The differences between these are summarized in table 4.1.

Network Element Subnetwork Adaptation Manageable Object Physical equipment Logical grouping Type of Logical object

equipment/technology Table 4.1: IMA database objects

The containment properties of the objects are as follows:

• A Network Element always belongs to an Adaptation.

• A Network Element always belongs to a Subnetwork.

• A Subnetwork can contain one or many Network Elements and Subnet- works (to a maximum of 5 levels).

Figure 4.1 shows the containment hierarchy of the database objects in UML notation. The Manageable Object is not included due to limited time and usage.

The mapping between the MIM containment hierarchy of the Inventory and Topology IRP (fig.3.3) and the IMA database is straight forward. Note that both Adaptation and Subnetwork match the IRPNetwork class since it both represents a common technology and is self containing [1]. The differences between them can be set with the networkType attribute in the IRPNetwork class.

4.1.2 Finding the CIM classes

Since no Solution Sets using CIM currently exist for the Inventory and Topology IRP, which CIM classes to use is not specified. Finding matching classes to

(29)

Adaptation

Network Element 1

*

1…* 1

Container Subnetwork 1

* Figure 4.1: Containment hierarchy of database objects

Adaptation IRPNetwork (adaptation type) Subnetwork IRPNetwork (subnet type) Network Element IRPManangedElement

Table 4.2: Mapping between IMA and the Inventory and Topology IRP

those in the IRP proved to be untrivial and since these probably have to be updated when the Solution Set is released the search was considered to have low priority. Instead, for the prototype, three classes were created according to CIM standards [8] representing the objects in the database. These ‘prototype classes’ can easily be replaced with standardized classes provided in a Solution Set.

4.2 Server design

4.2.1 Implementational issues

One of the main decisions was which HTTP server to choose. Microsoft Inter- net Information Server was considered to be the best choice since it supports Internet Server Applications and is already included free of charge in the IMA environment. No comparisons have been made with other HTTP servers according to speed but this can not be considered to be of any importance on the prototype level. Microsoft XML (MSXML), the XML/XSL engine used, is already included in Internet Explorer 5. Again, no time was set aside for tests determining whether it really is the best engine for the job.

Another main decision was the actual language of implementation. If an Internet Server Extension was to be chosen there are no alternatives to C++.

The primary advantages of this approach is the speed and low memory usage compared to serverside scripts. On the other hand, these advantages will only be noticable during times of heavy load. The main drawback is the increased development time compared to scripts. This springs from the debugging difficulties surrounding server applications as well as the general complexity of C++, especially when it comes to handling COM interfaces (ex. MSXML). It is likely

(30)

that the number of accesses to the server will be limited in the future, making the extra effort of a C++ implementation almost meaningless.

A COM interface is introduced between the IMA database and the actual server. There are two major reasons for this; (1) The server will not need to use C to access the IMA API, thus leaving the door open for other technologies like Visual Basic Script (VBScript) and (2) the COM interface is likely to be reused in other applications within the IMA environment.

Instead of a server application an ASP with VBScript was chosen as the preferred way to implement the server. The simplicity of VBScript, especially when it comes to COM, as well as the ease of maintainance of the server made it a better choice for the prototype. VBScript 5.0 features a limited kind of object-orientation making encapsulation possible, but lacking inheritance and polymorphism. These missing pieces are, in this particular case, considered to be of no concern.

4.2.2 System overview

The block diagram in figure 4.2 shows an overview of the basic building blocks of the server.

IMA IMA API

COM component

ASP IIS

COM interface

OPC Function calls

Figure 4.2: Overview of the server

The COM component is merely a wrapper for the methods in the IMA API making them accessible to every language with COM capability. The IMA API is a more convenient way to access the IMA proprietary database reducing the usage of OPC. The actual server and the COM interface are clearly separated;

the COM interface handles only the database access, all other functionality is implemented in ASP.

The information exchange between the client and the server consist of XML documents following the CIM standard [9] [10]. Figure 4.3 shows a possible

(31)

scenario where the client asks the server for database information.

Client

HTTP Server XML document containing

request in CIM format

XML document containing instances of CIM classes

Figure 4.3: Information exchange between server and client

The server program consists of five different types of classes/objects as shown in table 4.3. Their interaction during the flow of execution is shown in figure 4.4.

The particular case when the client requests information about all associations with a certain subnetwork is described below.

1. A request for database information is sent from the client over HTTP to the server where it is parsed by a Command Handler object.

2. The Object Handler object, created by the Command Handler, takes care of the actual execution of the commands.

3. The Object Handler creates the root subnetwork as an imaSUB object which searches for its associations recursively down to the level specified.

4. The IMA database is accessed via the COM interface.

5. The resulting tree structure of imaSUB and imaNE objects is converted into XML format following the CIM standard.

6. This resulting XML document is filtered using XSL according to the rules specified in the Inventory and Topology IRP [1].

7. The final filtered XML document is sent back to the client using HTTP.

By using XSL (the XML/XSL engine) as the method of filtering instead of a custom filtering routine implementation time is saved and flexibility added.

4.2.3 Future improvements

Currently the server supports the GetMO and SetMO operations as well as synchronizeMIB and getAssociation specified in the Inventory and Topology IRP. There are some limitations to these though; the SetMO operation is unable to write back the attribute value to the IMA database. This is because of the lack of write back capability in the IMA API. A solution to this would be to either extend the IMA API or use OPC directly.

(32)

Object Description

CommandHandler Handles the parsing of the incoming command ObjectHandler Handles issues concerning the CIM objects imaNE An instance of the CIM representation of a

Network Element in the IMA database.

imaSUB An instance of the CIM representation of a Subnet in the IMA database.

imaADP An instance of the CIM representation of an Adaptation in the IMA database.

Table 4.3: The objects of the server

The biggest problem is the mapping between the operations specified in the IRP and those specified in the CIM standard [9]. There is no convenient way to submit the filter in the GetMO operation to the server. Neither can setDNprefix nor setInventoryIRPversion be directly mapped to standard CIM operations. A solution would be to use the operation ExecQuery, but this would reduce the benefits of using a standard like CIM. The solution to this issue, in a future Solution Set, is eagerly awaited.

Further, the server can be extended to become a full fledged CIM server.

This will require some hard work though, and since most of the features of such a server never would be used in the scenario described in this thesis, this is not likely to be prioritized.

4.3 Client design

4.3.1 Implementational issues

It should be pointed out that the implementation of the client was given con- siderably less time than the server. The client is more of a test program and not supposed to be used in any critical environments.

Once again MSXML is chosen as the XML/XSL engine and Visual Basic as the language of implementation. An IE 5.0 Web Browser Active X control is used to visualize the XML documents. Since the client mainly is a test program, the implementation time is kept to a minimum to prioritize the server test phase. Considering that the probable future operating environment for the client is Unix, a client with a command line interface implemented in C++ or Java would have been less difficult to port to other operating systems. The client is currently very closely tied to Windows.

4.3.2 System overview

The client is basically an event driven Visual Basic application sending and receiving XML documents using MSXML and showing these in a Web Browser Active X control. Screenshots showing the two main windows can be seen in figure 4.5 and 4.6.

The flow of execution starts when the user clicks the ‘submit’ button. An XML document containing the request is sent to the server over HTTP. When

(33)

XML request

Command Handler

Parses the XML request document and creates an Object Handler

XML response

Object Handler

XML representation

Creates the root node and starts the search for associations.

Filtered XML

Filtering through XSL

HTTP

XML rendering Database access via COM interface

Figure 4.4: The flow of execution in the server

the client receives the response, the documents are shown in the web browser window.

4.3.3 Future improvements

There are a great deal of future improvements that can be made to the client.

First, as previously mentioned, the client should loosen it’s bond to Windows.

Further, XSL should be used to export the received database information to the proprietary text format used by NMS. The client should also be able to collect information from the server automatically after a given interval. These improvements can be considered important and are likely to happen in the near future.

(34)

Figure 4.5: The command window

Figure 4.6: The XML window

(35)

Bibliography

[1] Inventory and Topology Integration Reference Point (IRP), LME/DTF- 99:018, rev. PA6

[2] Notification Integration Reference Point (IRP), LME/DTF-99:023, rev. A [3] Notification Integration Reference Point (IRP) Specification: CORBA So-

lution Set, LME/DTF-99:024, rev. A

[4] Notification Integration reference point (IRP) Specification: SNMP Solu- tion Set, LME/DTF-99:025, rev. PA2

[5] Rose, Marshall T.; The simple book : an introduction to internet management 2nd ed. ISBN 0-13-177254-6

[6] Howes Timothy A. et al.; Understanding and deploying LDAP directory services 1st ed. ISBN 1-57870-070-1

[7] Rosenberger, Jeremy L.; Teach yourself CORBA in 14 days; Sams Publish- ing; ISBN: 0672312085

[8] Common Information Model (CIM) specification v2.2, Distributed Man- agement Task Force

[9] Specification for CIM Operations over HTTP v1.0, Distributed Manage- ment Task Force

[10] Specification for the Representation of CIM in XML v2.0, Distributed Man- agement Task Force

[11] CDS implementation proposal, 1/159 41-FCP 109 50/2 Uen, rev A [12] Simple Network Management Protocol

<URL:http://www.sei.cmu.edu/str/descriptions/snmp_body.html>

[13] Basking in glory - SNMPv3

<URL:http://www.nwc.com/915/915f1.html>

[14] SNMP - current standards and status

<URL:http://sun10.iihe.ac.be/scimitar/J1098/stc-98-06.html>

[15] About SNMP and the understanding

<URL:http://www.microwideconnect.com/netdoc/snmp.html>

Evaluation and implementation of protocols for configuration data export from IMA