Network Configuration with Plug-and-Play Components - CiteSeerX

Network Configuration with Plug-and-Play Components Syed Kamran Raza Technical Report: SCE-98-04

Abstract The installation and configuration of a new network component is a difficult task due to the heterogeneous nature of today’s telecommunication networks. This task requires substantial effort and extensive expertise on the part of the network administrator because he has to set hardware and software attributes for a variety of such components to make them work together. We propose a solution to this problem, i.e. to automate the installation and configuration process of new component using the plug-and-play concept. We have taken the idea of plug-and-play hardware from modern operating systems to plugand-play network components in the Network Management domain. A plugand-play network component is defined as a component that is capable of configuring both itself and other cooperating components in a network without human intervention. Several plug-and-play schemes are possible but we have implemented a scheme based on mobile agents. This paper describes the plug-and-play concept for network components and focuses on an implementation of the plug-and-play scheme that is based on mobile agent technology. The paper also addresses the related issues and assumptions and concludes with a brief evaluation of the scheme. Keywords: Network Management, Components, Auto-Installation

Mobile Agents,

Plug-and-Play

1. Introduction Network management is getting increasingly complex and harder because of the rapid growth of today’s computer and telecommunication networks. The multi-vendor heterogeneous nature of these networks makes the management tasks even more challenging. One of these important management tasks is the installation and configuration of a new component in an existing network. For instance, consider adding a new printer on a network that requires intervention of a network administrator for configuration. First, the administrator has to arrange for a hardware connection for the printer and then corresponding software attributes have to be adjusted. Furthermore, any network component that wishes to use services of the new printer has to have a printer driver installed on it. This requirement is quite difficult to achieve in a big heterogeneous network of (multi-vendor) hosts and different operating systems. Once all the arrangements have been made, the installed drivers are to be setup and activated on the corresponding components. All the aforementioned steps require substantial effort and extensive expertise from the network administrator. Moreover, the entire process consumes significant time (depending on the size, heterogeneity and other parameters of the network) before the installed component can be actually put into service. One of the solutions to the described problem is to automate the installation and configuration process of a new network component using the plug-and-play concept [2]. Apart from the hardware connection establishment, that has to be set up manually, our aim is to provide the plug-and-play capability in the components for all other mentioned steps. We define a plug-and-play network component to be a component that is capable of configuring both itself and other co-operating network components without human intervention. After such a component is plugged into the network, it is responsible for making the entire configuration arrangements. In other words, plug the component into the network, turn it on and it works after initial configuration. Other network components are also adjusted and reconfigured by the added component. Therefore, in this scheme, no one else but the added component takes care of the installation and configuration process. The idea of plug-and-play originated in operating systems’ world. For example, Microsoft’s Windows95 supports plug-and-play hardware devices by using a local registry and appropriate operating system functionality. Windows95 delivers a large number of drivers for different kinds of devices. As soon as a new device (recognizable by Windows) is inserted on the bus, it is detected automatically and its installation occurs almost transparently. A complete plug-and-play operating system will allow a particular PC hardware and an operating system to work with different network and peripheral devices [13]. We have transplanted the same idea to the network management domain for the management of network components. It addresses a particular area from Network Management’s standard functional areas, i.e. Configuration Management. The plug-and-play idea from the PC world requires some enhancements when applied in networked world because of certain constraints. For instance, there is no central operating system available on a network that can monitor and control entire plug-and-play process. Moreover, it is almost impossible to keep a registry of all the potential components on the network. After refining and applying the basic idea, the ultimate goal of our research is to have plug-and-play networks that are capable of self-configuration, self-diagnosis and self-repair [3]. There are several ways of achieving a plug-and-play capability; among these, some agent-based schemes are suggested in [2]. These schemes include local repository, remote repository and CORBA solutions that represent static-agent schemes. An introduction to a scheme based on mobile agents is also given in [2]. In this paper, we take the work of [2] onward and focus on an implementation of a network plug-and-play scheme using mobile agents technology. Mobile agents represent a powerful computing paradigm that provides significant advantages over traditional client/server computing. The flexibility and power of the mobile agent paradigm is well suited to any application dealing with a dynamic network environment so it is our choice for plug-and-play scheme. We have chosen a network printer as an example plug-and-play network component during the implementation of the idea. Before describing the actual implementation, the paper briefly discusses mobile agent technology and infrastructure for agent migration that we have used. The implemented plug-and-play scheme, assumptions and issues are described later. The paper concludes with a brief evaluation of this scheme.

2

2. Mobile Agent Technology Traditionally, computer communication networks are based on computing paradigms that operate in client/server manner. The major problem with client/server transactions is the consumption of network bandwidth because network remains engaged for the entire duration of a transaction [10]. An alternative computing paradigm that has evolved recently is Remote Programming (RP). In this approach, instead of shouting a request across the network to the server, the client computer supplies the procedures to be performed to other computer. The salient feature of the RP approach is saving network bandwidth as the network is used only one time during the transportation of procedures. After that, the client computer and the server can interact without using the network. In fact, the transported procedure executes locally at server machine on behalf of the client with no network interaction. Another similar approach that largely overlaps the RP paradigm is Code Mobility. As its name suggests, it exploits mobility of the code and is the approach of interest in this paper.

2.1 Code Mobility The idea of moving software programs by means of the network is quite old. For example, since the early days of networking, hosts have been downloading applications from file servers (where they are stored) to their machine (where they are executed). Similarly, Java applets in today’s Internet are example of mobile code that may be downloaded from remote server and executed locally. In the above examples, code is downloaded and moved from a storage environment to an execution environment, but the downloaded code generally does not carry state with it and starts execution from an initial entry point. More recently, the trend has been to “move programs while they run” [10]. Such software programs are termed as Mobile Code and this approach yields a powerful computing paradigm that is called Code Mobility. We can define Code Mobility as “… the capability to dynamically change the bindings between code fragments and the locations where they are executed” [9]. A conceptual framework for Code Mobility is characterized by three entities: design paradigms, technologies and applications as illustrated in [9]. Three mobile code paradigms are identified as Remote Evaluation (REV), Code On Demand (COD) and Mobile Agent (MA). These are defined according to the location of code, data and resources, before and after the task execution [5]. In the REV, the service code is sent from source computer to remote destination computer, where it is executed using the resources and processor. On the other hand, the COD paradigm defines a mechanism in which code is provided by the remote computer that is downloaded and executed using local resources and processor. Finally, in the MA paradigm, source computer has the code and the processing capability but the computations take place at remote computer where the resources reside. These paradigms constitute a major area of research in the field of mobile computing. For example, a case study of these paradigms is made in [11], while [1] builds a quantitative model to evaluate mobile code paradigms against the client/server architecture in network management applications. A technology for Code Mobility [9] comprises a programming language and code execution environment. Currently, many such technologies are available and being used; AgentTcl at Dartmouth College, Java from Sun Microsystems, IBM’s Aglets, MOLE at University of Stuttgart, DEC’s Obliq, TACOMA, Telescript from General Magic and several others. Of these design paradigms and technologies, we have chosen Mobile Agents and Java (with a proprietary code execution environment, section 2.3.1) for our implementation.

2.2 Mobile Agent A running computation that has a migration capability is called a Mobile Agent. Stated simply, a mobile agent is a software agent (procedure and state) that can move from one host to another host over the network, in order to achieve its task. Whereas, in today’s object-oriented world, a mobile agent is an object that has behavior, identity, state and location. It means that the same agent can be located at different machines at different times due to the migration capabilities.

3

Mobile Agent Systems (MAS) provide benefits in many application domains; typical application domains are distributed information retrieval, telecommunication service management, remote device control and configuration, electronic commerce, active networks [9], real-time interactions, network traffic and asynchronous interactions [6]. Our work explores the use of mobile agents for the configuration of the components in telecommunication and computer networks. There are always tradeoffs in a certain approach and Mobile Agent Systems are no exception. One of the main issues regarding MAS is security. Therefore, most of the MAS pay special attention to security risks and make their framework and agents secure by deploying standard security techniques. The security issues are addressed in many papers (e.g. [8]) and their further discussion is outside the scope of our paper.

2.3 Infrastructure for Code Mobility Mobile agents require an environment in which to execute. The environment should support agent facilities for agent execution, migration, serialization, communication, lifecycle, security etc. Object Management Group (OMG) is working on defining standard facilities that are called Mobile Agent Facilities (MAF) [14]. However, the MAF specifications mainly address agent management, tracking and transport facilities. It is obvious that the basic requirement for the Code Mobility is the presence of an infrastructure that can support specified mobility facilities. We call such an infrastructure a mobility framework. To implement such an infrastructure, the choice of technology is critical. Java supports the kind of services required for this infrastructure. The power of Java comes from its rich set of libraries, strong networking support, facilities for code migration (class loaders), security APIs and most importantly, platform independence. One of the basic requirements for a mobility framework is that a mobile agent must be able to run on each network component in a machine-independent manner. The Java Virtual Machine (JVM) provides the solution to this requirement by ensuring safe and secure execution of received mobile code, independent of underlying executing machine. The infrastructure that we have used for building our application is called the ‘Mobile Code Toolkit’ [15] [17]. Before discussing the plug-and-play implementation details, an understanding of this framework is important. 2.3.1 Mobile Code Toolkit Figure 1 shows the Mobile Code Toolkit (MCT) architecture. It is a framework for code mobility, developed under the umbrella of the PMP group [15]. This software is coded 100% in Java because of the aforementioned benefits. The high level view of the implemented kit illustrates three major interacting components: − Mobile Code Daemon − Mobile Agents − Interface to Network Resources

The Mobile Code Daemon (MCD) is the principal component for providing mobility and agent transaction facilities. It is a thread running under JVM; listening on a specific TCP/UDP port for an agent arrival. Other hosts that are running MCDs can send an agent as compressed bytecodes over TCP/UDP connection to the receiving host. An

NC

compressed code

NC

MCD JVM

Listening port TCP/UDP

CF

MF

SF

NC

MCD

MCD JVM Thread

JVM

VMC Network Resource

NC - Network Component JVM - Java Virtual Machine MCD - Mobile Code Daemon VMC - Virtual Managed Component MF - Migration Facility CF - Communication Facility SF - Security Facility

Figure 1: Mobile Code Toolkit framework 4

MCD also provides other basic facilities for byte-code management, communication, instantiation and migration of the agent. It is worth mentioning that MCT also addresses security risks and deploys strong security techniques by using algorithms like DSA, MD5 and SHA-1. The toolkit implements a mobile agent as a Java class that can be sent over the network in compressed code format. When a mobile agent arrives at a host, it needs to access the network component resources to perform network management tasks. For security reasons, they communicate with their host environment only via a permitted interface, i.e. they are not allowed to access network component and resources directly. Therefore, an interface to network resource is provided on each network component that is called a Virtual Managed Component (VMC). Any agent requiring an access to network resource and host environment has to access them via VMC. In other words, a VMC provides a uniform access to the underlying resource no matter what the actual platform and implementation are. This property allows us to use same mobile agent on a variety of vendor-specific network components.

3. The Plug-and-Play Printer After discussing the mobility infrastructure in the previous section, we are now ready to describe the actual implementation of the plug-and-play scheme. We start by describing the simple scenario that is followed by the implementation details and related issues. A printer is used in our implementation as an example plug-and-play network component.

3.1 Simple scenario The vendor supplies a printer that is Java-enabled with a specific plug-and-play interface installed on it. On one hand, the interface provides access to the printer, on the other, it is capable of initiating and controlling the autoinstallation process by sending and receiving mobile agents. Figure 2 illustrates a simple scenario for the plug-and-play printer scheme. Firstly, the printer is plugged-in and attached to the network. As soon as it is turned on, its bootstrap program installs and activates some software modules. These modules are capable of sending mobile agents on the network. The configuration process starts with the dispatch of a mobile agent to the vendor site for the registration purposes (#1 on Fig. 2). After successful registration, another mobile agent is sent over the network to discover the configuration requirements of other network components (#2 on Fig. 2). This mobile agent gathers information related to type, operating system and other attributes from each component while moving forward in the network using the default migration targets. When the mobile agent returns to its origin (printer), the plug-and-play component’s software determines the configuration requirements of the supported network and sends another mobile agent with these demands (request for drivers) towards the vendor site (#3 on Fig. 2 ). The agent arrives at the vendor component and accesses the corresponding interface to the driver repository. Through this interface, the requested drivers are copied into mobile 4 Setup Plug-and-Play component

2 Discover 3 1 Register

Request

Internet Vendor Repository

Figure 2: The Plug-and-Play printer scenario

5

agent’s data structure and sent back to the printer. The printer prepares and dispatches separate dedicated setup mobile agents towards each discovered component, carrying corresponding drivers (#4 on Fig. 2). These mobile agents contact the setup interface at each component and deliver the drivers to it. Thereafter, the drivers may be installed immediately or stored locally at the destination component. It completes the cycle of initial installation and configuration of the plug-and-play component and other network components respectively. Now, the plug-and-play component is up and running and other components are ready to use it whenever required. For future support of the plug-and-play component, two more steps need to be done. First, a permanent mobile agent is injected onto network that keeps scanning network for future discoveries (i.e. addition of new client component). In addition, any future upgrades on printer version are to be notified by sending some mobile agent (or simply by messaging) from vendor to the registered printer.

3.2 Implementation 3.2.1 General Setup We have implemented the plug-and-play printer scenario in our ‘Network Management Laboratory’ by setting up the environment and simulating the printer as an example plug-and-play (PnP) component. A general setup of an example network was established in which a PC was used to represent printer aspects. We needed a PC to simulate PC System VMC

Setup VMC

.....

Sun WS System VMC

Setup VMC

Mobile Agent

Internet

PnP VMC

Register VMC

Driver VMC

Printer Plug-and-Play component

repository

Vendor

Figure 3: Setup of example network the printer because no real plug-and-play printer exists yet. Our simple network comprised of three main interacting components: − Plug-and-play component (printer) − Vendor component − Other Network Components

The other network components included PCs from different vendors (running Windows NT/95) and Sun Workstations (running Solaris) that provided us a heterogeneous environment. Figure 3 shows this example network of components along with the implemented agents and VMC interfaces. 3.2.2 Assumptions Following assumptions are made for the sake of ease and simplicity in implementation: − Each network component is Java-enabled. − Each network component is running a mobility framework (i.e. MCD in our case). − The PnP component (printer) is shipped with a vendor-supplied plug-and-play module, called PnP-VMC. − The PnP component knows the URL/IP address of its vendor. − Migration paths are already established among the existing network components. − Migration paths are configured on components so as to form a single complete ring.

6

We realize that the assumptions regarding running Java, mobility framework and PnP module on a network component is bit unrealistic. However, we suggest that a minimal set of mobility functions (with a simplified PnP module) can be devised for small components. Moreover, with the advent of Java chips, we foresee that almost all network components will be Java-enabled in future. 3.2.3 Detailed Description Our application runs on top of the Mobile Code Toolkit infrastructure (MCT of section 2.3.1) and uses Java as its implementation language. As application developers using the Mobile Code Toolkit, we are required to write and customize mobile agents and network component’s VMC interfaces. Analogous to static method invocation in CORBA framework, the VMCs consist of published interface methods that are invoked by the visiting agents. Therefore, we have developed two kinds of modules: • Mobile Agents: that are to be sent to different network components with specific delegated tasks • VMCs interfaces: that provide access to actual network resource and component

We need to program many agents that support different tasks of the scenario. The basic structure of each agent is identical (as defined by MCT’s APIs) but each agent is customized to perform the delegated task by overriding the callback methods of the agent. The VMCs are required on all the network components that are potential recipients of the mobile agents. A network component can have more than one VMC providing different interfaces. Any mobile agent can access the VMC by using its name, so it has to know the standard name of the VMC in advance. A network component may have a vendor-specific VMC installed on it but it must use specified names for the VMC if it wants to be a part of a plugand-play scheme. We have chosen function-oriented (arbitrary) names for the VMCs, however, the standardization of this scheme may define certain standard names in future. We have implemented five different VMCs that are distributed over four different interacting components (refer Figure 3). The steps of the plug-and-play scenario can be listed in chronological order as: 1. Installation, booting and initial configuration of the plug-and-play printer. 2. Registration of the plug-and-play printer with the vendor. 3. Scan of the existing network to discover configuration requirements. 4. Fetching the required printer drivers from the vendor site. 5. Distribution of the drivers to the network components. 6. Auto-discovery of a new network component in future. 7. Upgrade notifications sent by the vendor to the printer. In fact, only the first five steps constitute basic plug-and-play scenario, while, the step # 6-7 provide future support for plug-and-play networks. Right now, our work also encompasses first five steps only but we plan to extend it, once major issues related to these basic plug-and-play steps are resolved. Figure 4 shows transactions among agents and interface VMCs by illustrating dispatched agents, interacting hosts and receiving VMCs of Figure 3. Above mentioned steps are listed (2-7) in time sequence on the diagram. From the figure, it is clear that all the mobile agents are destroyed when they return to the source (or their task completes) except the permanent auto-discovery agent (Step # 6). In the following sub-sections, we discuss each installation and configuration step of the plug-and-play scheme separately. We describe what we have implemented along with some other possible ways of doing the same. 3.2.3.1 Initial installation, booting and configuration

The vendor-supplied printer is Java-enabled with a plug-and-play VMC (PnP-VMC) pre-installed on it. This emphasizes the fact that our framework can support vendor-specific VMCs as well. A PnP-VMC is more powerful and active in comparison to the simple VMC introduced earlier. It plays a central role in the scenario by initiating and controlling the entire auto-installation process using mobile agents. The VMC is responsible for injecting, controlling and receiving most of the mobile agents and it synchronizes agent creation, dispatch, arrival and destruction. It does so in conjunction with the MCD that runs as underlying mobility daemon. To gain better control

7

in the multi-threaded environment of this underlying framework, the PnP-VMC is implemented as an independent thread. Many data structures are maintained by the PnP-VMC, that are used throughout the configuration process. The first step in plug-and-play scheme is establishing of the hardware connection. It means that printer hardware is physically connected to the existing network. The printer may safely be turned on after that and the bootstrap program in the printer starts by installing the MCD. Successful installation and activation of the MCD gives the printer the capability to send and receive mobile agents after which the vendor-supplied PnP-VMC can be activated. However, before starting other configuration phases, there is a requirement of inserting the printer into the migration paths that are already established among the existing network components. This issue is discussed in more detail later in subsection 3.3. By now, the PnP component is up and running, i.e. it is ready to start configuration phase. 3.2.3.2 Registration with the vendor

A vendor may have shipped many components to market but not all of them are on the network, so the need arises for registration of the component with the vendor, after the component becomes live. The registration serves another useful purpose, i.e. it helps the vendor in notifying the registered printer in case of any future upgrades. The PnPVMC sends a mobile agent, registry agent, to the vendor component for registration purposes. At the vendor component, an interface called the Register-VMC is provided whose job is to register plug-and-play component using the incoming registry agent (Fig. 4, Step 2). The other task of this VMC is to provide upgrade notifications to all the registered printers, which can easily be implemented by enhancing the capability of this VMC. The RegisterVMC also maintains a database of information for all the registered printers. After registering at the vendor site, the registry agent returns to the printer with the registration status. If registration is not successful due to some reason, the plug-and-play configuration process is halted and network administrator intervention is required. It should be noted here that the URL/IP address of the vendor component should be known to the printer in order to send mobile agents to the vendor site. 3.2.3.3 Network discovery and configuration requirements

Successful registration is followed by the injection of a second type of mobile agent, i.e. a discovery agent. It is dispatched over the network for discovering configuration requirements of the other network components. The agent scans the environment and gathers information such as type, location, owner, operating systems etc. on each visited component. The task is performed by querying each network component via a specific VMC, called a System-VMC (Fig. 4, Step 3). The System-VMC provides access to the system-specific information about the component. The discovery agent gathers this information via this VMC and sends it back to the PnP-VMC (on the printer) using a Printer

Node 1 (PC)

....

Node n (Sun)

Vendor

Register-VMC Registry agent

2

PnP-VMC System-VMC Discovery agent PnP-VMC

System-VMC

3

Discovery agent Discovery agent

Time

Driver-VMC Request agent

4

PnP-VMC Setup-VMC 5

Setup agent Setup-VMC

System-VMC

6

Permanent Discovery agent PnP-VMC

PnP-VMC

7

Notification agent

Figure 4: Agents transaction diagram

8

TCP socket. After traversing existing network, the agent returns to the printer and marks the end of the discovery cycle. Note that instead of using a socket connection to send information from each visited component, we could have chosen another approach. In this approach, the discovery agent visits a component, collects information and migrates to next component. In this manner, it traverses the entire network while carrying the accumulated information with it. Finally, it arrives back at printer where this information is communicated to the PnP-VMC. The problem with this approach is that in a big network, the agent size will grow with each hop and it will introduce an overhead in agent transfers and interactions. We want our agents to be lightweight, so we did not use this approach. 3.2.3.4 Fetching required drivers from the vendor

Now our requirement is to fetch the drivers from the vendor component and distribute them to corresponding hosts. There are several ways of implementing this step, mainly depending on the fact that who is responsible for the distribution of the drivers. We first describe our approach in which the plug-and-play component is responsible for the distribution of the drivers. From the accumulated information about components, the PnP component determines the configuration requirements and devises a minimum list of the required printer drivers. The list is implanted into a new mobile agent, called request agent, and the agent is dispatched towards the vendor component. The task delegated to this agent is to bring required printer drivers from the ven dor to the PnP component. The vendor provides a Driver-VMC as an interface to its repository of drivers and the request agent accesses this VMC to fetch the required drivers (Fig. 4, Step 4). The drivers are copied into the agent and the status of the copied drivers (success/failure, no. of bytes etc) is also updated. In case of an unsuccessful copy of one or more driver(s), the PnP component checks returning agent’s status data and notifies the corresponding component. We realize that idea of an agent carrying multiple drivers is inefficient. The reasons we have implemented it this way is that we first want to exercise our agents for almost every task in the scenario. Later, we will compare them with other approaches, such as sending drivers back to the PnP component over the socket connection (just like discovery information). An alternative way of achieving this step is as follows. Instead of using just the list of the required drivers, a list containing the URLs of network components, along with their required drivers could be sent to the vendor. In such case, the vendor is responsible for the distribution of the drivers to individual components. It may send the required drivers directly to each component, either using dedicated mobile agents or just sending it over some socket connection. We have chosen the scheme in which PnP component is responsible for the distribution of the drivers because we want the PnP component to play a central role in this scenario. 3.2.3.5 Distribution of the drivers to the components

The PnP-VMC constructs a dedicated mobile agent for each discovered component that carries the corresponding driver (or failure notification). These mobile agents are called setup agents and sent separately to the components. Each network component maintains an interface, called a Setup-VMC that accepts the incoming setup agent (Fig. 4, Step 5). The VMC detaches the corresponding supporting driver from the agent for setup purposes. The Setup-VMC may either store driver in its file system, or it may invoke some setup and activation facility. The driver might be discarded as well, if not needed. We leave the choice of operation on the specific implementation of the VMC; however, our implementation supports the first case. 3.2.3.6 Auto-discovery of the new components in future

By now, the initial installation, configuration and reconfiguration phase is completed for the existing network. However, due to the dynamic nature of networks, new components (requiring the services of printer) may be added in future that must be discovered and configured immediately. There is a need for some kind of permanent discovery agent on the network that will keep roaming from node to node, sniffing for any new component and notifying PnP component in case it finds any (Fig. 4, Step 6). This agent can also be useful if an existing configured network component wants to negotiate with the PnP component. The agent is a prototype of the discovery agent described in section 3.2.3.3, however, the nature of its task is permanent and it never terminates. We assume that there is only one such agent per subnet and each PnP component is registered with it. The agent is stored in some proxy server and it roams the network only periodically.

9

3.2.3.7 Upgrade notifications from the vendor

In case of a new release of the printer driver, the vendor may send dedicated mobile agents to all the registered printers, offering them the new version. The offer may be free of charge or may involve some trading service. When the PnP-VMC receives this offer from the vendor (Fig. 4, Step 7), it asks all the concerned network components. If the need arises, the drivers may be loaded from the vendor site using agents and repeating some steps from the scenario. This facility provides a significant advantage regarding availability of up-to-date drivers, as compared to the usual local database repository that quickly becomes obsolete. Again, an alternative way of notification is by using messaging. However, we wanted our implementation to use mobile agents and exercise them at maximum so we did not adopt this approach. Our goal in this paper is not to go into the performance issues, but to explore the maximum use of mobile agents for given application. We have presented an idea and we want to prove that it is achieve-able, so momentarily we are concentrating on its mobile agent based implementation.

3.3 Related Issues The previous section described a detailed scenario of a plug-and-play scheme, with an intention to keep it as simple as possible. However, there are major and minor issues associated with the scheme, which are discussed below. Before initiating the entire installation process, the plug-and-play printer needs a bootstrap program for installing mobility framework on itself. A related issue that is more critical is the requirement of some initial IP address in order to communicate over the network. It gives rise to the question that how does printer acquire its IP address and bootstrap code. We suggest the use of the Dynamic Host Control Protocol DHCP [7] as one of the possible solution to this problem. This protocol supports initial configuration and dynamic allocation of network addresses to a new component. Any host can act as a DHCP client and can obtain IP address (along with other options) from a DHCP server by sending a special request message over the network. Accordingly, a plug-and-play printer broadcasts its request for initial configuration over the network. The DHCP server recognizes the request and assigns an IP address on lease or permanent basis, depending on the type of request. It also provides other interesting options like host name, DNS server address, sub-net mask and boot file address (for second phase bootstrap) etc. The printer can now download bootstrap code along with a daemon MCD, using the TFTP mechanism described in [4]. In addition, DHCP has provisions for supplying vendor-specific options. However, there used to be a major problem associated with the DHCP configuration mechanism, i.e. it did not update DNS. However, a recent draft [12] has resolved this problem as well. Therefore, the DHCP addresses both the issues of bootstrap code and initial configuration. Other major issues are related to the migration of mobile agents. In the MCT framework, the Migration Facility (Fig. 1) is responsible for the migration and travel of the agent. It receives a migration target and dispatches the mobile agent to that target. Initially, at least one such target is needed by plug-and-play printer to inject agents into the existing network. The agent’s Migration-API allows agent to migrate to a specified target or a default target. The migration paths that are configured on each network component are the default migration targets for the agents residing on that component. Once an agent is able to migrate to any component (using specified target), it may migrate onward using configured migration path (default targets). Therefore, the problem is resolved if an initial target is obtained somehow. Another related issue is that the printer has to be inserted into existing migration network in a linked list manner. It may do so by modifying migration paths of MCDs running on each network component; an initial target is also required for this purpose. Therefore, the problem is to find a way of providing an initial migration target to the agents. We suggest that one of the solutions to above problem is the use of some Naming Facility in the network. At boot strap time, a mobile agent may request Naming Facility for an initial target and Naming Facility would be able to supply the actual address. The agent migrates to that initial target (first node) and from thereon it moves onward using existing migration paths. The onward-migration of an agent using existing migration paths is based on our assumption that migration paths are already established in a single complete ring fashion. To insert itself into the migration network, the agent modifies default migration targets of the last node and the printer, in a manner similar to insertion into a circular list. This way the plug-and-play printer becomes a part of the existing migration ring. The use of a Naming Facility, however, raises another issue i.e. how to locate a Naming Server on any network. We are addressing this issue by investigating another protocol, called the Service Location Protocol (SLP) [16], in conjunction with the DHCP. The SLP allows hosts to publish their services directly or by registering with an agent,

10

called a directory agent, and DHCP has provision of supplying the address of this directory agent as configuration options. The Naming Server would register with such directory agents and PnP component will receive the address of this directory agent during initial configuration via the DHCP. Later, the directory agent is approached to locate the Naming Server. In our implementation, we have resolved the issue temporarily by providing an initial target to our agents via a properties file. The default migration paths of our example network components are also programmed initially by us. Our future work focuses on this major issue and once we come up with enhanced framework, we will deploy it in our scheme. A minor issue is that the printer needs to store its vendor address somewhere in the form of URL as it needs to send many mobile agents towards the vendor. We assume that the vendors have already hard-coded this information into the device before shipping it out. Several other low-level issues are present that have not been addressed by us; e.g. network bandwidth, congestion, PnP component memory requirement, agent lost, vendor out of business, trading services etc. In this paper, our emphasis is on exploring the flexibility provided by the mobile agents in management applications. Here, we proposed one such management application, i.e. the configuration management using plug-and-play network components.

3.4 Evaluation Having implemented a plug-and-play scheme, we feel that the scheme based on mobile agents is superior to traditional client/server schemes. For us, the flexibility provided by the mobile agents is the biggest advantage. The other notable advantages of this mobile agent scheme are: − it is a platform-independent scheme since it uses Java both for the mobility framework and developed applications (agents and VMCs) − updating agents is easier as obsolete agents can be destroyed and replaced by updated agents dynamically using Java’s class loading features − the auto-discovery of network components is possible due to the presence of discovery agents on the managed network − the added component (PnP component) initiates the installation process and eliminates the requirement of polling by the operating system, as in the case of plug-and-play hardware of Windows 95. − components may always keep up-to-date drivers due to the notification provision There are, however, some drawbacks associated with the scheme: − big overhead is associated with running a JVM and a mobility framework on each network component. − well defined and powerful security schemes are needed because sending code over the network has inherent security risks. − considerable network bandwidth may be consumed by the permanent discovery agents if no attempt is made to control the density of such agents.

4. Conclusions and future work Mobile agents are an emerging technology that has great potential for future telecommunication and management applications. They offer considerable advantages like autonomy, intelligent behavior, asynchronous and real-time transactions and robustness [6]. It makes them an ideal choice for building applications for dynamic telecommunications and computer networks. Therefore, we have implemented the plug-and-play scheme based on mobile agent technology, using a simulated network environment and mobility framework. The results validated the theme that dynamic networks of plug-and-play services are possible in the near future. We plan to continue work on other enhancements related to the scheme. We will focus our future work for making provision of some Naming Facility in the network to provide more flexibility in the scheme. The use of DHCP with supporting protocols like TFTP [4], SLP [16] and DNS [12] will be investigated for the initial configuration of plugand-play components. Establishing migration patterns (paths) is another area for future work. Work is in progress for making enhancements like error control and recovery, auto-discovery of components and notification facilities for driver updates. After complete implementation of the mobile agent based PnP scheme, we will implement the

11

same scheme using CORBA platform. Finally, we plan to extend the idea of plug-and-play from a printer to other network components like routers and switches.

Acknowledgments This work is supported by grants from Communication Information and Technology Ontario (CITO) and Natural Sciences and Engineering Research Council of Canada (NSERC). Special thanks to Tony White and Cheryl Schramm for their help during the course of the project and Professors A. Bieszczad and B. Pagurek for conveying valuable knowledge on Network Computing, Network Management and related subjects.

References [1]

Baldi, M. and Picco, G. (1998); “Evaluating the Tradeoffs of Mobile Code Paradigms in Network Management Applications”; presented at the 20th International conference on Software Engineering (ICSE ’98); April 1998; Kyoto, Japan; http://www.polito.it/~baldi

[2]

Bieszczad A., Raza S. K., Pagurek B., and White T. (1998); “Agent-based Schemes for Plug-And-Play Network Components”; to be presented at an International Workshop on Agents in Telecommunications Applications (IATA’98); July 4-7, 1998; http://www.sce.carleton.ca/netmanage

[3]

Bieszczad, A. and Pagurek, B. (1997); “Towards plug-and-play networks with mobile code”; in Proceedings of the International Conference for Computer Communications ICCC’97; November 19-21, 1997; Cannes, France; http://www.sce.carleton.ca/netmanage

[4]

Bootstrap loading using TFTP; RFC 906; Internet Engineering Task Force (IETF); June 1984; ftp://ftp.isi.edu/in-notes/rfc906.txt

[5]

Carzaniga, A., Picco, G. and Vigna, G. (1997); “Designing Distributed Applications with Mobile Code Paradigms”; in Proceedings of the

19th

International

Conference

on

Software

Engineering,

pages

22-32;

May

1997;

Boston,

Massachusetts;

http://www.elet.polimi.it/~carzanig [6]

Chess, D., Harrison, C. and Kershenbaum, A. (1995); “Mobile Agents: Are they a good idea?” ; IBM Research Report; RC 19887 (88465); Intelligent Agents Project at IBM T.J. Watson Research Center; http://www.research.ibm.com/iagents/paps/mobile_idea.ps

[7]

Dynamic Host Configuration Protocol; Draft Standard RFC 2131; Internet Engineering Task Force (IETF); March 1997; ftp://ftp.isi.edu/in-notes/rfc2131.txt

[8]

Farmer, W., Guttman, J. and Swarup, V. (1996); “Security for mobile agents: Issues and Requirements”; In Proceedings of the 19th National

Information

Systems

Security

Conference,

pages

591-597;

October

1996;

Baltimore,

Maryland;

source:

http://www.cnri.reston.va.us/home/koe/bib/mobile.bib.html [9]

Fuggetta, A., Picco, G. and Vigna, G. (1998); “Understanding Code Mobility”; in IEEE Transactions on Software Engineering, vol. 24, no. 5, pages 342-361, 1998; http://www.polito.it/~picco/

[10]

General Magic Inc. ; “Mobile Agents White Paper”; web page: http://www.genmagic.com/technology/techwhitepaper.html

[11]

Ghezzi, C and Vigna, G. (1997); “Mobile Code Paradigms and Technologies: A Case Study”; In Proceedings of the 1st International Workshop on Mobile Agents; April 1997; Berlin, Germany; http://www.elet.polimi.it/~vigna

[12]

Interaction between DHCP and DNS; Internet-Draft ‘work in progress’; Internet Engineering Task Force (IETF); March 1998; http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcp-dns-08.txt

[13]

Microsoft Corporation (1994); “Microsoft Windows and the Plug and Play Framework Architecture”; March 1994; web page: http://www.microsoft.com/win32dev/base/pnp.htm

[14]

Mobile Agents Facility; Object Management Group, TC work in progress; 1998; ftp://ftp.omg.org/pub/docs/orbos/97-10-05.pdf

[15]

Mobile Code Toolkit; Version 1.0 (1997); under Perpetum Mobile Procura project, Network Management Laboratory, Carleton University, Ottawa; http://www.sce.carleton.ca/netmanage/mctoolkit

[16]

Service Location Protocol; Proposed Standard RFC 2165; Internet Engineering Task Force (IETF); June 1997; ftp://ftp.isi.edu/innotes/rfc2165.txt

[17]

Susilo, G., Bieszczad, A. and Pagurek, B. (1998); “Infrastructure for Advanced Network Management based on Mobile Code”; in Proceedings of the IEEE/IFIP Network Operations and Management Symposium NOMS’98; February 1998; New Orleans, Louisiana; http://www.sce.carleton.ca/netmanage

12