Mobile Agent Based Approach for Efficient Network Management and ...

Mobile Agent Based Approach for Efficient Network Management and Resource Allocation: Framework and Applications 


 

 




Symeon Papavassiliou , Antonio Puliafito , Orazio Tomarchio , Jian Ye  

New Jersey Institute of Technology

Electrical and Computer Engineering Department Broadband, Mobile and Wireless Networking Laboratory New Jersey Center for Multimedia Research University Heights, Newark, New Jersey, 07102, USA [email protected] 

Dipartimento di Matematica, University of Messina Contrada Papardo, 98166 Messina, Italy [email protected]



Dipartimento di Ingegneria Informatica e delle Telecomunicazioni, University of Catania Viale Andrea Doria 6, 95125 Catania, Italy [email protected]

Abstract Agent programming technology has emerged as a flexible and complementary way to manage resources of distributed systems due to the increased flexibility in adapting to the dynamically changing requirements of such systems. A very promising application of this technology is related to the control of forthcoming networking systems which will represent a competitive marketplace with a multitude of vendors, operators and customers. Thus, new reference models have to be investigated in order to better satisfy users’ requirements in a framework where resource allocation is provided under the control of different and often competing stakeholders (users, network providers, service providers, etc.). We believe that autonomy is one of the features that will characterize the behaviour of agents in such environment: autonomous choices will be taken as the result of coordination among different cooperating software entities. Following this direction, we describe the efficient integration and adoption of mobile agents and genetic algorithms in the implementation of a valuable strategy for the development of effective market based routes for brokering purposes in the future multi-operator network marketplace. The proposed genetic algorithm provides a kind of stochastic algorithm searching process in order to identify optimal resource allocation strategies. The agent-based network management approach represents an underlying framework and structure for the multi-operator network model, and can be used to facilitate the collection and dissemination of the required management data, as well as the efficient and distributed operation of the algorithm. We also present some numerical results to assess the performance and operation effectiveness of our approach, by applying it in some test case scenarios.

Keywords: mobile agents, network management, genetic algorithms, resource allocation 

Corresponding author: Prof. Symeon Papavassiliou, Electrical and Computer Engineering Department, New Jersey Institute of Technology, University Heights, Newark, NJ 07102, USA. Telephone: (973)642-7817, Fax: (973)596-5680, E-mail: [email protected]

1

1 Introduction The growth of commercial activities across networks has let to the network itself becoming a competitive marketplace with a multitude of vendors, operators and customers. In this environment, users will be able to choose from a wide range of network services, which provide different bandwidth requirements and various Quality of Service (QoS), and which will operate under different pricing schemes [19]. Technical and market forces are driving the evolution towards the traded resource service architecture (TRSA) model whereby network resources such as, bandwidth, buffer space and computational power will be traded in the same manner as existing commodities. To cope with these fast changing and complicated environments, users, whether buyers or sellers, need tools that facilitate expertise brokering activities such as, buying or selling the right products, at the right price, and at the right time. The brokering process will be guided by user preferences, which need to be processed according to some customized logic. The mobile agent technology seems to be a natural choice for dealing with these issues. The new emerging technology of agent programming has arised in the distributed programming field as a flexible and complementary way of managing resources of a distributed system and is a challenging opportunity for delivering more flexible services and dealing with network programmability. Distributing intelligence across the network allows the fast exploitation of more advanced services that can dynamically adapt to the user’s requirements. This also implies a strong integration of the user and the network perspective. User requirements have to be automatically translated into network requirements, and this implicitly assumes the possibility to interact with the network equipment. Network Providers (NP) need application level information to better manage their resources satisfying user needs and minimizing their costs. On an other hand, content providers (CP) have the knowledge of the network resources needed by their services in order to be properly accessed. Programmable networks are then the direction to go, although the technology is still in its infancy, and a lot of technical problems have to be solved. Which are the drawbacks of opening network equipment to software coming from the network? Do network providers have any convenience in doing so? How to guarantee adequate security levels? These and many others are typical questions that arise when discussing about the opportunity to have programmable networks [9, 8, 1]. Nevertheless, ad hoc software sent across the network may allow to use network resources more effectively, as they can be directly controlled at the application level. In this paper an agent based approach is investigated to provide the underlying framework for the implementation of efficient network management and resource allocation methods. Specifically the proposed agent based approach is used as an effective method for performing basic management operations of a network, such as collection of information about the state of the network, management of network devices through the monitoring of health functions, distribution of various functions and balancing of computation load inside the network, etc. We demonstrate the use of such an approach and structure by building a framework where resource allocation is provided under the control of different and often competing stakeholders (users, network providers, service providers, etc ). As a specific case for brokering resources, the paper describes the use of genetic algorithms technology, as a tool for the development of effective market based routes for brokering purposes in the future network marketplace. Specifically we use a genetic-based approach to calculate the optimal route from an end user to the corresponding content provider, in an environment where the set of feasible solutions can become very large, and the optimal solution identification involves many parameters and could result as a combination of multiple network providers. For demonstration purposes in this paper, the proposed approach is applied in a test case scenario where the optimal minimum cost path is identified in a multi-operator networking environment, under a predefined delay constraint. Following similar approach and reasoning, additional Quality of Service characteristics and constraints can be easily included into the overall routing problem. We also demonstrate that the use of mobile agents facilitates the implementation of this approach in an efficient way and helps overcome some of the issues associated with the need for distributed operation of the proposed genetic algorithm in the networking environment under consideration. Although our research and the results presented in this paper have been motivated by the use of our proposed methods in a brokerage environment, it can be extended 2

and used in many other scenarios where resource allocation and/or other functions are required to support different kind of services. The rest of the paper is organized as follows. Section 2 introduces the use of agents and mobile code as means to achieve customized system and network management. Section 3 describes a specific platform for the development and the management of mobile agents that gives all the primitives needed for their creation, execution, communication, etc. In sections 4 and 5 we present a commercial important application of a multi-operator network, where the use of mobile agents and genetic algorithms provide an effective infrastructure and strategy for the identification of efficient market-based routes. We also provide a detailed description of the actual integration of the genetic based algorithm in the framework of mobile agents and identify the roles of the individual elements (e.g. various agents) involved in the overall operation. Finally in section 6 we present some numerical results that demonstrate the operation and effectiveness of our strategy in some test cases, while section 7 concludes our paper.

2 Customized system and network management by means of mobile agents In order to provide each customer with the opportunity of implementing his/her own policy, trading costs with service quality according to his/her own preferences and capacities, network service must be open, flexible and configurable upon demand. A first step towards the realization of a programmable network is that of using an agent-based approach, in order to obtain a faster time scale of service deployment. A major incentive for an agent-based approach is that policies can be implemented dynamically, allowing for a resource-state-based admission and reservation strategy. Agents are used to discover about resources available inside the network and claim resources on behalf of customers according to some ”figures of merit” [3], which represent trade-offs between bandwidth claimed and loss risk incurred due to high utilization. Different customers may pay for resources in a different way, negotiating the costs for obtaining a certain ”figure of merit”. Agents are able to trigger adaptation of applications inside the network on behalf of customers. This allows for an immediate response to resource shortages, decreases the amount of useless data transported, and reduces signaling overhead. Mobile agents [4, 5] provide the highest possible degree of flexibility and can carry application specific knowledge into the network to locations where it is needed, following an approach similar to the one shown in some other programmable network projects [6, 1]. From a historical perspective, the use of mobile code has been introduced in network management as an alternative to the more traditional centralized approach, according to which the network management station (NMS) periodically accesses the data collected by a set of software modules placed on the network devices, by using an appropriate protocol. The centralized paradigm adopted by the SNMP (Simple Network Management Protocol) is appropriate in several network management applications, but the quick expansion of networks has posed the problem of its scalability, as well as for any other centralized model. At the same time, the computational power of the network nodes to be managed has increased, and has made possible significant functions of management on the nodes in a distributed mode. Centralization is generally appropriate for applications with a limited need for distributed control, that do not require a frequent polling of MIB (Monitoring Information Base) variables, and need only a limited amount of information. The typical example of this is the monitoring and the related displaying of some MIB variables. For example, the state of the interface of a router, or the state of a link involve only the query and the displaying of a limited number of MIB variables, and is therefore suitable for a centralized management. On the other end, we have some applications requiring a frequent polling of several MIB variables, which need to perform some computations on a large amount of information. An example could be the computation of a function that indicates the functionality level of the network, which must frequently detect the variations on a high number of MIB variables. In these cases, the monitoring and the control should be very close to the device. The drawbacks of the centralized approach are more evident in the periods of network congestion, when the manager’s action is very important. In fact, during those periods, the management operations required for overcoming the congestion cause an increase in the traffic close to

3

the congested part of network. By adopting mobile code technology in network management it is possible to overcome some limitations of the centralized management approach. In general, such technology is based on the idea of reversing the logic according to which the data produced by network devices are periodically transferred to the central management station. Management applications can then be moved to the network devices, thus performing (locally) some micromanagement operations, and reducing the workload for the management station and the overhead in the network [12]. This idea was expressed before developing the first systems based on mobile code. In fact, the idea of management by delegation, which is present in [14, 13], shows an architecture where the management station sends some commands to the remote device (instead of limiting to the request for MIB variables), delegating the remote agent to the actual execution. Of course, remote devices include a so-called elastic process runtime support, which can provide for new services and dynamically extend the ones present in the device. The approaches based on mobile code may include the management by delegation as a particular case, since their field of application is wider, and they are more flexible. In the following we briefly examine the management functionalities that can take advantage from the adoption of a specific scheme based on the mobility of the code. Use of Code on Demand The Code on Demand paradigm relies on a client which can dynamically download and execute code modules from a remote code server. The client has no need for unnecessary code installed, except for the runtime system allowing these mechanisms. Java applets are a very common example of such type of technology. The use of an approach based on Code on Demand increases the flexibility of the system, and maintains agents simple and small at the same time. In fact, the structure of the MIB in the SNMP approach is codified in the snmp-agent, and cannot be modified. The snmp-agent can in no way manage events defined by the user, nor it can act locally without involving the NMS. Maintaining management agents as simple as possible was one of the project restrictions followed while developing the SNMP, due to the limited computation capabilities of network devices. This was true until some years ago. Now, such devices have more powerful processors, and higher amounts of memory. However, we cannot think (this is not effective) of statically codifying all the management functions in an agent. In fact, a function (due to the specific nature of such applications) might be requested only on some devices. On other devices it could be seldom requested; on other ones it might be requested more frequently, while in other devices it would not be necessary. It is therefore clear that the static inclusion of such functions in an agent would lead to a considerable waste of resources. Using a code-on-demand approach, only when a function becomes necessary on a node, it can be downloaded from a code server and dynamically executed [16, 2]. In the same way, each software update requested by the agent can be obtained through this approach. Use of Remote Evaluation In the Remote Evaluation paradigm, a client sends a procedure to be executed on a remote host, where it is run up to the end; the results are therefore returned back to the client host which sent the code. This paradigm allows to deal with the issue of the bandwidth waste that occurs in a centralized system when micromanagement operations are needed. In a traditional system, no matter which processing has to be performed on the data of the device, they have to be moved from the snmp-agent to the NMS, where they are processed. Conversely, thanks to the mechanism of Remote Evaluation, the actions to be performed can be developed and sent to the remote device, where they will be executed without generating traffic in the network (except the initial one for sending the code to be executed). A typical example is the computation of the so-called health functions [13, 2]. In general, by health function we mean an expression consisting of several elementary management variables. Each variable provides a particular measure concerning the device to be controlled. In traditional systems the computation of this function is performed by transferring the variables involved in the NMS (through polling operations at regular time intervals), and doing the computation on site. In this way, the higher the number of the variables involved (or the frequency at which such a function has to be computed), the larger the amount of bandwidth occupied in the network (and the

4

computational load produced on the NMS) will be. By using a technology based on Remote Evaluation, we can compute these functions directly on the devices, and only when necessary. The code that performs such computations will be sent by the NMS and dynamically executed. This approach allows obtaining what is called ”semantic compression of data”. In fact, generally the manager of a network is not interested in the single value of a MIB variable, but in aggregate values containing higher-level ”information”. We can therefore develop a system in which the manager writes its management functions (or they might be already available), and then invokes their remote execution on specific devices, when necessary. Use of mobile agents The use of approaches based on mobile agents adds more benefits to the ones that can be obtained with remote evaluation. In fact, in this case the action on a device is always expressly started by the NMS. Conversely, in the case of mobile agents, the ability to store the state during the movements allows to develop applications in which the agent moves from a device to another, performing the management functions required. Besides, the agent can be delegated the task of deciding where and when to migrate according to its current state, thus reducing the interaction with the NMS, and making processings more distributed. The reduced interaction with the NMS is an advantage if we refer to situations in which the NMS has to manage different LANs and is linked to them by unreliable and/or low bandwidth links. In these cases, a traditional approach, which requires the exchange of several messages among the NMS and remote devices for a single operation, would mean delays in the execution of management operations, as well as their unreliability. Conversely, if we use mobile agents, once a given management function (which has been developed according to this new model as a mobile component) is sent to the remote environment, it can be run there. Once the agent has arrived at the LAN, it can execute the task he was delegated to do: in this case even if the agent’s size increases, there will be no negative effect, since we can always assume to have enough bandwidth available in a LAN. When it completes its task, the agent can report only the result to the NMS, without the need to go back to the original node carrying again all its code .

3 Network management using MAP 3.1 MAP overview In this section we introduce the agent system MAP [2], a platform for the development and the management of mobile agents that gives all the primitives needed for their creation, execution, communication, migration, etc. It has been entirely developed in Java, and this guarantees its total portability on the different hardware and software architectures. Java is also used as a language for programming agents, which can therefore exploit all of the potentialities of a complete object-oriented language. One of the features introduced in the latest MAP version is the compliance with the MASIF (Mobile Agent System Interoperability Facility) standard [7]. This is a standard for the interoperability of several agent systems, and is introduced by OMG. In fact, during the last few years, several agent systems have been created; such systems are different in architecture and implementation. Due to the improved research in the area of mobile agents, new basic requirements have appeared, which any agent platform should have. However, even if such functionalities are present in many agent systems, the differences in architecture and implementation make their interaction very difficult (or even impossible), thus preventing the agent technology from being used in some applications. The MASIF standard has been introduced in order to solve this problem and help the interaction among different systems, by defining a set of basic interfaces with which the systems must comply, in order to communicate and interact. The interfaces specified by MASIF are the following ones: MAFAgentSystem (which concerns the management, the transfer and the execution of agents) and MAFFinder (which provides the methods needed for locating and identifying agent and agent system, by considering a central component for their registration). Figure 1 presents the architecture of the MAP platform and its relation with the basic entities of the MASIF standard.

5

MAP Server

Region

Region Registrator MAFFinder

Dynamic Network ClassLoading MAP server MAFAgentSystem

Context CodeServer

MAP server MAFAgentSystem

Communication Interface

Agents

ORB

Figure 1: Architecture of the MAP agent platform

The compliance with the MASIF standard enables our agent system to interact with the CORBA world; this way, our system can re-use and access legacy services present in the network. The flexibility provided to the proposed management system is considerable, since the possibility of integrating management mechanisms based on CORBA [18] is added to the peculiar aspects of the mobile code (that have already been mentioned before). Security is another crucial aspect for agent systems. Besides, this aspect is more important if we consider the field of application of interest in this paper. In fact, the management of a network requires high levels of security: setting some crucial parameters in a network device might damage the functionalities of the network, so they should be allowed after a certain user authentication. Adequate access control mechanisms should be present. These issues have been dealt with in MAP by developing an adequate model of security adapted to the specific issues of the agents; this model will have to assure a high level of protection to the agents and the hosts, so that the hosts can be protected from the attacks of unsafe agents, and the agents can run on the hosts of the network without being damaged [15, 17]. Generally speaking, we need to avoid that the execution of an agent coming from outside damages the local machine, and to assure the possibility of identifying the entity who triggered and/or produced the agent. The security model developed for MAP considers the issues of authentication and authorization, in order to protect - on one hand - the hosts from the agents, and - on the other hand - the agents from the other agents and from the attacks coming from the network. In this area, the issue is finding a responsibility for the agent’s actions. We therefore make a distinction between the author of the agent’s code and the user who uses it by triggering its execution. Some rules, which are called security policies, are fixed for each node. With these rules we specify the conditions according to which the agents can access the resources; we also specify the authentication needed for the entities for performing some operations, and the level of security in the communication among the agents on different hosts. The techniques adopted make use of public key signing and encryption provided in Java 2. Finally the platform is provided with a graphical interface (shown in Figure 2) which enables a simple and efficient use of the system.

3.2 Management application In this section we show how, by using the services of the MAP platform, we have developed an agent-based application for performing the basic management operations of a network. The purpose of the implemented agents is to prove the effectiveness of an approach based on the mobility of the code for solving some of the issues described before. In particular, using the developed agents we are going to deal with the following issues: collection of information about the state of the network [11, 16] micromanagement of network devices through the monitoring of health functions defined by the network manager. The application through which the actual management agents are triggered and run, has been structured as an agent (called snmp-monitoring). Through the graphical interface of this agent we can select the agents to be sent to the 6

Figure 2: Graphic interface for the management of MAP

network, control the list of the active agents in the network, and evaluate the information collected by the agents that have finished their task. According to the type of agent selected, an appropriate dialog box is viewed. Through this box, the typical parameters for a kind of agent can be specified. By structuring the ”snmp-monitoring” application as an agent we obtain an immediate advantage: the independence of the NMS physical location. This means that the manager is no longer constrained to work only from a single location to control the network. At any time and in any place (only a MAP server is required) he can gain access to the full functionalities of the snmp-monitoring application. One of our purposes in the creation of the platform has been the complete integration and compatibility with the SNMP world. For this reason, in our system we have integrated and used some classes created by Advent[10], which implement the SNMP stack. In this way, we have had the opportunity to interact with the different nodes of the network through standard MIB variables. At the same time the developed framework allows us to monitor non-standard quantities (not defined by a MIB) defined by the user.

3.3 Agents for the management We have developed the following basic types of mobile agents for the Management. They perform very simple tasks, but the combination of their actions allows to perform even very complex actions of management. However, our purpose is not creating a complete management system, but showing how the ideas presented before can be easily implemented by our agent system. browser agent: The browser agent collects some MIB variables from a set of nodes specified by the user. Both the variables of the mib-tree to be collected and the servers to be visited are selected through an appropriate dialog box (Figure 3) of the application ”snmp-monitoring”. After being started, the agent reaches the first node to be visited, opens a Snmp local communication session, builds a pdu-request containing the MIB variables to be searched, waits for the reply from the Snmp daemon, and saves the data obtained in an internal structure. Then, if other nodes need to be visited, it reaches them, and repeats the procedure mentioned above. Otherwise, it returns to the platform from which it has been launched, where the results of the research are shown. This agent realizes the functionalities of an extended MIB browser. In fact, in an ordinary MIB browser, after 7

Figure 3: Graphical interface of the browser agent

activating a connection with a specific node, we can view the contents of the MIB variables, by sending a Snmp request to the node in question for each variable. Conversely, through the browser agent, such requests are first given to the agent, which (by moving from a node to another) interacts with them locally and reports the global result to the initial station. daemon agent: The daemon agent monitors a ”health function” defined by the user. For starting the agent, the function to be computed and the node of the network (where the computation has to be done) must be provided. Then this agent moves to the node in question, where it records the value of the function: if the value is higher than a fixed threshold (defined by the user), a notification message is sent to the server from which the agent has departed. We can also implement (by means of this agent) a mechanism of generalized trap, where the events in which the NMS is notified can be freely and very flexibly set by the user. Remote nodes (thanks to the use of the mobile code) do not need to have anything preinstalled. messenger agent: The two agents described before directly interact with the Snmp daemon present in the different nodes (through the Advent classes). Conversely, the messenger agent, during its migration through the nodes of the network, interacts with other agents for collecting specific information produced by them. During the configuration we need to select the agents to be contacted and the servers where they have to be searched, and (if necessary) also the number of times the agent has to contact such agents. Thus, the messenger agent performs operations at a higher abstraction level than the mere retrieval of MIB variables. In fact, since daemon agents can perform the computation of any function on the different nodes of the network, the messenger allows to collect such information, thus obtaining a general description about the state of the network. It must be noticed that the model of the agents involved in this architecture is always the same. The functions to be computed on each node, which clearly depend on the specific environment where we operate, need to be 8

changed for obtaining significant information about the network. verifier agent: The verifier agent does not perform an actual network management action. Its task is that of collecting important information, which might be useful for further operations of network management, from remote network devices to the starting host. It visits the nodes selected during the configuration, and computes a function whose purpose is the evaluation of the presence of a specific property of the system visited (for example, we might think of the verification of a software version, or the available space on disk not below a fixed threshold, or the verification of some log files, etc.). The verifier agent then reports to the server, from which it departed, the list of the nodes that satisfy this property. In the following, we demonstrate the use and benefits of the agent based approach by presenting a commercial important application where the use of agents can provide the underlying framework and structure for its implementation and deployment. Namely, we focus on brokering resources inside a multi-operator network. We describe the reference model and how by the simultaneous adoption of agents and genetic algorithms an effective strategy for market based routes can be implemented. The agent-based network management environment described previously, represents an underlying layer of the multi-operator network model, and can be used to collect all the management data required for the algorithm. The genetic-based strategy presented here aims to identify effective market based routes for brokering purposes in a multi-operator network environment. As it will be explained in detail in the following sections, the use of mobile agents facilitates the implementation of this approach in an efficient way and helps overcome some of the issues associated with the need for distributed operation of the algorithm in the networking environment under consideration.

4 Multi-Operator network model In the wide area electronic commerce communication services and applications in an open marketplace, many types of providers are usually involved in order to complete the end-to-end service offering. Specifically, the Service Provider (SP) is responsible for the definition of the service characteristics and the maintenance of the customer premises equipment, while the Network Provider (NP) provides the network infrastructure (i.e. high-speed network). The Network Provider relieves the other parties involved in that arrangement of the cost and effort of network management by reducing labor cost and capital investment. In such an arrangement the Service Provider is essentially a Customer of the Network Provider, while the Service Provider provides the service to its own customers or end-users (usually multiple customers with small to medium size). As a means of competition many different Network Providers offer access to a remote Content Provider (CP) which provides multimedia services such as voice, data and video. Similarly the Service Provider is capable of accessing many different Network Providers to request service. The various network operators (providers) will then be competing to sell their network links to clients through a representative agent host, the Network Access Broker (NAB). An SP may have more than one attachment points with an NP, for load distribution, redundancy and reliability purposes. The Service Provider (SP) acts as a single point of contact between a Client and multiple NABs, rather than the client having their own negotiating agents hoping between multiple network hosts. Hence several different customers’ resource requirements can be aggregated together in order to achieve a lower cost to the individual. For the sake of representation simplicity we can assume that for each network there is a Management Station (MS) and this maintains routing tables, network pricing, resource updates, and other management information and network statistics. The Inter Network Access Broker (INAB) serves as an intermediary between two neighboring networks. This allows negotiations for access to one another’s resources. This is useful either when Network A is unable to supply the requested end-to-end bandwidth asked by an SP agent, or when the SP determines that the combination of parts of two or more network providers could provide a more efficient and/or cost effective (for the user) resource selection. Overall such an approach tends to offer to the user the best available resource allocation and 9

cost at the time of the request, and also allows network providers to avoid losing potential revenue (by turning down a connection) if they are unable to provide a complete end-to-end cost efficient connection at the time of the request. Rather than turning down the request, Network A can complete portion of the connection within its network while supplement bandwidth will be provided from Network B, to compensate for any shortfalls or the inefficient solutions. Furthermore a similar situation and scenario may appear when a connection, in order to be established, requires the collaboration and interaction of different networks, and has the option of choosing among various networking solutions that may support different technologies with different quality of service provisioning and cost, and may be administered by different entities. In these cases the INABs will also have the responsibility of performing the appropriate interoperability functions. A scenario that involves three competing network providers and two service providers is illustrated in figure 4. The three networks are owned by three different operators, and each one of them is responsible for resource allocation and pricing strategies within its own environment. Moreover the three networks have some interconnection points with each other therefore allowing traffic to flow among the different networks, as it is expected in an open marketplace. The SP is informed periodically about the cost changes associated with each of those interconnection points. As a means of competition all three networks offer the same access to the remote CP. The SP serving a particular client is responsible to identify the best/optimal connection path per request of the customer. Such a path may traverse only one network or could traverse multiple networks. In the first case the only responsibility of the SP is to select the best route, at the time of the request, reported by each individual network provider. In the second case the SP is responsible for identifying the optimal solution that could result as a combination of all the possible route scenarios via multiple network providers. In this case the identification of the optimal solution becomes a complex optimization problem since it involves many parameters and the set of feasible solutions can become very large. In this paper we are using genetic algorithms as a means to address this problem. In general Quality of Service (QoS) routing with multi-constraint has been shown to be NP-hard problem in the literature (e.g. [21]). At the same time GA presents a good method to handle multi-constraint optimization problems and does not depend on the properties of the problem itself. Moreover, due to the intrinsically distributed nature of the problem under consideration, we believe that, the combination of GA’s parallel property that provides an efficient method for searching large spaces, with the distributed agent-based management architecture described in this paper, can provide an overall efficient and successful solution to the routing and resource management problems. Browser/Daemon Agents

Broker Agent

High_Speed Nerwork (ATM, Fram Relay, IP) INAB

NAB

           

CP

Messenger Agent INAB Messenger Agent

PC Client






        

NP A

SP

High_Speed Nerwork NP B (ATM, Fram Relay, IP) Browser/Daemon Agents INAB INAB

NAB

Broker Agent

PC Client

INAB NAB

High_Speed Nerwork (ATM, Fram Relay, IP)

NP C

Browser/Daemon Agents Broker Agent

Figure 4: Network model for agent brokering environment

10

CP

The proposed algorithm and some experimental results are presented in the following sections. What is important to stress here is how the underlying agent architecture may interact with the genetic algorithm itself. We assume that an SP may host a particular kind of agent (named broker agent) which is in charge of identifying the optimal path to manage a specific connection request. The interaction among a broker agent and the algorithm may occur according to the following strategies. 1) The broker agent is able to execute the algorithm in run-time upon the request from the PC client. 2) The broker agent sends a request to a network node where the genetic algorithm can be executed. The optimal path is then sent back to the broker agent, which activates the setup procedure. 3) A set of optimal paths for different pairs of PC client and content providers are stored in a database (eventually distributed) which is accessed from the broker agent to retrieve the more convenient path to satisfy the specific request. Once the connection is established, the genetic algorithm can be re-executed in order to identify a more convenient path, if the case. These various strategies present many different trade offs that range from the distributed nature of the strategy and its corresponding complexity, to the accuracy of the network state information and optimality of the identified routes, to the users’ and providers’ specifications and requirements. For instance the third strategy does not assume a real-time execution of the genetic algorithm, thus allowing a fast satisfation of the user request. Such choice might not be optimal; this is why a new path could be identified by an off-line execution of the algorithm. Such an approach also allows a loose interaction with agents dedicated to the retrieval of fresh and updated parameters to be used as input to the genetic algorithm. Of course, if network performance and reliability change due to some reason, monitoring agents distributed in the system will promptly react to pass the genetic algorithm the new data to recompute the new optimal paths. Moreover it should be noted here that one of the main features of our proposed agent underlying structure is its compliance with the MASIF standard by providing the necessary interfaces, therefore making our approach and platform appropriate for implementation in an open multi-operator network environment. A detailed description of the operation of the proposed strategy in the environment of mobile agents as well as of the involved elements, their funcionality and the corresponding algorithms that need to be executed at the various points of the network is presented in section 5.

5 Integration of genetic algorithms and mobile agents 5.1 Problem Formulation According to the changes in the different network conditions, Service Provider (SP) always wants to find a good route for its customers in real time. That is, with certain QoS constraints, SP wants to find a cost-reasonable route for its costumers. In the following, we assume that at certain time period, SP knows: a) Traffic from SP to CP, b) QoS requirements/constraints (i.e. time delay constraint from SP to CP), c) Connectivity of nodes of Network Providers(NPs), d) Bandwidth available for each link between nodes, e) Cost for the traffic to pass through each link, f) Time delay for the traffic to pass through each link. The use of mobile agents provides the complementary underlying structure in order to obtain this information in a distributed and efficient manner. This approach implies the strong integration of user and network perspective, and provides an efficient way to interact with the network elements, when needed. Specifically in subsection 3.2 we provided a brief description of how the developed agents can be used to deal with the collection of information ([11]) about the state of the network and the monitoring of helath functions that can be defined by the service provider. In our reference model the definition and creation of browser agents and daemon agents serve the purpose of collecting specific variables from a set of nodes (e.g. NABs and INABs) specified by the SP. Then by using messenger agents, during their migration through specific nodes of the network, we can interact with the other agents for collecting specific information produced by them, and therfeore obtaining a general description about the state of the network. Moreover due to the mechanisms of remote evaluation and mobile agents described in the previous sections, the actions to be performed can be developed by the broker agent of a specific SP and sent to

11

other remote devices where they will be executed on behalf of the broker agent, therefore limiting the generated traffic in the network and distributing the computational load and effort. Therefore the underlying structure provided by the use of mobile agents and the services offered by them, are crucial for the efficient implementation of the various steps of the proposed algorithm in order to find efficient market based routes in the multi operator networking environment. As the number of nodes in the network increases, the searching space of finding a route increases dramatically. Therefore it is not practical for SP to find an optimal route all the time. The purpose of this effort is to develop a practical approach of finding a cost-efficient route from SP to CP via nodes of multiple NPs according to the state of the networks at that time. It should be noted here that the nodes of interest represent the access nodes from SP to the individual networks, the edge nodes that provide interconnectivity among the various Network Providers (i.e. INABs), and/or egress nodes providing connectivity to the CPs. According to the multi-operator network model described in the previous section, each network provider is responsible for the resource management, routing updates and route discovery process within its own environment (i.e. only among nodes belonging to this network). Any changes within the context of a single operator are reflected by potential changes in cost and delays of the links (paths) connecting the access nodes, edge nodes and/or egress nodes. A link A–B as defined here, is either a ”direct” link or an ”extended” link between any two nodes of the ones defined above (i.e. SPs, access nodes, edge nodes, egress nodes, CPs). Such a link could represent either a ”direct” physical link between nodes A and B, or a combination of physical links (”extended link”) among multiple nodes that belong to the same network provider and are administered by the same administration entity. In the first case (”direct link”) nodes A and B of link A–B may belong to the same network or different networks (in case they represent interconnecting (edge) nodes). In the second case (”extended link”) nodes A and B are either access nodes, or edge nodes, or egress nodes that belong to the same network provider. However for the specific problem under consideration in our study this should be transparent to our algorithm and the links (either direct or extended) are treated the same way. The details of the ”extended link” are the responsibility of the specific NP and not of the SP. This paper emphasizes on cases where the optimal route spans various parts of many different network providers and not only one single network provider. Our algorithm aims to identify the ”best route” that could result as a combination of all the possible route scenarios via multiple network providers. In the following for representation purposes and without loss of generality on the applicability of the agent based approach and the proposed genetic algorithm, we provide the problem formulation under some model simplifications and assumptions regarding the constraints. Specifically the connectivity constraints and bandwidth requirements are handled as follows: for those pairs of nodes that either do not have a physical link between them, or the link presents insufficient available bandwidth to handle a request, we assume that the corresponding link (either real or virtual) has a very large delay. Thus, the problem can be described as the following optimization problem: , . However following similar approach and due to the fact that GA presents a good method to handle multi-constraint optimization problems and does not depend on the properties of the problem itself, a larger number of constraints and QoS parameters can be easily considered within our proposed framework. Furthermore, as mentioned before, due to the distributed nature of the problem under consideration, the combination of GA’s parallel property with the distributed agent-based management architecture described in this paper, can provide an overall efficient solution to the cost effective market based routing problem.


  

 

 "!$#%& (')*!$+&,!#

5.2 Algorithm’s Description and Operation In general Genetic Algorithm (GA) is kind of stochastic algorithm searching process in the solution space by emulating biological selection and reproduction. Indeed, GA has been used to solve various optimization problems [20] and in many cases have obtained very good results. GA only uses values of the objective function for optimization to select genes. This makes GA very attractive as an optimization tool since it doesn’t need to know the detailed information of the system. In general we can say that GA is robustly applied to problems with any kind of objective function. Because of GA’s parallel property, it is very suitable for large searching space cases. In this section we propose a genetic-based 12

algorithm in order to address the problem described in the previous sections. In the following we describe the different features and phases of our algorithm. 5.2.1 Encoding Approach Generally, GA can not operate directly in the search space of a specific problem. Therefore, we must map the search space of the specific problem into the space where GA can operate. This process is called encoding of GA. In the literature related work in using GA as an optimization tool for finding routes for vehicles [22] or using GA to solve the famous Traveling Salesman Problem [23] has been reported. There are several encoding approaches mentioned in literature, such as Adjacency Representation, Ordinal Representation, and Path Representation. Some encoding approaches are not suitable for GA operation(crossover and mutation), and some other encoding approaches are inefficient in searching the solution space. In our work we choose path representation approach to naturally encode a route due to its easy implementation. That is, we list all the nodes that the route passes through in sequence. In order to encode the route in a fixed data structure, we fill “0s” into the empty space of the code. For instance, in a scenario with 10 nodes in addition to the CP and SP, we can use an array with 10 elements to represent the route. Once the number of nodes that the route passes is less than 10, the corresponding element will be zero. In this case, we will use [1 2 3 4 0 0 0 0 0 0] to represent the following route: SP–1–2–3–4–CP. 5.2.2 Population Initialization In order to start GA computation, we need to identify some initial population. In the population initialization process, we can randomly determine how many nodes the route will pass through and randomly determine which node will be in the route and the sequence of the nodes of the route. However, there will be some solutions that may violate constraints of delay or inter-connectivity. We use ”penalty method” to deal with these constraints, as follows: a) For those links that do not exist, we assign a very large delay value to them, b) For those routes that violate the delay constraint, we add a penalty to their cost. In our algorithm, we use the following expression(1) to evaluate the weighted cost of those illegal routes.

 

,"    "&   "!$#%  *!$+&  ,!$#  (1) Where,  

  is the weighted cost of route,  

  is the function that evaluates the total cost of the links that the route may pass through; "!$#%  is the function that evaluates the time delay of the route; MaxDelay is










the upper-bound of the time delay constraint,  is the penalty constant(in our algorithm it is set to 2). 5.2.3 Fitness Evaluation

Fitness of the solutions are proportional to their survivability during GA computation. The Selection Operation mentioned in next subsection will use these values to keep ”good” solutions and discard the ”bad” solutions. For simplicity, we can use the cost of each route as the fitness of each solution. However, in order to prevent those solutions with very low fitness from being discarded by Selection Operation of GA at the first several computation loops of GA (this is called premature of GA), we enlarge the value of fitness of those ”bad” solutions. In this way, some ”bad” solutions still have chances to survive at the beginning of the evolution of GA and the ”good” parts in them will have chances to transfer to new generations. For convenience, we normalize the fitness of solutions to [0,1] by the following expression(2). 


    $&  ,*!$+ 

  "&   
 

  *!$+ 


 

   "&  

















(2)

Where MaxCost and MinCost are maximum and minimum cost of routes in each generation of population, respectively. In first 30 computation steps of GA, we adjust those fitness less than 0.005 to 0.005 and this helps to prevent premature efficiently. 13

5.2.4 Selection Operation The purpose of Selection Operation in GA is to keep ”good” solutions while discard ”bad” solutions at the same time. So after the selection operation, those solutions that have high fitness value will survive while those solutions with low fitness value will be discarded. This operation tries to simulate ”Natural Selection” in real life. Two selection operators are used in our algorithm. The first one is based on the “Fitness proportional model”. It is also called ”Monte Carlo selection”. The algorithm is as follows: (1) Add the fitness of all solutions; (2) Randomly generate a number between 0 and the sum of fitness; this number is called pointer of Monte Carlo wheel; (3) Add fitness of each solution one by one until the value is greater than the pointer. Then the last solution is being selected. Using this algorithm, the higher the fitness value, the bigger the chance of that solution being chosen. The second selection operator used in our algorithm is the ”best solution Reservation”. The best solution in the population will always survive and several duplicated copies will be generated for mutation operation. In this way, the GA will always converge to a certain ”good” solution. Moreover, there will be a good chance to find a better solution on the base of the best solution of each generation. 5.2.5 Crossover Operation Because of Crossover Operation, any pair of solutions in the population have a chance to exchange part of their solution information with others. Therefore those ”good” parts from different solutions may be combined together to create a new, better solution. The two original solutions are the ”parents” of the new solutions generated. There are are many crossover operators designed to solve different problems. K. Uchimura etc. [22] proposed a new kind of adjacency based operator in Vehicle Routing Problem. However this is a problem specific operator and uses complicated computation in order to obtain good results. In this paper, we use traditional one-point crossover method. That is, we find a certain point of the array and swap the part before and after the cross-point to generate two new solutions. However, because the number of nodes the route may pass through is not fixed, it is difficult to determine a fixed crossover point. So we designed a new dynamic crossover point method. The crossover point is determined by:
   , where A and B are the numbers of nodes that the two routes will pass through respectively, and the operator ”[ ]” is a rounding function. For example, let us assume that before the crossover operation, there are two routes: [1 2 3 4 5 0 0 0 0 0] and [6 7 8 0 0 0 0 0 0 0]. According to this procedure (       ) after the crossover, we get: [1 2 8 0 0 0 0 0 0 0] and [6 7 3 4 5 0 0 0 0 0]. Note that, only part of the population will experience crossover operation; this rate is called crossover rate.



 



 

5.2.6 Mutation Operation In mutation operation, we randomly choose a solution in the population and then change the solution slightly to generate a new solution. In this way, we have chances to find better solution that can not be found by only crossover operation. In our algorithm, four mutation operators have been designed: (1) Randomly delete a node from a route; (2) Randomly add a node into a route; (3) Randomly delete two nodes from a route; (4) Randomly add two nodes into a route. Only part of population will experience the mutation operation (this is called mutation rate). In order to enhance the local searching ability, those copies of best solution of each generation are all treated by mutation operator. In this way, GA may find out a better solution that is ”close” to the best solution of each generation. 5.2.7 Repair Operation During crossover and mutation operation, illegal representation of route may be generated because duplicated elements (nodes) may appear in the same route. In our algorithm, we delete those duplicated nodes that will bring high cost to 14

the route. For example, there may be a route like [1 2 3 4 5 3 7 0 0 0], where node ”3” is duplicated. We can evaluate cost of strings (2 3 4), (5 3 7) and delay of strings (2 3 4), (5 3 7). If the weighted cost of string (2 3 4) is less than (5 3 7), we will discard node 3 in (5 3 7). 5.2.8 Finding Route Efficiently and Dynamically Though GA can be used to search in large solution space and obtain an optimal solution, it may take a lot of time to converge to the optimal solution. In some cases GA can only find some other suboptimal solution instead. In practice, we usually want to find a suboptimal solution which however is close to the optimal one. So in this approach, we use a combination of conditions to determine when to stop our algorithm’s computation. The basic idea is as follows. After a minimum number of trails(MinTrails), if the algorithm has found a feasible solution and has made no more improvement for a specific period of time, we will have it stopped. In our algorithm the ”improvement” is presented by the average cost change rate of the best solution of certain generation. This change rate is evaluated by the following expression(3).


&!$  !$ $   


 


   
 (3) where, we assume the cost of the best solution of that generation changes at
th step and 
&!$  !$     is the average change rate of cost at  th step(  
). Once this value is less than a certain lower-bound(MinChangeRate), 











we may stop GA computation. As time passes by, the price of each link and congestion of the network will change gradually. So when new traffic comes, the SP will re-compute routes for its customers. During the dynamic operation of the system, in oder to improve the efficiency of our algorithm, we considered the approach of taking advantage of the results of the last computation. Surat Tanterdtid etc. [24] have discussed how to re-use past solutions for adaptive VPs assignment. They proposed to mix certain “training genes” into the initial population of the new route computation. However, we found that this will lead to premature and prevent GA from finding better solutions. Instead of mixing the past solution into the initial solution of GA, we mix the past solution into population after  of MinTrails of GA loops. In this way, we can still take advantage of the results of the last computation and prevent premature at the same time. If the network conditions change smoothly, we can take advantage of the past best solution of last computation. If the network conditions change dramatically at a certain time and the optimal route may totally differ from the past solution, GA will not take advantage of the past best solution by mixing the past solution into the population during the GA computation. 5.2.9 Flow Chart of the Algorithm The following flow chart(figure 5) summarizes the algorithm’s operation. Due to the intrinsically distributed nature of the problem under consideration, the management architecture described in the previous sections can be successfully adopted to collect the input data of the genetic algorithm. As mentioned before a set of daemon and messenger agents will monitor and retrieve traffic measures from SP to CP, while other daemon agents will monitor and evaluate the time delay for the traffic to pass through each link. Due to the flexibility of the agent system, the measure of a new and different parameter can be added to the system in a very efficient way. In fact, it is necessary only to develop the agent with the actual code for getting that parameter: then it can be dynamically executed in the most convenient place of the network. The main conclusions on the proposed algorithm’s capability and efficiency in finding the optimal strategy to market based routes are described in the following section.

15

Initialize the first generation of solutions

Evaluate the fitness of each solution

No

number of trails = MinChangeRate ?

# of trails >= 70% of MinTrails ? Yes

Yes give out the best solution of this computation

No

Monte Carlo selection

Mix past solution

Crossover operation

Evaluate the fitnesses of new generation

Mutation operation

Best solution reservation and duplication

Figure 5: Flow chart of GA

5.3 Using GA routing algorithm in the environment of mobile-agents Having already described in depth the proposed agent based approach and the corresponding algorithm for finding optimal market based routes, in this section we provide a more detailed description of the actual integration of the genetic based algorithm in the framework of mobile agents and identify the roles of the individual elements (e.g. various agents) involved in the overall operation. Specifically, as shown in figure 6, Broker Agents (BrkA), Messenger Agents (MA), Browser Agents (BA) and Daemon Agents (DA) are used to migrate among different network elements to implement the proposed routing algorithm. Once the PC client needs a connection to the CP, a Messenger Agent will be sent from PC client to SP containing information about the upper bound of setup time delay of the connection and the corresponding QoS requirements. After receiving the Messenger Agents from PC client, SP creates a Broker Agent to deal with this connection requirement. This Broker Agent creates Messenger Agents containing source and destination information, as well as QoS requirements, and multicasts the agents to each NAB that it is connected with. Then the Broker Agent in SP waits for the Agents from NABs to obtain the routing solution according to the scheme depicted in figure 7. As seen by the flow chart in figure 7 in order to control the connection setup time a timer is used to determine the deadline of the route searching procedure. If the Broker Agent receives a Messenger Agent from NAB with satisfactory routing solution before the expiration of the timer the route searching process stops and this solution is selected. Otherwise, when the timer expires the Agent chooses the best route among the route candidates found until that time. Each NAB also creates a Broker Agent to deal with the connection when it receives the Messenger Agents with the corresponding connection request from the SP. Then three kinds of agents are used to implement the routing algorithm as follows: Browser Agent:

16

PC Client

SP

MA

MA

Nodes in

NAB

Network X

INAB

node with computation Power

BrkA MA

MA

BrkA BA

BA

BA

BA

DA MA MA

DA

MA

MA

MA BrkA

Messenger Agent

BA

Broswer Agent

Broker Agent

DA

Daemon Agent

Mobile Agent migration route

Figure 6: Agents used to implement routing algorithms based on GA

Sending Messenger Agents to NABs

Start timer for routing algorithms

Receive Messenger Agent containning route solution?

No

No

No

Yes

Yes Saving this route as routing candidate

Time out?

Choose best route from routing candidates

Route good enough? Yes Sending Messenger Agent Back to PC Client accepting the connection

Yes

Route exists? No Sending Messenger Agent Back to PC Client refusing the connection

Figure 7: Algorithm for Broker Agent in SP to choose a route for its client

17

Browser Agent will be created and sent to nodes inside the individual private network that the NAB belongs to. These agents will collect resource information such as available bandwidth, delay of the link, price of the link etc. In a similar way the Broker Agent in each NAB will also send out Browser Agents to INABs to see if it can take advantage of network resources from other network providers. Daemon Agent: After collecting the necessary resource information, a Daemon Agent containing the GA code and resource related information will be created to implement the routing algorithm described in detail in the previous section. Instead of executing the algorithm in each NAB, the Broker Agent sends Daemon Agents to the most suitable nodes inside its private network (e.g. nodes with enough computation resources such as CPU, memory, etc). In this way, we can balance the computation load among nodes in the private networks, if needed. Messenger Agent: After the genetic-based route computation, Daemon Agents will send the results back to the Broker Agent by using a Messenger Agent. This Agent will be forwarded to the Broker Agent in the SP. As we can see from the above discussion, by using mobile agents we can not only collect the necessary resource information in an efficient way, but we can distribute and balance the computation load inside the networks, and even more importantly we maintain a high level of fault tolerance in the system by running several route searching procedures in different private networks and therefore performing the overall operation in a distributed way.

6 Results and evaluation In this section we present some numerical results to assess the operation, performance, and efficiency of our algorithm by applying it in some test case scenarios. Furthermore some quantitave measures about the agent migration times and their size are also provided, in order to demonstrate the very low overhead introduced to the system by using this agent-based approach.

6.1 Simulation Scenario Before proceeding with the presentation of the actual numerical results, we briefly describe the networking environment and the corresponding system parameters and service requirements for the test cases we studied. Specifically we assume a multi-operator network with one SP, one CP and 10 nodes belonging to different Network Providers. As mentioned before those 10 nodes represent either the access nodes from SP to the individual networks, or the edge nodes that provide interconnectivity among the networks of the various operators, or the egress nodes that provide connectivity to the CPs. The corresponding topolgy of the network under consideration in this numerical study is depicted in figure 8. As explained in the previous sections a link interconnecting nodes belonging to the same network provider may represent a combination of links interconnecting other intermediate nodes belonging to the same network (”extended link”). In this figure, for sake of simplicity, we only present the nodes of interest (i.e access, egress or edge nodes) and their interconnections. In the following we assume that cost and delay of links between any two nodes at certain time period are given. For nodes that no link exists between them or the bandwidth of the link can not support the traffic request between SP and CP, a large delay value(999) is assigned to that link. The objective of our experiment is to find the route from SP to CP which has the lowest cost and the delay is less than the maximum delay requirement. The cost matrix and delay matrix are given in table1(a) and table1(b) respectively.

18

Network Provider A 2

9 1

10




         

CP

PC Client

             

3

SP

8 6

Network Provider B

PC Client

4

7 5 Network Provider C

Figure 8: Experimental network topology

99

15

99

99

99

23

99

99

99

99

99

999

07

999

999

999

10

999

999

999

05

15

18

99

99

23

99

99

99

99

99

99

07

03

999

999

06

999

999

999

999

999

999

99

99

15

99

99

99

99

300

99

99

99

999

999

01

999

999

999

999

05

999

999

999

99

99

99

14

99

99

99

99

99

99

99

999

999

999

02

999

999

999

999

999

10

999

99

23

99

99

99

50

30

99

99

99

99

999

06

999

999

999

20

05

999

999

999

999

23

99

99

99

50

99

20

99

18

99

99

10

999

999

999

20

999

20

999

07

999

999

99

99

99

99

30

20

99

10

99

30

30

999

999

999

999

05

20

999

07

999

09

05

99

99

300

99

99

99

10

99

99

99

15

999

999

05

999

999

999

07

999

999

999

01

99

99

99

99

99

18

99

99

99

25

05

999

999

999

999

999

07

999

999

999

03

02

99

99

99

99

99

99

99

99

25

99

99

05

999

999

999

999

999

999

999

03

999

999

(a) Cost Matrix

999

(b) Delay Matrix

Table 1: Cost and Delay Matrix of simulation

"





   





  , is the cost(delay) from node i to node j, i,j      , element  is In these tables, element  ,  the cost(delay) from SP to node i, element    is the cost(delay) from node i to CP. The upper-bound(requirement) of time delay (Maxdelay) is assumed to be 25 time units in this study. The GA related parameters used in our simulation are as follows: population size: 71; crossover rate: 0.6; mutation rate: 0.1; best solution reservation:   of population size; MinTrails: 100; MinChangeRate : 20.




6.2 Experimental Results Based on the simulation scenario described in the previous subsection the optimal solution (route) is designed as: [2 5 7 8 0 0 0 0 0 0] and the corresponding cost of this route is 96. According to the selected encoding approach this route actually represents the following path: SP–2–5–7–8–CP. Initially we applied our algorithm without considering the stopping conditions (that is, we let the algorithm run for many iterations) to the network described above. In order to study in depth the behavior of our approach we repeated the experiment many times. In general, as a common practice, in order to evaluate the performance of the GA’s convergence and keep it independent of the actual hardware implementation and processors that may execute the algorithm, generation of evolution of GA has been adopted as a good measurement. In this study, following this principle we present the convergence of the GA measured in generations. The corresponding results are demonstrated in the following figures 9–12. For most of the runs the algorithm obtains the optimal solution in about 130 steps as demonstrated in figure 10. In some cases our algorithm finds the 19

optimal solution very quickly(in about 40 steps) as in figure 9, however there may be cases where longer convergence times are observed (figure 11) in order to obtain the optimal solution. Furthermore in figure 12 we notice that the algorithm has not obtained the optimal solution even after 250 iterations. However even in this case we can see that the cost of the sub-optimal solution obtained by our algorithm (i.e. [4 10 9 0 0 0 0 0 0 0]) is very close to the optimal one, and furthermore as a trade off, our algorithm achieves a solution with lower delay than the optimal one. In any case, as it can be seen by all figures 9–12 the algorithm always finds a good solution in less than 130 steps favoring the big changes at the beginning if needed, while applying smoother changes to the solution at every step when the intermediate solution obtained is in the neighborhood (”close to”) of the optimal solution. In addition it should be noted that in most of the practical cases the involved parties are mainly interested in obtaining a cost-efficient solution in real-time and not necessarily (especially in cases where the improvement of the optimal solution is very small) the optimal one. Taking this observation into consideration in figures 13 and 14 we present some numerical results regarding the operation of our algorithm, when we apply the combination stopping conditions described in the previous section. From those results we confirm that after applying the stopping conditions our algorithm stops having identified a cost efficient solution (either optimal or sub-optimal with cost close to the optimal one and lower delay). In fact, in the mobile agent environment, by running several route searching procedures based on GA in different network elements, we considerably improve the probability of getting the optimal routing solution. In the following we present some data related to the migration time and size of the agents involved in the overall mechanism. Even though the complete platform and scenario has not been fully deployed yet, we believe that these preliminary measures demonstrate that the overhead introduced to the system by using this agent-based approach is very low. First it should be noted that all the agents we developed (e.g. browser, daemon, messenger) are very small in size, ranging from 3Kbs to 8Kbs (apart from the graphical interface which however does not neet to migrate). Therefore the overhead introduced in the system by the agents’ size is very low especially when considering the level of flexibility that is obtained by using such an approach. The frequency with which the agents collect data on the network and the specific routes are computed and evaluated, depends on the network itself. Thus it is not possible to set a single value for such parameters, but the administrator may decide the right values after a fine tuning of the relevant network parameters. Regarding the overhead due to the migration of agents we performed some measurements on a 10Mbit LAN in order to evaluate the order of magnitude of these values. The observed migration time of a 5Kb agent between two points (Pentium III, 350MHz with 128 MB Ram) was 106ms in conditions of light network traffic, which represents a good indication of the concrete applicability of the proposed approach. Taking into account the network configuration depicted in Figure 8, the agents have to migrate from the SP to the three network providers. This can be done by sending in parallel three agents, minimizing the total migration time; in a more realistic network scenario we do not expect this to be a bottleneck, since as explained earlier in Section 5.1, agents do not interfere with the internal routing mechanism of the network provider. They are used only to collect aggregated data of a network provider, which in turn will be used by the genetic algorithm. In general, we believe that the involved migration times are very low with respect to the frequency with which routes are evaluated in the networking environment under consideration.

7 Conclusions The new emerging technology of agent programming has arisen in the distributed programming field as a flexible and complementary way of managing resources of a distributed system. In this paper we proposed the integration of mobile agents and genetic algorithms in order to provide efficient resource allocation in a multi-operator networking environment. The agent based approach we proposed is used as an effective method for performing basic management operations of a network, such as collection of information about the state of the network and the management of network devices through the monitoring of health functions. In the multi-operator network model under consideration

20

in this work, the agent based network management approach represents an underlying framework and structure. To demonstrate the capabilities of such an approach in this environment, we proposed and developed a stochastic algorithm searching process by emulating biological selection and reproduction, in order to identify optimal based routes based on the information provided by the mobile-agent based structure. Using as basis the underlying structure provided by the use of mobile agents, we can not only collect the necessary resource information in an efficient way, but we can distribute and balance the computation load inside the networks, and even more importantly we can maintain a high level of fault tolerance in the system by running several route searching procedures in a distributed way in different private networks. The numerical results reported in this paper demonstrated that our strategy always identifies in a small number of steps a cost efficient solution that is either the optimal one, or in some cases sub-optimal with cost very close to the optimal and lower delay. Moreover we presented some quantitave measures regarding the actual agent migration times and their size which demonstrated the very low overhead introduced to the system by using our agent-based approach. Our current and future research work in this area concentrates mainly on the in-depth performance evaluation of the integrated mobile agent and genetic algorithm based resource allocation strategy, the development and realization of a fully distributed and operational mode of the algorithm, and the development of guidelines of the specific functions to be performed by the various agents according to the users’ and providers’ requirements and specifications.

References [1] A.T.Campbell, H.G.de Meer, M.E.Kounavis, K.Miki, J.Vicente, and D.Villela. A Survey of Programmable Networks. ACM Computer Communication Review, 29(2):7–23, April 1999. [2] A. Puliafito, O. Tomarchio, and L. Vita. MAP: Design and Implementation of a Mobile Agent Platform. Journal of System Architecture, 46(2):145–162, January 2000. [3] H. De Meer, A. La Corte, A. Puliafito, and O. Tomarchio. Programmable Agents for Flexible QoS Management in IP Networks. IEEE Journal on Selected Areas in Communication, 18(2), February 2000. [4] M.R. Genesereth and S.P. Ketchpel. Software agents. Communications of the ACM, 37(7):48–53, July 1994. [5] K. Rothermel and R.Popescu-Zeletin Eds.,. Mobile Agents. Lecture Notes in Comp. Science, LNCS1219, 1997. [6] D.S. Alexander, W.A. Arbaugh, A.D. Keromytis, and J.M. Smith. The SwitchWare Active Network Architecture. IEEE Network, 12(3):29–36, May/June 1998. [7] D. Milojicic, M. Breugst, S. Covaci, and al. MASIF: the OMG Mobile Agent System Interoperability Facility. In Second International Workshop on Mobile Agents, (MA’98), Stuttgart (Germany), September 1998. [8] D. Tennenhouse et al. A Survey of Active Networks Research. IEEE Communication Magazine, 35(1):80–85, January 1997. [9] IEEE Network. Special Issue on Programmable Networks. 12(3), May/June 1998. [10] AdventNet Management APIs. Available at http://www.adventnet.com. [11] A. Bivens, L. Gao, M. F. Hulber and B. Szymanski,”Agent-Based Network Monitoring,” , in Proc. Autonomous Agents99 Conference, Workshop 1, Agent Based High Performance Computing: Problem Solving Applications and Practical Deployment, Seattle, WA, May 1999, pp. 41-53. [12] M. Baldi, S. Gai, and G.P. Picco. Exploiting Code Mobility in Decentralized and Flexible Network Management. In Proceedings of the First Int. Workshop on Mobile Agents (MA97), Berlin, Germany, April 1997. 21

[13] G. Goldszmidt and Y. Yemini. Distributed Management by Delegation. Proc. of the 15th International Conference on Distributed Computing Systems, 1995. [14] G. Goldszmidt, Y. Yemini, K. Meyer, M. Erlinger, J. Betser, and C. Sunshine. Decentralizing Control and Intelligence in Network Management. Proc. of the 4th International Symposium on Integrated Network Management, May 1995. [15] M.S. Greenberg, J.C. Byington, and T. Holding. Mobile Agents and Security. IEEE Communications Magazine, 7(31):76–85, July 1998. [16] A. Puliafito, O. Tomarchio. Using Mobile Agents to implement flexible Network Management strategies. Computer Communication Journal, 23(8):708-719, April 2000. [17] K. Schelderup and J. Olnes. Mobile Agent Security: Issues and Directions. In IS&N’99, volume LNCS1597, March 1999. [18] R. Zahavi T.J. Mowbray. The essential CORBA: Systems Integration Using Distributed Objects. John Wiley & Sons, Inc., 1995. [19] David Chieng, Ivan Ho, alan Marshall, and Gerard parr, “A Mobile Agent Brokering Environment for the Future Open Network marketplace” , Proc. of 7th International Conference on Intelligence in Services and Networks, IS&N 2000, February 2000 p.p. 3–15. [20] Z. Michalewicz, ”Genetic Algorithms + Data Structure = Evolution Programs” ,Springer-Verlag, 1992. [21] Zheng Wang and Jon Crowcroft, “Quality-of-Service Routing for Supporting Multimedia Applications, IEEE JSAC, September 1996, pp. 1228-1234 [22] Keiichi Uchimura and Hideki Sakaguchi,“Vehicle Routing Problem using Genetic Algorithms based on Adjacency Relations” , Vehicle Navigation and Information Systems Conference, 1995, p.p. 214–217. [23] Goldberg, David E, “Genetic algorithms in Search, Optimization and Machine Learning” ,Addison-Wesley Pub. Co., 1989. [24] Surat Tanterdtid, Worawit S. and Watit B., “Optimum Virtual Paths System Based in ATM Network Using Genetic Algorithm” , ICICS’97, 1997, P.P. 596–601

22

6

10

Cost of the best solution of each generation Cost of the optimal soluton 4

cost

10

2

10

0

10

0

50

100

150

200

250

generation 4

10

Time Delay of the best solution of each generation Upper−bound of the time delay 3

time delay

10

2

10

1

10

0

10

0

50

100

150

200

250

generation

Figure 9: GA converges to optimal solution at ”high” speed 6

10

Cost of the best solution of each generation Cost of the optimal soluton 4

cost

10

2

10

0

10

0

50

100

150

200

250

generation 4

10

Time Delay of the best solution of each generation Upper−bound of the time delay 3

time delay

10

2

10

1

10

0

10

0

50

100

150

200

250

generation

Figure 10: GA converges to optimal solution at ”middle” speed 5

10

Cost of the best solution of each generation Cost of the optimal soluton 4

cost

10

3

10

2

10

1

10

0

50

100

150

200

250

generation 4

10

Time Delay of the best solution of each generation Upper−bound of the time delay 3

time delay

10

2

10

1

10

0

10

0

50

100

150

200

250

generation

23 Figure 11: GA converges to optimal solution at ”slow” speed

5

10

Cost of the best solution of each generation Cost of the optimal soluton 4

cost

10

3

10

2

10

1

10

0

50

100

150

200

250

generation 4

10

Time Delay of the best solution of each generation Upper−bound of the time delay 3

time delay

10

2

10

1

10

0

10

0

50

100

150

200

250

generation

Figure 12: GA gets only suboptimal solution 6

10

Cost of the best solution of each generation Cost of the optimal soluton 4

cost

10

2

10

0

10

0

50

100

150

200

250

generation 4

10

Time Delay of the best solution of each generation Upper−bound of the time delay

time delay

3

10

2

10

1

10

0

50

100

150

200

250

generation

Figure 13: GA is stopped after getting optimal solution 6

10

Cost of the best solution of each generation Cost of the optimal soluton 4

cost

10

2

10

0

10

0

50

100

150

200

250

generation 4

10

Time Delay of the best solution of each generation Upper−bound of the time delay 3

time delay

10

2

10

1

10

0

10

0

50

100

150

200

250

generation

24 getting suboptimal solution Figure 14: GA is stopped after