[INET'99] [ Up ][Prev][Next]

Mobile Components to Manage the Heterogeneous Internet

M. KONETY <mkonety@hcitech.com>
HCI Technologies

R. DEV <rdev@lucent.com>
Lucent Technologies

D. PRABHAKAR <dprabhakar@hcitech.com>
HCI Technologies

I. R. CHEN <irchen@vt.edu>
S. GUPTA <sgupta@vt.edu>
Virginia Polytechnic Institute and State University


The Internet is a complex combination of devices, protocols, and technologies that poses a challenge in network management. This work investigates a new approach to internetworking management with the application of mobile components. We provide a novel approach that represents a significant shift in addressing network management issues from traditional systems. The work provides a functional decomposition of network management functionality and maps the independent functions onto process components. This process provides a platform-independent framework that can be applied to a myriad set of devices that now make up the Internet. We demonstrate the feasibility of our approach with a fault management application.


1. Introduction

Computer networking is an area of tremendous growth with the emergence of the Internet and the World Wide Web. Estimates of network growth have proven to be conservative compared with the actual growth rate. This spurt has also led to several new requirements and services from networks and their infrastructures. To address these requirements, several new areas of research and innovations are in progress. This has led to the creation of heterogeneous networks with a variety of devices, protocols, and technologies, and managing these networks is now a challenge.

A network is a combination of devices and communications channels that follow a set of protocols and provide connectivity. Typically a network consists of several end nodes connected through channels/links via intermediate network devices. These network nodes provide various functionality such as routing, translation between different network protocols, and maintenance of connectivity between different physical networks. Network management is the process of maintaining and administering the network, including its intermediate nodes and links [8]. Some of the functions include identifying the components of the network, ensuring the effective functioning of the network, modifying/enhancing the network, and providing security for the network.

These functional areas identify the overall requirements of a network management system (NMS). An NMS is a collection of processes, user interfaces, policies, and procedures for providing these functionalities. Currently, there are several approaches to network management, such as the simple network management protocol (SNMP) [6], the OSI common management information protocol (CMIP) [7] in data networking, and the telecommunications management network (TMN) framework [12] in the telephony area. These approaches use the manager-agent technology, similar to a client-server system where the processing is distributed between a manager and one or more agents that interact with the manager. The devices or resources to be managed are termed managed objects. Agents may be allocated close to these managed objects and report to a manager over the network.

Functionality distribution in current network management techniques is addressed by enhancing the capabilities of the agents or by introducing new managers at intermediate points [3]. The use of multiple managers in either a peer-to-peer or a hierarchical architecture is not scalable beyond a threshold. With the advent of new technologies, network nodes have become powerful enough to not only participate as communication devices but also perform computations [13]. Dynamic and flexible management is a key issue. Management can now be moved to be near a problem managed object rather than across the network. Traditional manager-agent frameworks cannot be easily extended because of the concentration of functionality at specific points. Any new model would be rendered useless if it requires the overhaul and replacement of existing infrastructures.

In this work we identify the specific needs in the management of complex networks in the Internet. On the basis of these needs we develop a management framework using mobile components and existing management technologies. We propose a model where the NMS is functionally decomposed into fine atomic functions that are represented as components. These components build on implementation-specific services such as communication protocols and data handling. This leads to a simple scheme for functionality distribution independent of the underlying technologies. The components can be moved to the managed devices and also be dynamically reconfigured. By separating the supporting technologies from the management functionality, we isolate the implementation schemes. Doing so provides us with the flexibility of incorporating the model into existing management platforms.

In the next section we highlight some of the popular efforts for network management. In section 3 we describe our mobile component model. Section 4 provides applications of the model including a specific application toward fault management. Section 5 summarizes the work and provides insight into some possible future research areas.

2. Network management models

A typical network management model consists of several elemental managers that manage a well-defined subset of the enterprise [3]. Elemental management systems in turn describe a manager/agent model that consists of various components including a user interface, a map of the resources being managed, a protocol for querying the state of the managed resources, and a database management system that stores historical and real-time information. The manager/agent model gives rise to three different architecture configurations:

A novel approach to network management has been proposed in [9]. This approach uses a combination of management delegation and extensible agent technology. Delegation involves the transfer of management functionality to an agent that is extensible, or in other words, able to dynamically incorporate new functions/services if needed. The most striking advantage of this approach is its ability to deploy management solutions to where the data reside. This is in direct contrast to traditional models where data must be extracted first and then a decision is made. One disadvantage of this approach is that the environment must support the extensible agent infrastructure. Second, there is always a need to correlate information across agents, which necessitates the use of a central manager to access information across agents.

A comprehensive survey on approaches to network management based on active networking appears in Tennenhouse et al. 1997 [2]. Active networking is a new paradigm where network nodes can process not only data packets for normal data communication, but also active packets for executing embedded programs.

In the "smart packet" approach [11], a program is fully contained by a sequence of active packets. These packets are received by an active node; the embedded program is executed; and then a return value is generated and sent back to the sender. In this paradigm, a manager can send programs to nodes near a problem area to perform localized management functions. A program can also be extended to include schemes to enable problem fixes, thus providing a more self-enabled management system with little intervention. The smart packet approach thus leads the management to the affected areas. It also provides a practical scheme by the use of small-sized programs (less than 1 Kbyte). A drawback of this approach, however, is that the state information on active nodes is not saved between executions. Thus, persistent or recurrent problems may not be solved efficiently. It also incurs some overhead in assimilating information in every execution. Moreover, it does not address the issue of managing distinct devices and networks. In Raz and Shavitt [1], applications of active networking to network management are described. The idea is to distribute and migrate program segments using active packets. However, no specific management problem is given as an illustration, and the issue of heterogeneous network management is not explored.

3. Component model

An NMS usually provides one or more core functions such as fault, configuration, accounting, performance, and security (FCAPS) management functions. To realize such a system, a set of base modules not part of the core NM functions is required. These base modules provide certain basic operating system, networking, and data processing functionality to support the core FCAPS management functions. A typical set of base modules includes Mediation, Data Handler (for Data Storage and Retrieval), Security, and User Interface. These modules are implementation specific and could vary from one system to another. Examples include the use of text files to store management information base (MIB) records in SNMP, use of a relational database system for data storage, use of the SNMP protocol as the communication protocol, and so on. Functionally, the structure of the NMS can be divided into two layers. The low layer includes essential base modules while the high layer are network management functions (NMFs) implemented using services provided by the lower-layer base modules. By separating the two layers and specifying interfaces between them, the NMS functionality can be distributed independent of the base modules. Figure 1 illustrates the relationship between the lower-layer base modules and the high-level core NMS functions.

Figure 1: NM Core Functions and Base Modules.

NMF decomposition to components

Functional components in our scheme are generated as a result of "functional decomposition" which involves recursively dividing the system's overall functionality to obtain smaller functions. This technique can be used to generate a functional tree that explicitly defines the relationship among the system's function sets. Applying this technique to the NMF, we can derive an independent function set that can be individually implemented so as to provide the required functionality independent of the managed devices and technologies. Later in section 4, we will show how to perform such a functional decomposition by constructing a functional tree in which the NMF is decomposed into smaller functional components called network management components (NMCs).

Message flow

An NMC acts on an active packet based on management policies associated with network devices. It generates an output to the next component based on the control information embedded in the active packet. Thus, the incoming or outgoing packet carries no source or target information. This enables us to easily define a policy and control decision without affecting or changing the implementation details of components. The system performs core network management functions by referring components to a set of policies stored in data handler module and also by embedding control information in active packets.


A NMS policy characterizes the behavior of a class of network devices and provides a way for the system's functional components to retain their generality. Policies determine not only what to manage but also how to manage. An example policy could be a threshold for the number of packets on a link that can drop before the link is considered faulty. Policies, like functions in the system, are decomposed in a hierarchical manner for optimal operation.

Component and service

An object-oriented approach for representing functional components is to define a component as a class, with its methods mapping to management functions and its properties mapping to policies (kept at the data handler module). The NMS can now be visualized as a complete set of components, where each functional area is represented by a set of unique components. For example, the functional decomposition for fault management can be represented as Oas = {Oas1, Oas2, Oas3, Oas4} with the four components in the set mapping to alarm detection, alarm logging, alarm reporting, and alarm correlation functions, respectively.

An aggregation of components can implement a service based on the requirements of the NMS. One way to provide a service is to use a container for components on a particular node. A component is unique across a functional area but it does not have to translate into unique services. Services could have overlapping components. A practical example of this would be two separate services running on two nodes having a common alarm surveillance component.


An essential part of the component architecture is the need to provide distributed control services responsible for (a) maintaining the functionality of different components; (b) ensuring the communication between them; (c) handling the distribution and load balancing issues; and (d) administering the various support services. An important task performed by such distributed control is to distribute sufficiently replicated components in the network. We will address this aspect in a separate paper. Briefly, the components are initially allocated to the nodes based on some initial placement algorithm. A control service module running on a node exchanges run-time load information with others and, based on this information, dynamically reallocates components running on the local or a remote node. This readjustment decision is controlled by a runtime readjustment algorithm with a goal to meet response-time requirements with respect to real-time events.

4. Application

A prevalent issue in the network management area is the need to manage heterogeneous networks with a diverse set of devices, protocols, and networking technologies. A common situation is the management of both circuit switched telephony networks and virtual circuit data networks. The internetworking between these two different types of networks is frequent and the status of one affects the other. Most solutions involve using separate management systems and also a manual or automated correlation scheme for information exchange between these two networks. This traditional NMS is illustrated in figure 2.

Figure 2: Traditional Heterogeneous Management.

We provide a new approach based on the component model described in section 3. The goal is to provide functional components to perform alarm surveillance for both IP-based routers and circuit switched telephony network devices (switches). The management functionality required by these two distinct networks is similar but the data format, management policies, and operating schemes of the two systems differ greatly. According to our component-based scheme, we propose a solution for managing heterogeneous devices in these two distinct networks with the following features:

Base modules

The first step in designing the system is the separation of the base modules from the core functionality. The primary base module is the mediation module for providing a common interface to support all device communication protocols. One significant difference in the two managed devices is the scheme used to communicate with them. The IP router would use user datagram protocol (UDP)-based SNMP for exchanging management information, while the circuit switched device would use a proprietary protocol or X.25-based protocols. To handle these issues, two mediation modules are required. The first module provides an interface to the IP router device, while the second interfaces with the telephony switch.

Another important base module is the data-handler module to allow the system to operate on a large amount of data and to distribute the data to functional components. The data handler module provides an interface to allow data to be accessed in a location-transparent manner; that is, the data can be stored locally or in a central repository. The management system uses the data handler interface to access the database without being aware of its detailed implementation or its location.

Communication and messaging

A simple communication bus scheme is used to provide an interface to all the modules and components. The communication bus is based on the object management group CORBA 2.0 [15] specification and provides a seamless interface between all the components and modules. The goal of the bus is to abstract the diverse interfaces, communication methodologies, and protocols between the various components.

The bus is used to exchange information between the various components with the information being formulated as messages based on the CMF format. The CMF is designed to provide a general communication scheme between the base modules, the management components, and the controller. The CMF field provides a platform- and implementation-independent representation of the messages. The message format for communication between the various components is essential in the mobile distributed system. The CMF message format as shown in figure 3 has a message header containing information about the component generating the message as well as a message body containing information about managed objects and events received. A special message type is used to exchange control and administrative information between the modules and components.

Figure 3: The Common Message Format

The Type field in the message header, in addition to defining the message type, also links a message to its destination component. Each component in the system subscribes to a set of message types. A message will be routed to those components that subscribe to its message type via the communication bus and control module. The Source field in the message header identifies the unique component id/node pair from which the message originates. The CTimeTicks field holds the time at which the message was generated with a representation in time ticks. In the message body part, the information about managed objects embedded in the message is in the form of (MOID: MO type:MO time ticks: value) for each managed object. The MOID field is the identification of a managed object from the MIB, and the value field holds a specific or current value of the object. In case a message is used to control information exchange between components, the value field is set to 0.

Functional decomposition

Here we show how the alarm surveillance network management function can be decomposed by means of a functional tree based on the ITU-T (International Telecommunications Union Telecommunications) TMN framework [12], as shown in figure 4. The first-level decomposition yields the five FCAPS management functions, of which the fault management function is further decomposed at the second level into quality assurance, alarm surveillance, fault localization, fault correction, testing, and trouble administration. The third level of decomposition out of the alarm surveillance function yields the function set at the bottom level in figure 4.

Table 1: TMN-Based Functional Decomposition
First-Level Decomposition Second-Level Decomposition Third-Level Decomposition

Fnm = {Ff, Fc, Fa, Fp, Fs}
Ff = Fault management functions
Fc = Configuration management functions
Fa = Accounting management functions
Fp = Performance management functions
Fs = Security management functions

Ff = {fas, ffi, ffc ... }
fas = Alarm Surveillance function set
ffi = Fault Isolation function set
ffc = Fault Correction function set

fas = { fas1, fas2, fas3, fas4}
fas1 = Alarm Detection
fas2 = Logging
fas3 = Alarm Reporting
fas4 = Alarm Correlation

Table 1 is derived from figure 4 to show that after a functional decomposition, a fully decomposed set for the surveillance function can be represented as Fnm= { fas1, fas2, fas3, fas4, ...} where each functional component in the set has a corresponding leaf node in the functional tree, as illustrated in figure 4.


Management policies are stored in the database system maintained by the data handler module. A management policy is specifically defined for a particular class of devices. This provides flexibility in enhancing the system to manage new device types by adding new management policies. After we identify the functional set for the alarm surveillance function via a functional tree as shown in figure 4 and table 1, we deal with the two heterogeneous device types by defining a set of policies that specify the attributes to be managed.

We use the platform-independent DMO representation to describe the device to be managed and the characteristics of the device that are of significance to the management system. The DMO for an object is implemented using the abstract syntax notation version 1 in the form of a MIB. The first step in defining the DMO is the identification of the objects considered important in the management of the device class. These objects are then collated, and a MIB record is generated to represent the information. MIB records are either implementations of existing standards or derived from them to provide a complete representation of the managed device. MIB records contain managed objects which represent various attributes of the devices. A single MIB is a representation of a class of devices, and each device managed by the system has an instance of the MIB instantiated for information storage and representation. An example for the representation of DMO is the use of a subset of MIB-II information to manage IP (Internet protocol) devices and a similar derived set of objects for the telephony switches. The MIB definitions are stored as part of the entire system database within the data handler module. An instance of the MIB is maintained by the data handler module for every device managed by the system.

Figure 4: Alarm Surveillance Functional Tree

We then use the DoOM format to specify the functional attributes specific to a device. Then, management policies are simply implemented as scripts to specify how the attributes of the managed device specified by the DoOM are managed by each of the components. The DoOM provides a scheme for generic functional components to interpret management data differently based on the device type and the overall management goal. The DoOM is specified on a device class basis and is stored as part of the policy database accessible via the data handler module.

System data flow

Figure 5 shows a fault event data flow in reaction to a fault being detected and reported. The following steps detail the actions taken by the system in response to such a fault event:

  1. A network device generates a fault event and forwards it to the appropriate network management node;
  2. The device mediation module on the management node receives the event from the network device, converts it to CMF, and forwards it to the bus;
  3. The bus routes the message to the event detection component;
  4. The event detection component processes the message and instantiates a copy of device MIB if one is not available;
  5. The event detection component, after seeing the DoOM policy, initiates a message to log the message;
  6. The bus then forwards the message to the logger component; and
  7. The logger component processes the message and on the basis of the DoOM management policy logs the event accordingly.

Figure 5: Fault Event Data Flow

The application in figure 5 illustrates an implementation of a second-level function -- that is, alarm surveillance -- using our approach. This may be extended to network management functions at other levels so as to fully implement an NMS.


In this paper, we have proposed a framework for internetworking management based on distributed mobile components generated as a result of functional decomposition. The proposed framework is a significant shift from the classic manager/agent paradigm in that we functionally decompose a network management function and then design components independent of the underlying network. The advantage of our approach is that we can change the functional decomposition method if necessary without having to adhere to any standard (e.g., TMN/ISO [International Organization for Standardization). This flexibility reduces the complexity in managing heterogeneous networks by avoiding standards that usually cater to homogeneous networks. Our proposed distributed mobile component framework divides the network management functionality into efficient pieces, thus effectively providing a way to implement network management services. The proposed framework does not stipulate how the functional components should be distributed. Thus, it is highly adaptive to network workload conditions and offers great potential for optimal network management.

A future research area is to design an optimal algorithm to dynamically reallocate sufficiently replicated functional components to network nodes in response to network load changes so that the overall response time with respect to network management events is minimized.


  1. D. Raz and Y. Shavitt, "An active network approach to efficient network management," http://cm.bell-labs.com/cm/ss/who/shavitt/pub/act.ps.
  2. D.L. Tennenhouse, J.M. Smith, W.D. Sincoskie, D.J. Wetherall, and G.J. Minden, "A survey of active network research," IEEE Communications Magazine, Vol. 35, No. 1, Jan. 1997, pp. 80-86, http://www.tns.lcs.mit.edu/publications/ieeecomms97.html
  3. A. Leinwand and K.F. Conroy, Network Management: A Practical Perspective, 2nd Edition, Addison Wesley, 1996.
  4. M. Rose and K. McCloghrie, Structure and Identification of Management Information for TCP/IP Based Internets (RFC 1155), May 1990.
  5. K. McCloghrie and M. Rose, Management Information Base for Network Management of TCP/IP Based Internets: MIB-II (RFC 1213), March 1991.
  6. J. Case, M. Fedor, M. Schoffstall, and J. Davin, Simple Network Management Protocol (RFC 1157), May 1990.
  7. U. Warrier, L. Besaw, L. LaBarre, and B. Handspicker, The Common Information Services and Protocols for the Internet (CMOT and CMIP) (RFC 1189), Oct. 1990.
  8. S. Feit, SNMP: A Guide To Network Management, McGraw Hill, 1995.
  9. Y. Yemini, G. Goldszmidt, and S. Yemini, "Network management by delegation," 2nd International Symposium on Integrated Network Management, Washington, DC, April 1991.
  10. G. Goldszmidt and Y. Yemini, "Distributed management by delegation," 15th International Conference on Distributed Computing Systems, June 1995.
  11. B. Schwartz, W. Zhou, A.W. Jackson, W.T. Strayer, D. Roackwell, and C. Partridge, Smart Packets for Active Networks.
  12. ITU-T Telecommunication Standardization Sector of ITU, Series M: TMN Management Functions, M.3400.
  13. D. L. Tennenhouse and D. J. Wetherall, "Towards an Active Network Architecture," Computer Communication Review, Vol. 26, No. 2, April 1996, http://www.tns.lcs.mit.edu/publications/ccr96.html
  14. Sunsoft, "The Java Language Specification," Sun Microsystems Inc., 2550 Gracia Ave, Mountain View, CA 94043, USA, 1995, http://www.javasoft.com/products/jdk
  15. Object Management Group, "Common Object Request Broker Architecture," OMG Technical Documentation Archive, 1997, http://www.omg.org/corba

[INET'99] [ Up ][Prev][Next]