1

A Session-based Mobile Socket Layer for Disruption Tolerance on the Internet ´ Crestana Guardia, and Edson dos Santos Moreira, Member, IEEE. Bruno Yuji Lino Kimura, Helio Abstract—Several existing IP Mobility solutions use invasive approaches, when adjustments in legacy protocols from the TCP/IP stack are necessary, or rely on specific network infrastructures. We devised an architecture to handle mobility using a Session-based Mobile Socket Layer (SMSL). With no need for software adaptation in the core of the network or adjustment on the TCP/IP stack, SMSL operates only at the end systems involved in the communication, being fully transparent to neighbouring Transport and Application layers. The session scheme allows for mobility awareness for TCP-based applications that require resilience to failures, delays, or disconnection. A general-purpose API extended from the Socket and implemented in GNU/Linux provides session services, such as tracking mobile peers, detecting disruptions, and suspending and resuming sessions with efficiency, security and reliability. In this paper, we present the entire session support system as a mature work of research achieved with advances made in our previous study. The results of experiments in real and emulated test environments demonstrate efficiency. SMSL introduces little overhead, with a mean goodput degradation of 6.9% compared to an application implemented on top of the standard TCP/IP stack. Disruptions are detected in microseconds, and suspended sessions resume in milliseconds for single-homed mobile nodes. Index Terms—Session-based Mobile Socket Layer, Disruption-tolerant Sessions, IP Mobility Management, IEEE 802.21

✦

1

I NTRODUCTION

T

HE design of intelligent techniques that take advantage of existing IP-based technologies to enable global mobility in heterogeneous wireless networks is a research challenge for the Next Generation Network (NGN) [1]. By offering multiple wireless access points on Internet networks, keeping users Always Best Connected (ABC) is also challenging [2]. IP layer handovers occur frequently while searching for better access points. Recent efforts have focused on support for network mobility in Vehicular Communication Networks (VCN) [3]. Internet-based infotainment applications run on high-mobility devices in Vehicular-to-Infrastructure (V2I) scenarios. IP mobility solutions require changes to operate efficiently in the vehicular protocol stack, mostly with respect to route optimisation and handover latencies. Several solutions have been proposed to address IP mobility. Protocols based on the Network Layer, such as Mobile IP (MIP) [4][5], require network infrastructure to route datagrams to the current locations of mobile nodes. Transport Layer end-to-end mobility protocols are implemented in the kernel space of the mobile node, such as TCP-Migrate [6], HIP [7], and recently MPTCP [8]. These protocols require changes to the legacy protocols and • Bruno Kimura is with the Institute of Mathematics and Computer Science from the Federal University of Itajub´a (IMC/UNIFEI), Brazil. E-mail: [email protected] • H´elio Guardia is with the Department of Computer Science from the Federal University of S˜ao Carlos (DC/UFSCar), Brazil. Email: [email protected] • Edson Moreira is with the Institute of Mathematics and Computer Science from the University of S˜ao Paulo (ICMC/USP), Brazil. Email: [email protected]

hence imply difficulty in deployment and maintenance. On the other hand, end-to-end user space mobility solutions, such as ROCKS [9], SIP [10], and TIPS [11], are implemented as software components at end systems. Except for SIP, these solutions can prevent the use of additional network infrastructure and are able to work transparently in the TCP/IP protocol stack. However, though kernel space protocols may be costly, user space solutions may present communication overhead when copying data between different memory spaces. Regardless of the adopted approach, handling mobility leads to performance degradation. The key issue is to design a solution that has minimum impact on TCP/IP stacks. In our previous work (see [11] and [12]), we proposed handling mobility using a non-intrusive communication session with a TCP/IP stack [13]. This solution, we named it SMSL, is suitable for applications that require the establishment of a secure connection, reliable end-to-end transmission, and tolerance to disruptions/disconnections caused by host mobility. SMSL is focused on TCP-based communications because TCP is widely used as the end-to-end reliable protocol on the Internet. We use the term “disruption” to refer to every event related to the loss of IP connectivity, which prevents gaining access to the Internet. Sessions in SMSL negotiate parameters during the establishment of communication between mobile peers, in addition to providing services to consistently manage the application state in the event of broken connections. A GNU/Linux implementation exports SMSL as a general-purpose API to allow for the creation of mobility-aware applications. Unlike other session-based architectures [9][14], our approach is innovative in that it gathers different mobility strategies into a single object,

2 Session Reopening

handover link down

link up

Open Session

b

b

disruption b

b

td

tld

tr

t

tdown

Fig. 1. Timeline of mobility events during handovers.

which is a lightweight and efficient approach. In this paper, we present the entire session scheme of SMSL, summarise previous results, and present new ones. The proposed session method provides transparent services: tracking of mobile nodes with the support of a Distributed Hash Table (DHT), which is used to retrieve location registers stored under unique mobile host identifiers; disconnection detection, compatible with IEEE 802.21 link events [15], for link disruption and reestablishment; session suspension by blocking transmission whenever a link and session are not ready for use; re-opening suspended sessions by synchronising sender and receiver with current session information on a new TCP connection. We consider the temporal relationship between events linked to IP mobility. When handling mobility with SMSL, the sequence of events occurs according to the timeline shown in Figure 1, where: td : disruption detection time between the handover beginning and the loss of IP connectivity (link down). tld : time elapsed from the detected disruption and connectivity resumption (link up). This time is not under SMSL control because it depends on other platforms to acquire an IP address in the visited network. tr : time to re-open a suspended session in a new location. This process involves TCP connection reestablishment, authentication, and transmission synchronisation. tdown : total disconnection time, which comprises the sum of the times described above. To provide seamless handovers, the proposed SMSL aims to minimise the time elapsed during events under its control: td , tr , and, therefore, tdown . We start from the hypothesis that distributed applications can address communication failures [13]. There are detection mechanisms in the Sockets API to identify the absence of a link. Similar to node authentication, an application could handle mobility-related events, such as timeouts, broken connections and re-establishment, losses of unconfirmed data, location-independent identification, and location services. Session abstraction is useful in limiting the scope and duration of a connection while maintaining the TCP/IP stack intact. Regarding the wide range of applications and com-

munication scenarios that exist, on the one hand, there is the need for efficient solutions that allow for minimum disconnection time tdown to enable seamless mobility. On the other hand, due to mobile node limitations, there is a need for low-cost solutions that are easy to deploy and maintain and transparent in the TCP/IP stack. The remainder of this paper is organised as follows. The next section describes session abstraction with critical data structures to provide disruption tolerance. Section 3 presents the SMSL architecture and its implementation, as well as details regarding its operation. Section 4 describes the use of a DHT to support the Location Management of mobile peers. Section 5 presents details regarding the session handshaking and mutual authentication mechanism. Section 6 describes the trigger management used to detect disruptions. In Section 7, we discuss the obtained results regarding session overhead and latency of session services. Relevant work is discussed throughout the paper. In Section 8, we provide qualitative comparisons. Finally, in Section 9, we present our conclusions.

2 D ISRUPTION - TOLERANT S ESSIONS SMSL provides state information to control end-to-end transmission and prevent an application from sending messages when peers remain disconnected. We adapted the socket state diagram proposed in [9]. The behaviour of a session is set according to a diagram of three states, as shown in Figure 2: CLOSED (C), OPEN (O), and SUSPENDED (S). Read/Write Open Session C

Close Session

disruption

O

Reopening

S

Broken Session

Fig. 2. Disruption-Tolerant Sessions [13]. The application starts a session in the CLOSED state. To open the session, it first needs to establish a TCP connection with the remote peer; perform a handshake; and then synchronise the data transmission status between the peers. When the session reaches the OPEN state, it releases the application to send and receive messages on a connected socket descriptor. Upon link disruption, the monitor changes the status of all OPEN sessions to SUSPENDED. When the link is ready for use, the monitor triggers the re-opening of the SUSPENDED session by consistently resuming the OPEN state again. A user-defined number of unsuccessful retries to re-open a session induces the monitor to change the session state to CLOSED. 2.1 Elements of a session SMSL’s session collects elements to store information about peers over the duration of an end-to-end communication. The collection of elements is given by:

3

S ={sstate, sevent, smutex, mh, sock, timers, buf, siL, siR , certL , certR , KprivL , KpubR }

(1)

where sstate recovers the current session state; sevent is the current session event, which assumes particular values for receiving, sending, opening, re-opening, and retransmission; smutex is a POSIX semaphore used to synchronise the application transmission according to the ongoing value of sstate; mh is the handler responsible for monitoring the link and sessions, as well as initiating mechanisms for resuming sessions after disruptions; sock contains socket parameters; timers is used for connection establishment and sending and receiving messages; buf is an ancillary send buffer for recovering lost data due to disruptions; siL and siR contain relevant Session Information for the node and the remote peer, respectively, which is exchanged by the peers during the handshake; KprivL and KpubR are RSA Private and Public Keys for the node and remote peer, respectively; certL and certR are X509 Certificates for the node and remote peer, respectively. 2.2 Session Information SMSL controls peers taking part in a communication by a pair of Session Information elements, Local siL and Remote siR . A Session Information element consists of a 5-tuple, where hid is the Host Identifier; sid is the Session Index; f are control flags; and seqS and seqR are transmission checkpoints. A data structure measuring 41 bytes in length encapsulates the Session Information, as shown in Figure 3. 19

0

hid

23

31

sid seqR

39

40

seqS f

41 Bytes

Fig. 3. Session Information: a control message exchanged between peers in session (re)opening. A session uses this information as a control message for session re-establishment. During (re)opening, the peers perform a 4-way handshake in which they exchange their Local Session Information siL and authenticate mutually. The node saves and retrieves a received Session Information from the siR session element. 2.2.1 Host Identifier Host identifier hid allows for unique identification independent of the node location (IP). TCP-Migrate [6], designed for the same purpose, uses Session Tokens, and HIP [7] provides HIT (Host Identity Tag). Similarly to HIP, the identifier hid is computed with an SHA-1 hash on the Local Public Key KpubL . However, SMSL uses the entire digested 2160 name-space capacity for unique identifiers.

The X509 certificate, signed by a trusted Certificate Authority (CA) common between peers, includes a node’s public key. This allows for peer authentication with signature verification and inhibits spoofed identifiers. 2.2.2 Session Indexes Each peer in a session uses local and remote indexes: sid = {iL , iR }. The socket descriptor value, which value is a positive integer if valid, provides proper use as an index of session in the array of sessions session[]. The indexes allow for the manipulation of the sessions in constant operation complexity O(1), avoiding searches during transmissions and session establishment phases. The mapping between the local and remote indexes is siL .sid .iL = siR .sid .iR . This mapping allows the node to locate and confirm a session the remote peer claims to exist. 2.2.3 Control Flags Control flags f determine the role the node plays in a session. They consist of a set of 3-bit fields arranged in a data structure that is one byte in length: f = {mh, srv, clt}. The control flags determine whether an application runs on a mobile host (mh), it is a server (srv) or it is a client (clt). Flags also determine the use of the location management strategy. The location register is only driven by a server if it is running on a mobile node (i.e., when flags siL .mh and siL .srv are enabled). The client, in turn, obtains the server’s location if a remote peer’s flags siR .mh and siR .srv are enabled. By preventing access to the DHT, the latency of session establishment is minimised. In P2P applications, both peers play equivalent roles. SMSL have no support to manage the communication of these applications. However, using role-specific flags allows for optimisation for session re-establishment by consistently treating bidirectional re-connections between two P2P nodes. 2.2.4 Checkpoints The sending and receiving sequences seqS and seqR are repositioning offsets measuring 8 bytes in length each. They are specially designed to control the transmission status and to access the session buffer (buf ). Sequences are initially zeroed when creating a session. Sequence siL .seqS cumulatively counts the size of successfully sent messages. Similarly, siL .seqR counts the number of bytes received by the application. The sequences function as checkpoints allowing peers to reliably resume suspended sessions. They determine the exact amount of data lost during disruptions to be recovered from the session buffer buf .

3

S ESSION - BASED M OBILE S OCKET L AYER

A layered architecture, placed on top of the two peers involved in a communication, provides session services implemented on top of Sockets.

4

TABLE 1 Socket API wrapping functions.

Application Mobile Socket Layer Monitor

Session

Location

Buffer

PKI

Function

Description

m socket()

Creates and initialises a session i, where i is the socket descriptor returned from the original socket() function. The session layer uses the descriptor value index in the array session[].

m connect()

Establishes a TCP connection and executes client-mode (re)opening with a 4-way handshake that includes mutual challenge-response authentication.

m accept()

Accepts a TCP connection from a client and executes the server-mode (re)opening with a 4-way handshake with mutual challenge-response authentication.

m write(), m send()

Reliable, consistent and disconnection-tolerant message sending.

m read(), m recv()

Reliable, consistent and disconnection-tolerant message receiving.

m close()

Closes a TCP connection and finishes an open session.

m getreg()

Obtained a location register stored in the DHT under a given hid identifier.

m putreg()

Places and updates a location register in the DHT under a given hid identifier.

SSL

TCP IP 802.21 802.3

802.11

802.16

3GPP

Fig. 4. SMSL architecture.

Figure 4 shows the components of the session layer: i. Session: the key component that performs session opening and re-opening and manipulates the transmission over the socket descriptors created by the Application. ii. Location: retrieves and stores location registers in the DHT to keep tracking mobile peers. iii. Monitor: passively watches the condition of both the link and session. In the event of link disruption or re-establishment, it notifies the SMSL component using the subset of the link event defined by IEEE 802.21 [15]. It is also responsible for coordinating application transmission according to the link and session states. iv. Buffer: preserves the last copies of sent messages to consistently recover data lost during a disruption. v. PKI, SSL: provide support for automatically and securely (re)opening a session through PKI-based challenge-response authentication. PKI requires functions provided by the SSL API. 3.1 The Implementation Over the past few years, Google’s Android Operating System has been massively adopted by smartphone manufacturers. Android is a GNU/Linux-based OS that runs on most modern mobile devices. Because GNU/Linux implements IEEE 1003 POSIX [16], it provides legacy APIs with an extensive set of functions for interprocess communication, including Sockets. To validate and evaluate SMSL on a platform compatible with these modern mobile devices, we implemented it using GNU/Linux POSIX and adapted our previous implementation of Transparent IP Sockets (TIPS) to support it. Thus, a general-purpose API provides support for disruption tolerance with a set of basic wrapper communication functions from the Sockets, as shown in Table 1. The function prototype preserves the same parameters of the original function from the Socket. The former implementation of TIPS [11][12] provided reactive support to applications by treating errors caused by host mobility. It now provides support for the SMSL

with the support of a monitoring mechanism that asynchronously observes the link and session conditions. This support allows for the early treatment of the disruption and re-establishment of end-to-end communication, which TIPS previously did not provide. Two methods of deployment are supported: i. slightly intrusive requires the inclusion of the tips.h library in the application code. Programmers use wrapper functions in TIPS in their C/C++ applications instead of using the equivalent ones provided by the Sockets. Therefore, the method involves little modification to the application code and recompilation. However, the programming logic is unchanged. ii. Transparent requires no modification or recompilation in the target application code. Application syscalls are trapped and replaced by the equivalent ones wrapped in the TIPS. Two shared libraries, libtips.so and libtips.ld.so, are provided. The former compiles wrapped functions, as shown in Table 1. The latter compiles a reimplementation of the original functions from Sockets, which calls the equivalent ones wrapped in the TIPS. libtips.ld.so is loaded and attached to the target application with ld.so, which is a native dynamic library link/loader in GNU/Linux. When setting up the LD PRELOAD environment variable to point to libtips.ld.so, ld.so loads the variable before loading the remaining libraries, which allows for the overwriting of functions provided in the remaining libraries. Thus, a function called by the application is driven first to the preloaded library. Figure 5 illustrates a transparent operation. The libtips.ld.so library catches a call for send() and then replaces it with m send() from library libtips.so. The sockfd file descriptor is used as a local iL index to access the corresponding session in the session[] array.

5

Following the session handling, the application message is effectively sent with the original Socket function (pointed to send()) over the sock.fd file descriptor from the iL session. The preloaded library technique allows SMSL to function as middleware transparent to the neighbouring Application and Transport layers. Aplication

Fig. 6. XML schema for a Location Register [18]. syscall: send(sockfd, . . . ); libtips.ld.so

ld.so

m_send(sockfd, . . . );

regs

DHT GW 203.0.113.10

get(siR .hid ) libtips.so

libc.so.6

Transport

Kernel Space

put(siL .hid , regs , Ksec )

Internet 198.51.100.10:60944

syscall: __send(_session[iL ]->sock.fd, . . .); User Space

b

DHT GW parses XML regs and replaces the external address and port with NAT mapping of the RPC request: 198.51.100.10 60944

NAT regs m_getreg(siR.hid )

NAT 192.168.0.1

m_putreg(siL.hid , regs , Ksec ) 192.168.0.10:12345

Fig. 5. Transparent operation performed by interposing dynamic shared libraries with the ld.so link/loader.

4

L OCATION M ANAGEMENT

Whereas DNS provides name resolution for stationary nodes on the Internet, Home Location Registers (HLRs) allow for the retrieval and storage of the current locations of a MN. Home Agents (HA) of MIP [4][5] and Rendezvous Servers (RVS) in HIP [7] function as HLRs on the Internet. SMSL uses a general-purpose DHT to function as an HLR. To this end, we adapted the open-source implementation of BambooDHT1 , which provides persistent and scalable storage, using a simple interface for remote access. The use of DHTs for Location Management was initially proposed in [11]. By hashing a host identifier as a search key, the DHT provides a balanced distribution of location registers among multiple DHT nodes. Recently, the use of DHTs has also been exploited by HIP [17]. 4.1 Location Register A DHT stores registers under the search key hid , which is the Host Identifier. As described by the XML schema in Figure 6, a register is an XML document that gathers the internal address (Ai) acquired from the current visited network and port (Pi) allocated by the application; the external address (Ae) and port (Pe) obtained from the NAT mapping of the outermost NAT router ahead of MN, if any; and an X509 Certificate (X509Data) in PEM format. The ts attribute is a Unix Timestamp used to indicate the moment of storage. SMSL improves the use of DHT as an HLR. Thus, the host identifier now resolves more sophisticated location registers than those ones originally proposed in [11]. In addition to representing internal and external location 1. http://bamboo-dht.org/

Client

Server

Fig. 7. Location Management [13].

information, a register also gathers an X509 certificate used for authenticating peers during session establishment. Placing a certificate into a register available for wide querying reduces the cost of certificate distribution. 4.2 Location Updating and Retrieval A DHT gateway (GW) receives a request for put and get data from a remote procedure call over TCP (RPC/TCP). When receiving a put, the DHT GW extracts the IPPort pair of the requester from the RPC. If NAT routers obfuscate the requester, the IP-Port pair is the NAT mapping of the outermost NAT router ahead of the requester. Then, DHT GW inserts this information into the Ae and Pe tags. Otherwise, the external pair Ae:Pe will be equal to the internal one, Ai:Pi, in the register. Figure 7 illustrates location retrieval and updating in a scenario in which both the client and the server are running on MNs. The server inserts its register in the DHT, while the client tries to find the current server location. We incorporated a simplified Java Class in the BambooDHT implementation to pre-process a register immediately before its insertion into the DHT. The DHT GW parses an incoming XML register and updates it with information obtained from the received RPC request. Thus, the location update with put is preprocessed by maintaining the DHT insertion mechanism unchanged. On the requesting node, we adapted put and get into two basic primitives for updating and retrieval location registers, respectively: m putreg() and m getreg(). The updating comprises a triplet of parameters: hid (Unique Identifier requesting MN), regs (location register), and Ksec (hash of a secret key).

6

TABLE 2 SMSL support and location registration according to the node role in a session. Node role

Mobile server

Stationary Server

Mobile or stationary client.

Unusual communication scenario. Restricted SMSL support. Registration location and lookup is mandatory for every detected disruption.

Usual communication scenario. Full SMSL support. Registration location and lookup are only performed in the first session establishment.

Similar to STUN [19], updates and queries in DHT allow an MN to discover the IP and port allocated for the NAT router. To detect the presence of a NAT router ahead, the MN can put a register and get it, and then compare the internal Ai:Pi with the external Ae:Pe. This process represents a useful support tool for techniques used to solve the traversal NAT problem, such as Hole Punching [20] for P2P applications. Although doubleNAT obfuscating both the client and server is a difficult environment for user mobility and session continuity, port-forwarding configurations in NAT gateways enable the session establishment to succeed. At this point, the use of the session location management strategy is quite convenient. As described in Table 2, the use of DHT as an HLR at least once is mandatory to establish the session. In addition, a stored register stays available as a configurable time-to-live limited to 604800 seconds (a week) in BambooDHT. Thus, periodic location registration is needed according to the defined TTL.

5

S ESSION

ESTABLISHMENT

Session establishment involves the completion of a 4way handshake between a client and server, which is a mutual challenge-response authentication process combined with the existent key material. We applied the authentication algorithm specified in RFC 6287 [21]. This compatibility helps to prevent failures and avoids having to prove the effectiveness of the adopted authentication and key exchange. Figure 8 illustrates the steps of mutual challengeresponse authentication. Challenge question messages carry Local Session Information siL . Server

Client 1: Qc 2: Rs , Qs

1: 2:

3: Rc 4: OK

3: 4:

Client computes and sends its challenge question Qc . Server computes the challenge response Rs and sends its challenge question Qs . Client verifies the server response Rs and then computes and sends its challenge response Rc . Server verifies the client response Rc and, if successful, sends OK to finish the authentication.

Fig. 8. Mutual Challenge-Response Authentication [21].

Each challenge response verification is delimited by a timer. In the case of peer heterogeneity, when an SMSL-enabled client establishes a connection and sends a legacy server its challenge question, the lack of a challenge response generates a session timeout on the client side; hence, it aborts the session establishment. Peer compliance is required to prevent fake nodes from successfully initiating session establishment. For the sake of communication security and data stream consistency, session establishment only succeeds when both communicating sides are SMSL-enabled nodes. 5.1 Session authentication A challenger produces a Question Q, as shown in Figure 9(a), by concatenating its local Session Information siL with a current Unix timestamp T into a single value Vq . The T timestamp acts as a NONCE to prevent replay attacks in session establishment. The SHA-1 Algorithm digests Vq into hashed Vqh . With its private key KprivL , the challenger signs Vh and produces a signature sig. The remote peer verifies the challenger’s signature sig in a received question Q as shown in Figure 9(b). It decapsulates Q into the corresponding fields siL , T , and sig. Then, it re-assemblies Vq and digests it into Vqh . The RSA Verifying Algorithm verifies Vqh and the decapsulated signature sig with the challenger’s Public Key KpubR . Upon the successful completion of this process, the node computes its challenge response R to the challenger’s question Q received. Otherwise, it aborts the session (re)opening. Because the remote peer requires the challenger’s certificate to verify its signature, both the client and server must first place their location registers in the DHT. The destination node uses the challenger’s hid (from the Session Information received in question Q) to obtain the challenger’s location register from the DHT. We assume certificates are signed by a common Certificate Authority between the peers. Thus, peers also verify the certificate signature. Before responding to a received question QR , the destination node generates a question to return a challenge to the challenger. Thus, it generates its local question QL , as shown in Figure 9(a), as a piece of the response. The response R is a value Vr encrypted with the challenger’s public key KpubR , as shown in Figure 9(c). Vr consists of the received QR , the locally generated QL , and a restricted secret S securely shared between the peers. The shared secret is an optional field computed by the client. It is denoted by S = SHA1(Ksec , T0 , rand(T0 )), which is a value hashed from the combination of the first timestamp T0 , a random value generated by using T0 as a random seed, and the secret key Ksec (used for registration in the DHT). The server preserves the received S from the first client response Rc for latter comparison during session re-opening. In step 2 in Figure 8, the server sends its challenge response Rs and question Qs to respond to the client’s

7 KpubR

Q siL

⊕

sig

Vq

RSA_private_decrypt(.)

SHA1(.)

Vqh

RSA_verif y(.)

⊕

T KprivL

1: equal sig.

SHA1(.) Vqh RSA_sign(.)

⊕

Q

sig

(a)

0: different sig.

-1: error Compute R

Abort session

′

Vr

n

QR

Vq = hsiL , T i siL

KprivL

R

T

response_cmp(.)

⊕

QL

Vr

S

−1 : error ′ Vr 6= Vr

RSA_public_encrypt(.)

′

Vr = Vr

R Continue

Abort session

KpubR

(b)

Vr

(c)

(d)

Fig. 9. Session authentication algorithms: (a) challenge question generation, (b) question signature verification, (c) challenge response computation, and (d) challenge response verification.

question Qc . The challenge response is verified as shown Figure 9(d). The node uses its local private key KprivL to decrypt the remote peer’s response R into the value ′ Vr . If it can decrypt R, the node compares the known Vr ′ previously sent with the decrypted Vr . The two values must be the same for a trusted remote peer; if they are equal, the session continues. Otherwise, the node aborts the session. As described in step 4 in Figure 8, the server sends an OK message to complete authentication. This message is a challenge question Qs with a new signature because the timestamp T is updated.

DHT GW

Client

Put client’s Register m_putreg(regc .hid , ...)

Server

Put server’s register m_putreg(regs .hid , ...)

CLOSED Session Regular L4 connection establishment m_connect(iL , ...)

Client’s Challenge Question m_send(Qc , ...)

Lookup client m_getreg(Qc .siL .hid )

client’s register regc

Server’s Response and Question Verify Rs

m_send(Rs |Qs , ...)

Verify sig Save regc Generate Qs Generate Rs

Lookup server m_getreg(Qs .siL .hid )

5.2 Closed Session Opening Location management and mutual authentication are combined to open a closed session, as illustrated Figure 10. A session is initialised from the CLOSED state and the peers place their location registers in the DHT. With the location register available, the node obtains the certificate and extracts the remote peer’s public key to authenticate it. After registration, the client tries to establish a TCP connection to the server. Once it is established, the client generates question Qc and sends it to the server. With the field in Qc .si.hid , the server queries the client location register from GW DHT. With the received regc , the server decapsulates the certificate from the X509Data field and stores it in certR ; then, it extracts the public key and stores it in KpubR . Using KpubR , the server verifies the client’s signature in question Rc . Then, the server generates its question Qs , computes the response Rs and sends them both to the client. Based on the host identifier received in question Qs , the client obtains the server’s location register regs , stores the certificate in certR , extracts the public key KpubR , and then it verifies the server’s signature in Qs . Once authenticated, the node locally saves session iL (where iL matches the socket descriptor connected between the peers) in session[iL ]. Thus, the session saves the key material from the received registers and the Session Information received as remote siR . The session

Verify sig Save regs Generate Rc

server’s register regs

Client’s Challenge Response m_send(Rc , ...)

Server’s OK Message Verify OK Save iL

Verify Rc Generate OK Save iL

m_send(OK, ...)

OPEN Session

Fig. 10. Closed Session Opening [18].

state changes to OPEN so that the client and server can transmit messages on the connected socket descriptor. Querying in DHT is costly and significantly increases the latency of session opening. We discuss performance issues in Section 7. 5.3 Suspended Session Re-opening To the best of our knowledge, the manipulation of kernel parameters to freeze and resume TCP sessions is not allowed in the user space. To overcome this obstacle, SMSL establishes a new TCP connection to resume communication. Although this approach incurs the burden of performing a TCP slow start during every re-connection, its cost is offset by the benefit of easy deployment and maintenance, and even higher performance, provided by user-space solutions relative to the characteristics of kernel-space solutions.

8

Server

OPEN Session disruption ... SUSPENDED Session Put client’s Register m_putreg(regc .hid , ...)

Put server’s register m_putreg(regs .hid , ...)

Lookup server Failure

m_getreg(Qs .siL .hid )

server’s register regs

Only executed when the server is mobile

DHT GW

Client

Regular L4 connection establishment m_connect(iL , ...)

Client’s Challenge Question m_send(Qc , ...) Verify sig Verify Rs Save regs Generate Rc Verify OK Validade iL Save iL Resend lost data, if any

Server’s Response and Question

Verify sig Generate Qs Generate Rs

m_send(Rs |Qs , ...)

Client’s Challenge Response m_send(Rc , ...)

Server’s OK Message m_send(OK, ...)

Verify Rc Generate OK Validate iL Save iL Resend lost data, if any

OPEN Session

Fig. 11. Suspended Session Re-opening [18].

Figure 11 shows a scenario in which both the client and server are running on mobile nodes. The operation in the grey area of Figure 11 is avoided when the server runs on a stationary node. In that case, the server’s location is unchangeable and there is no need for the server to place its location in the DHT before re-opening the session. Because the client already has the server’s key material, obtained previously from the closed session opening, it does not need to obtain the stationary server’s location register for the re-opening. Thus, the re-opening of a suspended session is less costly than the opening of a closed session. Peers use control flags to determine whether to perform location querying and updates. The node retrieves the remote peer’s flag from siR saved locally. The client, at the moment of re-opening, is aware of the server’s mobility with the enabled flag in siR.f.mh. In the case of connection failure, the client can obtain the current location register of the mobile server from the DHT. Thus, the client tries to re-connect to the server’s address Ae and port Pe from the obtained register, which allows the client to overcome a race condition when the server is not ready to accept new connections or the server’s location register is outdated in the DHT. In such cases, primitive m connect() returns connection failure and the client queries again to obtain the updated register. After failure, the client waits for 1 second to query the DHT and then tries to initiate a new re-connection. The 1 second client delay signals the server to update its register in the DHT. Experiments show that 61% of register updates are accomplished in less than 0.5 seconds [13]. The persistence of the client in re-establishing the

connection is user-defined by the number of connection attempts written in a configuration file. During mutual authentication, the indexes help confirm the existence of a given session i in the array session[]. To access the desired session, the index sent by the remote peer iR matches the local one iL , and vice versa. If iR session exists, the node compares the remote host identifier (obtained from the received challenge question Q.si.hid ) with the one known in session session[Q.si.sid .iR ]. In addition to authenticating, session validation also determines whether to continue the re-opening. 5.4 Reliability with recovery of lost data The socket send buffer accumulates an unconfirmed number of bytes of in-flight data in the send window and buffered bytes not ready for sending. A disruption leads to the loss of these bytes. To provide reliability at the Application Layer, SMSL saves and recovers sent messages from the ancillary session send buffer buf . The session buffer is sized by taking into account the worst case of data loss, which is a full send buffer. Because the maximum size of the socket buffer is 131071 bytes in GNU/Linux Kernel 2.4, the session buffer length is 128 KB. After session handshaking during re-opening, with the support of session checkpoints, the sender is able to determine the amount of data lost at the receiver’s Application Layer. The bytes lost during disruptions correspond to the difference between the number of bytes the sender assumes to have sent (siL .seqS ) and the number of bytes the remote receiver actually received (siR .seqR ). The sender recovers lost bytes from the session buffer buf and resends them to the remote peer, if any are recovered. Finally, after the mutual authentication and transmission synchronisation of the peers, the session state returns to OPEN.

6 M OBILITY T RIGGER M ANAGEMENT The radio link condition is key context information used to assist disruption detection in an MN. Based on the link state, the SMSL Monitor suspends a session and resumes it. Thus, we applied the subset of link events of the IEEE 802.21 [15] to define the following Link States LINK UP and LINK DOWN. SMSL assures data are sent and received only when the link state is LINK UP and the session is OPEN. To do so, an asynchronous monitor passively observes the Link and the Session State. When detecting disruption, the monitor causes the state to change from LINK UP to LINK DOWN and suspends all ongoing sessions. Such an event causes a session to transition to the SUSPENDED state, in which data transmissions remain locked. Upon the change in state from LINK DOWN to LINK UP, the monitor starts the re-opening mechanism to make a SUSPENDED session return to the OPEN state. Then, all locked transmissions are released to continue the session.

9

6.1 Synchronisation with link and session states POSIX semaphores control the use of the link and session. Figure 12 depicts two concurrent sessions, i and j. Threads operating on the session array are synchronised first by the link state. The function wait link() blocks threads in the case of disruption. The link semaphore remains locked when the state is different from the expected state LINK UP. Thus, the link state functions as a barrier for all concurrent sessions and prevents wasting processing time while the radio link is not available for use. _session[i]

_session[j]

b

b

wait_link(LINK_UP)

b

wait_session(i, OPEN)

messages, LSCD updates the link state to LINK DOWN with the set linkstate() function and immediately calls the function suspend all sessions() to change the state of all OPEN sessions to SUSPENDED. This change in state generates the blocking condition for other user threads running on the sessions, as shown in Figure 12. The message RTM ADDADRR indicates that the MN was addressed and it has IP connectivity at the visited network. LSCD then immediately updates the link state to LINK UP by calling set linkstate() and initiates a recovery mechanism by calling reopen all sessions(). The latter tries to re-open each SUSPENDED session to continue the execution of the application by releasing threads blocked by the session state.

b

wait_session(j, OPEN)

Fig. 12. Sessions i and j synchronised by link and session states. When SMSL Monitor detects IP connectivity again, it changes the state from LINK DOWN to LINK UP and releases locked threads. Then, the function wait session() immediately verifies the state of the ongoing session. Similarly, the semaphore of the ith session is locked when the session state is different from OPEN. Both wait link() and wait session() are placed within the wrapper functions in SMSL, as described in Table 1. While user threads remain locked, waiting for the unlocking condition, Monitor observes the link and the session. As shown in Figure 13(a), two asynchronous functions conduct the monitoring task: Link State Change Detection (LSCD) and Dead Peer Detection (DPD). 6.2 Link State Change Detection - LSCD To provide detection disruption beyond the failures returned from unsuccessful sending, SMSL provides LSCD. LSCD is a non-blocking POSIX User Thread responsible for detecting link disruptions according to mobility events triggered by the GNU/Linux Kernel. It translates changes in the routing table of an MN to the IEEE 802.21 link events LINK DOWN and LINK UP. To do so, our implementation uses Rtnetlink Sockets, as in [22]. This facility is also a Socket-based API available in GNU/Linux that allows user processes to communicate with the kernel using ordinary socket descriptors [23]. To prevent polled operation, the Rtnetlink socket descriptors are bound to receive notifications about wanted events. LSCD receives rtnetlink multicast group messages upon changes in the MN’s routing table. As shown in Figure 13(b), LSCD handles two particular Rtnetlink messages, RTM NEWADDR and RTM DELADDR. The GNU/Linux Kernel triggers the messages when adding or removing IP addresses to or from the MN’s network interface. Whenever the kernel triggers RTM DELADDR

6.3 Dead Peer Detection - DPD After disruption, the receiver still can read remaining data from the socket receive buffer. The receiver remains blocked when trying to read an empty buffer and detects disruption only when the TCP keep-alive timer times out. Until the timeout, the connection is considered halfopen by the receiver, which causes the receiver to enter into a deadlock, waiting for messages over a broken connection. DPD is a key mechanism used to detect and infer disruptions caused by remote peer availability. Instead of creating a specific keep-alive mechanism, DPD extends the existing TCP keep-alive mechanism to confirm a remote peer’s liveness. To allow for fast detection, the values of the TCP Keep-alive parameters are reduced in each session. Using the setsockopt() function provided by the Sockets API, the application can reduce the number of probes TCP sends before dropping the connection; the idle time before TCP starts sending probes; and the time interval between probes. Similarly to LSCD, DPD operates asynchronously to the application as a non-blocking POSIX user thread. For each OPEN session, DPD calls recv() over the connected socket descriptor of the ith session, as shown in Figure 13(c). By default, recv() remains blocked while the TCP receive buffer is empty for reading. To provide nonblocking operation, the socket reading timeout is set to 1 second. This allows the DPD to check each OPEN session in the session[] array every second. When TCP detects that the peer is dead, the recv() function fails and returns the failure of connection timeout (ETIMEDOUT). Then, DPD sets the state to SUSPENDED and starts the reopening mechanism. For the sake of the application consistency, recv() in DPD returns without consuming the byte from the socket receive buffer. The flag MSG PEEK treats the read byte as unread in the socket buffer such that the read byte remains buffered for subsequent calls of recv() by the application. SMSL can handle disruptions caused by unrelated mobility events and also preserve application consistency with DPD support. With the loss of keep-alive probes sent by peers, a disruption somewhere in a network generates a connection timeout in the peers, which causes both applications to reach the SUSPENDED state.

10

Application

GNU/Linux Kernel

LSCD recv(i, ...) send(i, ...)

RTM_DELADDR

_session[i] 0

suspend(i) reopen(i)

n−1

send(_session[i]->sock.fd, ...)

Monitor LSCD

DPD

User Space

tld

recv()

DPD recv(_session[i]->sock.fd, &byte, 1, MSG_PEEK); ETIMEDOUT

TCP Keepalive Network Events (Rtnetlink Sockets)

recv(_session[i]->sock.fd, ...)

set_linkstate(LINK_DOWN); suspend_all_sessions( );

td

RTM_NEWADDR set_linkstate(LINK_UP); reopen_all_sessions( );

tr

suspend(i); reopen(i);

td tr

Kernel Space

(a)

(b)

(c)

Fig. 13. Monitoring link and sessions: (a) monitor operation, (b) Link State Change Detection (LSCD), and (c) Dead Peer Detection (DPD).

7

O BTAINED R ESULTS

To evaluate SMSL efficiency, experiments were conducted and analysed considering the following factors: 1) Overhead of SMSL on the goodput of message transmission between peers. 2) Latency of session services: location querying and updating in the DHT, TCP connection establishment, authentication, opening of closed sessions, and re-opening of suspended sessions. The next section discusses the evaluation of overhead, and we provide a summary of the latency results previously discussed in [13][18]. Fig. 14. Testbed virtualised in the Netkit emulator. 7.1 Overhead of the Session Layer To evaluate the overhead of using SMSL in a test environment free of noise and transmission interference, we used the network emulator Netkit [24]. Netkit allows users to adopt various network topologies, where each node is a User Mode Linux Virtual Machine. A virtual hub interconnects VMs that run on the real machine. 7.1.1

Description of the emulation testbed

Experiments were conducted in a virtualised testbed, shown in Figure 14, to measure the goodput between the client (sender) and server (receiver). There are three access networks, represented by Autonomous Systems AS1, AS2 and AS3, where the DHT, client, and server are located, respectively. Routers (R1, R2, and R3) interconnect these networks using the BGP routing protocol. The DHT node ran our customised implementation of BambooDHT to function as a DHT GW. All VMs exhibited a homogeneous configuration: Debian GNU/Linux, Kernel 2.6.26-5, and 256 MB of RAM. The real node, which virtualised the testbed, had the following configuration: Ubuntu GNU/Linux, Kernel 2.6.38-13, Intel (R) Core (TM) 2 Duo 2.26 GHz CPU, 4 GB of RAM. SMSL was easily deployed in the VMs. The required development packets in the SMSL implementation were installed on the VM file system as they are typically installed, with the Advanced Packaging Tool (APT) from

the Debian packages repository. Once the software dependencies were resolved, the SMSL implementation was compiled with GCC on the VM’s file system. 7.1.2 Goodput analysis We collected 200 goodput measurements for messages of varying size (starting from 1 KB and increasing exponentially up to 1 MB) sent to the server by the client. Figure 15(a) compares the cases with and without the use of SMSL. For all message block sizes, the mean goodputs without using SMSL were greater than those with the use of SMSL, as we expected (Figure 15). The client sender presented a general average of 20.11 MBps without the use of SMSL, against 18.70 MBps with SMSL support. These results indicate a general overhead of 6.98% goodput degradation when using SMSL. Outlier values had a greater impact on the SMSL results than did the values of ordinary sockets. We observed such results when considering the distance between the averages and the medians in the boxplots of Figures 15(b) and 15(c). By analysing the summarised results in the boxplots and the cumulative probabilities in Figure 15(d), we can clearly observe a slight degradation in the performance of SMSL. When considering the medians, the general goodput degradation of SMSL is approximately 3.3%.

1 2 4 8 16 64 256 1MB Block size (KBytes) for sent messages

1.0

SMSL Goodput (MBytes/s) 17 19 21 23 25 27 29 1 2 4 8 32 128 512 Block size (KBytes) for sent messages

(a)

0.2

CPF 0.4 0.6

0.8

Sockets SMSL

0.0

15

Sockets SMSL

Socket Goodput (MBytes/s) 15 17 19 21 23 25 27 29

Average of Goodput (MBytes/s) 16.0 17.5 19.0 20.5 22.0

11

1 2 4 8 32 128 512 Block size (KBytes) for sent messages

(b)

4

8

12 16 20 24 28 Goodput (MBytes/s)

(c)

32

(d)

(a)

18

20

t_auth

16

2.0

2.5

3.0

t_tcp

1.5

Latency (ms) 2.5 3.5 4.5

145 140

1.5

150

150 145

t_d

t_o 155

155

t_auth

140

Latency (ms) 1.8 2.0 2.2

2.4

t_tcp

1.6

SMSL sends user data using the m send() function, which operates as follows: m send() checks the link and session states to continue; sets the session parameters; treats the return of the original send() called and proceeds appropriately if disruption failure occurs; copies the message into the session buffer buf ; and updates sequence seqS . The most costly task is the message copying step, which affects the SMSL overhead. Considering the benefit of providing mobile communication resilience in the user space of the node, we assume the SMSL overhead is reasonable, particularly when analysing the summarised boxplots results.

18 20 22 24 26 28 30

Fig. 15. Analysis of goodput for different message block sizes: (a) mean goodputs, (a) boxplot of ordinary sockets, (b) boxplot of SMSL, and (c) cumulative probabilities. t_r

(b)

Fig. 16. Summary of delays related to (a) closed session opening (to ) and (b) suspended session re-opening (tr ).

7.2 Latency of Session Services With reference to our previous results [13][18], we discuss the results regarding SMSL service latencies evaluated in a real wireless network. Unlike simulations, experiments in a real environment suffer from interferences and may produce incomprehensible quantitative results. To minimise such interferences, we isolated the networking traffic in the same network such that the experiment consisted of a Client, Server and Router in a single WLAN. Although in mobile scenarios it is rare that both nodes are located in the same network, by isolating the networking traffic and by collecting a large dataset of 800 measurements of latencies, we attempted to minimise sampling errors. A router node functioned as a border gateway to provide Internet access. A fourth node located on a remote network operated as a DHT GW. All equipment used in the experiments was off-the-shelf. The results were obtained from the analysis of 800 measurements in the dataset. 7.2.1 Closed Session Opening The closed session opening delay is to = ttcp + tauth ,

(2)

where ttcp is the TCP connection setup delay and tauth is the delay of the 4-way handshake delay of SMSL mutual challenge-response authentication.

The mean time required to open a closed session in the sample was 177 ms. The results summarised in the boxplot of Figure 16(a) indicate a median time of 146.3 ms. From the boxplot, we can observe that the most costly operation is the time required for mutual authentication, representing 97% of to . This large amount of time is due to the access to the DHT GW needed to initiate peer authentication and the dependency between authentication steps, which suggests that a node remains blocked waiting for the response of the remote peer. Figure 17(b) shows that 90% of the session openings were completed within 200 ms. 7.2.2 Location Management Because high latencies are caused by queries in the DHT, we evaluated the functions m putreg() and m getreg(). According to the observed sample, to achieve a completion time shorter than 500 ms, the probability of m putreg() placing a location register in the DHT is 0.61, whereas m getreg() has a 0.89 probability of obtaining a register from the DHT, as shown in Figure 17(a). The high latency of m putreg() is due to its several interactions with DHT. Multiple puts under a single search key makes the DHT store all of them in sequence. To update a location register, the node gets all registers stored under a given search key, removes each obtained

CPF 0.40 0.60

SMSL re−opening SMSL opening

0.0

0.00

0.2

m_getreg() m_putreg()

0.20

CPF 0.4 0.6

0.8

0.80

1.0

1.00

12

0.0 0.2 0.4 0.6 0.8 1.0 1.2 1.4 Latency (s)

0.00

0.10 0.20 Latency (s)

(a)

0.30

(b)

Fig. 17. Cumulative probabilities: (a) location registration request and (b) opening and re-opening SMSL session.

register and then puts the new register. The results indicate that the location update is the performance bottleneck. To validate the performance of the proposed SMSL scheme, experiments were conducted in real environments by using a single DHT node with few resources of an off-the-shelf PC (500 GB disk size, 2 GB RAM, Intel(R), Core(TM)2 Quad CPU 2.40 GHz) [13]. To provide scalability, however, BambooDHT allows for the population of the overlay DHT network by including nodes with heterogeneous resources as needed and electing multiple gateway nodes to increase availability. For the large scale of the Internet, a global public computing platform based on the BambooDHT was provided for years by OpenDHT deployed on PlanetLab. 7.2.3

Re-opening Suspended Sessions

acquisition delay. The delay tends to be zero when a node revisits a known network. We used a terminal command line script to change the MN’s IP address periodically, hence causing forced disruptions in OPEN sessions. We measured the time required for the LSCD to sense the changes in the MN’s routing table and to handle them according to the IEEE 802.21 Media Independent Handover (MIH) services of Link Up and Link Down. This time is the disruption detection delay td , and it ranged from 14 µs to 5 ms, with a mean time of 3.3 ms in our experiments. Figure 16(b) summarises the results obtained for td and shows a median time of 3.18 ms. Therefore, this extremely wide range consisted of outlier values. SMSL requires a mean time of 26 ms to re-open a suspended session and a median time of 23 ms, as shown in Figure 16(b). By preventing the DHT from operating, the session re-opening delay decreases significantly, representing a performance gain of approximately 6 times with respect to the opening delay. More than 90% of the session re-openings required less than 30 ms to complete, as shown in Figure 17(b). In [18], we evaluated other secure handshake protocols, such as SSH and SSL. Whereas more than 90% of SSL handshakes required less than 20 ms to complete, SSH handshakes require approximately 3 s to complete due to user-level authentication. Our aim was to quantify the SMSL-related operations required to re-open sessions. We evaluated the disconnection time of the best cases: no location registration; MN disregards IP acquisition; and no race condition such that the server is always ready to accept re-connections.

The suspended session re-opening delay is tr = td + ttcp + tauth ,

(3)

where td is the disruption detection delay, as we defined in Section 1, and ttcp and tauth are defined in Eq.(2). We evaluated the re-opening of suspended sessions in a single jump scenario, which is a common mobile communication scenario on the Internet in which only the client runs on a mobile node. Therefore, the use of location management in SMSL for session re-opening is avoided. Our goal was to analyse the effect of the SMSL on the total disconnection time tdown . The time tld is the time elapsed from the event of disruption detection (LINK DOWN, triggered whenever the IP address is removed) to the event of link availability (LINK UP, triggered whenever a new IP address is added). The time depends on the acquisition of access to the MH’s Link and Network Layers, which is not under the control of SMSL. Thus, we ignored the time required for IP acquisition. Although in a normal scenario the acquisition of an IP address should be considered in the time tdown , advances obtained with the IPv6 stateless auto-configuration mechanism allow for minimum IP

8

R ELATED

MOBILITY PROTOCOLS

Table 3 compares the related protocols according to qualitative parameters and the mobility techniques implemented. The end-to-end mobility protocol provides the common feature of having a unique host identifier decoupled from the IP Layer. HLR is a required infrastructure in end-to-end mobility protocols. We used DHT as a promising approach for achieving a scalable HLR. Unlike MIP and SIP, which are the most infrastructuredependent protocols, HLRs are not used as network infrastructures for mediating communication. Therefore, in this respect, legacy IP routing offers an advantage. Authenticity is a key security requirement for mobility solutions. MIP protects its registration process with specific location registration authentication, which is similar to manner in which IPSec provides protection. Rather than defining new specific security mechanisms, the other compared mobility protocols provide security support by reusing existing, validated security models. The transparency of the legacy applications running on the mobile node is intrinsically provided by mobility protocols that operate at the lower layers, such as MIP, or those implemented in the kernel space, such

13

TABLE 3 A qualitative comparison among related mobility protocols for single-homed mobile nodes. Parameters

MIP [4][5]

HIP [7]

TCP-Migrate [6]

SIP [10]

ROCKS [9]

SMSL [13][18]

Operation Layer

L3

L4

L4

L5

L5

L5

Implementation

Kernel space

Kernel space

Kernel space

User space

User space

User space

Host Identifier

-

HIT (128 bits)

Token (32 bits)

URI

Connection ID

hid (160 bits)

Infrastructure dependency

Home Agent (HA), Foreign Agent (FA)

RVS (HLR)

DDNS (HLR)

Redirect, Proxy, Registrar servers.

DNS (HLR)

DHT (HLR)

Security support

Location registration authentication

IPSec

ECDH

User level authentication

Diffie-Hellman

RFC 6287

Modification on the TCP/IP stack

yes

yes

yes

no

no

no

Deployment cost

high

high

high

medium

low

low

Transparency

native

native

native

no native support

Reliable Packet (RACK) filtering

syscall interception LD PRELOAD

Reliability

Above layer (TCP)

Above layer (TCP)

Native with TCP modifications

no native support

In-flight send and receive buffers

Ancillary session send buffer

IEEE 802.21 support

no native support

no native support

no native support

no native support

no native support

MIH Link Up and Link Down

Handover latency

> 1 s simulation, ∼ 10 s experiment

< 1 s simulation

< 1 s simulation

> 2 s simulation

< 2 s experiment

< 1 s experiment

as HIP and TCP-Migrate. Likewise, in the user space, such transparency can be provided by the system calls interception LD PRELOAD, as in SMSL. SIP support, on the other hand, is provided by API implementation for developing specific multimedia applications. TCP-based applications take advantage of the L4 reliability provided by TCP. However, for a mobile sender, there is no guarantee that the data buffered in its send socket buffer will reach the receive socket buffer at the remote peer. In addition, the remote peer may not consume the data available in its receive buffer. Thus, the reliability of TCP fails for mobile devices. ROCKS and SMSL provide reliability at the Application Layer. Whereas ROCKS requires send and receive in-flight buffers, SMSL uses only an ancillary session send buffer buf with the support of transmission checkpoints. While the use of IEEE 802.21 services is not natively provided by the compared solutions, SMSL implements the IEEE 802.21 MIH services of Link Up and Link Down to anticipate mobility handling. The performance of the mobility techniques can be assessed using the handover latency as a parameter. As discussed in [25], the handover latency of MIP is always greater than that of TCP-Migrate. First, MIP signalling messages are sent between MN and its Home Agent (HA), while TCP-Migrate signalling messages are sent between MN and CN. The distance between MN and HA is typically greater than the distance between MN and CN. Second, MIP handover is not transparent to TCP. Although MM’s new address is registered at the HA, TCP waits until the retransmission timer times out before sending a new packet [25]. In our previous experiments [12] using the route optimisation-enabled MIPv6 together with the stateless address auto-configuration, which is a common IP mobility solution reported in the literature, handover delays lasted 10 seconds on average. On the other hand, the fundamental function of TCP-

based end-to-end mobility protocols is to resume a session as soon as the node detects disruption and receives a new IP address. According to the simulation results discussed in [26], HIP and TCP-Migrate provide nearly the same performance with respect to handover latencies. They slightly differ due to the number and size of signalling control messages exchanged to complete handover. Because the size of the SIP signalling message is larger than that of the MIP signalling message, the SIP messages require a greater number of retransmissions. For UDP-based applications, this discrepancy results in a higher handover latency for SIP compared to that of MIP [25]. Whereas ROCKS assures re-connections that last up to 2 s [9] with user space mobility handling, SMSL is capable of providing re-connections in ms. When enabling multi-homing and multi-streaming to support resilient sessions, as in EMF [27], SCTP [28], and MPTCP [8], all of the mobility protocols should be able to drastically reduce the handover latency to zero. However, energy efficiency is another key requirement for multi-homing protocols to minimise the impact of concurrently using multiple network interfaces. In this paper, we have discussed the effects of implementing SMSL on per-link utilisation with a focus on singlehomed mobile nodes.

9

C ONCLUSIONS

This paper describes the full concept of a Session-based Mobile Socket Layer with the objective of providing communication disruption tolerance for legacy applications on the mobile Internet. Over the wide spectrum of existing IP mobility solutions, SMSL is a user space implementation-based protocol that provides the easy deployment and maintenance of a simple software component while maintaining the TCP/IP protocol stack

14

intact. The middleware provided by the mobile socket layer architecture allows for the incorporation of new functionalities with single control modules. Because it is capable of re-opening suspended sessions in dozens of milliseconds with consistency and reliability and without loss, SMSL offers good performance in terms of per-link utilisation during handover and low utilisation overhead for single-homed mobile nodes.

ACKNOWLEDGEMENTS The authors would like to thank the National Science and Technology Institute for Critical Embedded Systems (INCT-SEC, Brazil) for funding this work by means of the agencies CNPq and FAPESP.

R EFERENCES [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12]

[13]

[14] [15] [16]

[17] [18]

I. Akyildiz, J. Xie, and S. Mohanty, “A survey of mobility management in next-generation all-ip-based wireless systems,” IEEE Wireless Communications, vol. 11, no. 4, pp. 16 – 28, Aug. 2004. E. Gustafsson and A. Jonsson, “Always best connected,” IEEE Wireless Communications, vol. 10, no. 1, pp. 49 – 55, 2003. S. Cespedes, X. Shen, and C. Lazo, “Ip mobility management for vehicular communication networks: challenges and solutions,” IEEE Communications Magazine, vol. 49, no. 5, pp. 187 –194, 2011. C. E. Perkins, “IP Mobility Support for IPv4, Revised,” RFC 5944, November 2010. D. Johnson, C. Perkins, and J. Arkko, “Mobility Support in IPv6,” RFC 6275, July 2011. A. C. Snoeren and H. Balakrishnan, “An end-to-end Approach to Host Mobility,” in MobiCom ’00: 6th ACM Annual International Conference on Mobile computing and Networking, August 2000. R. Moskowitz, P. Nikander, and P. Jokela, “Host Identity Protocol,” RFC 5201, April 2008. A. Ford, C. Raiciu, M. Handley, S. Barre, and J. Iyengar, “Architectural Guidelines for Multipath TCP Development,” RFC 6182, March 2011. V. C. Zandy and B. P. Miller, “Reliable Network Connections,” in MobiCom ’02: 8th ACM International Conference on Mobile computing and Networking, September 2002. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and R. Schooler, “SIP: Session Initiation Protocol,” RFC 3261, June 2002. B. Y. L. Kimura and H. C. Guardia, “TIPS: Wrapping the Sockets API for Seamless IP Mobility,” in ACM SAC’08: the 23rd Annual ACM Symposium on Applied Computing, March 2008. B. Y. L. Kimura, R. S. Yokoyama, R. R. F. Lopes, H. C. Guardia, and E. S. Moreira, “Prototyping applications to handle connection disruptions in end-to-end Host Mobility,” in WONS 2010: the 7th IEEE International Conference on Wireless On-demand Network Systems and Services, February 2010. B. Y. L. Kimura, H. C. Guardia, and E. S. Moreira, “DisruptionTolerant Sessions for Seamless Mobility,” in WCNC 2012: the 2012 IEEE Wireless Communications and Networking Conference, April 2012. M. Snoeren, “A Session-Based Architecture for Internet Mobility,” Ph.D. dissertation, Massachusetts Institute of Technology, February 2003. IEEE Standard for Local and metropolitan area networks - Part 21: Media Independent Handover Services, IEEE SA - 802.21-2008. IEEE Computer Society - LAN/MAN Standards Committee, 2008. IEEE Standard for Information Technology - Portable Operating System Interface (POSIX) - Base Specifications, Issue 7 - IEEE Std 1003.1-2008: Revision of IEEE Std 1003.1-2004. IEEE Computer Society and The Open Group, 2008. J. Ahrenholz, “Host Identity Protocol Distributed Hash Table Interface,” RFC 6537, February 2012. B. Y. L. Kimura, R. S. Yokoyama, H. C. Guardia, and E. S. Moreira, “Secure Connection re-establishment for Session-Based IP Mobility,” in CBSEC 2012: II Brazilian Conference on Critical Embedded Systems, May 2012.

[19] J. Rosenberg, R. Mahy, P. Matthews, and D. Wing, “Session Traversal Utilities for NAT (STUN),” RFC 5389, October 2008. [20] P. Srisuresh, B. Ford, and D. Kegel, “State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs),” RFC 5128, March 2008. [21] D. M’Raihi, J. Rydell, S. Bajaj, S. Machani, and D. Naccache, “OCRA: OATH Challenge-Response Algorithm,” RFC 6287, June 2011. [22] E. Piri and K. Pentikousis, “Towards a GNU/Linux IEEE 802.21 implementation,” in ICC’09: the 2009 IEEE international conference on Communications, June 2009. [23] A. Udugama, “Manipulating the Networking Environment Using RTNETLINK,” Linux Journal, Mar 2006. [24] M. Pizzonia and M. Rimondini, “Netkit: easy emulation of complex networks on inexpensive hardware,” in TridentCom ’08: Proceedings of the 4th International Conference on Testbeds and research infrastructures for the development of networks & communities, 2008. [25] S. Mohanty and I. F. Akyildiz, “Performance analysis of handoff techniques based on mobile ip, tcp-migrate, and sip,” IEEE Transactions on Mobile Computing, vol. 6, no. 7, pp. 731–747, Jul. 2007. [26] P. A. Shah, M. Yousaf, A. Qayyum, and H. B. Hasbullah, “Performance comparison of end-to-end mobility management protocols for TCP,” Journal of Network and Computer Applications, vol. 35, no. 6, pp. 1657 – 1673, 2012. [27] M. Yousaf, A. Qayyum, and S. A. Malik, “An architecture for exploiting multihoming in mobile devices for vertical handovers & bandwidth aggregation,” Wireless Personal Communications, vol. 66, pp. 57–79, 2012. [28] S. Fu and M. Atiquzzaman, “SCTP: state of the art in research, products, and technical challenges,” IEEE Communications Magazine, vol. 42, no. 4, pp. 64–76, Apr 2004. Bruno Yuji Lino Kimura received his BSc degree in Computer Science from the Pontifical Catholic University of Minas Gerais in 2005, MSc degree in Computer Science from the Federal ˜ Carlos in 2008, and DSc deUniversity of Sao gree in Computer Sciences and Computational ˜ Paulo Mathematics at the University of Sao in 2012. He is an assistant professor and researcher at the Institute of Computer Science and Mathematics at the Federal University of ´ His research interests are related to Itajuba. Mobile Computing, Computer Networks, and Distributed Systems. ´ Helio Crestana Guardia received his BSc and MSc degrees in Computer Science from the ˜ Carlos in 1990 and Federal University of Sao 1993, respectively, and DSc degree in Electrical ˜ Paulo Engineering from the University of Sao in 1999. He is an associate professor and researcher in the Department of Computer Sci˜ Carlos. ences at the Federal University of Sao His research interests are in the following areas: Distributed Systems, Grid Computing, Wireless Networks and IP Mobility, Computer Networks and Operating Systems. Edson dos Santos Moreira received his BSc degree in Electrical Engineering from the University of Sao Paulo in 1982, MSc degree in ˜ Paulo in Physics from the University of Sao 1984, and PhD degree in Computer Science from the University of Manchester in 1989. He conducted post-doctoral studies at Strathclyde University in 1993 and the University of Cambridge at the Computer Laboratory from 2007 to 2006. He is a full professor and researcher at the Institute of Mathematics and Computer ˜ Paulo. His research interests are in Science at the University of Sao the fields of Computer Networking, Secure Wireless Communication, Mobility Management, and Internet Technology.