Palma: A P2P based Architecture for Location Management

Palma: A P2P based Architecture for Location Management Kaouthar Sethom1, Hossam Afifi1, Guy Pujolle2

1

Institut Nationale de Télécommunications 9 Rue Charles Fourier 91011 Evry, France {firstname.lastname}@int-evry.fr Tel: +33160764416

2

LIP6 , University of Paris6 Rue du Capitaine Scott Paris, France [email protected]

Abstract To realize the potential of ubiquitous mobile computing, keeping track of mobile application users becomes more important. In wireless mobile networks, in order to effectively deliver a service to a mobile user, the location of a called mobile node must be determined within a certain time limit before the service is blocked. With the upcoming 3G, 4G and wireless LAN technologies, it’s necessary to have an efficient location management system that adapts to such dynamic environments. In this paper, we propose a highly scalable, self-organizing P2P based architecture for location management; namely PALMA. The performance of the proposed scheme was evaluated through a prototype implementation.

Keywords System design, location management, 4G, peer-to-peer.

Palma: A P2P based Architecture for Location Management Kaouthar Sethom1, Hossam Afifi1, Guy Pujolle2 1

Institut Nationale de Télécommunications Evry, France {firstname.lastname}@int-evry.fr

Abstract— To realize the potential of ubiquitous mobile computing, keeping track of mobile application users becomes more important. In wireless mobile networks, in order to effectively deliver a service to a mobile user, the location of a called mobile node must be determined within a certain time limit before the service is blocked. With the upcoming 3G, 4G and wireless LAN technologies, it’s necessary to have an efficient location management system that adapts to such dynamic environments. In this paper, we propose a highly scalable, selforganizing P2P based architecture for location management; namely PALMA. The performance of the proposed scheme was evaluated through a prototype implementation. Index Terms— System design, location management, 4G, peerto-peer. I. INTRODUCTION

The vision of a mobile Web in which the computing environment will be composed of various mobile devices that are carried by different users as they go through their daily routine is becoming a reality. To cope with these future environments, efficient location management architecture is needed. Location management procedures involve numerous operations in various databases. These databases record the relevant information of a mobile user, trace the user’s location by updating the relevant database entries, and map the node’s identification to its current location. Various location management schemes have been designed to lower costs and improve the efficiency of search and update times [1,2,3]. However, most existing schemes rely on fixed sets of location servers that are inflexible and immobile, and cannot readily exploit the user mobility characteristic. In many systems, the databases are centralized, causing more reliability problems. In this paper, we propose a distributed architecture for location management that we called PALMA. It relies on a P2P algorithm: Tapestry. The rest of this paper is organized as follows. Section II presents the peer to peer paradigm and briefly describes its main advantages. In Section III, we describe PALMA design. Finally, in section VI, we present some measurements from our PALMA prototype.

2

LIP6 , University of Paris6 Paris, France [email protected]

II. THE P2P PARADIGM

P2P algorithms are a class of distributed routing techniques known collectively as Distributed Hash Tables (DHTs) (e.g., [4, 5, 6,7], etc.). DHTs assign values (logical IDs) to machines on a network, and allow packets to be routed “by value” to whichever machine is currently responsible for that value. The goal is to network a very large, quickly changing set of machines, allowing requests for values (keys) to be correctly routed to a machine currently managing that value. This is to be done without any global knowledge – or permanent assignment – of the mapping of keys to machines. DHTs typically partition a logical key domain among the current set of machines. DHTs typically have the following design constraints: • Few Neighbors : Each node should only maintain a small number of active “neighbors”, remembering for each neighbor its physical (IP) address, and its logical “key” partition. A typical constraint for the number of neighbors is log n for a network of n machines. By keeping this number small, the arrival or departure of nodes from the network results in a bounded number of update messages (log n for many DHTs). • Low Latency: Each node should be reachable from any other in a small number of network routing hops; this requires that the neighbourhood graph have small diameter. Again, log n is a typical constraint. • Greedy Routing Decisions: Each node should be able to decide how to forward keyed messages without consulting any other nodes. These greedy decisions must find the “short” (log n) paths between any pair of nodes. • Robustness: As nodes and links come and go, the network should remain mostly connected, and able to route packets. A necessary condition for these features is a network with a nontrivial min-cut, to allow multiple alternate routes for packets.

III. PALMA ARCHITECTURE

We developed a new and original approach for location management in mobile environments based on the Tapestry

algorithm, that we called PALMA (Peer to peer Architecture for Location MAnagement). It provides a performant tracking mechanism for mobile nodes (MNs), while adapting to the dynamic nature of wireless networks and applications. PALMA distributes location information for a mobile node, preserving locality such that CNs can reach nearby MN quickly. In PALMA [8], there is no notion of home network and visited network. In this section, we present in more details the design and the basic functions of the PALMA architecture. Note that PALMA just focuses on how to locate MNs for new communications (something like HLR and VLR in the GSM) and is not designed to solve mobility related problem for ongoing communications as in Mobile IP [1].

A. Name description Being able to contact objects, whether they are mobile or not, is traditionally supported by a naming service which maintains a binding between an object’s name and the address where the object can be contacted. A common example of such system is the DNS, ENUM [9]... This means that naming and location are closely correlated aspects, as the name of an object is the starting point in locating it. The DNS for example is mostly used to translate between domain names and IP addresses. The first problem is that of generating globally unique names (e.g., global process identifiers). In fact, today the presence of different numbering or naming schemes is a major barrier to make the system converge. In fact, mobile nodes can be telephones, Personal computers, PDAs ... and have thus different identificators: numbers (+31 20 44 47 784), characters ([email protected]), URL (ftp://dept.univ.tn/chap1)... Given the variety of applications requiring access to this shared infrastructure, what is needed is a location service that places no constraints on the structure of the object’s name to use in the search process i.e. a flexible naming. Furthermore, it is required that names are location transparent (i.e., they do not reveal physical location of the named object) and even location independent (i.e., the object can migrate without changing its name). In fact, to make name resolution efficient for wide-area systems, names often contain location information. For example, the URL http://www.intevry.fr/~toto reflects where the page is stored (int-evry.fr), allowing part of the name resolution process to take place at that location. However, using location information in names can make it difficult to handle mobility. If an object moves, we may have to change its name. What is needed is a naming facility that hides all aspects of an object’s location. Based on these requirements, we propose an architecture where the lookup procedure is independent from object’s locations and name semantic properties. The name of reference we adopted concatenates three categories of information, like below: service.device.owner. The service attribute may include the name or the type of the requested

service such as telephony or chat. The device attribute includes its manufacturer name and or its marketing name example mobile phone or laptop. Finally, the owner attribute has the value of a universally unique number example +31 20 44 47 784 or [email protected]. The proposed name scheme is expressive enough to handle a wide variety of services, resources and devices. The three categories of information used to define a name cover all the aspects that are of interest for a client and for the network management. The uniqueness of the name is provided by the presence of the owner’s universally unique number. Human-oriented names are usually variable-length strings, often with structure; thus they are easy to remember for humans, but expensive to process by machines. Thus we need system-oriented names. System names are usually fixed size numerals; thus they are easy to store, compare, and manipulate, but difficult to remember for the user. Using a hash function such as SHA-1, we generate new objects IDs in the form of random m-bit sequences from the mobile node name reference (figure 1). At this point, the location service uses this new m-bit identifier to locate the correspondent mobile node. The identifier length m must be large enough to make the probability of two nodes hashing to the same identifier negligible. As an example consider: 0x00245 = h( skype.pda. [email protected])

Name of reference Hash function h Logical ID : m-bits

Tapestry Routing & Location Current IP address

Figure 1: Naming vs. Addressing of MN

B. Basic components PALMA architecture is composed of a number of heterogeneous wireless and wired networks (hereafter referred to as “clusters”) connected via a high speed wired backbone network and extended with a number of distributed location servers (LSs) (figure 2). These LSs are organised into an overlay network to publish location information to each other for storage, and to collaboratively resolve CNs queries. Any device or computer in the network can potentially act as an LS, and a network of cooperating location servers provides a system-wide resource location service.

LS maintains a routing table consisting of the IDs and IP addresses of the LSs with which it communicates. We refer to this table as neighbours’ map of the local node. In order to establish itself as a communication endpoint, a MN must publish its location information. A request for insertion of unregistered MN begin at the first contacted LS and is propagated up to the MN root LS. As an illustration, consider the example in Figure 4, when the MN (M) first powers up in the network, it discovers the IP address of a nearby LS ( D ). This information can be given by the DHCP server among the rest of IP parameters (new IP address, default router, DNS server, nearby LS ...). The MN sends then a registration message to D, containing its reference name N = service.device.owner.

Figure 2: PALMA architecture

LSs form a virtual backbone that is dynamically distributed among the network nodes. They maintain interconnections among themselves using Tapestry [7] node insertion and neighbour notification algorithm. In this new virtual space, each LS is assigned a new identifier new_id that is generated from its IP address using a hash function h (SHA-1 [??]) (figure 3). Devices communicate with LSs to advertise their presence or submit queries. When a CN issues a query to an LS, it receives the response from that LS.

The LS knowing the secure hash function h, it computes the logical identifier for the MN IDMN = h(N). At this point, D can determine, using the Tapestry algorithm, MN’s root nodes. It then publishes that it has the object X (the binding between the name reference and the IP address of the MN) by routing the message toward the MN’s root nodes. Pointers to D are stored at each intermediate LS along the way. Finally, a copy of X is stored at MN root nodes.

X Root Node Publishing X Lookup for X

F C

Location routing plane

4588 9F64

new-ids 1456

Intermediate LSs

662E

2348 71BE

Hash function h

W D 192.30.44.8

IP routing plane

192.160.1.12

CN

MN

Figure 4: Lookup for a MN in PALMA 122.48.90.33

157.159.11.9

187.43.16.7

Figure 3: PALMA architecture

C. Search for a mobile node PALMA dynamically maps each mobile node K to unique live LS called the MN’s root. This is the closest LS to K in terms of IDs similarity. The root LS of a MN serves the important role of providing a guaranteed node where the location mapping for that MN can be found. To deliver messages, each

When looking up for MN current location, the CN sends a search request to its domain LS (W). W can be discovered as mentioned earlier using DHCP initial setup information. If the MN is in the same domain as the CN this means that W has the response in its cache. Else, W computes the MN’s ID using the hash function h and sends then a search query using PALMA infrastructure. As shown in Figure 4, a search path is established starting at W and going upward to the first LS where the MN is already known. The query is then immediately redirected to the nearest copy of X (i.e. D). In the

worst case, this means propagating the request up to MN one root node. PALMA registration process guarantees that the location information is always present at an LS which is close to the MN (this can serve queries from CNs that are in the same domain as the MN) and at multiple MN root nodes (for distant CNs). As Tapestry routing algorithm classify routes to neighbours by physical latency priorities, PALMA preserves locality such that CNs can reach nearby MNs quickly. Another fundamental propriety in PALMA design is that the location information is associated with soft state leases i.e. refreshed periodically ( Tr ). When an object X becomes inaccessible -either by deletion, server failure or MN movement- location information cached on intermediate LSs will time out.

D. Update process As a MN moves it may cross the boundary of a cell, and enter area covered by a different Base Station. This process, called handoff, may involve updating of the stored location information of the MN. Once, the MN has moved, it receives a new IP address and finds a new close LS (L) (by querying the new DHCP server). It then sends an update query to L, specifying its last LS (D). Server D after being contacted by L, establish a forwarding pointer to L for X, and forwards requests to L for the duration of the refresh time Tr. Figure 5 illustrate this mechanism.

X Root Node Old pointer path New pointer path

F

C

Intermediate LS

Pointer from D to L

D

L MN Figure 5: Location update in PALMA

Server L issues an update message to MN root nodes (e.g. R). The update message may reach intermediate LS where it intersects the old published path from D to R (node C in our example). It updates caches of all intermediate LSs from C to R ( F ). The rest of the old path will timeout and caches will be deleted.

IV. PALMA PROTOTYPE We developed a PALMA prototype software written in C++ and using an event-driven programming model. Nodes use UDP to communicate with each other. Our implementation is running under Linux and contains the following stand-alone modules:

A. PALMA Server This module is used for running location servers (LSs). In the following, we consider a number of issues that have to be addressed in the implementation of PALMA servers. First, a starting point for location resolution has to be fixed. This essentially means that the server agent in each LS must have at least one name server that it can contact at startup. When a server joins the PALMA network, it must contact a wellknown or bootstrap node. Any server, once running, can serve as a bootstrap node. However, the first server run as part of the network must bootstrap itself. We can run multiple virtual PALMA servers on a single physical machine, where each server is identified by a different port number. The location server agent is implemented as a library linked to the client program. It accepts inter-node messages and handles object publish/location and message routing. PALMA servers determine their new Unique IDentifier by applying a SHA-1 hash to their IP address. Each static server sends ping messages to all other servers, and uses the result to build its own routing table. After allowing some time (about 1 secs per PALMA server) for the underlying neighbor map to stabilize, servers will be up and running on the hosts we have chosen. The Server allows nodes to connect and request information. When a node connects to the server, a Connection object is created which stores basic information of the connecting node. Once the connection is established, the connected node, now a client of the server, can request information from the server node.

B. PALMA Client In general, a PALMA client performs one or more of the following operations apart from other network operations it performs: Sends lookup message for MNs, sends and periodically refreshes location information when it’s a MN. Since most of these operations are common across all PALMA clients, we provide a client API, the methods of which perform these operations. At a high level, the client API opens and manages the socket required by the client for sending and receiving the packets. A typical PALMA client that uses the client API contains the following pieces of code: client initialization, location information operations (insertion, update, etc), client shutdown… The ClientAdministrator object was created to encapsulate all the network client connections in one place so all the applications can use them, but not manipulate them, through collection of methods.

The configuration file for the client is in XML format and contains the list of PALMA servers to contact. It’s also possible to enable the option closest server to let the code automatically choose the closest PALMA server. C. Measurements The main problem of designing a test network for our implementation is the limited number of PCs in a laboratory, while trying to show the end-to-end delay of PALMA architecture in large backbone networks. We could bypass this by running more then one LS in each machine. However, the maximum number of LSs that we could run simultaneously was 40. All tests were performed under Red Hat Linux 9.1 stations with kernel 2.4.22. We used Tcpdump [11] to sniff network packets and make some statistical analysis out of those dumps. In each test, we inserted one binding for a MN in the PALMA architecture and then we fetched it multiple times. Each lookup began at a random client node in the network. Figure 6, shows the lookup and update delays for different scenarios (local, inter-subnets and inter-domains cases). Interdomain tests were run between nodes belonging to the National Institute of Telecommunication (INT, Evry) and the Higher National School of Telecommunication (ENST, Paris). From them, it can be seen that the lookup and update delays are very sensitive to the network topology, since they increase with the network distances. But the main conclusion is that these delays never exceed 110ms which is a satisfying result.

Update delay

lookup delay

120

delay (ms)

100 80 60 40 20 0 Local 1

inter-subnet 2

inter-domain 3

Figure 6: PALMA implementation performance

V. CONCLUSION

Recent advances in communication technology have created the opportunity for mobile terminals to receive many services that were, until not long ago, only available to static terminals. One of the challenging tasks in such environment is to efficiently maintain the location of the mobile users. In this paper, we have presented PALMA; a new P2P architecture for location management. Our prototype performance results are promising. Future works will focus on some security issues on PALMA such as authentication and authorization.

REFERENCES

[1] C. Perkins, “IP Mobility Support”, RFC 2002, Internet Engineering Task Force, October 1996. [2]Y. Rekhter, S.Thomson, Paul Vixie, “Dynamic Updates in the Domain Name System (DNS UPDATE)”, RFC 2136. [3]A.Pappas, S.Hailes, R.Giaffreda, “Mobile Host Location Tracking through DNS”, London Communication Symposium, September 2002. [4]S .Ratnasmy,P. Franciq, Y M.Handley, R.Karp, and I.Shenker, “A scalable content-addressable network”. ACM SIGCOMM, August 2001. [5]I.Stoica , R.Morris, D.Karger, M.Kaashoek, and H. Balakrishnan, “Chord: A scalable peer-to-peer lookup service for Internet applications”. ACM SIGCOMM August 2001. [6] A.Rowstron, P. Druschel, “Pastry: Scalable, distributed object location and routing for large-s cale peer-to-peer systems”. 18th IFIP/ACM International Conference on Distributed Systems Platforms (Middleware 2001). [7]Ben Y. Zhao, L.Huang, J. Stribling, S C. Rhea, A D. Joseph, and J. Kubiatowicz “Tapestry: A Resilient Global-scale Overlay for Service Deployment”, IEEE Journal on Selected Areas in Communications 2004. [8] K. Sethom, H. Afifi, Guy Pujolle, "A Distributed Architecture for Location Management in Next Generation Networks", IEEE Wirelesscom 2005 [9]S. Hollenbeck, “E.164 Number Mapping for the Extensible Provisioning Protocol”, draft-ietf-enum-epp-e164-03.txt 2004. [10] Secure Hash Algorithm (SHA-1) Encryption Standard, http://www.vocal.com/SHA-1.pdf [11]Tcpdump, http://hpux.cae.wisc.edu/