Previous section.

Inter-Domain Management: Specification Translation (JIDM_ST)
Copyright © 2000 The Open Group

Introduction

Scope and Purpose

This document is the first deliverable from the Joint Inter-domain Management (JIDM) working group, an activity jointly sponsored by The Open Group and the Network Management Forum (NMF). This project was initiated in response to a perceived need to provide tools that would enable interworking between management systems based on different technologies.

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:

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 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

Specification Translation covers the process by which specifications are translated from one specification to another. It is a static process which may be required to generate additional material for use in Interaction Translation. In this document an algorithm for the static translation of GDMO specifications to and from IDL interfaces, and the static translation from SNMP MIBs to IDL only, is described. This document does not attempt to detail the generation of additional information required by Interaction Translation but does make reference to the Interaction Translation process where this may impact on the static 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

Interaction Translation covers the process by which interactions from one domain are mapped onto one or more interactions from the other domain. A gateway, the entity responsible for translating interactions, might receive a CMIP PDU and must map this into one or more requests or replies on IDL interfaces. For example, if a scoped and filtered CMIP GET request is received, the gateway would have to identify the set of objects matching the filter within the scope and invoke the appropriate operation on each of those objects. The results would be collated and formatted into one or more CMIP PDUs in reply. It is the responsibility of the Interaction Translation document to define how this kind of translation is performed.

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:

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

OSI/CORBA Interoperability Scenarios identified a use of back-to-back gateways for interoperability. This technique may be re-applied to provide multiple translations as required.

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

The algorithms have been designed using a number of guiding principles to resolve issues:

Document Structure

This document defines algorithms for translating between CORBA IDL and the OSI and SNMP notations based on GDMO and ASN.1. Translations between OSI and SNMP notations are not contained in this document as they have already been addressed by the ISO-Internet Management Co-existence (IIMC) work sponsored by the NMF.

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.


Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

Contents Next section Index