1 Applied Research Area, Telcordia Technologies, Inc., Piscataway, New Jersey, USA. 2 ECE Dept. & ISR, University of Maryland, College Park, Maryland, USA.
(Proc. IEEE Int. Symp. Comput. Commun. (ISCC), Alexandria, Egypt, 2004)
Dynamic Survivable Resource Pooling in Mobile Ad-Hoc Networks ∗† ¨ Mariusz A. Fecko1 , Ulas¸ C. Kozat2‡, Sunil Samtani1 , M. Umit Uyar3 , Ibrahim H¨okelek3 1
Applied Research Area, Telcordia Technologies, Inc., Piscataway, New Jersey, USA 2 ECE Dept. & ISR, University of Maryland, College Park, Maryland, USA 3 Electrical Engineering Dept., CCNY, The City University of New York, New York, USA Abstract
Unfortunately, the existing RSP architectures [12, 13, 14] are unsuitable for ad-hoc networks because the global synchronization of pool registrations is prohibitively inefficient when the domains split, merge, or partition. We thus propose to implement the RSP in MANETs (RFC2501) by utilizing the concept of virtual backbone (VB) [7]: a highly distributed, scalable, and survivable network formed and maintained through one-hop beacons. VB is formed by Distributed Service Discovery Protocol (DSDP) [5, 6] that creates a mesh structure consisting of stable nodes that act as lightweight directory servers. DSDP also creates a subset of paths (also called virtual links) connecting VB nodes; and distributes service registrations, requests, and replies. In this paper, we adapt VB for providing a dynamic and survivable naming scheme to the pool users, called Dynamic Survivable Resource Pooling (DSRP). The concept of pools is extended to resources that include servers, services, and hardware entities with specific capabilities (e.g., sensors used in robotics and battlefield applications). The NSs are dynamically placed on a VB to create a dominating set [7]—each node in the network is at most one hop away from a member—and thus provide a fast name-resolution for a resource request. The DSRP • is able to reorganize itself in response to mobility, failures, and partitioning; • offers fast response time via a local name resolution; • provides load balancing of resources via NSs or users; • scales well with the network size; • is simple enough to be deployed on resource-constrained nodes; and • enables distributed resource selection modeled as policybased resource allocation. While the DSRP is applicable to any resources that can be pooled together, in the rest of this paper, we will focus on pooling servers and services as a particular type of resource. The NSs can serve as distributed configuration/network managers that pool various servers for higher availability and failover: FCS [8] backbone managers, Bandwidth Brokers [2], Situation Awareness (SA), Common Network Picture (CNP), SIP [9], and others.
The existing naming schemes for pooling resources are suitable only for static networks. We propose Dynamic Survivable Resource Pooling (DSRP) that provides a survivable naming scheme to the pool users in mobile ad-hoc networks. DSRP dynamically places the Name Servers (NSs) on a virtual backbone (VB): a highly distributed, scalable, and survivable mesh network formed and maintained through onehop beacons. In this paper, DSRP focuses on pooling resources such as servers and services that are common in robotics and battlefield applications. It provides an abstraction of all the functionally equivalent servers, whereby the client can access these servers as a single entity, termed server pool. A distributed backbone mesh of NSs is used to propagate service registrations, requests, and replies.
1. Introduction The reliable server pooling (RSP) [12, 13, 14] is one of the frameworks [4, 3, 10, 15] that address the reliability of services by introducing redundancy in the number of servers available to a client. It also provides an abstraction of all the functionally equivalent servers, whereby the client can access these servers as a single entity, termed server pool. In the RSP, the Name Servers (NSs) are responsible for maintaining server pools, load balancing, and server discovery. The client resolves the mapping from a server-pool handle to the addresses of servers registered in this pool by querying its Primary Name Server (PNS). Under this scheme, whenever a server fails, clients that utilize that server should transparently switch over to another server in the pool, possibly migrating the session to the new server [1, 11]. ∗ Prepared through collaborative participation in the Communications & Networks Consortium sponsored by the U.S. Army Research Lab under the Collaborative Technol. Alliance Program, Cooperative Agreement DAAD19-01-2-0011. The U.S. Government is authorized to reproduce and distribute reprints for Government purposes notwithstanding any copyright notation thereon. † Copyright c 2004 Telcordia Technologies, Inc., City University of New York, and University of Maryland. All rights reserved.
1
peer discovery associate, request, PE failure
2. Motivation and Overview We first outline our earlier research efforts [13, 14] in the service reliability for ad-hoc networks, which focused on the IETF RSerPool [13, 14]. We then show how the obtained results can be combined with the work of Kozat and Tassiulas [5, 6] on the DSDP.
2.1
Name Servers (NSs)
advertise
associate, register, I am alive Pool 1: PE11, PE12, …
RSP overview and scope
The RSP, whose basic architecture is shown in Fig. 1, mainly refers to the services that are survivable transparent to client applications. A server pool, which is identified by a unique identifier (also called a pool handle) [12], is a collection of server locations (i.e., ), where clients can access a given service. Clients (also called Pool Users (PUs)) access the service by providing only the corresponding pool handle. The RSP layer resides between the application and the transport layer. Therefore, PU’s payload packets are first processed by the RSP layer, which maps the logical pool handle to the actual server (also called Pool Element (PE)) location. Upon detection of a PE failure or QoS degradation, RSP layer can change the current end-point in the middle of an already-established session between the PU and the PE. Hence, a PU fails over to a new PE for a persistent connection. Although an issue of session migration is clearly among the major components of establishing a transparent failover, it has been studied elsewhere [1, 11], and is beyond the scope of our immediate interests. Instead, we focus on the following questions: How can we discover and maintain the available server pools in a highly dynamic network environment such as the FCS Unit of Action (UA)? Is a directory system, in which name servers/directory agents collect and maintain the server-pool information, preferred to a directory-less system or vice versa? To what extent a global view of the available network services is required in a directory system? In other words, do the name servers need to synchronize a common view of the namespace? How are PE failures or QoS degradations detected to effect switchover of the service to an alternate PE? Should applications be involved in the decision process? To what extent should the RSP layer be responsible for monitoring PEs, and what kind of feedback is needed from the PUs, PEs, and other layers (e.g., MAC or transport layer)? What kind of services can benefit from the RSP? What are their QoS parameters? How can we perform the PE allocations when we have a global view as well as when we have a local view of the available server pools? The existing RSP solutions such as IETF’s RSerPool are too rigid to perform satisfactorily under the highly varying network topologies [14]. The RSerPool relies on statically assigned NSs and global synchronization among them (Fig. 1). In other words, once certain nodes are assigned to
Pool Users (PUs)
Pool N: PEN1, PEN2, …
Figure 1. Basic architecture of the RSP. be NSs, they stay as such even though the network conditions change dynamically. NSs go through a peer-discovery phase at the start-up. They also advertise themselves to the PUs and PEs. Additionally, a PE/PU may follow a serverhunt process to locate its PNS. All of these discovery and synchronization efforts require multicasting support, which can incur significant load in the network. In addition to the prohibitive overhead, the RSerPool has no provisioning against network partitioning, which may be a common event in MANETs. Some partitions may be left without any name server; as a result, survivability of the entire RSP architecture becomes questionable.
2.2
VB overview and scope
Kozat and Tassiulas [5] demonstrate the feasibility of a directory/name-server system on VBs with respect to the signaling overhead. They also show the performance advantages over the peer-to-peer systems, where clients directly discover the end servers by utilizing multicast or anycast routing. We thus use the DSDP [5] to create a VB as a minimum connected dominating set of lightweight NSs. There are two parts in the VB-based service discovery [5, 6]: Backbone Management (BBM) and Distributed Service Discovery (DSD). 2.2.1
Backbone Management
The BBM groups nodes into decided and undecided (the latter also called white nodes), where decided nodes are further divided into backbone (also called black) and non-backbone (also called green) nodes. The selection and maintenance phases guarantee that the set of backbone nodes is a dominating set. All these operations are accomplished by exchanging 1-hop lightweight hello beacons (∼50 bytes). The result of this phase is a mesh structure of backbone nodes. The maintenance phase reorganizes a VB in response to topology changes due to the node mobility or failures. If a green node looses its PNS, it chooses another neighbor as its new PNS by giving strict priority to VB nodes and then to 2
other nodes satisfying the stability and highest-degree criteria. If a black node is deserted by its green nodes, this VB node must become a green node, and it is treated as if it had lost its PNS. If a black node has a neighbor that is also a black node, it sends a hello beacon to its green nodes indicating that it will change from black to green. All green nodes that receive this message determine the best VB neighbor to assign as their PNS. 2.2.2
PUs, PEs, and NSs have active BBMs and BSMs processes, only the VB nodes assume the functionality of NSs.)
3.1
BBM operations in DSRP
Let us represent the snapshot of a network at time t as a topology graph G(V, E), where the sets of vertices V and edges E correspond to network nodes and symmetric links, respectively. Graph G can be represented as the union of two mutually exclusive subgraphs: Gd (Vd , Ed ) and its complement Gdc (Vdc , Edc )1 , where Gd consists of all decided nodes and edges incident on them. Similarly, G c c c can be expressed as Gnlff (Vnlff , Enlff ) ∪ Gnlff (Vnlff , Enlff ), where Vnlff contains vertices with normalized link failure frequency (nlff) lower than a given threshold. For each k ∈ V , let N (k) and deg(k) be the set of k’s neighbors and the degree of k in G, respectively. c Backbone-node selection: Each k ∈ V d asynchronously and periodically checks the following conditions: Condition 1 k ∈ Vnlff ∧ (∀j ∈ Vdc deg(j) ≤ deg(k)). Condition 2 k 6∈ Vnlff ∧ N (k) ∩ Vnlff = ∅ ∧ (∀j ∈ Vdc deg(j) ≤ deg(k)). If vertex k satisfies Conditions 1 or 2, it joins the backbone. Undecided nodes become decided non-backbone (i.e., green) nodes when they detect a black neighbor, and label that neighbor as their PNS. Mesh formation: BBM also instruments the mesh formation by informing each VB node about the identities of other VB nodes within its 3-hop neighborhood. This mesh enables dissemination of control messages among the VB neighbors by forming distribution trees. Maintenance: While undecided nodes of the network run the selection phase, the decided portion runs the maintenance phase, which locally adapts VB upon the following events: (1) some VB node is not PNS of any node; (2) some green node lost its PNS; and (3) VB nodes are overly redundant (i.e., there are too many of them) in certain areas.
Distributed Service Discovery
The DSD distributes service registrations, requests, and replies. Once the VB is formed, a server has to register with its PNS. If it wants to register with more NSs, then multicast is used to distribute the registration messages. Similarly, a client requests a service by contacting its PNS. If the PNS does not have the service registration, then the service is requested from other NSs by multicasting. Every VB node keeps a forwarding list among its VB neighbors for each multicast tree. When a node receives a multicast message, it finds the next black node using its VB-routing table, and forwards this message to each node in the forwarding list. This way, a multicast tree from any VB node to any other VB node in the network is formed.
3. RSP over Virtual Backbone The DSDP operates efficiently with individual NSs having only partial knowledge of pool registrations; hence, there is no need for costly namespace-synchronization among NSs. However, it does not fully meet the RSP requirements (RFC3237) because it does not • support the discovery of more than one PE; • support switch-over functionality (a PU must issue a query and, upon receiving a response, must re-establish a connection with the new PE by itself); • clarify the interactions or primitives between the application and the DSDP layer; and • establish reliable communications for PE registrations. To meet the RSP requirements, we extended the DSDP into the DSRP architecture. We defined two entities that share RSP functionalities: (1) BackBone Manager (BBM) and (2) Backbone Service Manager (BSM). BBM is mainly responsible for the formation and maintenance of the virtual backbone. It also provides the signaling support among the backbone nodes to disseminate the server-pool QUERY and REGISTRATION messages. On the other hand, BSM handles the actual communication between the PEs/PUs and the RSP layer. BSM utilizes the BBM services to register PEs and to resolve the queries (Fig.2(a)). The propagation of control messages is determined by the close interaction between the BSM and BBM. Any pool allocation to individual PUs is decided by the BSM. (Note that, although all the
3.2
BSM operations in DSRP
The DSRP proactively constructs and maintains the server pools through PE registrations, while reactively resolving the pool requests. PE communicates with its BSM sublayer, indicating the lease duration and the scope of the registration. Regardless of the scope, which determines the depth of the registration along the virtual backbone, BSM sublayer reliably registers the service with BSM sublayer on the PNS side (Fig. 2(a)). At PNS, PE is added into the requested pool. If the scope of the registration is set to a value greater than one, registration is propagated unreliably to the next tier of NSs within three physical hops. The propagation is continued until the number of traversed tiers (i.e., 1 Complement of subgraph A over graph G is the subgraph with vertex and edge sets are obtained by removing vertices and edges of A from G.
3
PE BSM
REGISTER (1)
BBM
PNS BSM Request (1)
BBM ACK (3)
Reply (11)
REGISTER (2)
PE BBM
{PE1;PE2} NOTIFY (1)
BBM
PNS BSM
Query (2) Ucast (Reply) (10)
BBM
Mcast (Query) (3)
BBM
Mcast (Query) (4)
(a) PE registers with its RSP layer. Registrations are soft state.
BSM
PU BSM
Mcast (Query) (3)
Ucast (Reply) (9) BBM
PNS BSM
Reply (7)
BBM
Ucast (Reply) (7)
BSM
BBM NS Ucast (Reply) (8)
Mcast (Query) (4)
ACK (3) REGISTER (2)
Query (5)
BBM Mcast (Query) (5)
BSM { PE1;PE2}
(b) BBM notifies BSM of PNS hand-off for renewing pool registrations.
Query (6)
Figure 2. Pool registration events.
BBM NS
Figure 3. Sequence of events in a pool query. virtual links) reaches the requested registration scope. Unless the PE extends the lease by sending another registration, it will be removed from the server pool upon the lease expiry. When a PE/PU hands off to a new PNS, the BBM sublayer first notifies the BSM sublayer of this event. Second, the BSM reliably registers all the unexpired PE entries with the new PNS transparent to the local PE. Regardless of the original scope, the PE registration due to PNS handoff is scoped to be 1-hop, i.e., only the new PNS will receive the registration (Fig. 2(b)). Fig. 3 illustrates how the pool request from a PU is resolved. The PU’s BSM sublayer sends a direct QUERY message to the PNS’s BSM. If PNS does not have any PEs registered for the requested pool, it encapsulates the message and sends it toward other NSs that it is aware of. If there is no routing support, each message is transmitted through the IP broadcast to the well-known port address of the BBM (note that all BBMs share the same port number). Encapsulation is required to specify the address of the destination NS and the relay node. Hence, the BBM performs its own routing in the application layer on a hop-by-hop basis. In the case where the BBM works in coordination with the routing layer, instead of encapsulation and application layer routing, network layer routing can be exploited to find routes toward the destination NSs. To further increase efficiency, the BBM forms a multicast tree while QUERY is propagated between NSs. When any NS can resolve the query, the NS’s BSM creates a reply message. Again, assuming no routing layer support, this reply can be encapsulated and relayed hop-by-hop by the BBM layer. Otherwise, REPLY can be sent directly to the BSM on the PU side using UDP sockets and BSM address of PU. Both options are shown in Fig. 3 as Ucast (REPLY) and REPLY labels.
3.3
ity against the failures of pooled servers and NSs, as well as network partitioning events. Consider a five-node network topology in Fig. 4(a). The VB nodes are selected as node 2 and node 5; therefore, they are assigned as NSs. NS2 becomes the PNS for the user on node 3 (PU3); NS5 becomes the PNS for the servers on nodes 5 (PE5) and 4 (PE4), and for the user on node 1 (PU1). Both PE4 and PE5 register for a server pool A shown in Fig. 4(a). When PU3 issues a pool request to its PNS (NS2) with the minimum number of requested PEs equal to 1, NS2 replies back to PU3 with the server PE5 located on node 5. The communications between PU3 and PE5 is now established, and the data transfer starts. If PE5 fails without completing the data transfer to PU3, PU3 must contact its PNS again to request a new PE. Since NS2 does not have any other entries for pool A, it forwards the request to NS5 along the multicast tree, receives the information about PE4, and relays it to PU3. Thus, persistent communications is provided in case of a server failure. In Fig. 4(b), network partitions into two sets: nodes 2, 4, and 5; and nodes 1 and 3. Each set contains one NS that becomes the PNS for all nodes in the set: NS2 and NS1, respectively. In this figure, PE4 starts on node 4, and PU5 starts downloading from PE4. All nodes are subject to mobility in MANETs; therefore, PE4 moves out of this set after a certain time and is no longer available to PU5. When the two partitions merge, the VBs also merge to create one virtual backbone. If PU5 survives the service disruption until the partitions merge, it discovers PE3 through the new VB, and then resumes downloading from PE3. Thus, persistent communications is provided in case of both high mobility and network partitioning.
Example of DSRP operations
We created a proof-of-concept implementation of the DSRP on Linux boxes, which demonstrates its survivabil4
PU3
Pool List Pool A: PE5
2
less than that requested by the PU. Starting from the PUside RSP, at each intermediate node, a list of PEs that are already discovered are attached to the marked PEs in the QUERY message. NSs try to resolve the QUERY among the registered PEs that are not already in that list. Each newly marked PE reduces the number of PEs to be discovered. PU-side RSP uses a timeout period for each QUERY and reissues the QUERY unless REPLY for that QUERY is received from PNS before timer expires. To influence PE selection, PUs are allowed to raise the CHANGE END POINT flag in the RSP header that is placed in front of each payload data. In other words, a client can proactively indicate to its RSP layer that QoS degradation occurred or the current PE failed, and thus request a new PE from the pool. The PU-side RSP layer marks the PEs for each PU according to their utilization patterns and then ranks them. When it receives CHANGE END POINT primitive, PU-side RSP layer selects an unmarked PE and migrates the session to this new PE by providing the PU’s state information. If all the PEs are marked, PU-side RSP layer saves the PU state information, and starts a new QUERY by attaching all the marked PEs to the control message. Upon receiving a REPLY , PU state information is delivered to the new PE. PE registers with its RSP layer, which in turn reliably registers the PE with PNS to the requested server pools. During registration, PE defines a TTL field that determines the number of NSs that a registration message can traverse. Only the registration with the PNS is reliable—the registrations scoped further than PNS are performed unreliably. PE-side RSP layer is responsible for re-registrations in case PE hands over to a new PNS. All registrations are stamped with a life-time; they are thus soft entries, which can be refreshed only by the PE itself.
PNS = NS2
3
Pool A NS2 PE4 PNS = NS5
4
1 PNS = NS5
PU1
PNS = NS5 NS5 PE5
Pool List Pool A: PE5 PE4
5
(a) Formation of VB and pool registrations. Pool List
Pool List
Pool A: PE4
Pool A: PE3
PU5
NS2
NS1
5
2
1
3
PNS = NS2
PNS = NS2
PNS = NS1
PNS = NS1
PE4
4
PNS = NS2
PE3
Pool A
(b) Resilience to mobility and partitioning.
Figure 4. RSP based on virtual backbone.
4. Design and Implementation This section gives more details about the augmentations necessary for the DSDP [5, 6] to support the DSRP. It also shows how the overhead of the hello beacons can be eliminated by utilizing a proactive link-state routing protocol.
4.1
Design specifics
4.2
During the VB maintenance, when a node loses its PNS and has no other VB node in its neighborhood, it joins the backbone provided that it is the best node in its neighborhood. In the original DSDP, such a node instead forces the next best node, excluding itself, to join the backbone. PUs are allowed to determine the number of PEs they require in order to indicate the degree of the session survivability as well as the willingness of the PUs to access the services in remote locations. A PU can specify both the number of requested PEs and a list of undesired PEs. All pool queries are triggered by the PU application by sending REQUEST primitive to the PU-side RSP layer. The PU-side RSP layer starts a fresh QUERY toward its PNS after receiving the REQUEST primitive from the PU, where QUERY carries a list of marked PEs. If PNS has at least one PE that is not in this list, it immediately sends back REPLY message. Different from the DSDP proposal, PNS continues the query if the number of resolved PEs is
Integration of VB with link-state routing
To eliminate the signaling overhead of the VB formation and maintenance, one can utilize the signaling of proactive routing protocols. Consider an ad hoc routing protocol such as OLSR (RFC3626). An OLSR hello-beacon has a period of two seconds, and carries the following information: • node willingness to relay broadcast messages; • 1-hop neighborhood information (e.g. IP addresses) of the transmitting node; • link code: 8 bits total, but only the least significant 4 bits are defined to specify (1) neighbor-link type (symmetric, asymmetric, lost, or unknown); and (2) neighbor type (symmetric, relay-node, or not-a-neighbor). From the contents of OLSR beacons, we can infer the following information required by the BBM: (1) degree, (2) the number of a neighbor’s link losses, and (3) relay willingness. The BBM needs the following additional data: • effective degree (the number of undecided neighbors); 5
• neighbor’s color; • neighbor’s PNS; • other backbone nodes in the 3-hop neighborhood. The first three entries can be included in the OLSR hellobeacon headers by extending the semantics of a neighbor type. In addition to the symmetric, relay-node, and not-aneighbor type, we can introduce a new type as PNS. This new type allows us to identify the interfaces that belong to the PNS (if any). To declare the color of the transmitting node, we can use 2-bits of the most significant four bits of the first link code in the hello-beacon header, which is not used in the existing OLSR implementations. At this stage, the only missing piece of information is the list of NSs in an NS’s 3-hop neighborhood. One possibility is to modify the backbone-formation algorithm by letting each NS advertise itself via an IP packet (with TTL set to 3 hops). OLSR can then effectively limit the overhead of such local flooding. This approach avoids substantial modifications to OLSR. Another option is to utilize the information gathered by green nodes. When such a node discovers in its 2-hop neighborhood an NS node that is different from its PNS, it can send a unicast message directly to its PNS (instead of a beacon). Since OLSR is link-state based, a failure of any path to virtual neighbors can be detected by checking the routing tables. Thus, unicast messages should only be created when a new NS is detected by a green node. To summarize, we can easily integrate OLSR with VB through modest modifications to OLSR that (1) exploit the link codes in the hello beacons and (2) make the OLSR hello-beacons visible to BBM. Most modifications have to be made in the BBM itself for the purpose of information collection and to support the associated signaling changes.
[2]
[3] [4]
[5]
[6]
[7]
[8]
[9] [10]
[11]
[12]
5. Conclusion
[13]
Dynamic Survivable Resource Pooling (DSRP) provides a survivable naming scheme to the pool users in mobile adhoc networks. It dynamically places the NSs on a virtual backbone (VB): a highly distributed, scalable, and survivable mesh network formed and maintained through one-hop beacons. The mesh is used to distribute service registrations, requests, and replies with controlled scope. Future work will investigate the benefits of this highly distributed, directory-based RSP architecture by creating an analytical model of the DSRP, and by designing algorithms for distributed resource selection through resource allocation. 2
[14]
[15]
References [1] L. Alvisi, T.C. Bressoud, A. El-Khashab, K. Marzullo, and D. Zagorodnov. Wrapping server-side TCP to mask connec2 The
views and conclusions contained in this document are those of the authors and should not be interpreted as representing the official policies, either expressed or implied, of the Army Research Lab or the U.S. Government.
6
tion failures. In Proc. IEEE INFOCOM, Anchorage, Alaska, 2001. T. Anjali, C. Scoglio, and G. Uhl. A new scheme for traffic estimation and resource allocation for bandwidth brokers. [Elsevier] Comput. Netw. 41, pp. 761–777, 2003. Cisco Systems, San Jose, CA. Distributed Director. (http://www.cisco.com). F. Hao, E.W. Zegura, and M.H. Ammar. Supporting server selection in differentiated service networks. In Proc. IEEE INFOCOM, Anchorage, Alaska, 2001. U.C. Kozat and L. Tassiulas. Network layer support for service discovery in mobile ad hoc networks. In Proc. IEEE INFOCOM, San Francisco, CA, 2003. U.C. Kozat and L. Tassiulas. Service discovery in mobile ad hoc networks: An overall perspective on architectural choices and network layer support issues. [Elsevier] Ad-Hoc Netw. 2(1), pp. 23–44, 2004. X.-Y. Li. Algorithmic, geometric and graphs issues in wireless networks. In Stojmenovic, ed, Algorithmic. . . Aspects of Wireless Networks and Mobile Computing (S.I.), [Wiley] Wirel. Commun. Mob. Comput. 3(2), pp. 119–140. 2003. P. Sass and J. Freebersyser. FCS communications: Technology for the objective force. In Proc. SPIE AeroSense, Orlando, FL, 2002. H. Schulzrinne and E. Wedlung. Application-layer mobility using SIP. ACM Mob. Comput. Commun. Rev. 1(5), 1999. S. Selvakumar and M.M. Brahmadesam. Secure dynamic anycasting for ‘best’ server selection using active networks. [Elsevier] Comput. Commun. 24, pp. 1819–1827, 2001. F. Sultan, K. Srinivasan, D. Iyer, and L. Iftode. Migratory TCP: Highly available Internet services using connection migration. In Proc. IEEE Int’l Conf. Distrib. Comput. Syst. (ICDCS), Vienna, Austria, 2002. M. Tuexen, Q. Xie, R. Stewart, M. Shore, L. Ong, J. Loughney, and M. Stillman. Architecture for reliable server pooling. Internet draft, IETF, 2001. [draft-ietf-rserpool-arch, work in progress]. M.U. Uyar, J. Zheng, M.A. Fecko, and S. Samtani. Reliable server pooling in highly mobile wireless networks. In Proc. IEEE Int’l Symp. Comput. Commun. (ISCC), pp. 627–632, Kemer-Antalya, Turkey, 2003. M.U. Uyar, J. Zheng, M.A. Fecko, S. Samtani, and P.T. Conrad. Evaluation of architectures for reliable server pooling in wired and wireless environments. In Li et al., eds, Recent Advances in Service Overlay Networks (S.I.), IEEE J. Select. Areas Commun. 22(1), pp. 164–175. 2004. E.W. Zegura, M.H. Ammar, Z. Fei, and S. Bhattacharjee. Application-layer anycasting: A server selection architecture and use in a replicated Web service. IEEE/ACM Trans. Netw. 8(4), pp. 455–466, 2000.
