Heterogeneous Multi-Agent Architecture for ATM Virtual ... - CiteSeerX

Chapter 15: Mobile Agents for Managing Networks: The MAGENTA perspective* Akhil Sahai, Christine Morin INRIA-IRISA Campus de Beaulieu 35042 Rennes CEDEX, France asahai,[email protected]

1

Introduction

A network management system essentially manages a network. The management of network comprises of monitoring and control of a network. It plays an important role in the configuration, proper functioning, and maintenance of a network. Network management involves amongst other things the collection and visualization of network data, identification and management of faults, configuration and altering the behaviour of network components, and security management and control. A network management system necessarily comprises of one or more Network Management Stations (NMS) interacting with management agents statically located at the network elements being managed. The NMS and the management agents utilize a network management protocol for interaction. The existent network management systems essentially utilize client/server mechanism for all their functionalities. The client-server interaction model involves transfer of data or commands among static entities, in this case the NMS and the management agents. Data and commands form the mobile part of the computations while the entities themselves are static. As the computing processors become faster and the need of bandwidth increases the network interaction delays become a critical performance problem for distributed applications. Also the current NMS are centralized in nature and are responsible for almost all network management responsibilities while the peripheric devices perform minimal network management responsibilities. Mobile agents have been propounded as the computation paradigm for next generation computing. A mobile agent is a mobile code which in addition to being mobile, demonstrates the capability of autonomy, reactivity, proactivity and social ability . The mobile agent based solutions have been proposed to execute programs *

This work has been partially funded by Dyade, R D joint venture between BULL and INRIA

2 Sahai, Morin

asynchronously and remotely thus saving the network bandwidth. This makes their usage interesting in implementing delegation. Mobile agents can be utilized in network management to remove the constraints inherent in the present network management systems and to execute the network management program near the peripheric devices. They can thus be utilized to distribute and decentralize network management. Mobile code has been proposed earlier in network management [8][9]. In section 2, we present the state of the art in the domain. However, mobile agents being more general and being itinerant in nature can be utilized for implementing network management functionalities involving multiple network elements. The possible utilizations of mobile agents in network management is presented in section 3. Section 4 describes the Astrolog network management system, its components and the communication mechanisms it utilizes. Section 5 provides the details of the MAGENTA environment, which we have designed and implemented in this context. The quantitative comparison between the client/server and mobile agent technology is presented in section 7.

2

State of the art of mobile code in network management

2.1

Network management systems

A network management system as shown in Figure 1 typically consists of Network Management Stations (NMSs) interacting with management agents running on the network elements utilizing network management protocols and exchanging management information. A NMS is a computer system, typically a workstation, which executes network management applications. It provides the basic functionality of network management for a variety of different devices. The components of a typical NMS are: •

Management applications: management applications utilize the network information and provide various functionalities like monitoring, Event handling, Mib browsing, trouble shooting, performance, alarms etc. They usually utilize a programming API. An API is a library of programming procedures and functions allowing access to information kept within the NMS. The applications provide a graphical user interface to the users.

•

NMS kernel: It is central server of the NMS which interacts with the different components of the NMS and helps carry out the functionalities of the NMS. It obtains the requests from the management applications and passes them to the necessary daemons which obtain the result either from the DBMS or directly from the management agents and pass the result back to the management applications.

Moble Agents for Managing Networks: The MAGENTA perspective

3

•

Database management system (DBMS): The NMS uses standard methods to query devices as it must be capable of gathering information from many different vendor components. The information obtained from the devices is stored in the DBMS. A DBMS helps in many network management tasks. Management applications use it for information storage and to build relationships between data items, which help in network diagnosis and maintenance.

•

Stockage and retrieval mechanism: Information handling mechanisms are used for conversion, storage and retrieval of management information either from the DBMS or from the management agents. The information at the management agents is obtained by querying the variables defined in the MIB (Management Information Base) of the network element.

•

Management protocols: The NMS uses management protocols to communicate with agents running on the managed nodes. The information communicated between the NMS and agents is defined by a Management Information Base (MIB). The management protocols in use are simple network management protocol (SNMP), common management information protocol (CMIP) etc. SNMP is the commonly used protocol for network management because of its simplicity of installation and usage.

2.2

Mobile code in network management

The usage of mobile code has been proposed in the domain of network management. The mobile code is used to transfer and execute management code at the network elements. This helps in distribution of network management as all the management data need not be brought to the central NMS. This distribution reduces the load of the central NMS. The transfer of mobile code can be carried out in different ways. The mobile code could be either sent to the network element or it could be demanded by the network element depending on need. While in the former case the NMS plays the decisive role in deciding which code to be sent to the remote element, in the second case the decision is made at the network element which can be triggered by events at the network element. The more generalized form of a mobile code is a mobile agent, which can visit multiple network elements performing network management activities and retaining its state during their itinerary. A classification of different types of mobile codes is presented in [4]. They describe the above mentioned types of mobile code as remote evaluation (REV), code on demand (COD) and mobile agents respectively. In COD a component running on a given host can download and link on-the-fly the code to perform a given task from different (remote) component that acts as a "code server".

4 Sahai, Morin

Network Management Applications NMS Kernal Network Management Protocol

Stockage and Retrieval

DB

Network Management

Network Management

Network Management

MIB

MIB

MIB

Fig.1. A typical network management system In remote evaluation (REV) code is sent to the remote network element with parameters where it is initialized and executed and accesses the services locally. The mobile agents migrate with the code to be executed autonomously and access the resource of multiple machines. They suggest that the code on demand approach provides flexibility in network management by providing a facility of modifying the criteria of detection of events. The corresponding portion of the management agent code can be invalidated or replaced automatically with a new one retrieved from a code server thus they can be "patched" without any need to rebuild it. The REV approach can be useful for bandwidth saving and processing distribution as the code after it has been sent to a remote network element, sends only the relevant data back to the sender instead of sending large quanta of data, thus saving on the bandwidth. A similar attempt to classify the different possible types of mobile code depending on the applications they are utilized for has been made in the Perpetuum Mobile Procura project [8]. The mobile codes are classified as applets, servlets, extlets, deglets and netlets. Applets are downloadable programs while servlets are programs that can be uploaded to a network element to act as a server. An extlets is uploaded or downloaded to extend the functionalities of the recipient while deglets are delegated code to perform a given task. Netlets are integral parts of the network. Applets can be considered a type of mobile code as the code is brought to the user and executed close to the user. These applets are executed in a browser. A variety of


5

network management applets written in Java have been developed [16] [14] [7] [5]. These network management applets are constrained by the security model of the browser, which prevents the user applet from connecting to machines other than the one having launched it. Deglets are mobile code used to delegate task. In order to implement deglets for network management a mobile code infrastructure needs to be implemented. This infrastructure should be able to send mobile code from one network element to another. The infrastructure should be at least capable of receiving and instantiating the mobile code and of executing it. In addition they need to interact with the management agents, so a mechanism to interface the NMS and management agents capabilities with the mobile code capabilities needs to be furnished. One of the pioneering works in this domain has been the Management by Delegation (MbD) approach [9]. This approach dynamically distributes the management computations from the NMS to elastic servers (MbD-servers) at the devices where the managed resources are located. An MbD server is a process customized for network management and provides efficient bindings to management instrumentation and support for SNMP interoperability. In this approach the mobile code infrastructure is closely interfaced with that of the network management architecture. The approach provides for spatial and temporal distribution of management functionality. Spatial distribution reduces the physical distance between an application and the devices it manages by executing the management code near the network devices thus distributing the management load and saving bandwidth. Temporal or dynamic distribution is the capability of delegating new management code to the device when needed. Temporal distribution assists the developers of management applications to modify the management policies as administrative requirements change, and as the network grows and evolves. MbD eliminates the need for intensive network polling and therefore reduces the impediments of the present network management protocols. However, MbD code is limited in nature as it is not iterative in nature i.e does not involve more than one network element in its itinerary. They are also not autonomous and do not exhibit the capabilities of mobile agents in the stricter sense.

3

Mobile Agents in Network Management?

Mobile agents are generalized mobile code which satisfy one of the notions of agency [1]. As they are capable of conserving their state while being on the move at the same time and as their itineraries can involve multiple network elements, they can be utilized to implement a variety of network management functions, which are listed as follows: Distribution of management code Mobile agents can be used to distribute the code to the management agents as and when necessary, instead of moving large amount of data to the manager over the network which reduces substantially network bandwidth usage and reduces the network bottleneck as well as makes the architecture more

6 Sahai, Morin

scalable (e.g Mib filtering the amount of data involved is substantial). Decentralization They can be effectively used to decentralize network management activities. They do not need continuous attention of the administrator in some of the network management activities e.g installation and upgrade of software, periodic audit of network. Dynamic evolution of network management policies. As the network environment grows and changes the policies need to be changed over time and also in order to tackle temporally changing problems like intrusion detection the management policies needs to be altered. Instead of going through rewrite, compile and run cycle the management policies can be dynamically changed by writing new agents easily without altering the provided infrastructure. Monitoring and statistics Mobile agents are suitable for retrieving large number of samples of MIB variables and thus for studying the behaviour of network components over long period by accessing the MIB variables locally at the network element. Data Collection They are suitable for data collection, searching and filtering. Thus they can be used to query the servers for large quanta of data. High speed networks They are suitable for high speed network management (Gb/s) in which case it is not practical to bring all the network data to the manager, as the information may become redundant by the time it is brought to the central NMS. Autonomy The mobile agents can undertake local network management in case of the failure of the central NMS. They can manage one or more network elements in case of an emergency and being mobile can move from one element to another if need be. Automation A network element, in case of violations of the thresholds set for its network variables sends alarms to the central NMS. The central NMS needs to undertake corrective action. However, this process can be automated by implementing Code on Demand. In Code on demand the mobile agents can be dynamically brought to the network element on its demand and automatically to take corrective actions. The Astrolog network management system utilizes the mobile agent technology to implement some of its network management functionalities. The following section presents the components of the Astrolog network management system and the communication mechanisms it utilizes.

4

The Astrolog Network Management System

The Astrolog network management system [10] utilizes the MAGENTA environment to implement its functionalities. It is highly modular in nature. It comprises of managers, server and management agents (SNMP agents in our case) as shown in


7

Figure 2. The manager consists of the GUI and the application part of a typical NMS, while the server consists of the NMS kernel, the DBMS, the protocol and mechanisms for communicating with the management agents. There is thus a separation between the application and the kernel part of the NMS amongst the manager and server in our architecture. The network management load is thus distributed amongst the managers and the server and since the managers and servers typically execute at different sites there is a distribution of load over multiple machines. The managers are architecturally neutral and light-weight in nature. The servers obtain and store only the information which needs to be archived and comprises of various daemons which continuously collect information about the configuration changes in the network and perform network discovery. The network management system provides the possibility of adding multiple servers for larger networks and the number of servers is determined by the size of the network. In such a case the DBs needs to be replicated amongst the servers. The managers, server and the management agents are equipped with communication mechanisms to interact amongst themselves. Each manager is assigned a server however it can connect to other servers in case the assigned server fails (if other servers are available). This communication mechanism consists of client-server as well as mobile agent paradigm. The communication mechanism is chosen depending on the location of the manager and the suitability of the communication mechanism for the functionality being implemented. The architecture retains the client-server mechanism for interaction between the components. As is the case in traditional network management systems the managers can communicate with the management agents through primitives. They also interact with the servers through client-server mechanism. The managers, servers and the management agents are provided with the MAGENTA environment. The MAGENTA environment furnishes them the capability of sending, receiving and storing mobile agents.

8 Sahai, Morin

Fig. 2. The network management architecture

5

MAGENTA environment

MAGENTA (Mobile AGENT environment for distributed Applications) is a generic and portable mobile agent environment. MAGENTA introduces interesting mechanisms in the domain of mobile computing , fault tolerance of mobile agents, and in their execution. The MAGENTA environment has been written in Java which makes it available over a variety of systems.

5.1

Components of the environment


9

The environment comprises essentially of lieus and agents as shown in Figure 3. A lieu is a static program executing on a computer system intending to host an agent while mobile agents are mobile programs moving amongst the lieus.

Fig. 3. A schematic diagram of MAGENTA environment 5.1.1 Agents in MAGENTA environment The agents essentially are mobile programs that comprise of a state. The state of a MAGENTA agent consists of the values of the variables which are particular to the agent and which are retained and modified by the agent as it moves from one lieu to another. The state of an agent is initialized at the time of creation of an agent and is partially modified during its lifetime as the agent interacts with the environment afterwards. It comprises of variables the values of which are particular to an agent as shown in Figure 4. At the time of creation an agent is given a name which uniquely identifies it in the system. It is provided with a purpose to achieve. The purpose of the agent causes other agent fields to be set namely the perform field. The perform field carries the code to be executed by the agent. Depending on whether the agent intends to execute the code present at a lieu or it intends to carry the code with it, the perform field is set. The agent is also provided an itinerary (a list of sites to visit) and a permit which is used for authentication by the lieus, at the time of creation. Once the agent decides to move to another lieu it needs to have information about other lieus. In order

10 Sahai, Morin

to facilitate the movement of the agent it is provided with information about the lieu of its origin, namely launchingLieu. It also maintains the information about the precedent lieu in the precedentLieu variable and about all other lieus in the lieuTable. The agent while on the move, might discover the failure of lieus in its itinerary. This information is kept in the variable knowledge while the variable history keeps information about the lieus actually visited. The agent carries a note to be exchanged with other agent during a meet operation at a predefined lieu. A meet operation at a particular lieu allows the agents to exchange notes. It also utilizes buffer variable to carry large amount of code, if need be and folder to carry the results of its computations.

DATA STAE OF AN AGENT Name Purpose LaunchingLieu PrecedentLieu LieusTable Permit History Itinerary Folder Buffer Perform Note Knowledge Fig. 4. The data state of an agent 5.1.2 Lieus in MAGENTA Lieus provide the execution environment for the agents. The lieus have a globally unique name. They provide facilities for creation, execution, residence, interaction with other agents and migration of agents. They also maintain information about the agents launched by the lieu, agents resident in the lieu and the agents backed up on the lieu in addition to maintaining backup copies of the agents. They furnish a directory mechanism and provide static agents to access the system information. These lieus communicate with each other and can disappear and appear dynamically in the environment. They can also launch agents either on their own or on behalf of other lieus.

5.2

Characteristics of the environment

In addition to the basic mobile agent environment functionalities, the MAGENTA mobile agent environment provides for certain functionalities particular to it:


11

5.2.1 Different types of agent mobility MAGENTA provides for weak migration of agents i.e it provides for retention of the data state of the agent while on the move. However, it also provides for creation on demand and code on demand. In creation on demand a site/lieu can request another remote lieu to create and launch agents on its behalf. The results of the agent's computations can be obtained afterwards. Code on demand is a variant of agent mobility paradigm where a site requests another to send an agent to it with the desired code. 5.2.2 Naming Scheme In MAGENTA each lieu has a globally unique name. This name can be either chosen at the time of commencement of the lieu or can be automatically assigned. This renders the network transparent to the applications using MAGENTA. This enables the agents to interact with the lieus in a system and network independent manner. 5.2.3 Tolerating faults The agents because of their very nature of execution are prone to falling prey to numerous accidents. The lieus are also liable to disappear because of network element failures. Fault tolerance schemes have been provided to minimize the overheads associated in detection and recovery from such site failures. In MAGENTA we provide for disappearance and recreation of agents from a single fault at a time. We maintain backup copies of the agents in order to take care of abrupt disappearance of an agent. In order to reduce the number of backup copies and to reduce the communication which results in case of disappearance of an agent we employ a scheme to maintain judicious number of copies. A lieu before sending an agent to the next lieu saves a copy of it and takes the temporary responsibility of detecting the failure of the next lieu. The next lieu after sending the agent to another lieu informs the lieu with the backup to remove the backup. The lieu with the backup periodically performs checks on the next lieu until it receives a message from the next lieu to destroy the backup. In case such a message is not received by the lieu with the backup within timeout and if it detects that the next lieu has crashed it recreates the agent from the backup copy. This is explained with an example as shown in Figure 5. Before an agent moves from a lieu, lets call it a lieu A to the next lieu, say lieu B it makes a copy of itself on lieu A. Lieu B processes this agent and makes a copy of it before moving it to the next lieu, say lieu C. As soon as the agent is successfully moved to the lieu C, lieu B requests lieu A to delete the copy of the agent. In case lieu B discovers that it is not possible to move the agent to lieu C because of some problem, it tries to reach lieu D. In case this operation is successfully carried out it asks lieu A to delete the copy. Lieu B after successfully moving the agent to the next lieu waits for a message from the next lieu, say lieu C. In case, the lieu C fails to send message to lieu B, lieu B understands that lieu C has not been able to move the agent to the next site in the itinerary because of some problems. It thus first does its own check to find out the problem. In case lieu C has crashed, the backup copy of the agent on lieu B is used to create the agent, which is passed to the next alive lieu. This scheme thus takes care of

12 Sahai, Morin

single fault and regeneration of agent by keeping the messages to a bare minimum. Lieu A

Lieu B

Agent copies itself and m oves from Lieu A to Lieu B Lieu C Lieu B Lieu A

Agent successfully m oves to Lieu C from Lieu B Lieu A

Lieu B

Lieu C

Lieu B request Lieu A to delete its copy Lieu A

Lieu B

Lieu D

Lieu B does not receive m essage from Lieu C which, crashes. Lieu B checks and sends agent to Lieu D instead.

Fig 5: The implementation of fault tolerance scheme 5.2.4 Tracability of agents In MAGENTA a directory service has been provided so as to trace the agents. Every lieu can request all the other lieu about the latest information about the agents present on them and launched by them. This comes in handy to any lieu to determine the status of execution of agents sent by it. 5.2.5 Flexibility of location of code The agent can either bring the code to be executed along with it or can execute code present at a remote site. The choice of the location of the code to be executed thus can be made depending on the resources available and the frequency of usage of the code. If the code needs to be used over a long period of time it can be placed at the remote site however if the code is to evolve over time the code is brought by the agent. 5.2.6 System independence MAGENTA is implemented using Java programming language, in order to have a


13

system independent implementation. It was envisaged that for some network management applications it was necessary to access system information. Different systems use a different path separator and also need different native method implementations. So an effort was made to satisfy the requirement and at the same time maintain the system independence of MAGENTA. Dynamic class loaders were written for a lieu. The Native method implementations are thus loaded on the fly in case they exist. In the absence of such implementations and error is provided to the agent. A dot-notation has also been used to take care of the different path separators available on different separator.

6 The functionalities of the Astrolog network management system The network manager has been provided a variety of mobile agent based functionalities. These functionalities range from performance study of network components to installation of software at multiple remote sites. Following are some of the functionalities. Performance The manager can either obtain the values of the SNMP variables from a remote SNMP agent by using client server technique or can use mobile agents for the same. In case of client server mechanism the get, get-next, set request primitives are used to interact with the network components. While using mobile agents, the agent is given a number of samples, multiple oids (Object identifiers) and component's lieu name. The agent moves to the network component studies the oid values for a given number of samples and comes back to the manager carrying it's results in its folder. The studied values can be displayed in charts namely histograms, bar, pie and line charts. This is also useful for studying behaviour of network components over a long time. Install The agent is provided a software, the directory where to install the software and a list of network components. The agent moves from one component to another installing the software and returns with the results in its folder. MAGENTA uses a dot notation to overcome the problem of different path separators in different operating systems. These dots are replaced by local class path separators. In case the desired directory is not found the mobile agent installs the software in a default directory provided by the lieu. The folder of the agent contains the information about which components have the software installed and on which of them the agent was unable to install the software. The same agent is also used for software upgrade. Audit The agent is provided a list of parameters to look into e.g disk usage, system and application configuration, users using the machine etc and a list of network components. The agent moves from one host to another finding all the required information and comes back to the manager with all these results in its folder. Retrieve The agent is told to retrieve the desired information from one or more

14 Sahai, Morin

components. It is used to query the server for large quanta of information, especially to study the archives. Net checker The agent moves to the lieu on the server and performs, get, on all the SNMP variables from a list of SNMP agents provided by the manager. This is useful to test the status of the health of the network.

7

Performance evaluation

As the network management system is capable of utilizing the client-server and mobile agent technologies for implementing the basic network management functionalities, we have compared the performance of the two technologies over different platforms and under varied operating conditions.

7.1

Context

The performance evaluation was carried out on our local distributed system Astrolab. It comprises of heterogeneous machines running several different operating systems and connected by a 10Mbps Ethernet LAN. The machines are PCs (running Win95, WinNT, Linux, NetBSD), SUN Sparcs executing SunOs4.x, SunOs5.x and AIX Workstations. For the purpose of testing, SNMP agents were run on a variety of machines in the Astrolab environment. The server for the network management system was run on the machine Astrolog. Astrolog is an IBM Estrella machines having AIX 4.1 as its OS. The machines used for the performance evaluation are shown in the Table 1. Name OS Type Processor details Cezembre Windows 95 IBM Thinkpad Pentium PC 120Mhz 700CD Wallace SUN OS 5.5 SUN Sparc 5 MicroSparc II CPU, 110 Mhz Astrolog AIX 4.1 IBM Estrella 300 PowerPC 604e 166Mhz Table 1. Machines utilized for performance evaluation

7.2

Comparison between client server and mobile agents

We have compared the technologies for the basic network management functionality of retrieval of SNMP variables from single and multiple machines and for varying number of samples of the variables. 7.2.1 Varying number of samples The manager was executed on Wallace. The SNMP agent was located on the machine Astrolog connected on the same Ethernet. In the case of client-server, the response


15

times were noted by sending SNMP get requests from Wallace to Astrolog and the responses were obtained at Wallace. The total time taken until the last response packet received for the given number of sample queries were noted. In the case of mobile agent, a single agent was sent from Wallace to Astrolog and the agent performed the get request locally and brought back the values in its folder, as shown in Figure 6 . The response time in this case was noted. The comparison between the response times are depicted in Figure 7. The packet sizes of the SNMP get query and that of the response were noted to be 40 bytes and 31 bytes respectively. The size of the agent sent (10K) and received were also noted and the bandwidth utilization estimation based on the above measures is depicted in Figure 6. The estimations utilized are as follows: Estimation: In case of client-server paradigm, the manager sends queries to the SNMP agent. Let the size of the query be Qn. The SNMP agent responds back with a response PDU. Let the size of the response be Rn. So total cost in the case of client server mechanism will be

Tcs =

N n =1

(Qn + Rn )

We measured the Qn = 40 bytes and Rn to be 31 bytes. So, Tcs = (71/1000)n Kbytes, where n is the number of queries sent. In case of mobile agents paradigm, the agent moves to the site executing SNMP agent obtains the results locally and returns back to the manager. Let Sma be the size of the agent as it is sent by the manager. The agent accumulates results at the SNMP agent. Let the size of the results accumulated be Rn, which is dependent on the number of SNMP queries done locally. So total cost Tma will be

Tma = ( S ma + S ma +

N n =1

Rn )

The Sma is measured to be 10K and the N n =1

Rn = ηn

where η is measured to be 1/200 (The size of one result in Kbytes). The total cost of the mobile agent so estimated is thus:

Tma = (20 +

n ) 200

The corresponding graph is shown in Figure 8 and another graph for 5 SNMP variables is shown in Figure 9.

16 Sahai, Morin

The comparison is pessimistic because even a small amount of data, as is the case in client-server, might require a large UDP packet. The curve for the mobile agent starts at 20K bytes as the size of the agent sent is 10K bytes. The increase in size of the agent results from the data collected at Astrolog. As shown in Figure 7 in terms of response times the client-server is faster only for collection of few samples after which it becomes relatively costly to utilize. However, in terms of bandwidth utilization, client-server is beneficial up to a threshold of 300 samples after which the mobile agent technique becomes more effective. A similar comparison of bandwidth utilization for samples of 5 SNMP variables is shown in Figure 8. In this case as shown in Figure 9 as values of 5 SNMP variables are obtained from the SNMP agent the threshold is much lower in this case as the data obtained is much larger compared to above. The client server approach thus utilizes less of bandwidth upto 60 samples each of 5 SNMP variables from the SNMP agent. The mobile agent approach performs better after the threshold. Thus mobile agent approach is suitable for long term monitoring of a network component, while for short term monitoring it is advisable to utilize a client-server technique.

Fig. 6. Schematic representation of the test setup for varying number of samples 7.2.2 Varying number of machines The manager implements management functionalities that need interaction with multiple machines for performing the function. This could be a performance monitor of multiple machines, software installation and update, audit of the network components etc. We compared the response times of the client server and the mobile agents for performing monitoring of a SNMP variable. In this case the manager was


17

executed on Cezembre.

Fig. 7. Comparison of response times for varying number of samples of a single SNMP variable In the client server case, the manager connected to multiple machines one by one to collect the required number of samples of a SNMP variable while in the case of mobile agents, a single mobile agent was sent to multiple machines which collected the required number of SNMP variables in its folder and returned to the manager after traversing its itinerary, as shown in the Figure 10. In Figure 11, the comparison of response times is shown for 10 samples of SNMP variable were collected while in Figure 12 and in Figure 13 , a similar comparison for 100 and 200 samples respectively is depicted. The bandwidth utilizations in this case involving multiple machines are estimated as follows:

Estimation In the case of client server paradigm, as multiple machines are involved the total cost will be multipled by the number of machines involved. The cost will be,

18 Sahai, Morin

T cs =

71nm Kbytes 1000

In case of the mobile agent paradigm, the mobile agent visits multiple SNMP agents and obtains the results successively from the SNMP agents and returns back to the manager after collecting the results. The total cost would be,

Tma = ( S ma ) + ( S ma + nη ) + ( S ma + 2nη ) + ... + ( S ma + mnη ) which makes the total cost

Tma = (m + 1) S ma +

ηnm(m + 1) 2

η has been measured to be 1/200 Kbytes, where n is the number of samples desired. So total cost for the mobile agent is

Tma = 10(m + 1) +

nm(m + 1) 400

The estimated bandwidth utilization for the collection of n = 400 samples of a SNMP variable from multiple machines by either client server or mobile agents are compared in Figure 14. It shows that the utilization of mobile agents has lesser BW utilization till a threshold value of number of machines (in this case 17) is reached. After the threshold value, the agent should either empty its folder or a new agent needs to be launched.

Fig. 8. Comparison of bandwidth utilization for varying samples of a single SNMP variable


19

Fig. 9.Comparison of bandwidth utilization for samples of 5 SNMP variables Fig. 10. Schematic representation of the test setup for varying number of machines

20 Sahai, Morin

Fig. 11. Response times for collection of 10 samples from multiple machines

Fig. 12. Comparison of Response times for collection of 100 samples from multiple machines.

Fig. 13. Comparison of response times for collection of 200 samples from multiple


21

machines.

Fig. 14 Comparison of BW utilization for 400 samples of a single variable from multiple machines It is thus apparent that the client server and mobile agent technologies should be used depending on the number of samples which need to be accessed and the number of network elements involved in the operation. While accessing information from a single SNMP agent the client server technique is suitable if the information sought is short term in nature. Mobile agents are suitable for long term monitoring of a network component. In case of accessing multiple elements and when the information collected is substantial the mobile agent should have a limited number of machines in its itinerary. However for cases where the agent does not grow in size substantially a large number of machines can be incorporated in the itinerary of a single agent.

8

Conclusion

Mobile agent technology is well-suited to the domain of network management. The Astrolog network management system utilizes the mobile agent technology to implement some of the network management functionalities. For a basic network management functionality like retrieval of SNMP variables, the mobile agent technology compares well with the client server technology in terms of response times and bandwidth usage. The utilization of mobile agent technology in the domain of network management is being impeded by the lack of security mechanisms. Some

22 Sahai, Morin

research efforts are being undertaken to ameliorate the situation . With proper security mechanisms in place, the mobile agent technology has a potential of changing the way network management is done traditionally.

Bibliography 1. 2. 3. 4.

5. 6. 7. 8.

9.

10.

11.

12.

13. 14. 15. 16. 17.

18. 19.

Beale, R and Wood, A. 'Agent Based Interaction in People and Computers IX' : Proceedings of HCI'94, Glasgow,UK, August 1994 , pp 239-245 Case J., Fedor M., Schoffstall. M, and Davin J. 'A Simple Network Management Protocol (SNMP)'RFC 1157. Stallings, W. 'SNMP, SNMPv2 and CMIP: The practical guide to network management standards'. Addison-wesley publication, 1994. Baldi, M Gai, S., Picco, G. 'Exploiting Code Mobility in Decentralized and Flexible Network Management'. In the proceedings of Mobile Agents 97 (MA97), Stuttgart, Germany Product jsnmp at OutBack Resource Group, Inc. http://www.outbackinc.com/ Webbin CMIP product at IBM http://www.alphaWorks.ibm.com/ Product Tengah at Weblogic. http://www.weblogic.com/ Andrzej Bieszczad, Bernard Pagurek. Application-Oriented Taxonomy of Mobile Code. IFIP/IEEE Network Operations and Management Symposium (NOMS'98), Feb. 1998, New Orleans, USA Goldzmith G. and Yemini, Y. Decentralizing Control and Intelligence in Network Management. In the Proc. of 4th International Symposium on Integrated Network Management, Santa Barbara, CA, 1995. Sahai A., Morin C. Mobile Agent Enhanced Thin Client Approach to Network Management. In Proceedings of IEEE Singapore International Conference on Networking (SICON),July 1998, Singapore Sahai A. and Morin, C. Towards Distributed and Dynamic Network Management.In the Proc. of Network Operations and Management Symposium (NOMS'98) New orleans, LA, USA Mar. 1998, http://www.irisa.fr/solidor/work/astrolog.html. Sahai A., Morin C. Mobile Agents for Enabling Mobile User Aware Applications. In Proceedings of the Second International Confernce ACM Autonomous Agents (Agents 98), May 1998, Minneapolis/St.Paul, USA Wooldridge M. and Jennings R. N. Agent Theories, Architectures, and Languages: A Survey. Springer-Verlag Lecture Notes in Artifical Intelligence 890, pp 1-39 Advent Net Monitor fabricated by Advent Network Management Inc. http://www.adventnet.com. Java Management API by Sun MicroSystems. http://java.sun.com/products/JavaManagement/. Integrated System Management/ Open Master by BULL. http://www.ism.bull.net/. Sander, T. Tschudin, C. Protecting Mobile Agents Against Malicious Hosts. em In Vigna, Giovanni (Ed): Mobile Agents and Security, Springer-Verlag, 1998. http://www.icsi.berkeley.edu/ sander/publications/MA-protect.ps Hohl, F. An approach to solve the problem of malicious hosts. Technical Report Nr. 1997/03, Faculty of Computer Science, University of Stuttgart, 1997. Sahai,A. Morin, C. Mobile Agents for Location Independent Computing. In the proceedings of ACM Symposium on Applied Computing (Special Track on Mobile Computing), San Antonio, Texas, Feb, 1999 (to appear).