Copyright 2000 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.

This article was published in the January 2000 issue of
IEEE Communications.

CIRULE1.GIF (372 bytes)

Abstract
The increasing integration of telecommunications networks creates possibilities for interoperability among their respective management systems, using common management interfaces for CMIP, SNMP, CORBA, and Java RMI. Many Java technologies related to network management have been developed; therefore, it is desirable to create a development environment using Java technologies. In this article we explore a TMN-based management platform model and the applicable Java technologies. We demonstrate that the management platform can support certain candidate management interfaces as service components in a distributed computing environment. And lastly, we show that using Java technologies to provide network management indicates the feasibility of this management platform.

 

CIRULE2.GIF (100 bytes)


Enabling Network Management Using Java Technologies

CIRULE3.GIF (212 bytes)

Jae-Oh Lee, WarePlus Inc./Korea Telecom

 

Introduction

Due to the increasing complexity and heterogeneity of networks and services, many efforts have been made to develop distributed techniques for management. These require the integration of service software components and the management components that manage services. This integration makes use of component reusability and results in the need to support multiple interfaces among components. From the perspectives of systems and network management, major interfaces are used for Common Management Information Protocol (CMIP), Simple Network Management Protocol (SNMP), Common Object Request Broker Architecture (CORBA), and Remote Method Invocation (RMI) [1].
In the service-based age now dawning, a device- and service-driven network and data-centric model will soon replace the client-server-computing model. Devices, services, and data centers will change very rapidly under market pressure. New devices will be introduced daily, content owners will bring new streams of information, and service providers will add customized services on a daily basis. Networks and data centers will be permanently available, like phone networks today. Management systems are dynamic in nature, and therefore meet the requirements of service-driven management over heterogeneous networks and platforms [2]. CMIP and SNMP are the dominant network management protocols which have been used to exchange management messages to manage element and network resources, while object-oriented middlewares such as CORBA and RMI are considered to be valid candidates for service and business management.
Many organizations are currently developing standards for distributed management. The Telecommunications Information Network Architecture (TINA) Consortium applies the principles of open distributed processing (ODP) and Object Management Group (OMG) standards to the needs of the telecommunications industry. Also, the work of the XOJIDM group specifies the translation of Guidelines for the Definition of Managed Objects (GDMO)/ASN.1 to Interface Definition Language (IDL) to offer open systems interconnection (OSI) standards-compliant management. The TeleManagement Forum's (TMF's) SMART working group is addressing standards related specifically to service management. The Web-Based Enterprise Management (WBEM) paradigm aims at specifying a new protocol, namely Hypermedia Transport Protocol (HMTP). All of these distributed management approaches demonstrate the variety of management interfaces which are being and will be used for distributed systems management.
Java, due to its strong connection to Web-based applications, and also due to its simplicity in Internet-oriented programming, is currently very popular within the Internet community and is also supported by the majority of platforms. New graphical user interface (GUI) architectures can support a Java-based approach for service and business management. Application of the intelligent agent paradigm, which allows dynamic and remote delegation of tasks to appropriate management entities, offers a higher potential for distribution and flexibility. This enables cooperative interworking among agents for solving the problems related to network management. Therefore, the agent framework with the capability to adapt to multiple management interfaces is very important from the viewpoint of network management modeling.
Network management is an area which might involve integration of many technologies, including GUI standards, networking facilities, distributed processing, database, and object-
oriented modeling. Therefore, a network management application might well make use of the ease of programming, extensibility, object-oriented concept, and simple description of management service provided by Java. Since the number of Java-based applications for network management is increasing, there is a corresponding increase in demand for a Java-based management framework.
In this article we describe the design and implementation of a management platform based on the telecommunications management network (TMN) using Java technologies that can support a variety of management interfaces. Some candidate Java technologies for network management are briefly presented. The translation tools for management information are described. The management platform used as a core facility for network management applications is identified. A management system implemented using the management platform is explained. Finally, we summarize the article and explain considerations of future work.

Java Technologies for Network Management

Objectives for management platforms require that management interfaces be standards-based, scalable, and sufficiently robust for high-availability systems. In addition, management functions must be able to provide interoperability. The Java programming language environment provides a portable, interpreted, high-performance, object-oriented programming language, and includes a supportive runtime environment.

A Management Platform Framework Component Description

The framework of the management platform using Java technologies provides:
  • A TMN-based management framework for adaptation of higher- and lower-level management systems conforming to standard interfaces. A management system can be managed by higher-level management systems and manage lower-level management systems.
  • Integration of existing and future Java technologies.
  • Easier and simpler development of TMN-based management functions (e.g., monitoring and periodic reporting functions using multithreading technology).
We have designed the management platform using Java technologies in order to take advantage of the benefits mentioned above. Network management system developers can make use of Java technology to easily write light network management applications that fully support multiple management interfaces using the simple Java object model. In general, the management platform is divided into:
  • Management protocols
  • Management protocol mapping
  • The management factory
  • The management information tree (MIT) handling function
  • Management functions/services
Each of the above sections of the management platform is described below and depicted visually in Fig. 1. In addition, the directory and database services can be added to the management platform.

Management Protocols

Management protocols provide an operation interface and a notification/trap interface. The operation interface is used to perform management operations to a remote agent and to manipulate a remote or local database. The notification/trap interface is used to receive events from a remote agent and store them into a local or remote database.

Protocol Mapping

Protocol mappings among different management interfaces are accomplished through the above-mentioned interfaces. In particular, the CMIP Java object, a newly developed CMIP Java interface, includes the service primitives for the basic management messages defined in CMIP and supports the ability to create associations among management entities. Protocol mappings are invoked from management service and management information mappings. Absorbing the differences of management information models requires management information mappings. A management protocol of management system can be mapped into one or more management protocol(s) of another management system. For instance, a CMIP operation (e.g., create operation) can be mapped into several SNMP operations (e.g., a set of set operations), caused by differences in service primitives and information models.

The Management Factory

The management factory is used by management applications to perform management operations (e.g., create, delete, get, action, event-report) on the MIT. Therefore, the management factory must maintain the characteristic information of managed object classes and check the validity of management operations. Also, the management factory can receive the management messages sent from other management systems.

The Management Information Tree

The MIT is used to supply an abstract representation of physical/logical resources that indicate management information used in the management domain. Each managed object class instance (MOCI) is maintained in the MIT. The maintenance facility of the MIT provides create, delete, set attribute, get attribute, search, object identifier conversion, and similar operations.

Management Functions and Services

Management functions and services consist of management components that are closely related to fault, configuration, account, performance, and security (FCAPS). A management service is associated with multiple management functions. Figure 1 shows management platform components and some candidate Java technologies.

Candidate Java Technologies

Since Java is robust, secure, easy to use, easy to understand, and automatically downloadable on a network, it is an excellent language for the development of a variety of applications. The Java programming language has evolved to provide not only better portability, but also improved productivity. While Java was initially used primarily for user presentation components, it is now being used in a wide variety of applications. From the development process and environment point of view, the impact of introducing Java will have to be taken into account at all process levels. Java enables developers of protocol-independent network management systems to implement simple management applications and manipulate them in a dynamic way. In this section we describe some candidate Java technologies which are applicable to the management platform.

Object Serialization

The capability to store and retrieve Java objects is essential to building all but the most transient applications. The key to storing and retrieving objects is representing the state of objects in a serialized form sufficient to reconstruct them. Objects to be saved in the stream may support either the serializable or externalizable interface. Object serialization may be extended to support persistence of Java objects. For the purposes of network management, persistence can be used for storing management information and interfacing between the management system and the GUI. All message objects must support object serialization [3].

Java Dynamic Management Kit and Java Management Extensions

Experimentation with the Java Dynamic Management Kit (JDMK) [4] has demonstrated that this specification defines standard ways to make Java technology-based platforms, applications, or devices manageable, and introduces Java technology-based dynamic management for the service age. Java Management Extensions (JMX) [2] provides a set of standard application programming interfaces (APIs) at the instrumentation and agent services levels, as well as APIs to facilitate integration with existing SNMP or Web-based systems. Future releases will add new APIs for Java platform manageability and other management technologies. JDMK is Sun's commercial implementation of the instrumentation and agent services specifications; it is the Java-based solution for building and distributing management intelligence into network devices. Key features of JDMK include autonomous agents, push/pull technology, master agent functionality, multiprotocol support, and integration of SNMP, RMI, CORBA, HTML, and Hypertext Transfer Protocol (HTTP).

The Java Naming and Directory Interface

The Java Naming and Directory Interface (JNDI) provides a directory service API that is not only independent of the particular directory or naming service implementation, but also enables seamless access to directory objects through multiple naming facilities. Directory services play a vital role in intranets and internets by providing access to a variety of information about users, networks, services, and applications. JNDI can provide a variety of existing naming and directory services such as Domain Name Service (DNS), Novell Directory Services (NDS), Network Information Service (NIS) (YP), and X.500, and emerging ones such as Lightweight Directory Access Protocol (LDAP). Use of LDAP would allow a directory-enabled MIT.

Remote Method Invocation

RMI [1] enables the programmer to create distributed Java-to-Java applications, in which the methods of remote Java objects can be invoked from other Java virtual machines, possibly on different hosts. The distributed system interfaces can be designed in Java, and clients and servers can be implemented using those interfaces. Management applications with this mechanism can be in the service and business areas.

Java Data Base Connectivity

Java Data Base Connectivity (JDBC) [5] allows programmers to write to a single database interface, enables database management system (DBMS)-independent Java application development tools and products, and allows database connectivity vendors to provide a variety of different connectivity solutions.

Java Servlets

Servlets [6] are protocol- and platform-independent server-side components, written in Java, which dynamically extend Java-enabled servers. They provide a general framework for services built using the request-response paradigm. They can also be deployed in the Web using the Java bindings by providing servlet classes.

Java Beans

A Java Bean is a reusable software component that can be manipulated visually by means of a builder tool. The builder tool may include Web page builders, visual application builders, GUI layout builders, or even server application builders. Beans are appropriate for software components that can be visually manipulated and customized to achieve some effect. For example, alarm-reporting functions can be defined using the Java Bean event feature [7]. A Java class supporting the manager system can be dynamically configured to manage the different agent systems, which have their own specific management information, interfaces and management services. Connecting managed object beans and service beans together in a visual application development environment can be used to rapidly develop management applications.

The Java Native Interface

The Java Native Interface (JNI) [8] is a native programming interface. It allows Java code that runs inside a Java Virtual Machine (VM) to interoperate with applications and libraries written in other programming languages, such as C, C++, and assembly. Using native function calls, a device-specific access method can be created by the developer.

Java Interface Definition Language

Java IDL [9] lets the developer create distributed Web-enabled Java applications that can transparently invoke operations on remote network services using the industry-standard IDL and Internet Inter-ORB Protocol (IIOP) defined by the OMG. The idltojava stub generator produces ORB-independent stubs which call into ORB-specific protocol modules for all data marshaling or other ORB-specific operations.
The relationships between management components and some major candidate Java technologies are described in Table 1.
Using various Java technologies, we have added some software components for developing the TMN-based management platform. These are: the translation of GDMO/ASN.1 to Java objects; the CMIP Java object; the management factory; and the MIT Java object. These are the main software components used to construct the TMN-based manager and agent systems.

GDMO/ASN.1 Java Management Objects

The adoption of an object-oriented approach to model management information reduces the design of a managed object component (MOC) to an ad hoc composition of basic modules. These modules are defined in the GDMO specification of the MOC. In this way, it is also possible to reuse modules as attributes in different classes, thus reducing the amount of code to be written for each MOC, and also making the integration of different modules easier. Defining an API for each basic piece, which in Java is a set of attributes and methods, allows modules to be integrated from the Java development kit. The GDMO/ASN.1 translators are used to define the Java objects needed to implement the MOC and the transfer syntax [10, 11]. They are classified into "ASN.1 To Java Object (A2J)" and "GDMO To Java Object (G2J)." Figure 2 shows the process flow of translation tools and the generated files to be compiled by the Java compiler.
A2J compiles ASN.1 modules into Java objects. The generated Java code contains equivalent objects and core routines to convert values between the internal (Java) representation and the corresponding Basic Encoding Rules (BERs) format. G2J also produces the Java objects from the GDMO templates, which have their own defined Java objects imported from ASN.1 Java objects and their inheritance relationships. The number of Java objects is equal to the number of GDMO templates. The automatic creation of Java objects from the documents described by GDMO/ASN.1 as input files is necessary to create the association of management information with the management factory and application.
All ASN.1 Java objects are divided into an aggregate Java object (e.g., SEQUENCE, SET, CHOICE) and a nonaggregate Java object (e.g., INTEGER, OCTETSTRING, OBJECT IDENTIFIER), each having its constructors and methods. The Value Java object defines the static variables such as object identifiers and integers. In addition, ANY objects and ANY DEFINED BY objects and buffer management are defined. Unlike the objects generated for some of the aggregate objects, the data members of the nonaggregate objects are typically protected and accessed via methods. Each ASN.1 Java object has some protected data members, constructors, and methods. The basic methods perform assignment, encoding, decoding, and printing facilities. Each CHOICE type generates a Java object that has an anonymous union to hold the components of the CHOICE and a choice identifier field to indicate which component is present. Table 2 describes the declaration of Java object for a CMIP M-CREATE message generated from CMIP ASN.1 by the support of A2J and defined in the CMIP Java object.
A GDMO class template is the base of the formal definition of a managed object. In GDMO, the key construct used to define the structure and behavior of the MOCs is the MOC template. This template identifies the inheritance relationship, the contained packages behavior, and the attributes, notifications, and operation allowed in the MOC. The package template is a combination of behavior definitions, attributes, attributes groups, operations, notifications, and parameters. The semantics of the various components of a MOC is distinguished from its corresponding format. The parameter template qualifies and further defines the structures in the syntax of attributes, action requests/responses, and notifications. The basic operations on the attributes of GDMO definition are defined as user-defined methods by defining their constructor. The containment relationship among MOCs is represented as a name-bind object. The attribute syntax is defined by ASN.1, which provides a wide variety of types ranging from simple bit strings to complex structures. G2J produces the Java object code that represents the MOC to be accessed by the user in order to define behavior-dependent functionality. The methods of GDMO Java objects also provide access to the associations and relationships a MOC may have with other MOCs. They are used to support JDBC-based operations on the management information, which are maintained persistently in the database. When connecting to the database, each MOC has its own basic methods such as "connection with database server," "query operation," "connection close" (i.e., normal or abnormal), and so on. MOCs for accessing databases (i.e., in the current Mini Standard Query Language, MSQL, database) are imported from the MSQL Java object. The MSQL object class provides methods to perform manipulation of the database, such as Create, Drop, Insert, Delete, and Select. Table 3 shows an MOC template written in the Java language and a logRecord MOC generated by the G2J translator.

The Management Platform Framework and the MIT

A management platform supporting multiple management interfaces is described in this section. The presumed interfaces are used for SNMP, CMIP, CORBA, and RMI. CMIP and SNMP have been predominantly used as management communication interfaces and are directly adaptable to this platform. For the adaptation of CORBA-based management systems, the translation between IDL and Java can be used for the definition of the management interface and information. This allows a Java server to define objects that can be transparently invoked from remote CORBA clients. The RMI system also provides the capability to remotely invoke methods; this enables the development of distributed applications. Applications can execute and communicate, so they can run in parallel across multiple systems connected via a network. However, the Java objects of management protocols and managed object definitions for CORBA and RMI need standardization. At present, we assume that management protocols and managed object definitions for CORBA and RMI focus on a TMN-based model.
In order to follow the TMN architecture, it is very desirable to design the framework of the management platform using Java technologies which focus on the CMIP-based management interface and information model. This approach can therefore easily be embedded in a standards-conformant network and service management environment. TMN systems have three major requirements: extensibility, flexibility, and openness. According to the M3010 standard, TMN focuses on object- oriented information technology, distribution of applications, and standard interfaces.

The Management Platform Framework

Figure 3 shows the framework of the management platform.
As depicted in the figure, the management system performs basic functions such as receiving and responding to management operations, sending of alarms, sending of performance data via management interfaces and providing management services via internal management operations such as create, delete, get, set, and action. Management services can be represented as Java thread objects and can be implemented by the manipulation of MOCI in the MIT via management interfaces, either remotely or locally. Remote monitoring can be polling-based, as is the case with SNMP-based systems, or event-driven. TMN management encourages an event-driven paradigm through facilities such as object management, metric monitoring, and summarization. In general, object management provides object creation, deletion, and attribute value change notifications. Each MIT node must have service interfaces to access the service points provided by management interface mapping modules. Priority control is needed for system and performance tuning. This is easily accomplished by controlling the priority of every thread object.
The management system may require configuration updates to control and alter the way in which it behaves or performs. Often, there is a requirement for more than one system to receive this configuration information and to ensure that updates are performed automatically across all those systems. Some intelligence -- for example, the determination of virtual path (VP) and virtual channel (VC) identifiers -- is required and may be extended to support enhanced functions by exchanging management messages with other management systems and/or other intelligent systems.
Each MOCI can access the management system via multiple management interfaces. In general, the processing capability of the system depends on the complexities of time and memory for processing information.

The Management Information Tree Node

We have designed and implemented a data structure for the MIT node. Figure 4 shows the structure of an example MIT.
Each node is composed of the MOC name in a string format and the relative distinguished name (RDN) level for unique identification. In addition, it has a list of information about the MOCIs. It has a linked list structure in a node. Each list consists of distinguished name, instance identifier, parent instance identifier, right instance, a set of attributes, and next instance. This node information is the basic information applied to the management operations of create, delete, set, get, cancel-get, and action. Some of them can have their own scope and filter fields. Here, we must consider some key parameters for determining the processing capabilities required to carry out management operations involving other management systems. These are:
  • The encoding/decoding time of management messages
  • The search time of the MIT
  • The construction/deconstruction time of the MOCI
  • The processing time for accessing the database
  • The response time from real resources or adaptable management interfaces
Traversing of the MIT for each management operation is done in pre-order method and starts at the root node of the MIT. The containment relationship of the MIT is used for the naming service, which can be accomplished using JNDI.

The Management System

Distributed management generally leads to a hierarchical and/or federated organization in which each entity interacts to achieve the global task of management. From the perspectives of management roles, a management system might be represented as both the agent role for providing interfaces (e.g., RMI, CORBA) which higher-level management systems can access, and the manager role for providing interfaces (e.g., CMIS, SNMP interface) which lower-level management systems provide. Groups based on the topological, administrative, functional criteria, security, or other technical considerations managing resources in specific domains organize their management systems. The management network is organized hierarchically, but the federated organization can be mixed. The hierarchical organization is based on the manager-to- agent relationship, and the federated organization is used when cooperation among agents is needed. In this management system, generic functions for performance monitoring, load monitoring, and configuration management on asynchronous transfer mode (ATM) networks are fully provided. Also, we have developed a Q-Adapter system. This system performs mediation functions for the CMIP-based manager system as a higher-level management system and the SNMP-based agent system (i.e., ForeRunner ASX) as a lower-level management system. When the agent receives CMIP messages from the CMIP-based manager, it operates on the ATM switch via the SNMP interface and maintains management information as the MIT. Also, alarm trap messages are converted to CMIP event report messages (e.g., communication alarm, equipment alarm, environmental alarm, processing alarm) via protocol mapping; these are forwarded to the registered destinations. Figure 5 indicates a simple CMIP-based manager system supplied from the management platform.
This manager can interact with the agent system to exchange CMIP message after creating CMIP associations between two management entities that negotiate their contexts. The context parameter contains protocol-related information. In the case of CMIP, it contains the agent's AE-Title, whereas for SNMP it contains the IP address of the agent system. The major management functions are facility management, connection management, performance data collection/ control, access control mechanism, and so on. The services of the agent system are determined from its capability. In particular, the agent has some VP/VC connection management as a basic facility for virtual private network service. The GUI of manager is constructed using Java Foundation Classes (JFC) and performs management operations based on the requirements of TMN.

Conclusions

Nowadays the telecommunications market is characterized by fast-evolving technology, a multiplicity of providers, and the need for value-added (e.g., multimedia) services. Such trends promote rapid introduction of new and enhanced services and their management. Telecommunications services requirements for reusability, rapid provisioning, interoperability, reduced service interaction management, and distribution must be met. Because Java provides simplicity, an object-oriented approach, reliability, portability, and multithreading, Java-based distributed object computing has become increasingly popular as more complex products are written using a multitier architecture. Since many Java-based applications for network management have been developed, it is desirable to create the management platform using Java technologies. For these reasons, we have developed a management platform using Java technologies which meets the network management requirements of the next generation. In the future, we will enhance the functionality of the management platform by integrating existing and new Java technologies.

References
[1] Sun Microsystems, Java Remote Method Invocation Specification, 1996.
[2] Sun Microsystems, JMX: Java Management Extensions, First Public Specification, v. 1.9, 1999.
[3] Sun Microsystems, Object Serialization Specification, 1997.
[4] Sun Microsystems, JDMK: Java Dynamic Management Kit, 1998.
[5] Sun Microsystems, JDBC: A Java SQL API, 1997.
[6] Sun Microsystems, Java Servlet API Specification, 1998.
[7] Sun Microsystems, JavaBeans, 1997.
[8] Sun Microsystems, JNI: Java Native Interface Specification, 1997.
[9] Sun Microsystems, Java IDL, 1997.
[10] ITU-T Rec. X.722, "Structure of Management Information: Guidelines for the Definition of Managed Objects (GDMO)."
[11] ITU-T Rec. X.208, ISO/IEC 8824, "Specification of Abstract Syntax Notation One (ASN.1)."

Additional Reading
[1] Sun Microsystems, The Java Language Environment, 1996.
[2] Sun Microsystems, JNDI: Java Naming and Directory Interface, 1997.

Biographies
Jae-Oh Lee received his Ph.D. degree in computer science from Kwangwoon University, Seoul, Korea, in 1993. He has been a senior member of Korea Telecom and is a technical manager at WarePlus Inc., a venture company sponsored by Korea Telecom. His primary research interests are systems and network management platforms, software component technology, agent-based management, and object-oriented distributed computing technology.