Virtual Connections in P2P Overlays with DHT-Based Name to Address Resolution

of 15

Please download to get full document.

View again

All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
15 pages
0 downs
Virtual Connections in P2P Overlays with DHT-Based Name to Address Resolution
  Virtual Connections in P2P Overlays with DHT-Based Name to Address Resolution Telesphore Tiendrebeogo  LaBRI University of BordeauxTalence, France Email:  Daouda Ahmat  LaBRI University of BordeauxTalence, France Email:  Damien Magoni  LaBRI University of BordeauxTalence, France Email:  Oumarou Si´e  LTIC University of OuagadougouOuagadougou, Burkina Faso Email:   Abstract —Current Internet applications are still mainlybound to their transport layer connections. This preventsmany features such as end-to-end security and mobility fromfunctioning smoothly in a dynamic network. In this paper, wepropose a novel architecture for decoupling communicationfrom their supporting devices. This enforces the completeseparation of devices, applications and entities such as users,services and data. Our architecture is based on a peer-to-peer overlay network where each peer has a permanent nameand a variable address which depends on its position in theoverlay. In order to dynamically map names to addresses, ourarchitecture provides its own distributed hash table system.After presenting the design of our architecture, we provide ascalability analysis and by performing simulations, we assessits efficiency. Simulation results show that our overlay using aname to address resolution based on a distributed hash table isscalable and has acceptable performances given the flexibilityit can provide to applications.  Keywords -  overlay; virtual connection; distributed hash table; name resolution; I. I NTRODUCTION Current Internet communications are still based on theparadigms set by the TCP/IP protocol stack 30 years agoand they are lacking several key features. Although manyefforts have been done during the last decade to providemobility, security and multicasting, those efforts have mainlybeen focused on the equipment itself (e.g., computers, smart-phones, routers, etc.) rather than on the logical part of thecommunication. In fact, although we already have a lot of mobile equipment, it is still impossible to transfer a com-munication from one device to another without interruptingthe communication (and thus start it all over again). In thesame way, although we have the choice of many applicationsfor carrying one task, it is also still impossible to transfera communication from one application to another withoutinterrupting the communication. Layer 2 device mobility(e.g., WiFi, WiMAX, 3G and beyond) is nowadays wellsupported but users still have a very limited access to upperlayers mobility (e.g., MobileIP, TCP-Migrate).In this paper, we propose and describe a new architecturefor using virtual connections setup over dynamic peer-to-peer (P2P) overlay networks built on top of the TCP/IPprotocol stack of the participating devices. We have namedthis architecture CLOAK (Covering Layers Of AbstractKnowledge). This architecture supports names for entities(i.e., users, services, data) and devices, virtual addressesfor devices, and virtual sessions for managing all kindsof Internet communications. These new semantics broughtby our proposal open up many novel possibilities for suchcommunications. The virtual connections that are setup andmanaged by our solution, transparently handle the break-down and restore of transport layer connections (such asTCP or SCTP connections).This paper is an extended version of our previouswork [1]. We have added here a detailed description of the Distributed Hash Table (DHT) mechanism deployed inCLOAK, an analysis of the complexity of the DHT interms of distances, states and messages, as well as addi-tional simulation results including comparative ones to otherexisting DHT systems. CLOAK was srcinally presentedin our paper [2] which contained an extensive amount of background and related work as well as some preliminarysimulation results upon static networks concerning pathlength. Improving upon this foundation, our paper [1] pre-sented the protocols and modules of the architecture withgreater details and reported simulation results upon dynamicnetworks concerning routing success ratio, path length andstretch, as well as DHT requests performance indicators. Theaddressing and routing system based on hyperbolic geometrywhich is used by CLOAK was presented in our paper [3].Both the distributed addressing algorithm and the greedyrouting algorithm are detailed in this previous paper andwe have not included them here to avoid repetition. Theimplementation of the DHT scheme used by CLOAK overthis hyperbolic system is fully explained in Section IV.The remainder of this paper is organized as follows.Section II presents the design and features of our architec-ture. Section III describes the main elements of its possibleimplementation. Section IV presents the binding algorithmused by our DHT. Section V compares the algorithmiccomplexity of our proposal to those of various existing DHTsystems. Section VI presents various results obtained bysimulations for evaluating the routing and binding efficiencyof our system. Section VII outlines the related previouswork done on transport layer mobility, name and address 11 International Journal on Advances in Internet Technology, vol 5 no 1 & 2, year 2012,  2012, © Copyright by authors, Published under agreement with IARIA -  separation, as well as DHT schemes. We conclude the paperwith a summary of our contributions and present our futureresearch directions.II. A RCHITECTURE  A. Design In the context of our architecture, a  communication  isa set of interactions between several entities. It can beany form of simplex or duplex communication where in-formation is processed and exchanged between the entities(e.g., talk, view video, check bank account, send mail, etc.).An  interaction  is simply a given type of action carriedout between two or more entities by using an applicationprotocol (e.g., FTP, HTTP, etc.). An  entity  is typically ahuman user but it can also be an automated service suchas a server. A communication typically involves a minimumof two entities but it can involve many more in the case of multicast and broadcast communications. Finally, a deviceis a communication terminal equipment. On the device arerunning  applications  that are used by an entity to interactwith other entities. Given this context, the aim of ourarchitecture is to permit a communication to be carried outwithout any definitive unwanted interruption when some orall of its components (i.e., device, application or entity) areevolving (i.e., moving or changing) over space and time. Ourarchitecture ensures that a communication has a lifetime thatonly depends on the will of the currently implied entities.Changes in devices, applications and even entities (when itmakes sense) will not terminate the communication.Figure 1 shows the CLOAK communication paradigm.In order to untie entities, applications and devices, CLOAKintroduces the use of a  session . A session is a communica-tion descriptor that contains everything needed for linkingentities, applications and devices together in a flexible way.A session can be viewed as a container storing the identityand the management information of a given communication.Thus the lifetime of a communication between severalentities is equal to the lifetime of its corresponding session.As shown on Figure 1, a device can move or be changedfor another without terminating the session. Similarly, anapplication can be changed for another if deemed appropriateor even moved (i.e., mobile code) also without terminatingthe session. Finally, entities can move or change (i.e., betransferred to another entity) without terminating the sessionif this is appropriate for a given communication. We cansee that in our new architecture, entities, applications anddevices are loosely bound together (i.e., represented byyellow arrows in Figure 1) during a communication andall the movements and changes of devices, applicationsand entities are supported. Note that in Figure 1, onlyone instance of each part (device, application, entity) of acommunication is shown, other instances would obey thesame scheme. Figure 1. CLOAK communication paradigm. NETWORK LAYER( IP Protocol)OVERLAY LAYER(CLOAK) Figure 2. Overlay network.  B. Operation In order to provide all the above mentioned features, ourarchitecture sets up and maintains a P2P overlay network.Thus, routers are not part of the overlay. Only the devices(i.e., end-hosts or terminals) that wish to share resourcesin order to benefit from the architecture shall implementand run CLOAK. By doing so, they can join together toform an overlay. Figure 2 shows an overlay example withthe links shown in dotted red lines. The devices connectto the others by creating virtual links (upon transport layerconnections). Devices with two or more links play the roleof overlay routers. The overlay network can build up withoutany topological constraints, as network devices can connectarbitrarily to each others and join and leave the P2P network at any time.When joining the overlay, each device obtains a uniqueoverlay address from one of the peers already in the overlay.The method for addressing the peers and routing the packetsinside the overlay is based on the groundbreaking work of Kleinberg [4] that assigns addresses equal to coordinatesadequately taken from the hyperbolic plane (representedby the Poincar´e disk model). His method creates a greedyembedding upon a spanning tree of addresses (named ad- 12 International Journal on Advances in Internet Technology, vol 5 no 1 & 2, year 2012,  2012, © Copyright by authors, Published under agreement with IARIA -  dressing tree). This addressing tree is a regular tree of degree k . However in Kleinberg’s method, the construction of theembedding requires a full knowledge of the graph topologyand this topology must also be static. This is required as thedegree  k  of the addressing tree is set to the highest degreefound in the network. In our previous work [3], we haveenhanced his method in order to manage a dynamic topologywhich is able to grow and shrink over time. Because wesetup an overlay network, we are able to set the degree  k of the addressing tree to an arbitrary value and as such, weare able to avoid the discovery of the highest degree node.This specificity renders our method scalable because unlikeKleinberg’s method [4], we do not have to make a two-pass algorithm over the whole network to find its highestdegree. The fixed degree that we choose determines howmany addresses each peer will be able to give. The degreeof the addressing tree is therefore set at the creation of theoverlay for all its lifetime. In the overlay however, a peer canconnect to any other peer at any time in order to obtain anaddress thus setting the degree does not prevent the overlayto grow. These hyperbolic addresses are appropriately givento the peers so that a greedy routing based on the hyperbolicdistance metric is guaranteed to work when the network isconnected. Thus, only the addresses of the neighbors of apeer are needed to forward a message to its destination.This is highly scalable as the peers do not need to build andmaintain routing tables.In order to set up the DHT structure needed by ourarchitecture on top of the P2P overlay network, we onlyneed to add a mapping function between a keyspace and theaddressing space of the peers. When a peer wants to storean entry in the DHT, it first creates a fixed length key byhashing a key string with the SHA-1 algorithm. Then, thepeer maps the key to an angle by a linear transformation.The peer computes a virtual point on the unit circle byusing this angle. Next, the peer determines the coordinatesof the closest peer to the computed virtual point. The peerthen sends a store request to this closest peer. This requestis routed inside the overlay by using the greedy routingalgorithm presented above.With the addressing, routing and mapping services pro-vided by our architecture, any user/entity of the P2P overlaynetwork can communicate with any other by setting upa virtual connection on top of the overlay. The steps forestablishing a communication between two entities of anoverlay are the following:1) Bootstrap into the overlay by setting transport layerconnections to one or more devices (i.e., neighborpeers).2) Obtain an overlay address from one of those neighborpeers.3) Identify oneself in the overlay with unique device andentity identifiers.4) Create a session. Device BDevice ADevice COverlay connection(CLOAK)Entity E -Entity FTransport connection (e.g. TCP) Device A – Device BLink connection (e.g. Ethernet)Router W – Router XRouter WRouter XRouter YRouter ZEntity EEntity F Figure 3. Virtual connections. Device BOV@ 2Device AOV@ 1Device COV@ 3Device COV@ 4Packet 1Dev A -> Dev CDest OV@ 3Packet 2Dev A -> Dev CDest OV@ 3Packet 3Dev A -> Dev CDest OV@ 4Device C moves to OV@ 4Packet 4Dev A -> Dev CDest OV@ 4 Figure 4. Steering packets inside the overlay network. 5) Contact another entity to communicate with inside thissession.6) Set an overlay layer virtual connection to this entityas shown in Figure 3.7) Send the data stream through this connection.If an overlay address becomes invalid, two mechanismscan be used to overcome routing failures. The first oneconsists, for intermediate nodes, in using the destinationname inside the packet header to query the DHT for itsnew address. If the DHT has a more recent (and thus valid)entry, the intermediate node will then be able to updatethe header with the new address and forward the packetaccordingly. The second one consists, for the destinationnode, in replacing its old address with its new one in theheader of its reply packets. Upon reception, the source nodewill then be able to update the destination address to thenewly received one. These mechanisms are illustrated inFigure 4. We call  steering , the mechanism of querying theDHT on the fly by intermediate nodes. This mechanism alsoprovides multicast capability when it is performed in eachintermediate node. Indeed, a destination group name can besolved as several user names that again can be solved asoverlay addresses.To be able to implement our architecture, we need tointroduce several new types of identifiers. More specificallywe need to define the following new namespaces: 13 International Journal on Advances in Internet Technology, vol 5 no 1 & 2, year 2012,  2012, © Copyright by authors, Published under agreement with IARIA -  •  Session namespace: any session is attributed a uniqueidentifier that defines the session during its lifetime inthe overlay. •  Device namespace: any device is attributed a uniqueidentifier that permanently represents the device. Thelifespan of this identifier is equal to the lifespan of itscorresponding device. •  Entity namespace: any entity is attributed a uniqueidentifier that represents the entity in a given context.It can be the name of a real person (John Smith) but itcould also be the identifier of a professional function(Sales Manager) or the name of an organization (Miche-lin Company) or a specific service (Areva Accountingservice). The lifespan of this identifier is equal to thelifespan of its corresponding entity. •  Application namespace: any application used during apart or all of a session is attributed a unique identifierfor receiving data from the other applications of thissession. The lifespan of this identifier is equal to thelifespan of the use of the application. If the entityswitches to another application, this identifier is up-dated.The identifiers will be stored in a DHT built on the P2Poverlay network. Each peer will store a fraction of all therecords in its naming module. There will be records for thedevices (containing pairs like: device ID - overlay address),for the entities (containing pairs like: entity ID - device ID),for the applications (containing pairs like: application ID- session ID) and finally for the sessions (containing pairslike: session ID - session data information). An applicationusing CLOAK will not directly open a connection with anIP address and a port number as with the usual socketsAPI but it will use the destination’s entity ID as well as astream ID. Figure 5 shows a typical scenario relying on thisnaming system for solving an entity’s location. The yellowoval represents the CLOAK DHT. An entity B registers itself in the DHT by providing the device identifier it is on and itsoverlay address. Any entity A can now retrieve the locationof B by querying the DHT. It can then connect to B viathe overlay. When B switches to another device during thesame session, A can reconnect to B by using its new overlayaddress.As defined earlier, a session is a communication’s contextcontainer storing everything necessary to bind together en-tities, applications and devices that are involved in a givencommunication. Any device, application or entity can bechanged or moved without terminating the session. In orderto make this possible, the session will be stored in the DHTbuilt by the peers of the overlay network. The DHT willensure reliability by redundantly storing the sessions onseveral peers. This session management system ensures thesurvival of the session until all the entities involved decideto stop it. Figure 6 shows a typical scenario relying on this Figure 5. Identification and localization.Figure 6. Session management. session management system. The yellow oval represents theCLOAK DHT. Let us assume that an entity A wants to starta video conference communication with an entity B. It firstcreates a session called X describing the desired interaction(e.g., video conference) as well as the destination entity thatit wants to communicate with (here the entity B). Then Asends an invite message to B that replies by joining thesession X. Later on the entity B invites another entity C toparticipate in the video conference. C accepts and joins thesession X. Three entities are now involved in the sessionX. Later on, the entity A leaves the session X withoutpreventing the others to continue. This thus does not endthe session X. Later on the entity C leaves the session X.The entity B being the last one involved decides to destroythe session and thus to end the communication. C. Usage Our architecture has a wide range of usages. It providesmechanisms for mobile and switchable applications, foradaptive transport protocol switching and for defining andusing new namespaces. It can build scalable and reliabledynamic Virtual Private Networks, define fully isolatedFriend-to-Friend networks, or be used as a convergencelayer for IPv4, NATs and IPv6. The Table I shows thebenefits of   cloaked   applications. Applications are groupedby families. Messaging applications contain e-mail, talk and chat programs. Conferencing applications regroup real- 14 International Journal on Advances in Internet Technology, vol 5 no 1 & 2, year 2012,  2012, © Copyright by authors, Published under agreement with IARIA -  Table IF EATURES FOR  cloaked   APPLICATIONS .Applications Messaging Conferencing Sharing StreamingReachability   Mobility    E2E privacy    E2E auth.    Pseudonymity    Redirection    Multicasting     time audio and video communications based on signalingprotocols such as SIP [5] and H.323 [6]. Sharing applicationsencompass file-sharing, blogging and social networking ap-plications. Finally, streaming applications contain audio andvideo broadcasting services such as Internet radios, IPTV,and VoD. Most of the features are usually self-explainingbut we give a few examples to highlight possible scenar-ios. Reachability is the ability to be reached on whateverdevice the user is currently using. When someone sendsa message to an entity, the CLOAK DHT can be useddynamically to determine on which device is the entityand the message is routed to the proper device. Mobilityis the ability of CLOAK to hide the handovers of thelower layers to the applications. If an entity is moving orswitching devices, real-time applications will be maintainedwithout interruption at the application level. CLOAK cansecure connections by using entity IDs rather than deviceIDs (or IP addresses such as in IPsec), thus establishingEnd-to-End (E2E) encryption and authentication. The publickeys of the peers can be stored in the DHT, howeverthe certification of these keys must be done by a trustedthird party. Because CLOAK packets usually transit throughseveral terminals before reaching destination, the IP addressof the source is often unknown to the destination thusproviding partial pseudonymity. Redirection is the abilityto forward a message or a stream to another entity. Finally,multicasting support is provided by CLOAK as group namescan be easily set up in the DHT. This feature is useful forsaving bandwidth during group communications.III. I MPLEMENTATION Figure 7 shows the OSI layers where the CLOAK ar-chitecture fits in. CLOAK uses the session layer and thepresentation layer between the transport and applicationlayers. These layers do not exist in the Internet stack modelbut they do already exist in the OSI model. In these twolayers we add two new protocols. We add a CLOAK sessionprotocol (CSP) at the session layer and a CLOAK interactionprotocol (CIP) at the presentation layer. We also define newidentifiers to be used by these new protocols. These newidentifiers enable data streams to be bound to entities insteadof network identifiers (i.e., IP address, protocol n ◦ , port n ◦ ).As shown in Figure 1, identifiers for devices, applicationsand entities are interwoven together inside a session, but Figure 7. CLOAK architecture in the OSI model. for the purpose of implementation, we have to order them.We chose to manage a session and its involved devices atthe session layer. We also chose to manage the interactionsbetween entities at the presentation layer. As previously said,an interaction is a type of action carried out between two ormore entities. It is equal to the use of an existing applicationlayer protocol (e.g., FTP, SMTP, HTTP, etc.). Indeed, ourarchitecture will use the existing application layer protocolsas well as the existing transport layer protocols. Thus a filetransfer (FTP [7]) client application will still use the FTPprotocol to speak to a FTP server. Only the portion of codefor establishing a session and thus a connection to the serverwill have to be rewritten for using the CLOAK API insteadof the socket API [8]. The code implementing the applicationlayer protocol will not have to be changed. Please note thatthe CLOAK API and the mapping of application connectionsto transport sockets inside the middleware are not definedyet. They will be presented in a future work.We have shown in Figure 7 how the CLOAK architecturefits in the network protocol stack. We will show how thisdesign translates into the format of the packet headers.Figure 8 shows a CLOAK packet exchanged between a Webclient and a Web server. The application header involving theHTTP protocol is now located after the CLOAK headers.We have added two additional headers. The CSP headeris located directly above the TCP protocol managing theconnection in the operating system of the device. It containsthe overlay addresses for routing inside the overlay andenabling device mobility, the device identifiers for switchingdevices and enabling entity mobility and the entity identifiersfor switching entities. The CIP header is located betweenthe CSP and the application level header. It is used foridentifying streams and applications. The stream identifiersare used as virtual port numbering on top of the entity. Theapplication identifiers are used for selecting or switching 15 International Journal on Advances in Internet Technology, vol 5 no 1 & 2, year 2012,  2012, © Copyright by authors, Published under agreement with IARIA -
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks