Figure 1 An Example of CORBA and OSI in TMN Architecture
Raymond Raud
January 1998
ABSTRACT:
The strengths of CORBA and
OSI can be compared as follows:
·
OSI is powerful protocol with strong wire-line interface
compatibility allowing integration of multi-vendor hardware.
· CORBA provides an object oriented system
with well defined APIs which are aimed at standardizing and
simplifying the task of creating distributed applications.
The combination of them will provide the best of both worlds. Implementations have an advantage of efficient development environment for OSI manager or agent functionality and yet be able to easily integrate components from multiple vendors.
Telecommunication Management Network (TMN) standards from ITU-T are gradually being accepted by the industry. A significant body of standards is in place and others are in works. TMN specifies the overall layered architecture of telecommunication management network and defines the intercommunication between the component systems – OSI implementing this architecture.
In parallel the computer industry has developed a Common Object
Request Broker Architecture (CORBA) providing an object oriented
environment for distributed programs in any applications domain.
Since CORBA offers features similar to OSI essential questions
emerge:
1. are OSI and CORBA alternative or complementary,
2. which standards are appropriate to use where and
3.
how do they inter-work if at all.
This contribution will attempt to address these questions. First,
the contribution will compare the components of OSI and CORBA
analyzing their goal, applicability and strengths for
telecommunication applications. Second, it will go through the
network management system implementation aspects. Finally, it will
propose and justify an OSI/CORBA interworking architecture that
builds on the strengths of both standards Some recommendations for
industry and standards organizations fall out from the discussions.
They will conclude the contribution.
Re-iterating what is known from introductions to the standards in telecommunication industry the main purpose of a standard is interoperability of systems from different vendors. These systems range from network elements to distributed Operation Support Systems for different management layers. The standards are expected to provide full plug-and-play level interoperability as a minimum for common network management applications. This level of interoperability requires not only standard transaction and carrier protocols but also standard information models for these interfaces. With that objective in mind, this section analyzes the characteristics of both technologies for TNM implementation
OSI management and CORBA features and facilities have been compared by many authors elsewhere (see for example, [ 1, 2]). Suffice to summarize (referring to the original publications) that CORBA provides features and facilities that are functionally equivalent or exceeding the features of OSI in most aspects. Yet, literal mapping of all possible OSI specification details yields impractical implementations.
For example, ASN.1 has a much more complex type system than IDL. As a result, the translation loses some information in terms of tag values, sub-range types, compound type constants, etc. Also, IDL allows only primitive type constants (boolean, integer, floating-point, character and string). It cannot adequately represent constant values of complex ASN.1 types. For solution all constant values which cannot be represented directly in IDL, a special constant values interface can be defined in the same IDL module. Although, this does not actually define a constant, the constant value is accessible as the return value of an operation in this interface.
Another example, is OSI’s naming hierarchy. A distinguished name of an object instance contains the names of "parent" objects, revealing the containment relationship. That forms the basis for associative operations (scope and filters) on multiple managed objects in an agent domain. CORBA object names are opaque, without any structure, thus not providing any information on parent objects in the hierarchy. OSI naming relationship can be modeled in CORBA domain via separate naming attribute and a construction of naming hierarchy by the same rules OSI does.
Alternatively, same and increased functionality can be achieved by using CORBA object-oriented features. Containment is a relationship expressed by an attribute. Methods findParent, findChild inherited from the base class could traverse the naming tree (via containment attribute) and locate the object instance by the OSI distinguished name. Other methods, can be devised to match with the predefined filter and limit the scope. These methods would mimic the associative behavior of OSI agent where needed. They will invoke the objects that match the filter to respond to the associative management operations. Since the number of these relationship attributes is not limited, many containment relationships can be defined. That could eliminate the need for extensive use of pointers to related managed object instances in GDMO definitions, thus simplifying the Information Models.
Query service is another CORBA facility that can be used to match the OSI associative management operations (scoping and filtering). Query service provides a powerful and general way to reach multiple managed objects selected by variety of criteria. Yet, care should be taken to limit the amount of data generated by the operation to avoid overloading the communication channels.
Both, OSI and CORBA target interoperability at syntactic and semantic levels, but approach that differently. Where OSI stops at communication interoperability CORBA also provides for interoperability of computing components (application processes) and heterogeneous programming environments. That gives the flexibility for fine decomposition of system components with standard interfaces and a standard approach for integration with legacy applications and applications of heterogeneous programming environments.
Assessing a technology other than for its technical
characteristics should be considered also including
·
availability of tools
· Staff experience required
·
Overall cost and complexity.
Growing popularity of CORBA among network management systems developers directly stems from its goal – support for object-oriented distributed systems development. CORBA is used in many computer application domains. Correspondingly, experienced software engineers are easier to find, tools evolving faster and are significantly less expensive. They do not require domain specific knowledge.
TMN tools for automation are expensive because the total market demand is limited. ASN.1 and GDMO the specialists are more difficult to find as they rely on in-depth knowledge of industry specific specification languages. High price of TMN tools precludes smaller outfits from starting up with OSI. As result, the amount of software engineers knowledgeable in OSI grows slowly in comparison to CORBA.
To conclude a list of advantages/disadvantages is provided to arrive at the scenarios where use of CORBA is justified and beneficial.
1. Heterogeneous programming environment with simple mappings to
C++ and other widely used programming languages
2. Lightweight
protocol and without the encoding and decoding of CMIP
3. Same
object distribution mechanism for components and applications of TMN
layers
4. Both, push and pull models are supported for event
distribution
1. Currently only IIOP protocol defined (TCP/IP support)
2.
IDL offers less features for data type definitions
3. IDL
multiple inheritance allows only single attribute of the same name
4. There are no standard information models for telecommunication
interfaces
5. Basic services need extension to match OSI. These
extensions are not defined yet. For example, life-cycle, logging,
asynchronous (concurrent) operations, optionality (or late
binding)
1. Limited number of TMN layer interface specifications
2.
Heavyweight protocol, unusable between application processes
3.
Complex specifications in domain specific languages ASN.1/GDMO,
software engineers must know these languages in addition to the
programming language
4. Expensive and complex tools
Understanding that both technologies have significant strength in their target areas the scenarios and architecture that would capitalize on their power are analyzed below.
Two scenarios are possible in the use of CORBA for TMN
implementation:
1. CORBA implementation of all TMN layers
and features,
2. interworking OSI and CORBA domains.
The first scenario requires that CORBA provides support that is functionally equivalent to that of all OSI features and that international standards exist for layer interfaces. Although the first requirement holds by authors of comprehensive comparisons, the second does not. An obvious way to achieve the second requirement is to create a literal mapping of all details of all OSI constructs in CORBA. That mapping should produce equivalent interfaces to those of OSI and the equivalence should be easily testable for any generic construct in ASN.1 and GDMO. If achieved this mapping would be the OSI implementation in CORBA. Due to significant differences in objectives and approach of CORBA and OSI a practical mapping of all details has not been produced yet. The NMF JIDM group has been active in developing a mapping and they have admitted that to be impractical (for example, recursive attribute syntax structures, see chapter 18 of [1]).
Figure 1 An Example of CORBA and OSI in TMN Architecture
The second scenario provides for the use of OSI facilities on external interfaces that must be standard (for example, OSS interface to network elements, interface to an external trouble ticket or customer care application) and CORBA on internal, management component and application interfaces (for example, integration with existing traffic analysis applications). It requires a gateway (or proxy) that mediates needed objects and attributes from one domain to another. Note, that this mediation is significantly less stringent than literal mapping. It must provide only access to the required data elements and management operations not the whole scope of standard specifications with all details. See Figure 1 for an example architecture.
At current stage, if standard interfaces are required, only second scenario is viable. Once ITU-T Open Distributed Processing (ODP) effort finally produces result and if the inputs from OMG, NMF’s JIDM group and others are folded in these, emerging standards the situation may be different.
Figure 1 depicts an example OSS architecture that implements
network element and network layer functionality. Service and Business
layers can be implemented similarly. The standard OSI interface is
provided on external interfaces and between the management layers,
while CORBA is used for distributed environment of management
applications. Management applications implement CORBA client
interface to access data from CORBA servers. Same management
application can be a client for some objects and a server for others
allowing significant flexibility in configuration the OSS. Three
types of management applications are depicted on Figure 1.
·
An application that consumes (client) and produces (server) data (for
example, an event correlator)
· An application that only
consumes data (for example, a surveillance display)
· A
server only application (for example, a database )
A CORBA Application environment of a layer is communicating to the network and the other layers through CORBA-CMIP gateways that either implement a TMN Manager or TMN Agent functionality. Since the interfaces between the management applications are not defined by OSI, a literal mapping from OSI to CORBA and implementation of all CMIP aspects is not important. As long as required data elements and functionally equivalent operations on them are available through the gateways, the management applications can function.
An example of a network layer functionality is provided on Figure 2. Here the network configuration application is implemented in Java and interacts with the configuration server component. Configuration server provides data for the event correlator component. Event correlator receives the network events through the gateway from the network. Event correlator, in turn feeds the trouble ticket application and alarm surveillance application. Alarm surveillance application relies on the event correlator and log applications.
Both, network configuration and alarm surveillance applications are developed in Java and use Web based distribution. Server applications (event correlator, configuration server and log) are implemented in C++ for better performance. Combining applications from different language environments is one of the major benefits of CORBA.
OSI provides the standard Information Models for the interfaces. These are an important factor for the applications data model, but the data model will likely include more than just interface data elements. This, data model can be specified in IDL. It will provide definition of network objects (data elements and management operations) that are required for the management applications. The mapping between the interface objects and application objects defines the gateway functionality. The gateways will provide the actual data format and operation conversion from one domain to another. Intricate details of specific Information Models, re-creation and recognition of complex mapping structures becomes localized in the gateways rather than being an issue for all management applications. The original protocol used to deliver the objects (CMIP, TL/1, SNMP, other) becomes transparent to the applications as long as the gateway provides required mapping. This approach achieves the "plug-and-play" concept for much wider scope than just standard CMIP interfaces.
Figure 2 An Example Network Layer Implementation with Components
The benefit of this architecture is that each of the technologies, OSI and CORBA, are used for their primary purpose: OSI for defining standard system interfaces and CORBA for distributed application interfaces. The architecture reflects the current level of standardization. Standard interfaces (protocols, data models) are defined for variety of layers. Common data models for the layer functionality implementation are just starting to emerge from various industry groups. Their standardization allows to construct the OSS’s from variety of off-the-shelf application components customized to support the service provider processes. CORBA and IDL are the likely environments were these data models emerge.
TMN architecture defines standard interfaces with powerful protocol and strong compatibility allowing integration of multi-vendor hardware of multiple technologies and across multiple network operators. Many of these interface standards exist today and is provided by OSI. CORBA provides a strong object oriented environment with well defined APIs which are aimed at standardizing and simplifying the task of creating distributed applications. CORBA enables efficient and cost-effective development of TMN layer components and integration with legacy management applications. Using both of these technologies for what they were developed for will provide the best of both worlds. Implementations have an advantage of efficient development environment for OSI manager or agent functionality and yet be able to easily integrate components from multiple vendors.
In addition use of CORBA for distributed application environment and OSI for external interfaces will enable a standard, interoperable component based OSS architecture. The network operators could assemble their OSS’s from components required to support their operation processes and network architecture. The components are provided by multiple vendors, supporting multiple technologies and management operations. Developing commonly accepted definition of standard functionality for management applications, common data models for applications and external interfaces where justified is the task already started by industry groups and standards bodies.
Since coexistence of both technologies is advantageous for the vendors and end-users the need to map the information models at every interface is evident. To reduce the effort required for mapping the industry groups and standard bodies should use a protocol independent language for specifications. This language should allow simple, automatic mapping to both GDMO/ASN.1 and IDL. Some industry groups, like OMG and NMF have accepted Unified Modeling Language – UML [3 ] for their specifications. UML representation of GDMO/ASN.1 definitions are in development by some vendors (for example, extensions to Paradigm Plus from Platinum Technology).
1. Inter-domain Management: Specification Translation, The Open Group, 1997 Order form http://www.opengroup.org/public/pubs
2. Harssema Marnix, Integrating TMN and CORBA, 1996. Computer Science Masters Thesis, University of Twente. Enschede, The Netherlands.
3. UML Resource Center,
http://www.rational.com/uml/index.shtml
©1997, 1998 Raymond Raud. All Rights
Reserved.
Last Modified: January 27,
1998