Introduction

Reference Model

In order to be able to interwork between a particular pair of management reference models, there are two aspects that need to be defined:

• A translation scheme between the different object models of both management reference models. This is referred to as Specification Translation.

• A dynamic conversion mechanism between the protocols and behaviours used in both domains. This is referred to as Interaction Translation.

This allows objects in one domain to be represented in the other domain, and the interactions are governed by the domain of choice rather than by the domain in which the target object is implemented. In addition, this is achieved done without either party being aware of the conversion.

This document presents a set of facilities to provide interoperability between CORBA and alternative telecommunication management models, specifically OSI management and Internet management. As described above, two aspects need to be defined: Specification Translation and Interaction Translation

Specification Translation

The definitions in this Interactive Translation Book 2 fully support the associated Specification Translation Book 1.

Interaction Translation

There are three levels of interfaces being defined:

• Generic interfaces, management model independent
  These facilities provide a generic framework to access a managed domain, independently of the management reference model being used. These generic facilities are referred to as JIDM Facilities, and are described in JIDM Facilities.

• Generic interfaces, management model specific
  Two management reference models are considered - OSI Management, and Internet Management (SNMP):

  • OSI Management Facilities, presented in OSI Management Facilities, provide a CORBA view of the OSI Management reference model, as described in the relevant ITU-T and ISO documents (see, among others, references X720 and M3010). This set of facilities extends the generic JIDM Facilities to support all CMIS interactions in CORBA, and to support OSI specific concepts such us scoping, filtering and multiple replies both in pure CORBA environments and in interworking environments (gateways).

  • SNMP Management Facilities, presented in SNMP Management Facilities, provide a CORBA view of the Internet Management reference model. This set of facilities also extend the generic JIDM Facilities to support all SNMP interactions in CORBA, and to support Internet specific concepts.

• Specific interfaces, information model and management model dependent
  These interfaces provide functionality that is specific to a given information model, that conforms to a certain management reference model. These interfaces reuse and extend the generic CORBA facilities of the corresponding management reference model (OSI Management or SNMP Management facilities) in an information model-specific way. In case the specific information model is specified in a foreign specification language (GDMO/ASN.1 for OSI management, SNMP SMI for Internet management), the equivalent CORBA IDL model may be automatically generated by following the translation algorithms defined in reference JIDM_ST. Note that it is possible to specify an information model directly using CORBA IDL, and yet reuse the OSI management or SNMP management facilities.

  It is beyond the scope of this Interaction Translation specification to specify any information model-specific interfaces. However, the mechanisms to specify such interfaces, as well as a generic set of algorithms to translate existing information models, are specified.

There is a dependency between these three types of interfaces, as shown in JIDM Facilities.

Basic Concepts

A distributed management system is composed of two kinds of entities: manager entities and managed entities.

Manager entities are those that have responsibility for one or more management activities, by issuing management operations and receiving notifications. They are the components exploiting the behaviour provided by implementations of a given information model.

Managed entities are those that have responsibility for certain underlying resource(s). They perform management operations issued by manager entities on the underlying resources, and emit notifications whenever some specific circumstances occur. They are the components implementing the behaviour of a given information model.

In object oriented systems, these abstract entities are materialized in the form of specific objects. Therefore the terms manager object and managed object can be considered synonymous of the above in object oriented systems.

Manager objects (entities) are said to act in the manager role, while managed objects (entities) are said to act in the agent role.

These objects (entities) are grouped into domains, according to some specific grouping criteria. Domains are considered the unit of accessibility, therefore being the independently addressable components within a distributed system; each domain (both manager and managed) may have any number of objects within it.

Managed domains are sometimes referred to as agents and managed object domains, while manager domains are sometimes referred to as manager applications or simply managers.

Domains are identified by using titles. Each domain may have an arbitrary number of titles associated with it, but a title uniquely identifies one domain.

Whenever a manager or an agent needs to interact with an agent or manager (respectively), it must first gain access to the other domain. This access is always granted though an specific port to the domain. Each port is uniquely identified by one of the titles associated to the domain being accessed.

Specifically, two types of ports are identified:

• When access to a domain is required in order to be able to create and/or invoke operations on managed objects within the domain, the port is called domain port.

• When access to a domain is required in order to be able to forward events to manager objects within the domain, the port is called event port.

When a manager (agent) gains access to a managed object domain (manager domain), it is said that a session has been established. That session may be released, meaning that no further exchange of information may happen, because access has been revoked.

Any number of sessions may exist between a manager and an agent at any given time.

Design Objectives

Invoking Operations on Managed Objects

• Create a new member of the domain (a new managed object) and assign a name to it.

• Obtain a reference to a member of the domain (an existing managed object) given its name.

• Operate on collections of those members of the domain which meet some criteria (for example, descendants of some managed object which pass some specific filter, etc.).

A complete solution requires explaining how these CORBA Facilities will interact with Naming and LifeCycle Object Services at CORBA Managed Object Domains. These questions are represented in Invocation of Management Operations.

A fundamental requirement for definition of such CORBA Facilities is that the specific management protocol (CMIP, SNMP, CORBA IIOP, etc.) being used to get access to a Managed Object Domain and operate upon managed objects located there, must be totally transparent to CORBA manager objects and CORBA managed objects.

Event reporting

• Events reports emitted by CORBA managed objects to be reported to specific CORBA Managers that have been designated by their titles.

• CORBA Manager objects to be notified about events reported from remote Managed Object Domains.

A fundamental requirement for definition of such CORBA Facilities is that the specific management protocol (CMIP, SNMP, CORBA IIOP, etc.) being used to report an event must be totally transparent to CORBA manager objects and CORBA managed objects.

When solving the problem of event reporting, the following scenarios must be considered:

• One manager application must be able to change the list of destinations (titles) to which event reports emitted by managed objects in a managed object domain are being reported. In the OSI environment, this will be accomplished by means of changing the destination attribute value of an EFD object that is member of the managed object domain being considered.

• One manager application may spontaneously start receiving event reports from a remote managed object domain due to a decision taken by a third party (another manager application) who has changed the list of destinations for event reports associated to the managed object domain.