A heuristic approach to resource locations in broadband networks

Journal of Network and Computer Applications (2002) 25, 1ÿ35 doi: 10.1006/jnca.2002.0126, available online at http://www.idealibrary.com on

1

A heuristic approach to resource locations in broadband networks P. C. Saxenay, D. R. Choudhuryz, G. Gabraniz*, S. Guptay, M. Bhardwajx and M. Choprax y School of Computer and System Sciences, Jawaharlal Nehru University, New Delhi 110067, India z Department of Computer Engineering, Delhi College of Engineering, Bawana Road, New Delhi 110042, India x Delhi College of Engineering, Bawana Road, New Delhi 110042, India (Received 1 February 2001; accepted 28 November 2001) In broadband networks, such as ATM, the importance of dynamic migration of data resources is increasing because of its potential to improve performance especially for transaction processing. In environments with migratory data resources, it is necessary to have mechanisms to manage the locations of each data resource. In this paper, we present an algorithm that makes use of system state information (state of each site corresponding to all data resources) and heuristics to manage locations of data resources in a distributed network. In the proposed algorithm, each site maintains information about state of other sites with respect to each data resource of the system and uses it to ®nd (i) a subset of sites likely to have the requested data resource and (ii) the site where the data resource is to be migrated from the current site. The proposed algorithm enhances its effectiveness by continuously updating system state information stored at each site. It focuses on reducing the overall average time delay needed by the transaction requests to locate and access the migratory data resources. We have evaluated the performance of the proposed algorithm and have also compared it with one of the existing location management algorithms, by simulation studies under several system parameters such as frequency of requests generation, frequency of data resource migrations, network topology and scale of network. The experimental results show the effectiveness of the proposed algorithm in all cases. # 2002 Elsevier Science Ltd. All rights reserved.

1.

Introduction

A distributed system consists of a collection of geographically dispersed autonomous sites that are connected by a communication network. These sites do not share common memory but communicate with each other by sending messages over the network. Enslow [1] has characterized a distributed system to contain the following ®ve components: a multiplicity of general-purpose resources, a physical distribution of the resources, a high-level operating system, system transparency and * Corresponding author: E-mail: [email protected] 1084±8045/02/010001 ‡ 35 $35.00/0

# 2002 Elsevier Science Ltd. All rights reserved.

2

P. C. Saxena et al.

cooperative autonomy. Distributed systems offer a great potential for increasing the amount of computing power and resources available for large-scale applications. The distributed environment considered in this paper is a set of sites having a number of Data Resources (DRs), such as databases or ®les, distributed over them and interconnected by a broadband network, such as ATM [2,3]. In order to process the transactions on these DRs, the following two methods are employed. The ®rst method for transaction processing normally employed in conventional distributed systems is ®xed processing [4,5] where each DR is ®xed at a particular site. In this method, the transaction initiation site performs operations on the DR through several operation request (query) messages and constantly validates it by Two Phase Commit (2PC) protocol. The second method called DR migration proposed by Hara et al. [5], makes use of high bandwidth of broadband networks. In this method, the whole DR is migrated to the transaction initiation site and the operations on the DR are performed locally. In broadband networks, migration of the whole DR takes a small amount of time. For example, it will take nearly 0.8 s to transmit a DR that is 100 Mb in size, if the bandwidth available is 1 gigabit/s. Since, in a broadband network, the propagation delay is almost equal to that in conventional networks and the transmission delay is very small even for data of large volume, it is more ef®cient to transmit a large amount of data once than to transmit a small amount of data multiple number of times. Several approaches that employ migration of data for performance improvement have been developed in the literature. For example, Hac [6] presents a distributed algorithm for performance improvement through ®le and process migration. Hurley et al. [7] establish through simulation that ®le migration can be utilized to provide performance bene®ts over a system without ®le migration. Banerjee et al. [8] have proposed transaction processing methods employing data item migration in ®bre-optic ring networks. In [5], Hara et al. have used the DR migration technique for improving transaction processing throughput in ATM networks. They have shown that the overall transaction processing time reduces considerably when DR migration is employed in a distributed system. We also illustrate this by an example. Suppose a 1.5  107 metre long ®bre optic cable with a bandwidth of 1 gigabit/s connects two sites Si and Sj. Since the speed of light in the ®bre is 2.1  108 m/s, the propagation delay between the two sites is nearly 0.071 s. Let us say site Si wants to access a DR at site Sj that is 100 Mb in size. Transfer of the whole DR from site Sj to site Si would require about 0.8 s, neglecting processing delays at sites and switching delays at intermediate switches. Therefore, if the transaction at Si needs to query the DR at Sj in more than six rounds then, clearly, it is better to transfer the DR from Sj to Si in order to increase performance. Hence, with the advancements in broadband networks, DR migration will soon become a powerful tool for transaction processing, especially since the upper limit of the light makes it impossible to improve the propagation delay drastically. Also, as the replication of DRs is considered as one of the most effective techniques for improving transaction processing throughput, Hara et al. [9]

Resource locations in broadband networks

3

have shown that DR migration technique can be used for constructing a replica of a DR The use of DR migration technique has also been demonstrated in [4,10--13]. Hara et al. [4] suggested that both the methods, ®xed processing and DR migration, can be employed in a distributed system and whenever a transaction is processed, an adaptive selection between the two transaction processing methods can be used for performance improvement. We, in this paper assume a distributed system similar to that used in [4,5,10] that supports both the methods for transaction processing. (Note that how a site makes a choice between these two methods is not discussed in this paper. Interested readers may refer to [4] for studying the mechanisms a site employs for selection between the two transaction processing methods.) It should be noted that we do not consider DR migration for DRs having high location dependency or for very large sized DRs of the order of terabytes. A closed system such as a distributed DR system in an enterprise intranet with different branches located in different cities is assumed. To take advantage of DR migration, it is desirable that the DRs have low location dependency and are not extremely large (say at most the total size of all DRs is about 1 Gb) and the sites are distributed in a wide area. For example, product DRs installed in an intra-network of a company with many branches around the world can be a good candidate. If the company has 8000 different kinds of products with 100 kb of data for each product, the total size of all the DRs would be 800 Mb. Hence, in the distributed system assumed in this paper, a transaction initiation site can generate two types of requests that is, for ®xed processing on a DR or for migration of a DR. It can be easily visualized that in such an environment, the locations of the DRs change as they migrate from one site to another. Therefore, a method is required for identifying the exact locations of the DRs. Also, it is necessary to develop a mechanism that controls the DR migration operations, that is, it should determine the site (out of many requesting sites) where the DR should be migrated from the current site. Both these issues are to be dealt with in a manner such that overall average time delay in locating and accessing the migratory DRs by transaction requests of the system is reduced. This problem can be partially related to the problem of locating mobile hosts in several ®elds, such as in mobile computing environments [14--21]. In such environments the focus of the problem is only to locate the mobile host, since there is a difference in the characteristics of mobility. In mobile computing environments, each mobile host moves at the owner's will. However, in our context (DR migration in broadband networks), all migration actions are controlled by the system and hence are predictable. Therefore the site to which the DR migrates is controllable by the system. In [10], Hara et al. have suggested various algorithms for the management of DR locations. Broadly these algorithms can be categorized into centralized and distributed algorithms. The centralized approaches possess certain disadvantages. If the centralized server breaks down, the whole system goes down because the information about system and data resources gets lost. Also, the centralized algorithms are neither scalable nor fault tolerant. Though this problem can be solved

4

P. C. Saxena et al.

using backup systems, they involve considerable overhead for failure detection and recovery. Furthermore, as the number of DRs increases, the increase in load at the centralized server negatively affects the performance of the algorithm. In order to remove the disadvantages of the centralized algorithms, Hara et al. proposed various distributed algorithms. These algorithms do not require any centralized controller and so are free of the drawbacks of centralized systems. Typically, the distributed algorithms can be classi®ed into three broad categories: broadcast, Chain Forwarding (CF) and Chain Query (CQ). The broadcast methods are not favoured in ATM networks. This is because in order to make use of the broadcast facility, an ATM virtual LAN must be constructed. In this case we must choose a certain site as centralized server and establish point to multi-point PVC (Permanent Virtual Connection) connection from that server to every site in the virtual LAN. However, in wide area networks, it is not realistic to construct an ATM virtual LAN, since the network structure changes all the time and, therefore, it is impossible to set the PVC connection from the centralized server to all the sites (note that the centralized server may also lead to a single point of failure). The CF and CQ algorithms have been adopted from mobile computing [17]. These algorithms were modi®ed by Hara et al. to take advantage of ATM networks and were called ECF (Extended Chain Forwarding) and ECQ (Extended Chain Query), respectively. We explain these algorithms (CF, CQ, ECF and ECQ) now. In these algorithms, each site maintains a table called DR location table that stores the latest known locations of all the DRs of the system. In CF, the transaction initiation site sends a request for ®xed processing or migration of a DR to a site according to its own DR location table. If the site receiving the request does not hold the requested DR, it forwards the request to another site according to its own DR location table. This process continues till the request reaches the site holding the requested DR (target site). The target site then migrates the DR (in case of migration request) or sends an acknowledgement message (in case of ®xed processing request) to the transaction initiation site. In CQ, similar to CF, the transaction initiation site ®rst sends the request to a certain site according to its own DR location table. If the receiving site does not hold the requested DR it sends the information about the location of the requested DR, according to its own DR location table, to the transaction initiation site. The transaction initiation site then updates its DR location table with the received information and sends the request again to the site given by the updated DR location table. This process continues until the request reaches the target site. Similar to CF, the target site either migrates the DR or sends an acknowledgement message to the transaction initiation site. In ECF and ECQ, the basic principles of CF and CQ, respectively, are retained. Additionally, ECF and ECQ maintain DR migration count together along with the location information of the DRs in the DR location table at each site. Every time a DR migrates, its migration count is increased by one. Hence, newer information about the location of a DR can be recognized by comparing its migration count. The request messages also carry the contents of the DR location table of the transaction

Resource locations in broadband networks

5

initiation site. At every site visited by the request, DR migration counts given by the DR location table of both request and the site are compared and older values are replaced with newer values. Finally, when the request for DR migration or ®xed processing reaches the target site, the DR or an acknowledgement message along with the updated DR location table is sent to the transaction initiation site respectively. Simultaneously, only in the case of ECF, another category of message called update message is used. The target site on the receipt of request generates an update message. Each update message carries the contents of the DR location table of the target site and it follows the route taken by the corresponding request in the reverse direction to the transaction initiation site. It updates the DR location tables of all the sites falling in its way. Hara et al. [10] showed that the ECF method gives the best performance among the above distributed algorithms. However, it should be noted that in the ECF algorithm, the request that reaches the target site ®rst receives the DR; the target site does not employ any method to determine the site (out of many sites requesting for the migration of the DR) to which the DR should be migrated from the current site. Therefore, the ECF algorithm does not ensure any kind of fairness amongst various requesting sites. In this paper, we present a simple heuristically-aided algorithm to manage locations of the DRs in a distributed network. The goal of the proposed algorithm is (i) to reduce the time delay in locating the DRs and (ii) to control the DR migration operations which guarantee fairness and liveness properties and at the same time to maximize the number of transaction requests being ful®lled in a unit amount of time. In the proposed algorithm, the sites use system state information (state of each site corresponding to all DRs) and heuristics to determine their course of actions in order to achieve improved performance in terms of reduced overall average time delay needed for locating and accessing the migratory DRs. For this, each site maintains information about the state of other sites with respect to all DRs of the system and uses two heuristics: heuristic-1, to decide to which sites the request should be forwarded to in order to locate the DR, and heuristic-2, to decide to which site (among the current requesting sites) the DR should be migrated from the current site. The effectiveness of heuristic techniques has already been demonstrated in the problems that are stochastic in nature such as distributed scheduling [22,23], network routing [24,25], multiaccess channels [26] and distributed solving [27] as well as in the problems where systems must satisfy strong and sharply de®ned constraints such as mutual exclusion [28]. Finally, we evaluate the performance of the proposed algorithm by a simulation study. We also compare the performance of the proposed algorithm with ECF (because ECF gives the best performance among the distributed algorithms developed so far) and demonstrate its improved performance in terms of reduced time delay in locating the DRs that result due to the use of system state information and the heuristics. The rest of the paper is organized as follows: In Section 2, we describe the principles involved in the design of the algorithm. A detailed description of the algorithm is given in Section 3. The analysis of the algorithm is done in Section 4. In Section 5, we

6

P. C. Saxena et al.

present the simulation model and describe the results on the performance of the proposed algorithm. Finally, we give some concluding remarks in Section 6.

2.

Principles of the algorithm

In the distributed system assumed by this paper, a site can generate two types of requests: (a) access request which signi®es that the transaction initiation site will use ®xed processing on the DR, and (b) migratory request, which signi®es that the DR will be migrated to the transaction initiation site before any operations are performed on it. A site can be in the state of requesting a DR, performing operation on a DR, not requesting for a DR or not requesting for a DR but holding the DR. The set of states of all the sites corresponding to all the DRs of the system is called system state. Each site maintains tables, one for each DR to record the state of all the sites of the system with respect to that DR. The state information is disseminated among the sites by passing messages. Therefore, the information given by these tables may be partially out-dated. Since the proposed algorithm relies upon the state information to guide its actions for locating the DRs, fast dissemination of changes in the system state is a desirable requirement. This reduces imprecision and uncertainty in state information available to a site and thus increases the chances of the request being forwarded to the site holding the DR. Moreover, as the state information is also used to determine the site to which the DR is going to be migrated to from the current site, with the increase in precision of state information, the chances that the algorithm chooses the correct site also increases. This in turn reduces overall average time delay involved in ful®lling the requests of the sites. In the proposed algorithm, we do not use additional messages for disseminating the state information but, rather, the messages used for locating the DR and the DR itself are used to pass the state information. Whenever a transaction initiation site generates a request for a DR, it sends a request message to a group of sites selected by using heuristic-1 and the system state information available to it. These sites are called favourable sites and include those sites that are either holding the DR or are likely to receive it. When the site holding the DR receives an access request, it responds to it by sending an acknowledgement message. The acknowledgement message in response to an access request informs the transaction initiation site about the location of the DR so that it can execute its transaction remotely by ®xed processing. When the site holding the DR receives a migratory request, the requested DR is migrated to the transaction initiation site, which then performs operations on the DR locally. After the site ®nishes its operations on the DR, it does not keep the DR with itself, instead it migrates the DR to another site (if any) requesting for its migration using heuristic-2 and the system state information available to it. Heuristic-2 decides which of the many sites requesting for migration of the DR should receive the DR. It chooses a site to whose less number of requests have been catered so far.

Resource locations in broadband networks

7

Although the proposed idea seems quite simple, the designing of heuristics and the mechanisms for exchanging the state information among the sites, which ensure fairness and liveness and are at the same time ef®cient (reduce the overall average time delay in locating and accessing the DRs), is nontrivial. This is because it may happen that the transaction initiation site while deciding the sites to which the request message is to be transmitted selects some sites such that none of these sites has the requested DR or is likely to receive it in the near future. Or when a DR is to be migrated to another requesting site, it may be migrated to the same site again and again. Ideally the DR should not be migrated to the same site for the second time (or more number of times, for ful®lling the subsequent requests of the site for that DR) while other sites are still waiting for their ®rst requests for that DR to be ful®lled. Therefore, in order to ensure liveness and fairness, the heuristics and the mechanisms that update the system state information should take into consideration the following: (i) if a site is in the not requesting state for a DR then it should have information about at least one site that is requesting for that DR, (ii) if a site has generated a request for a DR, then in ®nite time it should have information of the site that is either holding the requested DR or the site that has generated a request for that DR and knows the site holding the requested DR, and (iii) a site should not keep the requested DR with itself forever, when some other site has issued a request for it. In the next section, we present the description of the proposed algorithm.

3.

The algorithm

We assume that the distributed system comprises of Q sites uniquely numbered from 0 to Q-1. There are M DRs at these sites numbered from 0 to M-1. Each site contending for the DR has equal priority and no central control is supported. As already mentioned, each site can make two types of requests: access or migratory to access any of these DRs. We use the following terms for simplicity: Requesting site is the transaction initiation site, which generates a request for a DR; Target site is the site that has the requested the DR. Any site other than the target site, which receives a request from the requesting site, is called Sender site. When the target site receives the request, it responds to the request by sending an acknowledgement message or the requested DR to the requesting site depending on the type of request received. 3.1 Different states of a site At any instant of time, each site of the system can be in one of the following states for a speci®c DR: R (Requesting), the site is requesting for a DR or performing an operation on a DR, H (Holding), the site has the DR and has not sensed any request for it, and N (Not Requesting), the site is neither requesting nor holding the DR These states of the site are with reference to a particular DR since sites in the system are multitasking in nature. Each site can generate multiple requests for different DRs

8

P. C. Saxena et al.

in the system, simultaneously. The only assumption in the proposed algorithm is that a site cannot request for a DR before its previous request to the same DR has been ful®lled. It is assumed that all operations on a DR are atomic in nature. 3.2 Sequence number In order to distinguish between the present request and an old request, each site of the system maintains a sequence number. The sequence number is maintained for each DR and it increments by 1 whenever a site generates a request for that DR. The updated value of the sequence number is carried by the request message. Each site also keeps a record of the highest known sequence number of each site for all the DRs of the system. By comparing the sequence number in the received request message with the latest known sequence number of its sender site, a site can determine if the request for that DR is obsolete. The sequence number is basically an implementation of Lamport's logical clock. It ensures fairness and liveness as shall be explained later. 3.3 Access ¯ag Each site maintains an Access Flag for each DR to distinguish between access and migratory requests. Whenever a site generates a request for a DR it sets this ¯ag to 0 for migratory request and 1 for access request. 3.4 Information structures A set of M (corresponding to each DR) information structures called System State Information (SSI) tables are maintained by each site to store the system state. Each SSI table contains information of the state of all the sites in the system with respect to one DR. Each SSI table, say corresponding to DRi maintains the value of three parameters, State of Site (SS), Sequence Number (SN) and Access Flag (AF) of all the sites with respect to DRi. The SS variable tells the latest known state of all the sites (i.e. R, H or N) corresponding to DRi. The SN ®eld holds the latest known sequence number of all the sites with respect to DRi. The AF parameter is a boolean variable and represents the value of the access ¯ag for the last known request of all the sites with respect to DRi. (Note that SN is also a measure of the correctness of the system state information at a site. A higher SN indicates more recent information and this property is used for the updation of the SSI table.) The structure of the SSI table at each site is as follows: struct { int SS[Q]; / * latest known State of Site of each site */ int SN[Q]; / * latest known Sequence Number of each site */ int AF[Q]; / * Access Flag of the last known request generated by each site */ } }SSI[M]; / * M SSI tables corresponding to M DRs */

Resource locations in broadband networks

9

3.5 Heuristics The heuristics should be such that using the information given locally by the SSI table corresponding to the requested DR, a site should be able to i. form a set of sites that is likely to have the requested DR, and ii. migrate the DR to the correct site in order to ensure fairness and liveness. The heuristics used by the proposed algorithm are as follows: Heuristic-1: This heuristic determines the sites to which the requesting site should send its request. In this paper, we propose the following as heuristic-1: `All sites which are in R or H state for the requested DR (as given by the SSI table of the requested DR at the requesting site) form a set of favourable sites, and the requesting site sends requests to all such sites'. It is reasoned that the requesting site that requests for a DR will receive or access it after a ®nite delay. The credibility of the heuristic depends on the correctness of the state information it is operating on. It is important that the heuristic should not lead to a miss (none of the sites selected by heuristic-1 holds the requested DR or is likely to receive it). If a miss occurs then the site uses this heuristic again and repeats the whole process of forming a set of favourable sites and sending the requests. Heuristic-2: Using this heuristic a site determines which site (out of many requesting sites) with migratory requests should get the DR next. The site after ®nishing its execution on a DR uses this heuristic to determine if there are any sites waiting to receive the DR. We propose the following as heuristic-2: `If there is more than one site contending for the DR, the site with lowest SN for that DR (as given by the SSI table of the requested DR at the DR holding site) is chosen to be the next holder and the DR is migrated to it'. This is done so as to satisfy the requests generated by a site whose less number of requests have been ful®lled so far. 3.6 Messages The proposed algorithm does not require additional messages to disseminate the state information to different sites in the network. Instead, the messages that are required to locate the DRs, and the DRs themselves, are used for the purpose. Note that the DR while migrating from one site to the other carries a copy of the SSI table (of the site that migrates it) corresponding to it. The site that receives a message or DR updates its SSI table with the information carried by the message or DR. In order to reduce the size of messages only the information pertaining to the requested DR is passed between sites. There are four types of messages in the system: 3.6.1 Request message. These messages are generated by any site that does not hold the requested DR. The request message (Req_msg) does not carry any tables along with it and hence its size remains small. When a site receives this message, it updates the information regarding the requesting site in its SSI table for the

10

P. C. Saxena et al.

requested DR. The format of the Req_msg is Req msg(S, DN, SN, AF) The parameters are described below: S: DN : SN : AF :

Site number of requesting site (from 0 to Q-1). requested DR Number (from 0 to M-1). Sequence Number of the requesting site for the requested DR after it has been incremented by 1. Access Flag of the request which is either 0 or 1 (for migratory or access request, respectively).

3.6.2 Acknowledgement message. A site, in response to an access request, generates an acknowledgement message. This message is called Access Request Acknowledgement message (ARA_msg). This message is sent to the requesting site (1) by the target site if it receives an access request from it, or (2) from a sender site when it receives an ARA_msg from the target site against its own access request. Any site that receives an ARA_msg in response to its access request or DR in response to its migratory request sends an ARA_msg to all sites that have pending access requests (sites which are in state R with AF ˆ 1 in its SSI table for the requested DR) at that site. Thus, this message informs the requesting site of the location of the DR (note that the source of this message chain is the target site) so that it can proceed with the operation on the DR This message carries the SSI table of the target site corresponding to the requested DR along with it. The SSI table of the requesting site is updated with the SSI table in the message. It's format is: ARA msg(S, DN, SS[Q], SN[Q], AF[Q]) The parameters of the message are described below: S : Site number of target site (from 0 to Q-1). DN : requested DR Number (from 0 to M-1). SS[Q] : SS field of SSI table of target site for requested DR. SN[Q] : SN field of SSI table of target site for requested DR. AF[Q] : AF field of SSI table of target site for requested DR.

3.6.3 DR migrate message. The target site sends DR migrate message (DR_mig_msg) to the requesting site when it receives a migratory request for a DR. This message is DR along with the SSI table of the target site corresponding to the requested DR. The requesting site when receives this message, ®rst performs updation based on the SSI table information carried by the DR. Then it sends an ARA_msg to all sites from which it has received an access request for that DR, thus

Resource locations in broadband networks

11

informing them about the location of the DR. Then the requesting site can execute its operations on the DR. The format of this message is given below: DR mig msg (DN, SS[Q], SN[Q], AF[Q]) The description of the parameters is the same as that for ARA_msg. 3.6.4 I aM Not Requesting message. An I aM Not Requesting message (IMNR_msg) is generated by a site to the requesting site in two cases, (i) if it is in not requesting state for the DR for which it receives a Req_msg and (ii) if it has issued an access request for a DR and it receives a migratory request for the same DR; this is done because the site will not be able to ful®l the migratory request as it will not receive the DR (as it has issued an access request for the DR). This message also carries a copy of the SSI table corresponding to the requested DR at the sender site for updation at the requesting site. The requesting site keeps a record of the number of these messages received and compares them with the number of sites to which the Req_msg was sent (the size of the requesting site's heuristic). If these are equal (meaning thereby all the sites selected by heuristic-1 are in not requesting state), it indicates that a miss has occurred, that is, none of the sites in the heuristic has the requested DR or is scheduled to receive it. In such a case, the requesting site generates another set of favourable sites (using heuristic-1 and its updated SSI table for that DR) and sends out requests again. The format of IMNR msg is given below: IMNR msg(DN, SS[Q], SN[Q], AF[Q]) The de®nition of these parameters has been given above. 3.7 An example To illustrate the proposed algorithm, we show how a request originating at one of the sites is ful®lled. Figure 1 shows, as an example, a system consisting of ®ve sites namely S1, S2, S3, S4 and S5 (shown as circles in the diagram). Though the number of DRs in the system is more than one, for simplicity, SSI tables and messages related only to one particular DR, say DRi are shown in Fig. 1. The SSI table corresponding to DRi at each of the ®ve sites is shown as a 6  4 matrix. The upper left corner speci®es the site number where the SSI table resides. The ®rst column gives the site number corresponding to the entries in that row and the ®rst row gives the column heading to specify whether the entry in that column is SN, SS or AF (for simplicity in the diagram only F is written in place of AF). For example, the entries in the third row of the SSI table at site S1 (Fig. 1(a)) depicts that according to site S1, site S2 has generated three (SN ˆ 3) requests for DRi and presently S2 is in requesting state (SS ˆ R) and has issued a migratory request (F ˆ 0) for DRi. Any changes in the SSI table entries are shown in bold letters. Figure 1a shows the initial state of the system. We assume that S2 and S3 have already issued migratory and access requests for DRi, respectively. These requests

12

P. C. Saxena et al.

have been forwarded to all sites that are either R or H in their respective SSI tables for DRi. S5 is presently holding DRi. Now, S1 generates a migratory request for DRi. The entire process for the ful®lment of the request generated by S1 is shown in the Fig. 1(b--e). Since S1 has generated a migratory request, S1 increments its sequence number for DRi and enters the requesting state for DRi. For this it makes SS[1] (SS ®eld (a)

(b)

(c)

Figure 1. (a--c)

Resource locations in broadband networks

13

(d)

(e)

ARA_msg

Site Not Requesting for DR

DR_mig_msg

Site Holding the DR

Figure 1. (a--e): An example.

corresponding to S1) as R, increments SN[1] by 1, makes AF[1] ˆ 0 in its SSI table for DRi. It then uses heuristic-1 to generate a set of favourable sites (i.e. the sites that are listed as R or H in its SSI table for DRi) to which it must send the request for DRi. This set comprises S2, S3 and S4 and Req_msg[1], that is, Req_msg generated by S1, is sent to each of the sites in that set. The Req_msg[1] reaches sites S2, S3 and S4 and the information (SN and AF) contained in the Req_msg[1] is used to update SSI tables for DRi at these sites (Fig. 1(b)). In the meantime, let us assume that the Req_msg[2] reaches S5. Since it is a migratory request, S5 makes itself N and S2 as H in its SSI table for DRi and sends DR_mig_msg to S2. This message also carries a copy of the SSI table corresponding to DRi at S5 so that when it reaches S2, it updates the SSI table for DRi at S2

14

P. C. Saxena et al.

according to the updation rules, that is, information with higher or equal SN replaces that already present. Now let us assume that S4 receives Req_msg[1]. S4 then sends an IMNR_msg to S1 since it is in not requesting state (a site sends back an IMNR_msg if, either, it is not requesting state for that DRi or the site has issued an access request for DRi and it receives a migratory request for it). On receiving this IMNR_msg, S1 checks if the number of IMNR_msgs received corresponding to this particular request for DRi equals the number of sites to which Req_msg[1] has been sent. Since the number of IMNR_msg received by S1 is equal to 1, whereas Req_msg[1] had been sent to three sites (S2, S3 and S4), S1 concludes that at least one of these sites is either holding DRi or is likely to receive it. S1 then updates its SSI table with that of S4, a copy of which is carried in the IMNR_msg. (Note that if the number of IMNR_msgs had equalled the number of sites to which the Req_msg[1] had been forwarded (a condition that miss has occurred), then after updation S1 would use heuristic-1 again to generate another set of favourable sites and the entire process to locate DRi starting from generation of a set of favourable sites and sending Req_msgs to them would be repeated.) Now Req_msg[3] reaches S5 after DRi has migrated from S5 and hence updation takes place at S5 and it sends an IMNR_msg to S3 (Fig. 1(c)). S2 after receiving DR_mig_msg checks whether it has some pending access requests for DRi by looking at its SSI table for DRi. Since S3 is requesting for ®xed processing (R with AF ˆ 1) on DRi (Fig. 1(c)), S2 sends an ARA_msg to S3, makes S3 as N in its SSI table for DRi (Fig. 1(d)) and then starts its execution on DRi. The ARA_msg informs S3 about the location of DRi so that it can start ®xed processing on DRi at S2. It also carries a copy of the SSI table corresponding to DRi at S2 to update the SSI table for DRi at S3. S3 can then start its execution on DRi at S2 (Fig. 1(d)). After the completion of execution of operations on DRi by S2 and S3 at S2, S2 now determines if it has some pending migratory requests for DRi. If more than one migratory request is pending, then it uses heuristic-2 to determine the site to which the DRi is to migrate next. This heuristic states that the DR shall be migrated to a requesting site with minimum SN. By applying heuristic-2, it is found that DRi is to migrate to S1, so S2 makes itself N and S1 as H in its SSI table for DRi and sends DR_mig_msg to S1. On receiving DR_mig_msg, S1 updates its SSI table with the information carried by DR_mig_msg and then starts its execution on DRi (Fig. 1(e)). In the next section, we give the detailed description of the algorithm. 3.8 Detailed description 3.8.1 Initialization. Initially, each DR is assumed to be located at a different and unique site. A DR, say DRi is located at site Si. Thus M DRs are distributed among Q sites. Thus a site is in state H for a maximum of one DR and N for the rest (Fig. 2(a)). Also the SN ®eld in SSI tables corresponding to all DRs at all sites is set

Resource locations in broadband networks

15

(a)

(b)

Figure 2. (a) Initial State of All Sites in the System for All DRs. (b) A Pictorial Representation of the SSI tables at Any Site.

to 0 (Fig. 2(b)). The SSI tables corresponding to each DR at each site are initialized as follows. for(i=0;i < M;i++){ /*SSI tables of M DRs*/ for(j=0;j < Q;j++){ /*state of all sites*/ if(i=j) SSI[i].SS[j]=H; /*Si is in holding state for DRi*/ else SSI[i].SS[j]=N; /*not requesting for the rest*/ SSI[i].SN[j]=0; /*initialize SN in all SSI tables at all sites to 0*/ } }

3.8.2 Execution rules of the algorithm. Each site Si in the system is driven by the following events.

16

P. C. Saxena et al.

3.8.2.1 Site Si generates a Req_msg for DRj. When a site Si generates a request, migratory or access (AF ˆ 0 or 1, respectively), for DRj it ®rst checks to see if it holds it; if so it accesses it and completes its operation on it. If not, it uses heuristic-1 to form a set of favourable sites to locate DRj and sends a request message to all the sites in that set after incrementing the SN for itself in its SSI table for DRj by one. Si then goes to R state for DRj. The number of sites to which the request message is sent is also maintained for comparison with the number of IMNR_msg received in response to the request messages (to know whether miss has occurred or not). A detailed procedure of generating a request follows: /* This procedure is executed by site Si when it generates a Req_msg for DRj */ if(SSI[j].SS[i]==H){/*to find if site Si holds DRj*/ DRj access(); /*site Si accesses DRj*/; } else{ count_Req_msg[j]=0; /*initialize the counter which counts the number of sites to which Req_msg for DRj is sent*/ SSI[j].SS[i] = R; SSI[j].SN[i] = SSI[j].SN[i]+1; /*site Si changes its state to requesting and increments its SN in its SSI table for DRj*/ for(k=0;k < Q;k++){ if(SSI[j].SS[k]==H||SSI[j].SS[k]==R) {/*sends Req_msg to sites which are in holding or requesting state in its SSI table for DRj*/

}

}

}

send Req_msg{i,j,SSI[j].SN[i],SSI[j].AF[i]} to site Sk ; count_Req_msg[j]++; /*count the number of sites to which Req_msg is sent*/

3.8.2.2 Site Si receives a Req_msg for DRj. Each site Si on receiving a Req_msg from site Sj for DRj goes through the following steps: i. Discards the Req_msg if the SN in the request is lower than the SN of Sj as recorded in the SSI table of Si for DRj. ii. If Si is in state N for DRj, it makes SS[j] as R and replaces SN[j] and AF[j] with that in the Req_msg in its SSI table for DRj. It sends an IMNR_msg to site Sj. iii. If Si is state R for DRj and has not already sent a Req_msg for DRj to Sj, it sends a Req_msg to Sj now. It also updates its state information as in step ii. If the AF of Si is 1 (it has already issued an access request) and that in the Req_msg is 0 (it receives a migratory request), Si sends an IMNR_msg to Sj, since it will not

Resource locations in broadband networks

17

receive DRj in response to its access request for DRj and hence cannot cater to a migratory request for DRj. iv. If Si is in state H for DRj, its response is based upon the AF of the Req_msg. If the request is a migratory request (AF ˆ 0), it makes SS[j] ˆ H and itself as N in its SSI table for DRj and then sends a DR_mig_msg to Sj. If it is an access request (AF ˆ 1), it makes SS[j] ˆ N in its SSI table for DRj and then sends an ARA_msg to Sj. It also replaces SN[j] and AF[j] in its SSI table for DRj with that in the Req_msg. The detailed description of the procedure is as follows. /* This procedure is executed by site Si when it receives a Req_msg(S, DN, SN, AF) for DRj from site Sj*/ /*(note that Req_msg.s represents Sj and Req_msg.DN represents DRj)*/ if(SSI[Req_msg.DN].SN[Req_msg.S]< ˆ Req_msg.SN){/*find out if request is obsolete*/ switch (SSI[Req_msg.DN]. SS[i]){ case(N): /*Si is in not requesting state for DRj*/ /*update Sj's entries for DRj in SSI table for DRj*/ SSI[Req_msg.DN].SS[Req_msg.s]=R; SSI[Req_msg.DN].SN[Req_msg.s]=Req_msg.SN; SSI[Req_msg.DN].AF[Req_msg.s]=Req_msg.AF; /*send IMNR_msg to Sj*/ send IMNR_msg{Req_msg.DN, &SSI[Req_msg.DN].SS, &SSI[Req_msg.DN].SN, &SSI[Req_msg.DN].AF} to site Sj; break; case(R): /*Si is in requesting state for DRj*/ /*send Req_msg to Sj if Si has not previously sent a Req_msg to it*/ if(SSI[Req_msg.DN].SS[Req_msg.s]==N){ send Req_msg{i, Req_msg.DN, SSI[Req_msg.DN].SN, SSI[Req_msg.DN].AF} to site Sj } /*update Sj's entries for DRj in SSI table for DRj*/ SSI[Req_msg.DN].SS[Req_msg.S]=R; SSI[Req_msg.DN].SN[Req_msg.S]=Req_msg.SN; SSI[Req_msg.DN].AF[Req_msg.S]=Req_msg.AF; /*send IMNR_msg to Sj if the request received is migratory while Si has issued an access request for DRj*/

18

P. C. Saxena et al. if((Req_msg.AF==0)&& (SSI[Req_msg.DN].AF[i]==1)){ send IMNR_msg{Req_msg.DN, &SSI[Req_msg.DN].SS, &SSI[Req_msg.DN].SN, &SSI[Req_msg.DN].AF} to site Sj; } break; case (H): /*Si is in holding state for DRj*/ /*update Sj's entries for DRj in SSI table for DRj*/ SSI[Req_msg.DN].SN[Req_msg.s]=Req_msg.SN; SSI[Req_msg.DN].AF[Req_msg.s]=Req_msg.AF; if(Req_msg.AF==0){/*incoming request is migratory for DRj*/ /*to cater to migratory request Si enters in not requesting state and Sj enters in holding state. Then DRj along with SSI table of DRj at site Si migrates to Sj */ SSI[Req_msg.DN].SS[Req_msg.s]=H; SSI[Req_msg.DN].SS[i]=N; send DR_mig_msg{Req_msg.DN, &SSI[Req_msg.DN].SS, &SSI[Req_msg.DN].SN, &SSI[Req_msg.DN].AF} to site Sj; } else{/*incoming request is an access request for DRj */ /* since access request of Sj is now fulfilled, Sj enters in not requesting state. Site Si sends an ARA_msg to Sj*/ SSI[Req_msg.DN].SS[Req_msg.s]=N; send ARA_msg{S,Req_msg.DN, &SSI[Req_msg.DN].SS, &SSI[Req_msg.DN].SN, &SSI[Req_msg.DN].AF} to site Sj; }

}

break;

3.8.2.3 Site Si receives an IMNR_msg for DRj. When Si receives an IMNR_msg in response to its Req_msg for DRj it ®rst updates its SSI table corresponding to DRj with the SSI table information carried by IMNR_msg. The site also increments a counter which counts how many IMNR_msgs are received in response to the Req_msgs for DRj. If the number of IMNR_msgs received are equal to the number

Resource locations in broadband networks

19

of sites to which Req_msgs have been sent, then site Si concludes that a miss has occurred. In case of a miss site Si generates another set of favourable sites using heuristic-1 and again sends request messages to all sites in that set. The detailed description of the procedure follows: /*This procedure is executed by site Si when it receives an IMNR_msg (DN, SS[Q], SN[Q], AF[Q]) */ UPDATION(IMNR_msg); /*section 3.8.3*/ count_IMNR_msg[IMNR_msg.DN]++;/*count the number of IMNR_msgs received*/ /*if number of IMNR_msgs equals the number of sites to which Req_msgs have been sent, then again form a set of favourable sites for the purpose of sending request messages*/ if(count_IMNR_msg[IMNR_msg.DN]==count_Req_msg [IMNR_msg.DN]){ count_IMNR_msg[IMNR_msg.DN]=0; /* resetting counters */ count_Req_msg[IMNR_msg.DN]=0; for(k=0;k < Q;k++){ if (SSI[IMNR_msg.DN].SS[k]==H||SSI[IMNR_msg.DN]. SS[k]==R){/*sends Req_msg to sites which are in holding or requesting state in its SSI table for DRj*/

}

}

send Req_msg{i,IMNR_msg.DN,SSI[IMNR_msg.DN].SN[i], SSI[IMNR_msg.DN].AF[i]} to site Sk ; count_Req_msg[IMNR_msg.DN]++; /*count the number of sites to which Req_msg is sent*/ }

3.8.2.4 Site Si receives an ARA_msg for DRj. When Si receives an ARA_msg from Sj in response to its access request for DRj, it updates its SSI table with the SSI table contained in the ARA_msg. Si then sends an ARA_msg to all sites that have generated access requests for DRj by looking at its updated SSI table for DRj, to apprise them of its location. At the same time it makes them not requesting in its SSI table for DRj. It then starts its operation on DRj. Also, as Si's access request for DRj has been ful®lled, it goes into not requesting state for DRj. The detailed description of the procedure follows: /* This procedure is executed by site Si when it receives an ARA_msg(S, DN, SS[Q] SN[Q], AF[Q]) */ UPDATION(ARA_msg); /*section 3.8.3*/

20

P. C. Saxena et al. /*send an ARA_msg to all sites that have generated access requests for DRj*/ for (k=0;k < Q; k++){ if(SSI[ARA_msg.DN].SS[k]==R){ if (SSI[ARA_msg.DN].AF[k]==1){ send ARA_msg{ARA_msg.s,ARA_msg.DN, &SSI[ARA_msg.DN].SS, &SSI[ARA_msg.DN].SN, &SSI[ARA_msg.DN].AF} to site Sk; SSI[ARA_msg.DN].SS[k]=N; } } } if(SSI[ARA_msg.DN].SS[i]==R){ /*find out if Si is still requesting for DRj */

}

DRj access(); /*site Si accesses DRj */ SSI[ARA_msg.DN].SS[i]=N; /*after execution Si enters the N state for DRj */

3.8.2.5 Site Si receives a DR_mig_msg for DRj. When site Si receives a DR_mig_msg it updates its SSI table for DRj with that in the DR_mig_msg and starts execution on DRj. It then sends an ARA_msg to all sites whose access requests for DRj are pending (which are in state R with AF ˆ 1 in its updated SSI table). Si after completing its execution with DRj checks if there are any pending migratory requests in its SSI table for DRj. If migratory requests are waiting, it uses heuristic-2 to decide which site to send DRj next. It chooses a site Sk, which is in the requesting state and has the lowest SN in its SSI table for DRj. DRj then migrates to the site Sk and the state of Sk and Si is updated to holding and not requesting, respectively in the SSI table for DRj at Si. If no migratory request is waiting, Si keeps DRj with itself and enters the holding state for it. The description of the procedure follows: /* This procedure is executed by site Si when it receives a DR_mig_ msg(DN, SS[Q], SN[Q], AF[Q])*/ UPDATION(DR_mig_msg); /*section 3.8.3*/ DRj access(); /*site Si accesses DRj*/; SSI[DR_mig_msg.DN].SS[i]=H;/*site Si enters into holding state*/ /*send ARA_msg to all sites that have generated access requests for DRj*/ for(k=0;k < Q;k++){ if(SSI[DR_mig_msg.DN].SS[k]==R){ if(SSI[DR_mig_msg.DN].AF[k]==1){ send ARA_msg{i,DR_mig_msg.DN,

Resource locations in broadband networks

}

}

21

&SSI[DR_mig_msg.DN].SS, &SSI[DR_mig_msg.DN].SN, &SSI[DR_mig_msg.DN].AF} to site Sk; SSI[DR_mig_msg.DN].SS[k]=N;

} if(heuristic-2()){ /*find if DRj is to be migrated*/ send DR_mig_msg{DR_mig_msg.DN, SSI[DR_mig_msg.DN].SS, &SSI[DR_mig_msg.DN].SN, SSI[DR_mig_msg.DN].AF} to chosen site Sk; /*DRj along with the SSI table of DRj at site Si migrates to Sk*/ SSI[DR_mig_msg.DN].SS[i]=N; SSI[DR_mig_msg.DN].SS[k]=H; }

3.8.3 Updation rules. The updation rules followed by the algorithm essentially compare the sequence number at the sites performing the updates with those in the incoming message to determine who has more recent information about the state of sites for the corresponding DR and restores the outdated entries with more current ones. The detailed procedure for the updation on the receipt of a message (received_msg, for simplicity) that may be an IMNR_msg, DR_mig_msg or ARA_msg is given below: /*This procedure is executed by site Si when it performs updation after receiving an IMNR_msg or DR_mig_msg or ARA_msg*/ UPDATION(received_msg (IMNR_msg/DR_mig_msg/ARA_msg)){ for(k=0;k < Q;k++){/*update all entries in the SSI table corresponding to DRj at Si*/ if(SSI[received_msg.DN].SN[k]<=received_msg.SN[k]){ SSI[received_msg.DN].SS[k]=received_msg.SS[k]; SSI[received_msg.DN].SN[k]=received_msg.SN[k]; SSI[received_msg.DN].AF[k]=received_msg.AF[k]; } } }

4.

Analysis of the algorithm

4.1 Liveness Liveness means that any site requesting a DR eventually gets an access to the DR in a ®nite interval of time. In the proposed algorithm a site can access a DR after

22

P. C. Saxena et al.

receiving either an ARA_msg or DR_mig_msg; therefore, the condition for liveness of the algorithm can be written as: A site requesting a DR receives an ARA_msg or DR_mig_msg in a ®nite interval of time. The above stated condition can be justi®ed by breaking it further into two conditions both of which will be shown to hold. (a) `A site requesting a DR eventually sends a request to a site that is in R or H state corresponding to the DR.' The requesting site uses heuristic-1 and the state information available to it to determine the sites to which the Req_msgs to locate a DR must be sent. This state information may sometimes be outdated, which may lead to a miss. Therefore, requesting site keeps count of the number of sites to which it sends the Req_msgs and if it receives an equal number of IMNR_msgs, it sends Req_msgs again based on its updated SSI table. Since on the receipt of an IMNR_msg, there is updation at the requesting site with the SSI table of the sender site, the requesting site ®nally has the most updated SSI table of all sites to which it had sent the request. Thus, its heuristic becomes more focused and this process of updation and sending requests stops only if the number of IMNR_msgs received is less than the number of sites to which the Req_msgs have been sent, that is, at least one of its Req_msgs reached a site that is in R or H state for the requested DR. The request therefore gets lodged at the R site or ful®lled by the H site. (b) `A site which has lodged its request with another site eventually receives either an ARA_msg or DR_mig_msg.' If a site Si has lodged its request with site Sj for DRj, a number of cases arise: i. Si has sent an access request and Sj is in H state: Sj sends an ARA_msg to Si. ii. Si has sent a migratory request and Sj is in H state: After Sj completes execution, it uses heuristic-2 to send the DR_mig_msg to some site Sk. If k is not equal to i, the DR_mig_msg causes the request of Si to be lodged at Sk (the site that has DRj currently). Sk after ®nishing its operations on DRj uses heuristic-2 to determine the site to migrate DRj. This process continues till site Si is the chosen site. iii. Si has sent an access request and Sj has already issued a migratory request (is in R state with AF ˆ 0): As soon as Sj receives DRj (DR_mig_msg), it sends an ARA_msg to Si, if it is in R state in the SSI table at Sj for DRj which has been updated with that carried by the DR_mig_msg. iv. Si has sent an access request and Sj has already issued an access request (is in R state with AF ˆ 1): As soon as Sj receives an ARA_msg from the target site it forwards it to Si. v. Si has sent a migratory request and Sj has already generated a migratory request (is in R state with AF ˆ 0): If Sj receives DRj before Si it ®rst performs an operation on it and then the same steps as in case ii take place.

Resource locations in broadband networks

23

vi. Si has sent a migratory request and Sj has already issued an access request (is in R state with AF ˆ 1): Site Sj makes Si as R in its SSI table for DRj but replies with an IMNR_msg to Si as it will not be able to ful®l the request of Si. This avoids starvation at Si. Hence, the liveness of the proposed algorithm is ensured. 4.2 Fairness Although the serialization principle is not strictly FCFS, the algorithm ensures fairness by making the DRs accessible to all sites by way of the sequence number priority scheme. A site with lower SN (i.e. fewer previous requests for a DR) has higher priority than one with higher SN. This ensures that no site monopolizes the DRs. Currently, the SN of a site with respect to DR increments when a site makes a request for that DR. We can have another scheme in which SN increments on every operation that is performed on the DR. The heuristic can then be modi®ed such that it bases the priority on the number of operations on a DR rather than the number of requests made for it.

5.

Simulation model and results

The general ATM network environment similar to that used in [10] has been assumed in this paper. The communication network is assumed to be reliable (i.e. messages are neither lost nor duplicated and are transmitted error free) and sites do not crash. The algorithms (proposed and ECF) are implemented on the following three network topologies: i. a binary tree with depth k (number of sites n ˆ 2 k) having sites as leaves and ATM switches at every other level (Fig. 3(a)), ii. a star topology with a central switch (Fig. 3(b)), iii. a mesh topology (Fig. 3(c)). We chose this topology because of its realistic interconnection structure of a possible ATM network. Each of the 32 nodes (shown as * in the ®gure) in the network is an ATM switch and each switch in the network is assumed to be associated with a single site. It should be noted here that in a real network there can be more than one site associated with a switch but for simplicity purposes we chose to assume otherwise. The sites communicate by setting up SVCs (Switched Virtual Connections). An SVC between two sites remains valid for 20 min after the setup. When site Si sends a message to the site Sj, the message is routed through intermediate ATM switches. The total time required for transmitting one message between two sites consists of two parameters: (a) the time required for setting up the SVC connection called

24

P. C. Saxena et al. (a)

× ×

×

k … ATM switch

×

×

…

×

×

… S1

S2k-1

S2

(b)

×

ATM switch (c)

Figure 3. (a) Binary tree topology. (b) Star topology. (c) Mesh topology.

S2k

Resource locations in broadband networks (a)

25

P9

d

R

×

Si

…

R

d

×

Sj

h

ATM switch (b)

P

d Si

r

×

ATM switch

…

r

d

×

Sj

h

Figure 4. (a) Connection establishment. (b) Message transmission.

Channel Establishment (CE) delay (Fig. 4(a) and (b)) the time needed for the transmission of the message once the connection is made, called Message Transmission (MT) delay (Fig. 4(b)). Thus, if h is the hop count (i.e. the number of ATM switches) between the two communicating sites, P 0 the total processing delay at both sites, d the constant propagation delay between two arbitrary ATM switches, R and r the constant routing con®guration time and the constant routing time, respectively at an arbitrary ATM switch, then CE…h† ˆ P0 ‡ 2…h ‡ 1†d ‡ h…r ‡ R†

…1†

If during transmission P is the total processing delay at both sites, then MT…h† ˆ P ‡ …h ‡ 1†d ‡ hr

…2†

Hence, the total Communication Time (CT) required for making a SVC connection and transmitting one message from one site to another via h hops is determined by CT…h† ˆ nCE…h† ‡ MT…h†

…3†

26

P. C. Saxena et al.

 n ˆ 0; when SVC connection already exists between Si and Sj where n ˆ 1; when SVC connection does not exist between Si and Sj The ATM network parameters considered in this paper are consistent with [10] and are given in Table 1. We have simulated both proposed and ECF algorithms. For simplicity, each site generates requests with equal probability and the requested DR is chosen among M DRs with equal probability. We assume 32 sites and 20 DRs in the network unless otherwise stated. In our simulation experiments 5000 requests are processed by each method, in which the intervals between requests follow exponential distributions that are based on the mean access interval called interaccess delay (ia_delay). The ia_delay is varied from 10 s to 3 min in steps of 10 s. In the simulation both access and migratory requests are generated and the relative probability of generation of access or migratory requests is proportional to Access to Migration (A/M) ratio. The performance of the algorithms has also been studied with respect to A/M ratio, which is varied from 1 to 15. We have calculated the time delay (time required to locate and access the DR, which is the time spent between generation of a request and receipt of corresponding acknowledgement message (ARA_msg) or the requested DR (DR_mig_msg)). Note that the time delay does not include the transmission delay of DR migration, since this delay is the same in both the methods (proposed and ECF) and thus, can be neglected. We have also calculated the message traf®c and the navigation count. The message traf®c is the total number of messages exchanged between the sites in order to ful®l a request (includes Req_msg, ARA_msg, DR_mig_msg and IMNR_msg) and the navigation count is the number of sites (including requesting site) involved in ful®lling a request. We have calculated these values by averaging the values obtained in processing the 5000 requests. The simulations were carried out in PARSEC (PARallel Simulation Environment for Complex systems), which is a C-based discrete event simulation language [29,30]. It adopts the process interaction approach to discrete event simulation. An object (or physical process) or set of objects in the physical system is represented by a logical process. Interaction among physical processes (events) is modelled by time stamped message exchanges among the corresponding logical processes.

Table 1. Parameters P0 P r R d

ATM Network Parameters Values (seconds) 0.03 0.01 0.002 0.01 0.005

Resource locations in broadband networks

27

(b)

(a)

300

13

150

10

100

/M

7 4

50 1

0 1

3

5

7

200 13

150 10

100 7 50

4

0

9 11 13 15 17

1 1

ia_delay (× ×10 s)

/M

200

250

A

250

Avg. time delay per request (ms)

300

A

Avg. time delay per request (ms)

350

3

5

7

9 11 13 15 17

ia_delay (×10 s)

(c)

100 80 60

13 10

40

/M

7 20

A

Avg. time delay per request (ms)

120

4

0

1 1

3

5

7

9 11 13 15 17

ia_delay (×10 s)

Figure 5. (a) Time delay using the proposed algorithm for binary tree topology (for Q ˆ 32 and M ˆ 20). (b) Time delay using the proposed algorithm for mesh topology (for Q ˆ 32 and M ˆ 20). (c) Time delay using the proposed algorithm for star topology (for Q ˆ 32 and M ˆ 20).

The results of our ®rst simulation experiment have been plotted as threedimensional graphs in Fig. 5. The x-axis represents the variations in ia_delay and the y-axis that in the A/M ratio. The average time delay is plotted along the z-axis. In order to provide the reader a better understanding of exact variation that takes place in average time delay values, we also give these values in Table 2, for the minimum and maximum values of ia_delay for four different values of A/M ratios. We observe from Fig. 5 and Table 2 that the time delay varies from 195--332 ms, 144--248 ms and 63--104 ms for binary tree, mesh and star topology, respectively for different values of A/M ratios and ia_delay. The highest time delay is obtained for binary tree topology and lowest for star topology, which indicates that the performance of the proposed algorithm improves with the connectivity of the

28

P. C. Saxena et al.

Table 2 Variation in Average Time Delay per Request (ms) with A/M Ratio using the Proposed Algorithm for Different Network Topologies A/M Ratio

ia_delay (s) ! Time delay for binary tree topology (ms) Time delay for mesh topology (ms) Time delay for star topology (ms)

1

5

10

15

10--180 196--327 145--244 63--102

10--180 195--329 147--248 63--103

10--180 195--332 147--247 63--104

10--180 197--332 144--240 63--104

network. It is also observed that time delay values remain nearly unaffected by the changes in the values of A/M ratio (frequency of DR migrations). This is because in the proposed algorithm, the request message (access or migratory) is sent to either a holding site or a site that is already requesting for the same DR (going to hold the DR in the near future). The holding site satis®es the request immediately, whereas the request gets lodged at the requesting site (called sender site). Note that in the proposed algorithm the request message does not chase the DR (as in ECF), but whenever the sender site receives the DR, it caters to the requests of the requesting site. Therefore, whether the request is access or migratory, it gets lodged at the sender site and will be ful®lled by that site only. Hence the number of access or migratory requests (that is proportional to A/M ratio) does not affect the time delay in processing these requests. As seen from the results, the time delay values vary substantially with ia_delay. At lower values of ia_delay, the requests are generated frequently; therefore, most of the requests are catered to using existing SVCs, whereas at higher ia_delays as requests are generated after a longer time period, more number of SVCs are broken and hence are to be re-established, thereby increasing the time delay. We have also observed that the requesting site has to use the heuristic to send requests to locate a DR not more than twice. In the second experiment, we simulated the ECF algorithm. The time delay values obtained for the three topologies are plotted as three-dimensional graphs shown in Fig. 6(a--c). Also the time delay values (at minimum and maximum values of ia_delay) for four different values of A/M ratios are given in Table 3. We observe from Fig. 6 and Table 3, that the time delay values obtained using ECF varies from 265--543 ms, 185--382 ms and 85--170 ms for binary tree, mesh and star topology, respectively. From the given values, clearly, the proposed algorithm comes out to be far better than ECF in terms of time delay for all the three network topologies. The proposed algorithm gives lower time delay values than ECF in every access interval and for all values of A/M ratio. We observe that in ECF, unlike in the proposed algorithm, the time delay varies substantially with A/M ratio. At lower A/M ratios the performance of ECF deteriorates because the DRs migrate frequently, quickly rendering their location information obsolete. Also, in ECF, the requesting site does not get the latest location information till the algorithm ®nds the target site. At high A/M ratios and high ia_delay values, the performance of ECF

Resource locations in broadband networks

29

(b)

(a)

400

600

Avg. time delay per request (ms)

Avg. time delay per request (ms)

350 500 400 13

300 10

200 7 100

4

0

A/M

1 1

3

5

7

9

300 250 200

13

150

10

100

7

50

4 1

0

11 13 15 17

A/M

1

ia_delay (×10 s)

3

5

7

9

11 13 15 17

ia_delay (× ×10 s)

(c)

180

Avg. time delay per request (ms)

160 140 120 100 13

80 10

60 7

40 4

20 0

A/M

1 1

3

5

7

9

11 13 15 17

ia_delay (× ×10 s)

Figure 6. (a) Time delay using ECF Algorithm for Binary Tree Topology (for Q ˆ 32 and M ˆ 20). (b) Time delay using ECF Algorithm for Mesh Topology (for Q ˆ 32 and M ˆ 20). (c) Time delay using ECF Algorithm for Star Topology (for Q ˆ 32 and M ˆ 20).

Table 3

Variation in Average Time Delay per Request (ms) with A/M Ratio using ECF Algorithm for Different Network Topologies A/M Ratio

ia delay (s) ! Time delay for binary tree topology (ms) Time delay for mesh topology (ms) Time delay for star topology (ms)

1

5

10

15

10--180 367--543 245--382 117--170

10--180 352--513 238--364 112--161

10--180 323--465 219--323 103--147

10--180 265--353 185--251 85--112

is comparable to the proposed algorithm because at such large access intervals, the sites are idle most of the time. We illustrate these observations with an example. In binary tree topology, at A/M ratio ˆ 1 and ia_delay ˆ 10 s, the time delay obtained with the proposed algorithm (196 ms) is 46% lower than that of ECF (367 ms) and at higher values of ia_delay say 180 s, the improvement in the time delay obtained by

30

P. C. Saxena et al.

the proposed algorithm (327 ms) to that obtained by ECF (543 ms) decreases to 39%. At A/M ratio ˆ 15 and ia_delay ˆ 10 s, time delay obtained with the proposed algorithm (197 ms) is 25% lower than that of ECF (265 ms) and at ia_delay ˆ 180 s, the improvement in the time delay obtained by the proposed algorithm (332 ms) to that obtained by ECF (353 ms) decreases to 0.06%. Similar behaviour is observed in mesh and star topology at A/M ratio ˆ 1, where the time delay nearly varies from 145 to 244 ms and 63 to 102 ms (for ia_delay values varying from 10 to 180 s) respectively using the proposed algorithm and 245 to 382 ms and 117 to 170 ms respectively using ECF. Whereas the values of time delay at A/M ratio ˆ 15 nearly varies from 144 to 240 ms and 63 to 104 ms using the proposed algorithm and 185 to 251 ms and 85 to 112 ms using ECF for mesh and star topology respectively. As seen from these values, the difference between the time delay values obtained by using the proposed and ECF algorithms becomes lesser at higher values of A/M ratio and ia_delay. The goal of the proposed algorithm is to reduce the overall average time delay and we have been able to reduce it signi®cantly. In order to have a better insight into the algorithm, we studied the average number of messages generated by the proposed algorithm. In the third experiment we varied ia_delay and A/M ratio (same values considered above) and computed the average number of messages generated per request for each pair of values. We observed that the average number of messages varied from 23 to 25 (against 4.34 in ECF at A/M ratio ˆ 1 and ia_delay ˆ 10 s) per request. Note that in the proposed algorithm, message traf®c is independent of A/M ratio, whereas in ECF message traf®c increases with decrease in A/M ratio. This is because in ECF, at lower A/M ratios, the DRs migrate frequently, quickly making their location information outdated. Therefore, the request message has to travel more number of sites. Also, more messages are in turn needed to update the location information on sites traversed by a request. The values for ECF are given here to give the reader an idea of ECF performance in terms of message traf®c form the basis for comparison. In the fourth experiment, besides network depth of 5 (Q ˆ 32), we also performed simulations for depth equal to 6 and 7 for binary tree topology. The number of DRs was kept at 20. Figure 7 shows the comparison of the time delay values obtained using proposed and ECF algorithms with the enlargement of network. The time delay here is the average over the range of values of ia_delay considered previously for an A/M ratio of 8. The graph shows that the performance of proposed algorithm improves with increase in the number of sites in the network. Also, as the number of sites in the network increase, the time delay using ECF rises rapidly whereas the increase obtained by the proposed algorithm is not as sharp. It is also observed that the message traf®c and navigation count in the proposed algorithm increases from 24 to 75, and 12 to 38, respectively as the number of sites in the network increases from 32 to 128. Thus, from the above results, we can summarize that the proposed algorithm is superior to ECF, unaffected by the frequency of DR migrations, largely affected by

Resource locations in broadband networks

31

ECF

1200

Proposed Algorithm

Avg. Time Delay per Request (ms)

1000 800 600 400 200 0 5

6

7

Network Depth

Figure 7. Variation in time delay with network depth for binary tree topology (for A/M ˆ 8 and M ˆ 20).

the frequency of requests generation and that these advantages become more obvious with the increase in network population and connectivity.

6.

Conclusion

In this paper, we have presented a heuristic based algorithm to manage locations of DRs in a distributed network. We have shown that the algorithm locates DRs without fail and is free from starvation. The algorithm uses system state information and heuristics to achieve better performance (lower time delay in locating DRs) than the existing algorithm ECF. We have conducted a performance study of the algorithm using an event driven simulation language and seen that the algorithm is effective over different topologies and its performance improves with better connectivity. The increased connectivity reduced the initial time delay involved in sending requests. It is not so advantageous in the ECF algorithm, since it involves serial propagation of the requests. In ECF, time delay becomes poor because requests propagate serially from one site to another. Since a request message chases the DR along its migration track, the performance of ECF algorithm deteriorates when DRs migrate frequently. Moreover, ECF algorithm does not ensure fairness amongst the various requests generated by the system. The reduced time delay obtained by using the proposed algorithm becomes more conspicuous as the number of sites in the system increases. This is because the proposed algorithm performs constant updation of system state information whereas the performance of ECF degrades due to outdated DR location information. We have modi®ed on the heuristics suggested by Mukesh Singhal [28] to adapt to our environment (DR location in broadband networks) and to ensure that there is no case of deadlock without imposing any restriction on the sites. The algorithm accounts for all possibilities except that of site or media failure. The crash recovery

32

P. C. Saxena et al.

mechanisms should be constituted to obviate these problems, but we have not addressed these issues in this paper. Finally, we have attempted to illustrate the effectiveness of heuristic techniques in the environments that support DR migration. Since DR migration is one of the basic operations employed in transaction processing, proper mechanisms for the migration of DR and minimization of DR location delay are necessary to improve transaction processing throughout.

Acknowledgements The authors are thankful to the reviewers for their valuable comments. It would not have been possible for us to put the paper into its present form without their suggestions.

References 1. P. H. Enslow 1978. What is `Distributed' Data Processing System. IEEE Computer. 13--21. 2. H. Armbruster 1998. The Flexibility of ATM: Supporting Future Multimedia and Mobile Communications. IEEE Communications Magazine 33, 76--84. 3. R. Handel, M. N. Huber & S. Schroder 1999. ATM Networks, Concepts, Protocols, Applications. Third Edition, Addison Wesley. 4. T. Hara, K. Harumoto, M. Tsukamoto & S. Nishio 1998. DB-MAN: A Distributed Database System based on Database Migration in ATM Networks. Proceedings of the 14th International Conference on Data Engineering (ICDE 98), 522--531. 5. T. Hara, K. Harumoto, M. Tsukamoto & S. Nishio 1998. Database Migration: A New Architecture for Transaction Processing in Broadband Networks. IEEE Transactions on Knowledge and Data Engineering 10(5), 839--854. 6. A. Hac 1989. A Distributed Algorithm for Performance Improvement Through File Replication, File Migration, and Process Migration. IEEE Transactions on Software Engineering 15(11), 1459-1470. 7. R. T. Hurley & S. A. Yeap 1996. File Migration and File Replication: A Symbiotic Relationship. IEEE Transactions on Parallel and Distributed Systems 7(6), 578--586. 8. S. Banerjee, V. O. K. Li & C. Wang 1993. Distributed Database Systems in High-Speed WideArea Networks. IEEE Journal on Selected Areas in Communications 11(4), 617--630. 9. T. Hara, K. Harumoto, M. Tsukamoto & S. Nishio 2000. Dynamic Replica Allocation Using Database Migration in Broadband Networks. Taipei Proceedings of International Conference on Distributed Computing Systems (ICDCS 2000). 10. T. Hara, K. Harumoto, M. Tsukamoto & S. Nishio 1997. Location Management Methods of Migratory Data Resources in ATM Networks. Proceedings of the ACM Symposium on Applied Computing (ACM SAC 97), 123--130. 11. S. Nishio & M. Tsukamoto 1996. Towards New Multimedia Information Base in Broadband Networks. IEICE Transactions on Fundamentals of Electronics, Communications and Computer Sciences 79(4). 12. P. C. Saxena, S. Gupta & G. Gabrani 2000. A Location Chasing Algorithm for Migratory Data Resources in ATM Networks. International Journal of Information and Computing Science 3(2), 1--28. 13. P. C. Saxena, S. Gupta & G. Gabrani 2000. A Security Model to Support Data Resource Migration. CSI Journal: Computer Science and Informatics 30(4), 21--29. 14. I. F. Akyildiz & J. S. M. HO 1996. On Location Management for Personal Communications Networks. IEEE Communications Magazine, 138--145.

Resource locations in broadband networks

33

15. B. R. Badrinath, T. Imielinski & A. Virmani 1992. Location Strategies for Personal Communication Network. Proceedings of Workshop on Networking of Personal Communication Applications. 16. R. Jain & Y. B. Lin 1995. An Auxiliary User Location Strategy Employing Forwarding Pointers to Educe Network Impact of PCS. ACM-Baltzer J. Wireless Networks 1(2), 197--210. 17. R. Kadobayashi & M. Tsukamoto 1995. Performance Comparison of Mobile Support Strategies. Proceedings of 1st International Conference on Mobile Computing and Networking (Mobicom 95), 218--225. 18. S. Mohan & R. Jain 1994. Two User Location Strategies for Personal Communications Services. IEEE Personal Communications, 1st quarter, 42--50. 19. S. Tabbane 1997. Location Management Methods for 3rd Generation Mobile Systems. IEEE Communication Magazine 35, 72--78. 20. M. Veeraghavan & G. Dommetry 1997. Mobile Location Management in ATM Networks. IEEE Journal on Selected Areas in Communications 15, 1437--1454. 21. J. Z. Wang 1993. A Fully Distributed Location Registration Strategy for Universal Personal Communication Systems. IEEE JSAC 11(6), 850--860. 22. K. Efe 1982. Heuristic Models of Task Assignment in Distributed Systems. IEEE Computer. 50--56. 23. D. L. Eager, E. D. Lazowska & J. Zahorjan 1986. Adaptive Load Sharing in Homogeneous Distributed Systems. IEEE Transactions on Software Engineering 662--675. 24. R. R. Boorstyn & A. Livne 1981. A Technique for Adaptive Routing in Networks. IEEE Transactions on Communications 474--480. 25. J. M. McQuillan 1980. The New Routing Algorithm for the ARPANET. IEEE Transactions on Communications 711--718. 26. R. A. Maule & A. Kandel 1985. A Model for an Expert System for Medium Access Control in a Local Area Network. Information Science 37, 39--83. 27. G. M. Baudet 1978. Asynchronous Iterative Methods for Multiprocessors. J. ACM, 226--244. 28. M. Singhal 1989. A Heuristically-Aided Algorithm for Mutual Exclusion in Distributed Systems. IEEE Transactions on Computers 38(5), 651--662. 29. K. Bagchi, J. Walrand & G. W. Zobrist 1998. Advanced Computer Performance Modeling and Simulation. Amsterdam, The Netherlands: Gordon and Breach Science Publishers. 30. R. Meyer 1998. PARSEC User Manual Release 1.1. Computer Science Department, UCLA, Los Angeles, CA 90024.

P. C. Saxena is a Professor of Computer Science at School of Computer and System Sciences, Jawahar Lal Nehru University, New Delhi, India. He has supervised nine Ph.D. students in the area of Database Management, Networking and Multimedia. He has also guided ®fty-®ve M.Tech. Dissertations. He has published several research papers in International and National Journals. His research interest include DBMS, Data Communication, Networking, Distributed Computing and Multimedia.

34

P. C. Saxena et al. D. Roy Choudhury obtained his M. Tech. degree from Universtity of Calcutta, in 1966 and Ph. D. from the same university in 1971. From 1971 to 1973, he was associated with the Institute de Reglage Automatique EPFL, Switzerland. Since 1974, he has been in the faculty of Delhi College of Engineering, University of Delhi, New Delhi, India. At present, he is Professor in the Computer Engineering Department at Delhi College of Engineering. His ®eld of interest includes Distributed Systems, Neural Networks and Petrinets.

G. Gabrani is an Assistant Professor of Computer Engineering at Delhi College of Engineering, University of Delhi, India. She received her Bachelors and Masters degrees in Engineering in 1984 and 1990, respectively. She has guided several B.E. projects and around 15 M.E. Dissertations. She has published several research papers in International and National Journals. Her research interests include Distributed Systems, Networks and Digital Systems Design.

S. Gupta is an Assistant Professor of Computer Science at School of Computer and System Sciences, Jawahar Lal Nehru University, New Delhi, India. She received her Bachelors degree in Engineering and Masters in Technology degree in 1991 and 1995, respectively. Further, she did her Ph.D. in 1999 in the area of Distributed Computing. She has published several research papaers in International and National Journals. Her research interest include Distributed Systems, Networks and Multimedia Database.

M. Bhardwaj did his Bachelor's in Engineering from Delhi College of Engineering, University of Delhi, New Delhi, India, in 2001. His research interests include Distributed Systems, Networks and Optical Communications.

Resource locations in broadband networks

35

M. Chopra did his Bachelor's in Engineering from Delhi College of Engineering, University of Delhi, New Delhi, India, in 2001. His area of research is Distributed Systems, Networks and System Modelling.