Issues and Experiences of CORBA-based Management Agents

Daniel Ranc, Institut National des Télécommunications, France

George Pavlou, University of Surrey, UKDavid Griffin, University College London, UK

Juan Simon de la Horra, Polytechnical Center of Saragossa, Spain

Abstract

This paper addresses a number of issues related to the evolution of the TMN framework in terms ofthe associated interface technology. A review of the manager-agent model is followed by an analysisof the challenges raised by emerging distributed object architectures which may result in highlydistributed management systems; from these, fundamental requirements for CORBA-based TMNagent architectures are derived. The paper describes two approaches for realising CORBA-basedmanagement agents that attempt to fulfil these requirements. Both approaches have been validatedthrough implementation while operational experiences with the two approaches are presented.1. Introduction

Over the years, operators and vendors of telecommunication networks have progressivelystandardised, developed and deployed a comprehensive set of network management tasks fortelecommunication networks and associated equipment. The ITU-T has produced the sophisticatedTelecommunication Management Network (TMN) [M3010] architecture which is based on the OSISystems Management (OSI-SM) framework [X701], while vendors exhibited a variety of proprietaryattempts. The current landscape of telecommunications management consists of a solid base of TMN-based systems, which are, however, increasingly challenged by new distributed object architectures,e.g. the Common Object Request Broker Architecture (CORBA) [CORBA], and associatedframeworks for integrated management and control, such as the Telecommunication InformationNetworking Architecture (TINA) [Chap95]. This paper tries to identify how these new architecturesmay be used in the context of TMN but also considers their limitations with respect to theperformance and reliability requirements of large-scale management systems.

Over the second half of the 90’s a substantial amount of effort has been invested in identifying howdistributed object technologies will be used in telecommunications management. In particular, theNMF-X/Open1 Joint Inter-Domain Management (JIDM) task force has produced significant results[JIDM][Rutt94] which were input to OMG’s Telecommunications Special Interest Group (TelSIG). Inthe minds of the authors, the JIDM approach, however important it may be, is subject to debateregarding key TMN requirements such as scalability and other architectural difficulties that motivatethe need for further refinement [Pav99]. This paper presents two approaches for building TMN agentapplications which use parts of the JIDM results: one choosing a native CORBA-based approach, butrespecting TMN requirements and standards, and another one that migrates TMN software platforminfrastructures to a CORBA-based environment.

While the manager-agent model of the TMN has been mainly conceived for network management, thesituation is different in the service management layer, in which the amount of managementinformation is not of the same scale as in network elements. In this environment, there is arguably noneed for agent-like entities that provide optimised access to managed objects but generic distributedobject services such as trading and naming may be used instead. The last part of the paper examines 1

Now TMF and Open Group respectively.

the possibility to use such generic services for object location and access and discusses the briefly theissues and potential problems with this approach when last amounts of highly distributed objects needto be accessed.

The rest of the paper has the following structure. In section 2, we present an overview of existing andemerging telecommunications management architectures, including the manager-agent paradigm,CORBA in the context of the TMN, TINA and the JIDM work. In section 3, we identify keyrequirements for a credible telecommunications management agent architecture. In section 4, wepresent an architecture and design for a CORBA-based agent which relies on existing TMN softwareplatform infrastructure. In section 5 we present a different architecture and design for a nativeCORBA-based agent. In both cases, we present our operational experiences with the respective agentsand we comment on the extent to which they meet the requirements identified before. In section 6 wediscuss the possibility and implications of using generic object services such as trading and namingfor object location and access, avoiding agent infrastructures. Finally, in section 7 we present ourconclusions.

2. Existing and Emerging Telecommunication Management Architectures

2.1. The TMN and the Manager-Agent Paradigm

The manager-agent paradigm is a fundamental part of traditional network management systems,appearing in both the Simple Network Management Protocol (SNMP) and OSI Systems Management(OSI-SM) [X701] approaches. The TMN (Telecommunication Management Network) [M3010]architecture defined by ITU-T uses the manager-agent entity as a fundamental building block of large-scale, hierarchical TMN systems.

In the TMN, Operations Systems (OSs) are dual manager-agent while Network Elements (NEs) areagent entities which use an OSI 7 layer stack and CMIS/P [X710/1] as the communication service andprotocol. In this scheme, the manager issues CMIS/P requests via the OSI stack, which are processedby the agent, with the results being passed back later in an asynchronous fashion. The agent andmanager are roles, i.e. this notion is dynamic in time, with OSs taking either of the two roles indifferent instances of communication.

The information presented to the manager by the agent is standardised and consists of publiclyavailable Information Models. The latter are specified using the Guidelines for the Definition ofManaged Objects (GDMO) [X722] formalism; which is object-oriented and consists of classes,attributes and methods (actions and notifications). Values of GDMO attributes, action and notificationparameters are represented using the Abstract Syntax Notation One (ASN.1) [X208] structuringlanguage and particular coding rules in order to be transmitted by the OSI stack.

An agent entity is composed of three fundamental elements: the Managed Information Base (MIB),the collection of implementation objects, and the resources. The MIB consists schematically of thenaming tree and the Managed Objects (MOs). The naming tree is the access structure for theManaged Objects via a standardised hierarchical naming scheme. The managed objects, specified inGDMO, are the entities subject to manipulation by the manager through CMIS/P operations. Themanager-agent model with the managed objects, implementation objects and resources is depicted inFigure 1.

The scenario depicted above is, however, not cast in stone. New, powerful distribution infrastructuresand telecommunication architectures are emerging. The following two sections summarise the twoemerging frameworks in this area.

2

managerq reference pointagentmanaged objectsmanaged information baseTMNimplementation objectsresourcesFigure 1 The TMN Manager-Agent Model

2.2. CORBA From a TMN Point of View

The Object Management Group (OMG) has specified the Object Management Architecture (OMA)and is now defining higher level business-oriented services and entities, making the overallarchitecture more and more complete [CORBA].

The distribution architecture of CORBA is built upon a software bus, the Object Request Broker(ORB), which provides the infrastructure allowing distributed software components to communicate.Key aspects are: ubiquitous use of the client-server paradigm, true object orientation, implementationlanguage independence, and implicitly distant objects i.e. no difference between local and remoteobjects and access transparency.

The latter property is particularly powerful for TMN systems designers. Within the OSIcommunication framework, the programmer has (even with sophisticated software layers between thelocal representation of the Managed Object, and the distant one) to deal explicitly withcommunication aspects; whereas in a CORBA-based environment, the programmer does not evendistinguish (after some simple initialisation) between local and remote objects: the remote objectappears, and is manipulated, in the same manner as a local one in the programming language.Additionally, data representation burdens, which are taken care by the ASN.1 standard in the ITU-Tworld, are dealt with in a completely transparent way by the ORB.

An additional benefit of CORBA, compared to OSI Systems Management, is its ease of use. An OSIprogrammer is faced with relatively expensive tools and complex software Application ProgrammingInterfaces (APIs) such as the low-level XOM/XMP2 or the more high-level TMN/C++, whereasCORBA systems are comparatively cheap and easy to learn. Typically, competent C++ programmersare able to build simple client-server systems in half a day under CORBA; this is, unfortunately, notthe case with OSI-SM technology. These shifts in distribution technology are the main motivationsthat make CORBA attractive environment when projecting new TMN systems.

This decision-making point however hides some key questions regarding the TMN architecture.CORBA does not have the powerful access aspects of CMIS/P such as scoping/filtering, neither doesit provide a suitable architecture for credible telecommunication management e.g. thinking of buildingblocks like the Event Forwarding Discriminator, an essential entity for scalable, fine-grain event 2

The XOM/XMP API has been specified by the X/Open consortium, now known as the Open Group.

3

dissemination in telecommunications systems, and the Systems Management Functions (SMFs) whichsupport generic Fault, Configuration, Accounting, Performance and Security (FCAPS) functionality.In summary, the TMN system designer is very much tempted by the comfort of the CORBAarchitecture, but has no real valid support regarding the management of telecommunications systems.The temptation may be so strong, however, that some had-hoc implementations may arise and solveparticular local network management problems but at the cost of ITU-T standards respect and, as aconsequence, at the cost of the hope for general interoperability between all stakeholders of thetelecommunications service architecture.

2.2. The TINA Architecture

The Telecommunication Information Networking Architecture Consortium (TINA-C) [Chap95] aimsat providing an advanced object-oriented software architecture for integrated telecommunicationnetwork and service management and control. In summary, the TINA architecture consists of twomajor building blocks:

• the Service Architecture, which represents a step forward beyond the specifications delivered by

the ITU-T, which are limited to the network and element management, and which addressesservice control. The service architecture introduces the concepts of access and service session andintegrates service control with service management.• The Network Resource Architecture, which is the TINA view of TMN network and element

management. This uses the Network Resource Information Model (NRIM) to model connection-oriented networks in a technology-independent fashion.The distribution infrastructure proposed by TINA is the Distributed Processing Environment (DPE),which is based on CORBA, but is enhanced with telecommunication-oriented features. The DPE runson an overlay network that is used for control and management, known as the Kernel TransportNetwork (kTN). TINA makes an extensive use of Open Distributed Processing (ODP) [X90x]methodology in its specifications.

A discussion on the architectural relationship and potential migration of the TMN to the TINAarchitecture can be found in [Ranc97], which was written with the idea that TINA will eventuallyreplace today’s Intelligent Network (IN) and TMN functionality. However, it is no longer clearwhether TINA will be fully applied in a unifying telecommunications software architecture. Morerealistically, a selected set of TINA concepts and components are expected to be found in futuretelecommunications systems.

2.3. JIDM Agents

A number of studies and projects have considered CORBA as distribution platform for networkmanagement systems. In this section we present a brief summary of the major one. The Joint Inter-Domain Management (JIDM) [JIDM][Rutt94] study group of the OMG has worked on both amapping scheme of GDMO/ASN.1 to IDL, and on an interaction translation for mapping an OSI-SMagent environment to CORBA.

• GDMO/ASN.1 to IDL mapping. This study group has specified a complete GDMO/ASN.1 to IDL

mapping, proposing a number of rules enabling to build a complete compiler for automatic IDLgeneration from GDMO specifications.• JIDM agent. An architecture for a management agent was specified, the features of which could

have made it an interesting candidate for a TMN agent. This architecture defines managed objectsas individual CORBA objects e.g. servers possessing individual IDL interfaces that are generatedby the GDMO to IDL mapping rules. The relations between instances, containment for instance,are modelled using CORBA references.Two remarks emerge from a closer examination of these specifications. The first one concerns themapping of ASN.1 to IDL. Recalling that the function of ASN.1 is to transport attribute, action and

4

notification values between agents and managers in a platform-independent fashion, and that thisfunction is taken care transparently by CORBA’s Object Request Broker (by its internalmarshalling/unmarshalling functions), one may question why to duplicate this function a second timeby translating the ASN.1 structures to IDL. Moreover, this encoding/decoding is left to the managedobject itself, because it holds the corresponding IDL, whereas this function was largely taken care byplatform services in existing TMN frameworks.

A second remark concerns the mapping of managed objects into CORBA servers. This feature is anattempt to use the CORBA paradigm as deeply as possible, however the consequences arequestionable. The granularity of a CORBA server is, in the eyes of the authors, the size of a systemcomponent (a distributed system holding, for example, the order of 10 such components) – whereasthe granularity of a managed object instance is the size of, for instance, a C++ object instance. Thisdifference results in a granularity mismatch. Moreover, in the JIDM scheme the managed objects arenot any more structured in a MIB – they are all visible at the same level (even if the referencesemulate a virtual naming tree). This may become hazardous in realistic TMN situations with,typically, 1E6 managed object instances for an agent, because existing ORBs are not designed tomanage such a large number of server objects.

These two remarks motivated us to consider the possibility of further enhancements and to proposethe solutions presented in this paper.

3. Some requirements for a credible telecommunications agent

With the previous considerations in mind, a credible telecommunications agent should exhibit anumber of characteristics, including:

• Scalability. Network equipment, especially public Wide Area Network (WAN) equipment, such

as Synchronous Digital Hierarchy (SDH) add-and-drop multiplexers or large scale AsynchronousTransfer Mode (ATM) switches, become more and more complex. This is reflected both in thecomplexity of the management software at the desk of the operator, and at the level of the agent.The latter results in very large MIBs where a magnitude of 1E6 managed objects is typical. Up tonow, only the sophistication of the TMN architecture through the manager-agent model was ableto deal with such vast quantities of data.• Dynamicity. This equipment offers a large number of dynamic features which where absent of

previous technologies. These features allow operators to offer new, more dynamictelecommunication services. On demand establishment of connectivity for e.g. multimediaapplications is a typical operation that requires, at the agent level, a large number of interactionsto insure the configuration of the Virtual Channels, their capacity and Quality of Service (QoS),as well as adequate cross-connections. These interactions have to be fast enough to ensure nearreal-time access to the required telecommunication service.• Interoperability. The telecommunications market is becoming more heterogeneous. The

traditional operators are challenged with aggressive competition. Actors such as major softwarevendors (Microsoft) or content providers (Bertelsmann, Disney) are more and more involved inthe telecommunication business. As a contemporary example of the level of interactions betweentelecommunication companies, a simple telephone call from e.g. a fixed line in Paris to a mobilephone in London requires interactions between at least 4 companies: the French traditionaloperator (who owns the access part of the line), the Eurotunnel operator (owning the opticalfibber in the tunnel), an arbitrary English operator up to London, and a mobile operator in Londonitself. Future multimedia services such as video on demand will require interactions between thedifferent participants that together, deliver the service: the network operators (for theconnectivity), the content provider at least. The requirements for interoperability are thereforebecoming even stronger.• Standard compliance. This requirement is related to the interoperability requirement and concerns

both the computational viewpoint and the information viewpoint of the system. The

5

computational viewpoint has already been discussed earlier, and refers to the powerful aspects ofCMIS, the naming scheme of the managed objects etc. The information viewpoint refers to theimportant, and valuable, capital of existing GDMO information model specifications both at theelement and network management layers. It is reasonable to assume that GDMO specificationswill continue to be the ultimate source of the information in the TMN, even if the GDMOspecifications are turned into other forms of interface specifications by translation tools.

In the following sections, we present two approaches regarding the design and implementation ofCORBA-based TMN agent environments. The first one uses already existing TMN platforminfrastructure, parts of which are re-used to result in a CORBA-based agent. The second one isdesigned from the beginning based on a CORBA environment, without reusing any previousinfrastructure. Both approaches try to address the requirements for scalability, dynamicity /performance and interoperability that were identified before. We also comment on the operationalexperiences with both approaches.

4. A TMN platform CORBA-based Agent

4.1. Architectural and Implementation Considerations

A JIDM-based approach for mapping the OSI-SM model to CORBA has already been presented in[Pav99]. One key aspect of this approach is that it tries to stay as closely as possible to the OSI-SMapproach, minimising the use of CORBA services [COSS] and allowing reusability of existingmodular OSI-SM platform infrastructures. In this paper we present an implementation approach whichreuses parts of the OSIMIS platform [Pav95] and allows a phased transition strategy that will easecompatibility and interoperability with existing TMN systems.

The first step for migrating towards the target framework is to support only agent discovery and CMISinteractions through CORBA, without individual IDL interfaces for managed objects. This essentiallymeans that a Management Broker (MB) object with a CMIS-like interface will act as an agent thatprovides access to managed objects which are implemented by existing TMN platform infrastructurei.e. GDMO/ASN.1 compilers and relevant APIs. The MB may be used in conjunction to the existingQ3 agent object within an agent application. In this case, the TMN application in agent role will havetwo interfaces: the existing Q3 interface and the CORBA version of the CORBA-based “Q3” interface.The latter may be according to JIDM pseudo-CMIS specification. The current implementation uses adifferent pseudo-CMIS which was designed in parallel with the JIDM one and stays as close aspossible to the ITU-T CMIS [X710]. In this approach, notifications are disseminated through OSI-SMEvent Forwarding Discriminators (EFDs) and a “push” model, supported by a i_CMISManagerinterface.

This minimal approach is depicted in Figure 2 and has no impact at all at the implementation ofmanaged objects which are based on TMN platform technology e.g. OSIMIS [Pav95]. Existing OSI-based manager applications will continue to function while new CORBA-based managementapplications may be developed. CORBA manager objects get access to the MB interface referencethrough the CORBA naming services [COSS] while OSI manager objects get access to the address ofthe OSI agent through the OSI directory [X500]. It should be noted that two different notations havebeen used in this figure to depict interactions, one for CORBA using object interfaces and one forOSI-SM using arrows.

6

NSDSATMN Agent ApplicationCORBA MgrMOsMB OSI Mgr Q3Agentinternal APINS: Name ServerDSA: Directory Service Agent

Figure 2 Dual Q3 and CORBA based Agent

This architecture exploits the fact that the object models are the same in the two frameworks, andprovides a “dual-agent” access paradigm. In this framework, the managed object GDMO/ASN.1specifications are translated to IDL but the resulting IDL interface specifications are not instantiated:they simply “document” the management broker interface which provides access to those objects in adynamic, weakly-typed fashion. The attribute, action and event ASN.1 types are used across themanagement broker interface through the equivalent IDL types. A variation of this approach is thegateway approach, in which the management broker becomes a separate application which accessesone or more management agents in the “back-end” through their Q3 interfaces. The gateway approachis useful to provide adaptation for TMN applications that are already deployed, in which case it is notpossible to add to them the management broker in a tightly-coupled fashion.

Implementing this framework was fairly straightforward. The only difficulty encountered was the bi-directional translation between ASN.1 and IDL data types. This can be automated if one has access toa flexible ASN.1 compiler, which could be customised to produce the equivalent IDL types as well asthe conversion routines in both directions. Since OSIMIS uses the ISODE pepsy compiler whichcannot be easily customised, these conversions had to be hand-coded. Implementing the tightly-coupled dual agent version was also straightforward given the well-defined OSIMIS APIs foraccessing managed objects within an agent application. Based on this approach, existing OSIMISagent applications can be made to work over CORBA by changing a few lines of code in the mainprogram and re-linking them with the management broker library.

The complete CORBA-based framework requires also that individual managed objects becomecomputational constructs with IDL interfaces. The advantage in this case is strongly-typed access,superior distribution aspects and potentially better performance. Having produced the relevantspecifications using GDMO to IDL translation, the key issue is how to support CMIS features such asmultiple attribute get/set and filtering, which are very important for performance and scalability. Thisfunctionality can also benefit from existing OSI-SM platform infrastructure and should be supportedby a i_ManagedObject interface from which the OSI-SM i_top interface derives.

Classes for derived interfaces should pass to their i_ManagedObject parent class the names and typesof their attributes when an object instance is created. The i_ManagedObject part will subsequentlyaccess the attributes of derived parts as if they belonged to separate objects, through the CORBADynamic Invocation Interface (DII). This scheme supports the multiple attribute get and set methods.The only way to deal with filtering is to provide the IDL compare methods by hand, in a hash tableindexed by the relevant type. The i_ManagedObject part will retrieve the attributes involved in thefilter and will invoke the relevant compare and traverse methods, getting access to them through theattribute type which is known from its “repository”. While this is feasible, it is far from desirablesince it requires hand-written routines for every attribute type. On the other hand this is the only

7

approach to support filtering until OMG considers the inclusion of relevant features in IDL and theirconcrete support through the programming language mappings.

4.2. Performance and Scalability

Having implemented the management broker approach in parallel with the existing Q3 agentinfrastructure, another consideration is to assess the performance difference and the packet sizes inthe two approaches, one based on the Q3 interface and the other on its precise equivalent in CORBAIDL. We conducted a number of experiments on a pair of Sun Sparc20 workstations running Solarisand being connected to a lightly-loaded Ethernet. The Q3 protocol stack used operated over TCP/IPusing the RFC1006 method while the CORBA protocol used was the Internet InteroperabilityProtocol (IIOP). The OSIMIS research prototype was used for the Q3 interface [Pav95] as opposed toa commercial CORBA implementation.

An example managed object was used, supporting methods with various data types in ASN.1 whichwere mapped to the equivalent IDL types. While a detailed performance comparison could be thesubject of a separate paper, the key conclusion was that the CORBA-based access times for methodinvocations through the management broker were faster by about 30% on average. Performing thesame operation to the managed object through a direct IDL interface resulted in 45% faster times. Inaddition, the initial bind operation through IIOP was about 60% faster than association establishmentusing the Q3 protocol stack. The use of the CORBA IIOP protocol in this case seems to be a morelightweight solution compared to the relatively heavyweight Q3 protocol stack, especially formanaged objects with IDL interfaces.

The next experiment concerned the size of packets exchanged, which were measured at the TCPpayload level using the Berkeley tcpdump program. Performing an echo operation of 1 byte to anobject in the first level of the MIT incurred 72/88 byte packets for the request/response in the case ofQ3, 177/47 bytes in the case of the management broker and 101/32 bytes in the case of a direct IDLinterface. Performing an operation asynchronously through the management broker, which means thatan Interoperable Object Reference (IOR) is exchanged, resulted in 409/97 byte packets. After manydifferent measurements with different argument types, we came to the conclusion that IIOP generatesa relatively large amount of traffic in comparison to Q3, especially when IORs and IDL any types areexchanged, since the latter convey CORBA type-code information.

The final experiment concerned the memory required for managed objects in both TMN and CORBAplatforms. In the case of CORBA, the ORB which is typically running as a separate process isrequired amounts to 2.7 Mb at runtime. The size of a process containing a single server object and anassociated factory object was about 2.6 Mb. The size of the equivalent OSI agent was 2.3 Mb but thelatter contains also functionality of name resolution, scoping, filtering event reporting and logging.The key issue though is not the size of the infrastructure which is incurred once but the data size ofmanaged objects at runtime. After various experiments and memory size measurements, it becameclear that the data size of a CORBA object is about 2-3 times more than the size of a GDMO object,depending on the data type of the attributes and the relevant values. In addition, the particular ORBused seemed to have a problem to cope with very large amounts of managed objects.

These experiments confirmed the fact that IIOP is expected to perform better than Q3 interfaces,generating though larger amounts of management traffic. On the other hand, the experiments alsoconfirmed the fact that the required memory size is bigger for native CORBA managed objects, whichmay result to scalability problems. This reinforces the management broker approach presented in thispaper as an approach that benefits from the better performance of CORBA without the associatedpotential scalability problems. The native CORBA-based managed object approach could be the nextstep, with more mature, second or third generation ORB products coming to the market place.

8

5. A Native CORBA-based agent

5.1. Architectural motivations

Given the different constraints and requirements to build a realistically deployable TMN agent basedon CORBA, a number of considerations and options come to the mind of the system designer. In thisparticular project, several options were taken as main architectural options:

• Referring to the scalability requirement, it has been chosen to design the agent such as to hide the

managed objects inside the agent as the default option. This way, it is possible to accumulatemanaged objects by the millions without dealing with ORB limitations. An option to publish, onrequest, the CORBA reference of a particular sub-tree of the MIB is kept open (e.g. if repetitiveaccess to the physical view of an equipment is foreseen, the manager could be interested in such ashortcut through the naming tree).• The external access to the agent conforms to the JIDM pseudo-CMIS specification. This has the

double advantage of a standardised publicly available IDL specification, and of a totalindependence from the information model used by the agent. Full implementation of all CMISfeatures, such as scoping and filtering, were put at a top priority.• Regarding the ASN.1 architecture mismatch referred in section 3, a heavy decision has been

made: to discard the existing ASN.1 definitions and to replace them by native IDL types by hand.This has the drawback of deriving from strict standard handling, at the benefit of a considerablesimplification of the designer’s life. A close examination of ASN.1 types delivered by standardsindeed leaves an impression of pointless complexity (as an example, all ASN.1graphicString, printableString etc. types, many in the standards, are thus replacedwith the unique IDL string type). The cost of hand-typing the types has been tested on theexisting implementation, and has been felt as quite acceptable.

5.2. Realisation

The architecture of the agent has been designed as a GDMO template handling engine at the heart ofwhich is the naming tree. The latter is implemented using a son-brother scheme holding the managedobjet skeletons, which in turn refer to their packages, and finally to attributes and even later to values.The complexity of the system relies on list and memory management, thus quite classical algorithmscould be used.

A special note has to be made on multiple result handling. In the CMIS/P context, the agent answersto requests by replies, as many as the result requires (quite many, for a wide scoped request forexample). This scheme had to be emulated in the CORBA infrastructure, because the team did notproject to depend on a notification service. The actual workaround has been to encapsulate multipleresults in a IDL sequence, where each element represents one result.

5.3. Implementation notes

The implementation of the agent was based on a quite standard environment: a Sun workstationrunning Solaris 2.5.1, the Orbix CORBA system and the Sun C++ compiler.

The large use of dynamic memory allocation mechanisms and pointer management has to beemphasised. As an example, the instantiation of a managed object through a M_CREATE requestdetermines the allocation of dynamic memory for each and every entity of the instance (the instanceitself, its attributes, their values). Reciprocally, the deletion of an instance requires to free all thememory allocated previously. All the MIB management is implemented using pointers which modelthe relations between all instance entities. An efficient tree management structure using the classicalson-brother scheme has been used. The following figure shows partially how these entities linktogether.

9

char* tc_FDNchar* tc_RDNtreeClass* tc_brothertreeClass* tc_sonMObject* tc_objectchar* mo_classattributeList* mo_listidvalueidvalueidvalueidvalueFigure 3 Management Information Tree Implementation

The agent’s IDL interface contains all the information and structures needed to run pseudo-CMISrequests under CORBA. This interface is unique e.g. independent of the Information Model. Allfunctions are confirmed e.g. returning results. The IDL definition followed the JIDM standard withthe notable exception of the ASN.1 structures, which have been considerably simplified.

The agent has been run with a minimal manager reading requests from ASCII files. This schemeallowed to test the agent with very large request sets. A hierarchical scheme were the cities containdistricts, the latter containing zones, and zones containing equipment, has been used. This network isvariously meshed depending on the importance of nodes and their geographical situation.

The information model used for this experiment has been the TINA NRIM. The main class used tomodel networks is the subNetwork class which is subject to a recursive containment relationshipe.g. subNetwork instances of layer (n) contain subNetwork instances of layer (n-1) and so forth.Other classes defined in the NRIM information model that were used are link,topologicalLink, linkTerminationPoint and topologicalLinkTermination-Point(see figure below).

SNW ( France )CITIESSNW....TPLLink ....SNW....Link....TPLSNWDISTRICTSSNW....Link ....SNW....Link ....LPTPLPZONESSNW........Link ........SNW........Link ........LPTPLPCPEsCPELink CPELink LPTPLPFigure 4 The NRIM-based Simulated National Backbone

Scalability tests included a large scale simulation of a French backbone including instantiation of430.000 objects. Performance results were rewarding. One M_CREATE request including manager toagent and return paths through the available laboratory IP network takes less than 30 milliseconds.The agent has been extensively tested and its stability has been remarkable, both in terms of constantresponse time and of resilience.

10

5.4. Future developments

This architecture is expected to evolve in three areas:

• OMG component. The OMG defined recently a new architecture for servers called components,

which really are a mapping of JavaBeans features onto the CORBA architecture. Powerful items,such as introspection e.g. the ability of the CORBA object to possess a knowledge about itself,and to communicate it to other components, are very attractive to implement within a TMN agent,in the perspective of intelligent, open TMN software systems.• Scalability. One of the performance questions in the system is due to the depth of the naming tree.

The longer the trail within the naming tree to access the object, the lower the performance. Onedefence regarding this aspect is a hash-code based access scheme. Another is the possibility forthe agent, given a certain maximum size, to instantiate a new sub-agent holding a certain sub-treeof its parent. Requests to this part of the naming tree would then be subcontracted to this sub-agent by the original agent. Sub-agent instantiation would make profit of CPU and memorystatistics to adequately distribute the load over the network.• Software engineering. In order to enable quasi-industrial handling of this software, a suitable

software engineering environment is needed. In particular, a GDMO compiler suite able togenerate C++ classes for the agent is concretely planned as a next step.6. Considerations on Pure ODP/CORBA based Approaches

The original idea behind Open Distributed Processing (ODP) [X90x] was to deal with the globaldistributed universe as a “sea of objects”, administered through generic services such as trading,naming and event/notification [COSS], mentioning those that are pertinent to network management.In this section, we consider briefly the issues behind a purely ODP-based approach, without the OSI-SM-like support for managed objects organised in agents, as presented before. This approach could bepossibly used at the service management layer, though in this section we will consider theimplications of using it more generally, even in the network and element management layers.We will consider first a pure ODP approach, using only traders. In such a distributed managementenvironment, managing objects will discover managed objects based on assertions on properties andattributes through the trader. An important issue with the use of trading is that federation is a keyaspect in order to achieve scaleable systems. In essence, it will be necessary to have dedicated tradersfor every logical cluster of managed objects, for example in every managed element, in order toreduce traffic and increase real-time response. Those “low-level” servers will need to be unified by“higher-level” servers in a hierarchical fashion. Federation issues become thus very important buthave not yet been worked out and are not simple. Even with such facilities in place, the managementtraffic in terms of the required application-level packets will be at least double that of OSI-SM. InCORBA, matching object references will be returned by the trader to the client object and theoperations will be performed on an object-by-object basis. In OSI-SM, a multiple object accessrequest will be sent in one packet while the results will be returned in linked replies, one for eachobject accessed. The potential advantage of this approach is that it does not require a hierarchicalnaming scheme based on containment. On the other hand, this approach requires federated trading ofnon-hierarchical search spaces, which is an open research issue. A more detailed consideration of thisapproach can be found in [Pav97]; the approach is depicted in Figure 5.

11

ITE“Import”“Federate”ITE“Export”“Search”M”OAccess per MO MOObject “Cluster”M”O: Managing ObjectMO: Managed ObjectT: Trader

I: Import I/FE: Export I/F

Figure 5 Object Discovery Through Trading

A more feasible approach is to use the CORBA Naming Services (NS) for object discovery, retainingthe TMN hierarchical naming architecture. In this case, naming servers will be organisedhierarchically, in a similar fashion to the traders of Figure 5. Given a hierarchical naming architecture,this approach is feasible and federation will be supported through a “protocol” similar to the X.500Directory System Protocol (DSP). Naming servers currently support discovery of the first-levelsubordinates of a particular name; it would be fairly easy to extend this facility to provide thefunctionality of CMIS scoping, but this requires a change of the current NS interfaces. In principlethough, naming services could support object discovery facilities based on a hierarchical namingarchitecture. The problem is the absence of object selection through filtering, which is something onlytraders can do, albeit in a non-federated manner.

It is evident from the above analysis that TMN agent-like facilities are still needed in order to dealwith the vast amount of objects present in telecommunications environments in an efficient fashion.This holds particularly for the element and network management layers of the TMN hierarchy. ODPand CORBA were conceived initially for general purpose distributed systems. The ubiquity ofCORBA and its relatively user-friendly APIs can be exploited in TMN environments through agent-like architectures which can deal with the problems of performance and scalability.7. Conclusions

The work presented in this paper addresses the complex subject of using distributed objecttechnologies for telecommunications network management, moving away from protocols and trying tobenefit from the ubiquity, usability and ease of ease of distributed object platforms such as CORBA.In this case, the key requirement is scalability but also performance, since network managementfunctions may be used as a replacement for some traditional control functions e.g. call and connectionestablishment, as it is the case for example in TINA’s connection management architecture. The workcarried out needs to be verified further in this respect in terms of feasibility and viability in thecontext of large-scale telecommunications networks.

Deployment of distributed object technologies will be accelerated in the coming years but we observethat: 1) there is a huge demand from operators for such technologies and 2) at the same time there is alow confidence in these technologies. One of the reasons is that these technologies have originated inthe computing world while telecommunications environments pose different requirements ofrobustness, availability, scalability, integrity and performance. It is only when telecommunicationsrequirements will be taken into account in the context of emerging architectures that viable solutionswill be provided. In the context of the TMN, the manager-agent paradigm is of paramount importanceand we have shown in this paper that it can be realised in the context of CORBA, maintaining keycharacteristics of scalability and performance.

12

References

[Chap95][CORBA][COSS][JIDM]

[M3010][Pav95]

[Pav97]

[Pav99]

[Ranc97]

[Rutt94]

[X208][X500][X701][X710/1]

[X722]

[X90x] ITU-T Draft Rec. X.901-904, Information Technology - Open Distributed ProcessingM. Chapman, F. Dupuy, G. Nilsson, An Overview of the Telecommunications

Information Networking Architecture, in Proc. of the Telecommunications InformationNetwork Architecture (TINA’95) International Workshop, Melbourne, Australia, 1995Object Management Group, The Common Object Request Broker: Architecture andSpecification (CORBA), Version 2.0, 1995

Object Management Group, CORBA Services: Common Object Services Specification(COSS), Revised Edition, 1995

NMF - X/Open, Joint Inter-Domain Management (JIDM) Specifications, SpecificationTranslation of SNMP SMI to CORBA IDL, GDMO/ASN.1 to CORBA IDL and IDL toGDMO/ASN.1, 1995

ITU-T Rec. M.3010, Principles for a Telecommunications Management Network (TMN),Study Group IV,1996

G. Pavlou, G. Knight, K. McCarthy, S. Bhatti, The OSIMIS Platform: Making OSIManagement Simple, in Integrated Network Management IV, A. Sethi, Y. Raynaud, F.Faure-Vincent, ed., pp. 480-493, Chapman & Hall, 1995

G. Pavlou, From Protocol-based to Distributed Object-based ManagementArchitectures, in Proc. of IFIP/IEEE Distributed Systems: Operations and Management(DSOM’97), A. Seneviratne, V. Varadarajan, P. Ray, ed., pp. 25-40, 1997

G. Pavlou, A Novel Approach for Mapping the OSI Systems Management TMN Model toODP / OMG CORBA, in Integrated Network Management VI, Proc. of the IFIP/IEEEIntegrated Management Symposium (IM’99), Boston, USA, M. Sloman, S. Mazumdar, E.Lupu, eds., pp. 67-82, IEEE, May 1999

D. Ranc, G. Pavlou, D. Griffin, A Staged Approach for TMN to TINA Migration, in Proc.of the Telecommunications Information Network Architecture (TINA’97) InternationalConference on Global Conference of Telecommunications and Distributed ObjectComputing, pp. 221-228, IEEE Computer Society, Santiago, Chile, 1997

T. Rutt, ed., Comparison of the OSI Systems Management, OMG and InternetManagement Object Models, Report of the NMF - X/Open Joint Inter-DomainManagement task force, 1994

ITU-T Rec. X.208, Information Technology - Open Systems Interconnection,Specification of Abstract Syntax Notation One (ASN.1), 1988

ITU-T Rec. X.500, Information Technology - Open Systems Interconnection, TheDirectory: Overview of Concepts, Models and Service, 1993

ITU-T Rec. X.701, Information Technology - Open Systems Interconnection, SystemsManagement Overview, 1992

ITU-T Rec. X.710, Information Technology - Open Systems Interconnection, CommonManagement Information Service Definition and Protocol Specification (CMIS/P) -Version 2, 1991

ITU-T Rec. X.722, Information Technology - Open Systems Interconnection, Structureof Management Information - Guidelines for the Definition of Managed Objects, 1992

,

Basic Reference Model of Open Distributed Processing, 1995

13