Towards plug-and-play networks with mobile code - CiteSeerX

Towards plug-and-play networks with mobile code Andrzej Bieszczad SCE Technical Report SCE-97-08 March 1997

Abstract In this paper, we present an innovative approach to managing telecommunication networks based on mobile agents or, more general, mobile code. Our approach addresses the issues in traditional client/server, or in this context manager/agent, Network Management systems like the amount of data that needs to be transmitted, problems inherent to heterogeneous environment, like interoperability issues, problems with maintainability of involved software, etc. The necessary elements of the infrastructure have been implemented in Java. The infrastructure includes mechanisms for code migration and communication with managed resources. Network simulator has also been built to provide a testbed for the research. We explain innovative management ideas through demonstrations of the use of the infrastructure for several simple applications of mobile code that we categorize into servlets, deglets and netlets. We address the network security issues by defining a piglet as a hostile, malicious mobile code. We explore more advanced issues by describing several management applications that we are actively researching and implementing in the areas of discovery and presentation of component capabilities and information. Furthermore, we introduce a schema for dynamic network configuration. Our research is directed towards an ultimate goal of plug-and-play networks.

Introduction The telecommunication networks that are in service today are usually conglomerates of heterogeneous, very often incompatible, multi-vendor environments. Management of such networks is a nightmare for a network operator who has to deal with proliferation of humanmachine interfaces and interoperability problems. Network management is operator-intensive with many tasks that need to be handcrafted and controlled by humans. The legacy network management systems are very strongly rooted in the client/server model of distributed systems. This model applies to both IEFT (Case et al., [2]) and OSI (Yemini, [11]) standards. In the model, there are many agents providing access to network components and considerably fewer managers that communicate with the agents using specialized protocols like SNMP or CMIP. The agents are providers (servers) of data to analyzing facilities centered on managers. Very often a manager has to access many agents before any intelligent conclusions can be drawn and presented to human operators. The process involves substantial amounts of data transmissions that add a considerable strain on the throughput of the network. A delegation of authority has been proposed (Yemini, [10]) to address that issue. Delegation techniques require appropriate infrastructure that provides homogeneous execution environment for delegated tasks. One approach to the problem is SNMPscript (Case and Levi, [5] with serious constraints related to its limited expression as a programming language and to the limited area of its applicability (SNMP only). Although delegation is quite a general idea, the static nature of management agents still leaves the considerable control in the domain of the manager. The legacy network management systems tend to be monoliths that are hard to maintain and require substantial processing resources. They experience as well problems with the synchronization of their databases and the actual state of the network. That synchronization can be improved by increasing the frequency of updates or polling with further severe consequences on the performance of the system and the network. An emerging technology that provides the basis for addressing problems with the legacy systems is network computing based on the Java technology (Gosling et al., [4]). We refer to Java as a technology rather than only as another programming language. Java incorporates facilities to implement innovative management techniques based on mobile code (Kotay and Klotz, [6]; also [8]). With these techniques we can harness many interoperability issues and work toward plug-and-play networks by applying mobile agents that can take care of many aspects of configuring and maintaining networks in an autonomous way. Code distribution and extensibility techniques keep maintainability of networks and management facilities under control. The data throughput problem can be addressed by delegation of authority from managers to mobile agents that are able to analyze data locally without the need for any transmission. We can limit the use of processing resources on network components through periodic execution of certain tasks by visiting agents. Through engineering of a suite of simple management tools based on Web standards we address the problems inherent to monolithic systems that result from their size and processing requirements. With a user interface based on standards, we lower the learning curve for network operators. Incorporating intelligent agents that can handle tasks autonomously, we limit the requirements for human attention in the management process. In this paper, first, we introduce the necessary infrastructure for mobile code that we designed and implemented in Java. The infrastructure includes the following necessary components: • mobile code daemon,

• • • •

migration facility, interface to managed resources, communication facility, security facility.

It would be unreasonable to expect any network operator to allow for online experiments that involve autonomous agents. Therefore, we designed and implemented a network simulator for testing the ideas. It is described next. We continue with the taxonomy of mobile code into the following groups: • servlets, i.e., extensions or upgrades to servers that stay resident as integral parts of the servers, • deglets, i.e., mobile agents that are delegated to perform a specific task, • netlets, i.e., mobile agents that provide predefined functionality on a permanent basis. Each type is illustrated by an example of its use in the network management that we implemented using our framework. In the context of network security, we shortly analyze another, potentially malicious type of mobile code, piglets. In the next sections, we describe several realistic management tasks that we are solving using the described infrastructure. We conclude with our view of the prospects for the future and a review of planned activities. A similar effort, albeit more abstract, has been published very recently (Baldi, et al., [1]). In contrast to that work, we our paper is based on the experience with a number of applications that are driving our research.

Infrastructure It is not feasible to perform network management tasks without appropriate infrastructure in place. We have designed a new framework and implemented its elements that are required to explore our ideas. None of the existing technologies could accommodate our advanced approaches. The choice of Java for the implementation of the infrastructure is rooted in the portability of the language and built-in facilities to chunk the code and transport it to remote locations for execution. Java is an interpreted language; i.e., it is compiled to intermediate code known as bytecode that is executed (interpreted) by the Java Virtual Machine (JVM). Very strong support from the telecommunication and computer industry makes the language portable due to the proliferation of implementation of JVMs. JVMs are available, or will be available in the nearest future, for virtually any computing platform starting from mainframes and ending on consumer electronics items. The portability makes Java a very attractive implementation platform for systems that have to function in heterogeneous settings. Network Management is one of the primary examples of such a diverse environment. The second feature that we have mentioned, the modularity and remote execution, is ideally suited for systems that by their nature are distributed. Even in the classical static client/server approach the Java solution can bring plenty of advantages such as the capability to update component agents online without the need to restart, or to use Web browser to run various

applets as management tools. We will discuss these issues later on in this paper after the elements of the infrastructure are introduced. Java is an object-oriented language, so it is very convenient to provide default capabilities that are required for an agent system in a form of super classes. Applications that utilize the default behaviors can be easily constructed by sub-classing from those defaults collected in Application Program Interfaces (APIs). Overloading the default behaviors is the way to provide customization. The fundamental assumption that we are making is that each managed resource is Javaenabled. In our vision of the future networks, each network component runs a Java Virtual Machine. It is a very strong, revolutionary assumption. We realize that before such networks arrive, we need to accommodate existing systems. Therefore, there are certain provisions in place for more gradual, evolutionary approaches. They will be described shortly. At this point, let us proceed to the description of our framework. Code mobility daemon A facility for transportation of portable code is the basic requirement for employing solutions based on mobile code. Figure 1 shows the elements that are needed to send code between Java Virtual Machines (JVMs) running on network components (NCs). The centerpiece of the transport facility is the Mobile Code Daemon (MCD). MCD is a thread running inside a JVM that listens on two communication ports for incoming messages. We employ two ports to accommodate both TCP and UDP communication. We use arbitrary NC port numbers, although in the future, NC we would like to use advertised and, listening on a well-known port standard well-known1 ports. Another (UDP or TCP) MF MCD can send a message containing MCD Java bytecode to one of those ports. JVM MCD As illustrated in Figure 1, at any NC given time various bytecodes can JVM NC - network component move asynchronously between JVM - Java Virtual Machine MCD - mobile code daemon network locations. MCD

JVM

compressed code

Java thread

MF - migration facility

Upon a reception of a bytecode representing one type of an agent, the MCD validates the included Java classes, loads them using the Figure 1. Infrastructure dynamic class loader and instantiates objects for the agent. The code can be tagged as active or passive. If the code is tagged as active, then it is installed and activated as a Java thread by calling its initialization and starting methods. Passive code is just installed; it can be used later on. Deglets and netlets are examples of active code, while servlets are passive.

1

Well-known port is a communication port that is reserved by standards for specific use; e.g., there are well-known ports for SNMP, FTP, etc.

Migration facility The Migration Facility (MF) is the part of the MCD concerned with determining destinations for agents. If the bytecode instantiated by the MCD and running inside the JVM as a thread represents a netlet, then after its task at the node has been accomplished, the netlet may request the MCD to migrate it to another NC. The MCD uses the MF to determine which of the default migration strategies is applicable to the requesting netlet. One of applicable strategies is used to send the bytecodes representing the netlet to one of the ports on another listening MCD. Alternatively, a netlet can implement its own migration that may depend on the intended application. Similarly, a deglet may migrate using the algorithm provided by the delegating application. The simplest possible migration strategy is to predefine the migration destination from each MCD. Another simple alternative is a random selection of one of the neighbors. Other migration strategies can vary from similarly simple schema to elaborate algorithms that are based on the application needs and network conditions. Security facility The most common concern of operating companies about autonomous mobile agents cruising NC throughout telecommunication JVM networks is network security. We address this and similar concerns with ASF a security based on agent MCD authentication. Java provides a reach MCD JVM collection of security classes that are NSF NC used to sign the agents and verify its NSF - network security facility authenticity through the use of ASF - agent security facility NC - network component security keys. As illustrated in Figure MCD - mobile code daemon 2, the Network Security Facility JVM - Java Virtual Machine (NSF) is a part of the MCD that ensures that only trusted agents are allowed to be instantiated. Additionally, agent’s actions are also Figure 2. Network and agent security verified against its capabilities through the interfaces to network components, which are addressed in the next section. The second most common concern about netlets is a danger of flooding the network by autonomous agents reproducing themselves in the network without any control. A solution is a provision of meta-level management facilities that apply to the agents themselves. For example, ensuring that certain constraints on the quantity of netlets present in the network are satisfied can control their density. If a control agent determines that a threshold is exceeded for certain type of netlets, then some of them are intercepted and destroyed. Conversely, if there are too few agents, then new netlets are generated. A netlet security is closely related to network security. If a netlet is not properly secured from intruders, then it may become a piglet and indirectly impact the security of the network. Therefore, a visiting netlet is equipped with a shield that protects its integrity. An agent can

be modified in any way only by trusted entities. The Agent Security Facility (ASF) that is illustrated in Figure 2, is a default component of an agent that provides a security mechanism. Interface to managed resources Access to network information is the fundamental requirement for a management system. In the legacy systems, such functionality is provided by management agents; for example, an SNMP or CMIP agent in systems based on standards or an Appliance Agent in the Java Management API (Gosling et al., [4]). All of these agents are static in nature; i.e., they do not change the location where they are running. They are usually fairly complex servers that have access to kernel level functions of the managed resources. They are very component-specific, but may also support standard access methods.

Managed Resources

Security Methods

Interface to Managed Resources

Management Applets

Recovery Procedures

Provisioning Procedures

Virtual Managed Component Interface (VMCI) External parties

In an environment that involves mobile Figure 3. Architecture of Virtual Managed rather than static agents, there is a need Component for a more ubiquitous way of accessing network information. Netlets are lightweight agents that can implement neither direct (kernel level) nor indirect (SNMP, CMIP, etc.) access methods to all network components that they visit. The access facilities have to be local. As illustrated in Figure 3, Virtual Managed Component (VMC) is a collection of facilities that can be used by mobile agents to access the managed resources. External parties use the Virtual Managed Component Interface (VMCI) to interact with the VMC, and with the managed resources. To be useful, a visiting agent has to understand at least some elements of the VMCI. There are a number of functional facilities shown in Figure 3. The security subsystem protects the managed resources from unauthorized use and provides a security mechanism for installing extensions of the VMC. If an agent wants to access any of the component resources, then it has to use one of the provided access methods. A VMC may include management applets that can be transferred to the manager location, loaded into a Web browser and used to manage the component in a way predetermined by the vendor. There are usually plenty of certain component faults that are not fatal. The VMC may include a repository of recovery procedures that the vendor makes available to other applications. Another facility may provide provisioning agents that can be used to automatically configure the component into the network settings.

The VMC provides the only interface to a network component. The VMCs are local; i.e., they can NC MR MR be accessed only locally on the component. However, a VMCs may allow for installing extensions that VMC can export the interface. A VMC is MCD built upon a vendor specific JVM VMC VMCI NE information structure, which internally can have a flat or NC - network component hierarchical organization. As MR - managed resource JVM VMC - Virtual Managed Component illustrated in Figure 4, a VMC may VMCI - VMC Interface MR MR incorporate many managed JVM - Java Virtual Machine resources. Processes that run remotely cannot communicate with Managed Resources (MR) unless there are specific provisions for Figure 4. Accessing managed resources with local extensions of the VMCI. There Virtual Managed Components might be many VMCs for a single network component if the vendor chooses to structure the access in such a way. Vendors may implement complex algorithms to provide and modify the information. VMCs are selfcontained, but may provide for bringing in additional data related to the component or the network. There is no built-in network knowledge in any of the VMCs, since component vendors engineer them prior to connecting the components to networks. Due to similar reasoning, there are no built-in interactions with other VMCs. Again, extensions might be allowed to establish such communication after the component has been put in service. VM CI

Vendors may choose to provide a VMC that do not correspond to any physical entities. Such logical components might be convenient ways of dealing with certain types of information. Additionally, application programmers may use the provisions for extensions to incorporate VMC into alternate logical schema. An example of such use is presented in Figure 5. There is an application modeling the network that uses direct links to VMCs to feed the data into the objects in the network model. An object in the network model can be built upon a number of VMCs. For example, a logical network link object can be constructed from data coming from two nodes that are the endpoints of VMC the link. VMC Physically, a VMC can execute on the computing resources of the managed component or it can execute remotely. For example, a VMC running on a PC can use a micro-controller to access data coming from a photonic switch and to control such a switch. In the example, the VMC is still the only interface to the switch from the perspective of the management system. Ontologies

VMC

VMC

VMC

VMC VMC

Figure 5. Modeling networks with VMCs

An important issue in the agent-based systems relates to so called ontologies. Ontologies address communication between agents and the environment and between the agents themselves. The VMCI defines an ontology for all application agents that act within our framework. The agents communicate with the managed resources using the ontology. In addition, VMCs may support certain standards like GDMOs or MIBs or vendor specific extensions. Through standard provisions of the VMCI, a visiting agent may negotiate with the VMC the way of enhanced communication, which goes beyond the VMCI defaults.

NC BB

MCD JVM

NCF

NE

JVM

NCF - netlet communication facility BB - communication blackboard JVM - Java Virtual Machine

Figure 6. Inter-agent communication

Another set of ontologies relates to the inter-agent communication. Inter-agent communication depends on the involved application. Nevertheless, there are certain standard ways in which the agents can exchange information. One of the default provisions is a blackboard system, which is a data structure that can be written by visiting agents. Agents might be allowed to write and read data from the blackboard. The default blackboard that is a part of the framework can be extended to an arbitrary complex shared data structure by downloading and installing appropriate extensions. The netlet communication facility is a proxy that supplies an indirect communication link between agents that visit a location at the same time. Agents that have extension privileges can expand the default capabilities of the proxy. Network simulator At present, there are not too many operating companies that would allow autonomous mobile agents to float inside its network. To conduct many parts of our research, we need a network simulator. From a perspective of an agent, there is no difference between a real and a Simulated Network Component (SNC) as long as Network both run the MCD that is able to accept simulator and execute the agent’s code. With the simulator, we can create plenty of SNCs on a limited number of real NCs. Each SNC runs its own JVM with the MCD. From the agent’s perspective, such a virtual network is indistinguishable from the real network. As a matter of fact, virtual and simulated components can be networked together with no impact on agent’s behavior. Figure 7. Simulating large heterogeneous networks Each SNC has a behavior determined by Simulated and Real Network Elements

Real network

its implementation. In the simplest case, there might be a table of attributes that are modifiable by the operator of the simulator. However, the behavior can be arbitrarily complex; for example, a value of an attribute can be expressed as a function of time.

Management methods based on the use of mobile code We introduced four types of mobile code earlier in this paper: servlets, deglets, netlets and applets. In this section, we will examine several methodologies that are built upon them. Extensibility The capability to transfer code for remote execution (Daniele et al. [3]; Stomos et al. [9]) opens a Pandora box of opportunities for distributed computing. Remote repositories of software components can be downloaded for host 1 host 2 execution on a per need basis. Network management systems can take advantage of myTelnet myTelnet many of these techniques. As a simple demonstration, consider the case of an installable protocol driver shown in Figure 8. If host 1 wants to talk to host 2, then they both need to understand the same language; i.e., they need protocol handlers for the same protocol. If host 2 does not have a protocol handler, for example for myTelnet, then no communication can take place. However, if there is an infrastructure for transferring code, then host 1 can decide to install the handler for myTelnet on host 2. Now, the communication is possible.

host 1

host 2

myTelnet

myTelnet

Figure 8. Installable (soft) protocol

A similar scenario is shown in Figure 9, but in this case neither host 1 nor host 2 have handlers for myTelnet. There is a negotiation between host 1 and host 2, in which they agree upon the communication protocol. When that is settled on myTelnet, the protocol handlers for myTelnet are downloaded from a remote repository to both hosts.

myTelnet

host 1

myTelnet

host 2

Figure 9. Installable services from protocol server

The protocol handlers from the examples can be generalized to any type of services. It is not only a complete lack of an expected service, which can be addressed with these techniques. For example, an older version of a client can be upgraded if it attempts to access a server that handles only a newer version. Similarly, the server can be upgraded or extended without taking it off line. In that way, there are no problems with incompatible protocols or their versions and the maintenance of the software is extremely easy. In network management systems, a vendorspecific agent can offer a complete communication protocol (or extensions to

such) to the manager. Vice versa, the manager may upgrade, extend or install an agent on a device that does not have an up to date services. Delegation Delegation of authority (Yemini, [10]; Stomos et al. [9]) has already found a solid ground in Network Management as a methodology that allows for construction of distributed systems. Instead of encoding the complete management knowledge into one entity, the central manager, there are certain responsibilities that are assigned to other processes. These tasks can be still controlled to some degree by the central authority, but in many cases, local managers can perform various tasks in an autonomous way. Code mobility adds another dimension to the convenience of the delegation techniques. PC browser

PC 1 NC 1

In traditional network management systems, both centralized and distributed, all managers, central and local, are static processes. To fulfill their duties, they communicate through standard protocols, like SNMP (version 2) or CMIP. Any task that is delegated to a local manager has to be implemented by that manager. If a new task is to be delegated, then all managers that have to be upgraded must be taken off line.

Figure 10. Delegation I

The problems with static distribution of managers can be addressed by employing techniques based on mobile code. An example of such an approach is illustrated in Figure 10. Instead of communicating with other managers and asking them to perform a certain task, the manager can instead send an agent to perform the task. The task can be arbitrarily complex and may involve one or many network locations. If the task is a one-shot assignment, then we refer to the agent as a deglet. Autonomy

Figure 11. Autonomy

The task assigned to an agent might be of a permanent nature and it does not have to address existing network condition. If the agent is mobile, then we refer to such an agent as a netlet. Societies of netlets are inherent elements of the network management infrastructure that may address many issues. For example, there might be netlets that can handle network problems. In many cases, the capability to provide autonomous, on-spot diagnosis might be superior to the centralized option that involves transmission of large amounts of data that have to be processed centrally by some kind of an inference engine. Netlets can be engineered to

handle problems in a distributed manner; for example, each netlet can deal with a single network fault. In general, netlets can be used to maintain many aspects of the network autonomously.

Applications In this section, we examine a number of applications of the methods based on mobile code that we have implemented or are in the process of implementing. The applications are thought as testbeds for the ideas rather than complete solutions for management systems. Most of them can be implemented in standard ways, but we argue that the use of mobile code is beneficial. Network utilities As the first example, let us consider a system presented in Figure 12. The operator of the network opens a management tool (applet) in a Web browser, which is to display an active list of devices in the network. In a traditional system, to collect the responses from the nodes the manger (the applet) would use a ping-type command. Such a solution requires that a list of the potential destinations be maintained in the manager. In our approach, we are injecting a deglet (or a number of them) into the network with a task of reporting the visited nodes. Since an MCD on each network node implements a migration algorithm, the deglet will visit many nodes. Alternatively, the deglet Figure 12. Host sniffer can include its own migration patterns. A good migration algorithm will result in complete coverage of the whole network. For example, marking visited nodes can ensure that each node is visited only once. A variation of this application is the use of deglets that report only the nodes that satisfy certain conditions. For example, a list of nodes that are overutilized can be requested. Host browser

PC 1 Printer 1 NC 1

yes PC browser

PC 1 NC 1

no yes

Figure 13. Condition sniffers

The task performed by a deglet can be more complex. In another application that is illustrated in Figure 13, a deglet (or a number of them) is sent to the network nodes not only to report certain condition, but also to actually perform certain local action which depends on the condition. For example, a server that contains outdated software components can be updated or a node with an increasing failure trend is requested to restart. This technique can also be used to distribute new services to certain locations in the network. In all similar applications, netlets can be used in place of deglets. In that way, the

network management functions gain certain degree of autonomy. For example, the list that is displayed in the Web browser in Figure 12 can be a list of active traps (alarms), if a society of netlets reporting traps is active in the network. If netlets are used in place of deglets in the way described in Figure 13, then many management functions can be achieved autonomously. A comprehensive suite of similar applications can be the basis for truly intelligent networks with autonomous management infrastructure. Such an infrastructure including all kinds of intelligent methods rooted in the Artificial and Computational Intelligence is one of the main goals of our research. The applications presented in this paper give just a taste of the things yet to come. Managed information browsers Today, browsers with which network operators can get access to the information about the network components are the most popular management tools. The Web technology brings new opportunities for a design of convenient component browsing tools that can be opened in Web browsers and access the managed data over the Net. Networking technologies like CORBA, DCOM or Java’s RMI bring additional value through their support for distributed computing with remote software components. Java’s core libraries add plenty of classes that can enhance the Graphical User Interface (GUI) of the management tools making the Java platform even more attractive. Java also brings the code mobility that is exercised by the Web browsers to download applets and execute them within the browser environment. While discussing Virtual Managed Components earlier in this paper, we indicated that a VMC might include management applets. Such an applet can be downloaded to the manager as illustrated in Figure 14. In this application, the manager maintains a list of network components using the techniques that were described previously. When the operator requests the managed data for a component whose VMC includes a management applet, then the applet is downloaded to the manager and Figure 14. Component browser executed within the Web browser. Java is a rich language that makes it possible to build arbitrary complex tools. The vendor might be the provider of such applets, so the component designers can carefully craft the way, in which the component is handled in the network setting. It may include component specific graphics and verification routines for management data. Host browser

PC 1 PC 2 Printer 1 Printer 2 NC 1 Router Laptop

Provisioning Provisioning ATM’s Virtual Circuits is a fairly complex process involving several parties. It took quite a long time to negotiate all aspects of a PVC that we established between a Newbridge switch in our lab at Carleton University and a Fore switch in the network management lab at National Research Council. The PVC includes a path through a cloud in the OCRINet maintained be Bell Canada. The process would be even longer if there was another operating company offering similar services; for example, Bell’s competition could offer better prices. There were several network managers involved in the process. We are in the process of designing a system based on agents that could handle similar tasks in an autonomous way. A request to setup a PVC is assigned to a deglet, who coordinates the overall process. It uses additional deglets to perform partial tasks. Using the deglets all of the necessary data is exchanged by the endpoints using the provisions incorporated into their respective VMCs. The deglets communicate with Fore Newbridge (NRC) (Carleton) VMCs using a special ontology that generalizes the knowledge of setting up a PVC by the vendor. Parts of the necessary data may be brought as required from remote locations; for example, OCRINet vendor’s Web sites. Then, another deglet negotiates with the VMCs in the operator’s clouds. The best deal is selected and the subsequent exchange of necessary information completes the setup. At that point, the requesting Figure 15. Provisioning PVCs party is informed that the task has been accomplished. We are also looking into the use of netlets to manage the PVCs. For example, if any of the operating companies modifies its offer, then a special-purpose netlet can detect that fact and the negotiation process can be repeated. Plug-and-play networks Self-maintaining networks that we introduced in earlier sections of this paper can be folded into a broader concept that guides our research and experiments, a plug-and-play network. To exercise the ideas, we are looking into an application that is illustrated in Figure 16. It has been derived from the problems that we experienced while installing a CDROM in one of our PCs. We spent several days before we resolved all of the problems related to a device driver that was necessary to make use of the CDROM. The example in Figure 16 is a generalized version of our problems.

In the scenario, there is a Java-enabled printer to (PCs and Unix) and other devices. The network maker of the printer. The vendor provides a provisioning deglets and netlets. After connecting to the network, a netlet (or a number of them) is sent to the network to determine the environment requirements; i.e., it discovers the type of workstations and their locations. Then, a deglet contacts the vendor’s repository of drivers and downloads drivers appropriate for the printer and for the environment. The drivers are installed on the devices that will make use of the printer. The printer registers with the vendor, so when a new driver is released, then the printer can negotiate with the network whether the local drivers should be upgraded. The netlets that travel in the network are also assigned a task of detecting new destinations for the drivers.

be connected to a network of workstations is connected to the Internet, and so is the VMC with the printer, which includes

Internet Network

Printer vendor

printer driver (updates)

Figure 16. Plug-and-play components

Inter-working with legacy systems It is worth to note that the old manager/agent schema can easily be implemented using VMCs. For example, an application that uses a local VMC and implements an SNMP protocol handler can be installed inside the MCD. Thereafter, it can act as an SNMP agent. An alternative that we have implemented within our framework is a handler of an extension protocol. We tried the idea with the DPI protocol. A VMC extension registers with an SNMP agent and acting as an SNMP subagent provides data to SNMP requests. Both of these ideas could be applied in cases where the inter-working with the legacy system is required. We can associate simulated network components with actual devices running legacy agents through properly engineered VMCs. It is also helpful within our simulated environment to be able to link simulated components to the real ones if an idea that has already been tested through a simulation is to be tried on a live network.

Conclusions and future work The preliminary research into the area of the use of mobile code for network management has proven that there are plenty of opportunities that are worth further explorations. We have demonstrated that the mobility adds another dimension to the management methodologies. The work on the mobility framework has convinced us that the Java technology is the ideal candidate for implementation of the methodologies based on mobile code. We have determined many components that are necessary for the infrastructure on which the methodologies could be built. We are just at the beginning of our journey towards plug-and-play networks. We will continue to research the requirements for the infrastructure, which we consider to be the basis for the futuristic networks. We will focus on further research into its components, what are the necessary patterns of their behavior and what are the limitations and constraints. In

particular, we will be looking carefully into the security issues, which will be based on the security features of Java, the migration patterns for netlets, inter-agent communication strategies, the ubiquitous interface to managed resources and its extensions. In the application area, we have already started to explore the use of agents, and mobile agents in particular, for fault diagnosis. We have put forward several projects involving methods from Artificial and Computational Intelligence. We expect to present results from some of the projects in the near future, while there are a number of others that are long term; for example, diagnostic techniques based on swarm intelligence or mobile, distributed expert systems. The work on an autonomous provisioning agent project has initiated our research on self-configuring networks. It is an exciting area that has a fuzzy border with service management. We hope to benefit from the research on ODP, TINA (Megadantz, [7]), etc. contributing at the same time our own ideas. It is not our intent to provide off-shelf solutions or set standards. Our research will retain its exploratory nature as a vehicle for generating and testing ideas that may prove useful for networks of the future. We believe that our research will be a considerable step forward towards the realization of the ultimate dream of any operating company: a trouble-free, plugand-play network.

Acknowledgments We would like to acknowledge the contribution to the work presented in this paper by the members of the Perpetuum Mobile Procura project at Carleton University: Research Associate Cheryl Schramm and our students Gatot Susilo, André Campeau, Richard Brunet, Yanrong Li and Tony White (who is also a Member of the Scientific Staff of NORTEL on a temporary assigment at National Research Council).

References 1. Baldi, M., Gai, S. and Picco, G. P., Exploiting Code Mobility in Decentralized and Flexible Network Management, First International Workshop on Mobile Agents Mobile Agents’97, Berlin, Germany, April 7-8, 1997. 2. Case, J. D., Fedor, M., Schoffstall, M. L. and Davin, C., Simple Network Management Protocol, RFC 1157, May 1990. 3. Daniele, M., Wijnen, B. and Francisco, D., Agent Extensibility (AgentX) Protocol, Version 1, Proposed Standard, SNMP Agent Extensibility (agentx) Charter, Operations and Management Area of IETF, Dec. 1996. 4. Gosling, J. and Arnold, K., Joy, B., Steele, G., Lindholm, T., Walrath, K., Campione, M., Yellin, F. et al, The Java Series, Addison-Wesley, 1996. 5. Jeff D. Case, David B. Levi, SNMP Mid-Level-Manager MIB, Draft, IETF, 1993. 6. Kotay, K. and Kotz, D., Transportable Agents. In Yannis Labrou and Tim Finin, editors, Proceedings of the CIKM Workshop on Intelligent Information Agents, Third

International Conference on Information and Knowledge Management (CIKM 94), Gaithersburg, Maryland, December 1994. 7. Krause, S. and Megadantz, T., Mobile Service Agents Enabling “Intelligence on Demand” in Telecommunications, Proceddings of IEEE GLOBCOM’96, London, U.K., 18-22 Nov. 1996. 8. Mobile Code Bibliography, http://www.cnri.reston.va.us/home/koe/bib/mobile-abs.bib.html 9. Stomos, J. W. and Gifford, D. K., Remote Evaluation, ACM Transactions on Programming Languages and Systems, 12(4), pages 537-565, October 1990. 10. Yemini, Y., Goldszmidt, G. and Yemini, S., Network Management by Delegation. In The Second International Symposium on Integrated Network Management, Washington, DC, April 1991. 11. Yemini, Y., The OSI Network Management Model, IEEE Communication Magazine, pages 20-29, May 1993.