Introduction

Scope and Purpose

In the real world there are several technologies that are appropriate to solving this complex task. Each has strengths and weaknesses and will undoubtedly feature in future network management systems. The Open Group and Open-Network Management Forum Joint Inter-domain Management (JIDM) group has identified three key technologies:

• CMIP (see reference CMIP)

• SNMP (see reference SNMP)

• CORBA (see reference CORBA),

and is seeking to enable interoperability between them, both within a single organisation and between organisations. SNMP has a large embedded base in the general purpose computing market, CMIP is mandated in the telecommunications arena by the TMN standard, and CORBA is recognised as the emerging standard covering distributed object oriented programming. Each technology has its strength; thus full interoperability will enable designers to select the most appropriate technology to apply to any given problem. The Network Management Forum ISO-Internet Management Coexistence (see reference IIMC) group has addressed SNMP/CMIP interoperability. Thus JIDM has chosen to concentrate on CMIP/CORBA and SNMP/CORBA interworking.

To enable interworking it is necessary to be able to map between the relevant object models and to build on this to provide a mechanism to handle protocol conversion on the domain boundaries. The results of comparing the object models of OSI Management, CORBA and Internet Management is provided in Part 8 of this document. For a particular pair of domains, the specification of the mapping is split into two parts:

• The first part, covered in this document, is referred to as Specification Translation, and is expressed as a mechanism for translating between GDMO (the object definition language used in conjunction with CMIP - see reference GDMO), SNMP MIB Definition language (see references SNMPv2 and ISMIv2), and CORBA's Interface Definition Language (IDL - see reference CORBA)whichisusedfordefiningtheinteractionsbetweenobjectsin the CORBA domain.

• The second part, to be detailed in a subsequent document, is known as Interaction Translation and covers the mechanisms to dynamically convert between the protocols in one domain and the protocols within the other without either party necessarily being aware of the conversion. This allows objects in one domain to be represented in the other domain and the interactions can be governed by the domain of choice rather than by the domain in which the target object is implemented. For example, an object in the CORBA domain should be able to interact with a GDMO object as if it were in the CORBA domain, ideally without having to know that the target object is in a different domain. Naturally the converse is also true, that an OSI Manager should be able to manage CORBA objects as if they were defined in GDMO (this requires the reverse mapping).

The main advantage of this is that the strength of CORBA (object oriented system with wel-ldefined APIs which are aimed at standardising and simplifying the task of creating distributed applications) can be combined with the strength of CMIP (powerful protocol with strong wire compatibility allowing integration of multi-vendor hardware) to give the best of both worlds. The implementor would have an effective environment in which to implement manager or agent functionality and yet be able to easily integrate components from multiple vendors. OSI/CORBA Interoperability Scenarios illustrates the main interoperability scenarios identified for the OSI and CORBA domains. SNMP/CORBA Interoperability Scenarios illustrates those for Internet and CORBA.

Specification Translation

When translating from GDMO to IDL, trade-offs are encountered between enabling access to the full power of CMIP and generating simple IDL representations which simplify the application programmer's task. Wherever possible, these have been resolved according to the principle of keeping it simple in the most number of cases at the expense of making lesser used constructs more complex.

Interaction Translation

This is clearly a fundamental part of the work. To date, significant effort has been put in to address the content of this. At this stage, it seems that production of a gateway for a particular set of GDMO or SNMP MIB definitions is entirely feasible. The main outstanding issue is the provision of dynamic access in the CORBA domain to Management Information about these specifications, for example, for example, default values, sub-ranges not representable in IDL, behaviours, etc. This dynamic access allows more powerful and generic tools to be constructed and, in particular, a gateway that is independent of the particular object model could be constructed.

In addition, Interaction Translation must cover initialisation identifying how the gateway is initialised and populated. How it identifies the existing object population and what other service instances it may need to use. The gateway will probably interact with existing standard services in the CORBA domain, for example, OMG Name Service to resolve Distinguished Names, OMG Lifecycle Service to create new object instances and the use of OMG Event Channels for event distribution.

Interaction Translation requires that the interactions be captured by a gateway which converts them in accordance with the mapping rules. Thus, in the OSI/CORBA scenarios, the gateway must:

• receive any incoming CMIP SET/GET/ACTION request and translate it into one or more invocations to methods supported by some object(s)

• receive any event generated by an application object and translate it into an EVENT-REPORT request to be forwarded to remote systems that had register their interest in receiving events

• receive incoming method invocations and forward them as CMIP SET/GET/ACTION requests to some OSI agent

• receive CMIP EVENT-REPORT requests and forward them as CORBA events to interested parties in the CORBA domain

• receive any incoming CMIP CREATE/DELETE request and translate it into an invocation to a method being supported by an object (for example, a factory object)

• receive method invocations for creating/deleting objects in a remote system and forward a CMIP CREATE/DELETE request to some OSI agent.

This protocol conversion is complicated by such things as the need to map identifiers due to the differences between GDMO and IDL scoping and case-sensitivity, to map between GDMO Distinguished Names and CORBA Object References and to handle CMIP scoping and filtering requests which may require one CMIP request to be mapped to multiple sequences of IDL operations.

Whilst it may seem desirable to map the type ObjectInstance from CMIP (see reference CMIP), directly to CORBA Object References, this is not the correct mapping because the semantics are different. The translation maps the type ObjectInstance exactly as any other ASN.1 defined compound type would be mapped, that is, retaining the Distinguished Name format. The use of the DistinguishedName is entirely self consistent and does not require the Specification Translation process to translate ObjectInstance as a special case. Also the Interaction Translation process will require the ability to convert between ObjectInstance and CORBA Object References, so run-time facilities will exist to do the mapping for applications if necessary. These will be addressed within the the Interaction Translation document.

Usage Overview

Figure: OSI/CORBA Interoperability Scenarios

A common scenario is that a set of objects are defined in GDMO. The GDMO is statically translated via the Specification Translation algorithm in this document, into IDL interfaces. A manager implemented as a set of CORBA objects, would manage objects supported by an OSI agent as if they were CORBA objects (that is, via the generated IDL interfaces). These interfaces would be supported by a gateway supporting the Interaction Translation algorithm. This would dynamically translate IDL requests into CMIP PDUs based on the original GDMO specification. The Interaction Translation is obviously bi-directional translating CMIP PDUs originating from the Agent into the appropriate IDL requests and replies. Conversely, if the Manager is an OSI manager, it generates CMISE exactly as if the objects were supported by an OSI agent. The CMIP protocol is terminated by the gateway which dynamically translated the CMIP PDUs into IDL requests on the CORBA implemented object.

The final case illustrates the use of CMIP as an environment-specific interoperability protocol. It allows both the Manager and the Agent to be implemented in the CORBA domain and yet to offer the standard Q3 interface externally. Neither party is aware of the implementation of the other but two gateways back-to-back ensure the smooth working of the system. This is obviously less efficient than direct IDL invocation, however, it does allow use of CMIP as an environment specific interoperability protocol, which could be used in the TMN environment.

Figure: SNMP/CORBA Interoperability Scenarios

SNMP/CORBA Interoperability Scenarios illustrates a similar set of scenarios between Internet management and CORBA.

A CORBA Agent is an Agent which has its object definitions specified in CORBA IDL. A CORBA Manager is a Manager which has its object definitions defined in CORBA IDL.

Using the scenarios described in this section, a CORBA Manager may interact with OSI, SNMP, and CORBA Agents.

Futures

In addition, this gateway approach is entirely in line with the interoperability specification adopted by the OMG as part of CORBA 2.0 (see reference CORBA). The OMG is currently in the process of drafting a Request for Proposals (RFP) on CORBA-COM interoperability which is likely to require the details of specification and interaction translation necessary to enable interworking between Microsoft Windows applications and CORBA applications. This move by the OMG to standardise interworking with non-CORBA domains should be extended to cover GDMO and SNMP, so it is desirable that this document and its companions be submitted for approval through the OMG using its fast-track process.

It should be noted that future work on Interaction Translation may introduce further requirements on the translator.

Assumptions and Principles

• Completeness:
  The aim was to provide a complete mapping insofar as it was possible. Rules have been provided for all cases regardless of their frequency. In some cases, this means explicitly ignoring information, (usually this will be addressed in Interaction Translation), but all cases should be considered.

• Simplicity (The 80-20 rule):
  ASN.1 allows many constructs that are difficult to map into IDL. Many of these are not frequently used. In the light of the completeness principle, it was decided to select the simplest mapping for 80% of the cases allowing the remaining, more obscure cases, to be more complicated if necessary.

• Reuse of OMG services:
  The CORBA domain does not have a Network Management architecture; it provides a distributed processing environment. It is populated by an increasing number of Object Services such as Naming and Events which are useful building blocks. The JIDM group has tried to exploit these facilities where possible, for example, Event services are used for OSI notifications.

• Freedom of implementation:
  This document refrains from defining or constraining implementations unless it is absolutely necessary. Whilst the group discussions have naturally established the feasibility of implementation, the document does not attempt to provide hints.

Document Structure

This document is divided into several parts:

Part 1: Introduction

Part 2: ASN.1 to OMG IDL Translation Algorithm

This part of the document provides common translation rules used by both the GDMO and SNMP translation algorithms.

Part 3: GDMO to OMG IDL Translation Algorithm

This part of the document addresses the translation of OSI GDMO-based specifications into OMG IDL.

Part 4: OMG IDL to GDMO/ASN.1 Translation Algorithm

This part of the document addresses the translation of OMG IDL-based specifications into GDMO.

Part 5: SNMP to OMG IDL Translation Algorithm

This part of the document addresses the translation of SNMP-based specifications into OMG IDL.

Part 6: OMG IDL to SNMP Translation Algorithm

This part of the document is currently not provided.

Part 7: IDL Modules and Examples

This part of the document contains the standard IDL modules defined in the specification, and also provides informative examples of the application of the algorithms defined within the document. In the case of any discrepancies between the examples and the specification of the algorithms, the specification is to be regarded as definitive.

Part 8: Comparison of Object Models

This part of the document provides a comparison of the OSI, SNMP and OMG object models. It is an updated version of NMF Technical Report TR107.