IP in UPMT Networking - Compare and Contrast

(1)

The UPMT solution

(Universal Per-application

Mobility Management using Tunnels)

Technical Report - Version 1.1, June 2011

S. Salsano(1), M. Bonola(1)

(1)_{University of Rome “Tor Vergata”}

Available at: http://netgroup.uniroma2.it/UPMT Contact: [email protected]

DISCLAIMER

This work has been partly funded by the EU in the context of IST PERIMETER project (http://www.ict-perimeter.eu/), but it does not necessarily represent the official position of the project itself and of its partners. Authors are solely responsible for the views, results and conclusions contained in this work.

COPYRIGHT

"Copyright and all rights therein are retained by authors. This work may not be modified or reposted without the explicit permission of the copyright holder"

(2)

1. What is

UPMT?

UPMT is a mobility and multi-homing solution based on "IP in UDP" tunneling that provides per-application flow management, i.e. traffic flows of different applications can be independently routed on different access networks. UPMT provides transparent support of legacy applications, so that they can use UPMT without being modified or linked to updated versions of standard libraries. UPMT does not require any support from the access networks and is fully compatible with existing network infrastructures, in particular with all legacy NATs. UPMT is a mobility mulit-homing solution well suited for Always Best Connected scenarios, whose basic idea relies on the automatic selection "at any time" of the "best" interface for sending and receiving data.

UPMT has been implemented for the "mainstream" Linux and then ported on the Android OS and the source code is available under the GPL open source license. For demonstration purposes, a UPMT Linux Live distribution is provided and both UPMT mobile and anchor nodes can be set up in a few steps.

The home page for downloading source code, installing UPMT and retrieving more information about UPMT (including two .ppt presentation) is:

(6)

2. work

and

problem

statement

2.1 Always Best Connected

The concept of Always Best Connected has been thoroughly discussed in a 2003 paper [1] ever since it has entered the common nomenclature. ABC services can be described as follows: “For a person to be always best connected means that he or she is not only always connected, but also connected through the best available device and access technology at all times. The definition of best depends on a number of different aspects such as personal preferences, size and capabilities of the device, application requirements, security, operator or corporate policies, available network resources, and network coverage. Depending on the applications and user preferences, a user can be connected over one access at a time or over multiple accesses in parallel. The ABC concept includes virtually all types of access technologies; fixed and wireless, and existing technologies as well as those that are yet to come.”.

Two aspects of the description reported above are worth being remarked. The statement “always connected through the best available access technology at all times” leads to following considerations: (1) ABC services require a mobility management solution that allows the ABC terminal to move seamlessly between different access network technologies, while maintaining connections to application servers. (2) no assumptions other then basic IPv4 connectivity about the possible access networks can be made, as well as no support from the access network can be required. Even though modifications to the access routers, or in general to the devices present in the access network, could improve the seamless mobility management, the case of no control over such devices has to meet; (4) no limitation regarding the applications and the correspondent hosts can be posed. In other words, the mobility management should support all types of application and should provide mechanisms to communicate with legacy correspondent hosts not implementing the mobility management mechanisms.

Another important aspect is related to the statement “depending on the applications and user preferences, a user can be connected over one access at a time or over multiple accesses in parallel”. Since application and user preferences vary from application to application, a per-application independent multi-homing and mobility management is

(7)

required. In other words, a ABC terminal should be able to manage different application flows independently, and take different handover decision for each application.

Moreover, regarding the mobility support provided by the ABC service, the following additional requirement has been considered: “[…] Certain types of services, commonly known as push services, require a means to locate a user at his or her current network location. Such a solution for reachability or presence can be included in the ABC service offered to the user […]”.

2.2 Mobility Management requirements for ABC scenarios

With regards to the considerations discussed in the previous section, we have identified a set of functional requirements for a mobility management solution to support ABC services in our vision. These requirements are summarized and listed hereafter:

1. The Mobility Management solution should not require additional support in the access networks. The access networks are only required to provide IP connectivity. The capability to offer Mobility Management services should not be an exclusive prerogative of the network operators. On the other hand, it should be possible for network operators to provide added value and enhanced services, by exploiting their network and servers assets.

2. The Mobility Management solution should be able to separately deal with different applications and decide different handovers for each one based on a set of criteria like for example: cost; QoS/QoE parameters like throughput, loss, delay/jitter; security… (N.B. A discussion of the criteria is out of scope of this work)

3. The Mobility Management solution should be compatible with NAT traversal. Users should be able to roam from an access network to another, even when one or both access networks use private IP addressing and are behind a NAT. Terminals that are not connected behind a NAT or that are in the same access network should be able to communicate directly, wherever possible

4. Legacy application must be supported on the mobile host side, i.e. we should not require applications to be rewritten/recompiled to run on the mobile hosts and exploit mobility features. On the other hand it should be easy to deploy new applications or enhance existing applications to fully exploit the capability offered by the Mobility Management solution

5. The Mobility Management solution should support all types of applications. Both TCP and UDP based application needs to be supported, as well as all existing application level protocols.

6. The Mobility Management solution should not require any modifications to the Correspondent Hosts, nor to the applications running in the CHs. All existing terminals should be able to interoperate with roaming MHs. On the other hand, if the Correspondent Host / Correspondent application is aware of the Mobility Management solution, this should be exploited to provide a more efficient solution 7. The Mobility Management solution should be able to scale by distributing any server

side capability into a set of nodes, taking into account load sharing issues as well as optimization of forwarding paths.

(8)

8. In order to preserve the privacy of the users, it should be possible to hide the actual location and the movements of the user to the CH, while maintaining reachability even in access networks behind NAT.

9. When switching from an access network to another one, the Mobility Management signaling should be sent over the new target network, since the old one could suddenly become unavailable; in such a case it is necessary to perform the whole handover procedure on the new network (this is known as “Forward” handover or “break before make”). On the contrary, if the old network is still available, the availability of both networks can be exploited in order to assist and speed up the whole procedure (“make before break”). When two or more networks are available at the same time, they can be used in parallel (“multi-homing”).

10. The vertical handover must be as fast as possible. This means that the user should not perceive any service interruption. If it is not possible to completely hide the effect of the handover, then the service disruption should be minimized.

11. The Mobility Management solution should provide security services (message and entity authentication, data confidentiality, etc..) without necessarily depending on a particular existing security protocol.

2.3 Related Works

This section presents some mobility management approaches among the large number of proposals that can be found in the literature and in the standards and try to relate them with the list of requirements reported in Section 2.2.

2.3.1 Mobile IPv4 and Mobile IPv6

Mobile IPv4 (MIPv4) [3] and Mobile IPv6 (MIPv6) [4] deal with IP mobility management issue from a network layer point of view. When a Mobile Host moves from the home network to a foreign network, a new IP address (Care of Address - CoA) is obtained. The Home Agent (HA) is informed of this movement and updates the “binding” between the MH Home Address (HoA) and the new CoA. Packets addressed to MH’s HoA are intercepted by HA and tunneled (IPv4 in IPv4 or IPv6 in IPv6) in IP packets addressed to MH’s CoA. Furthermore, both MIPv4 and MIPv6 specification define a route optimization mechanism that provides packets direct routing between MH and CH through the optimized path.

As for additional security mechanisms, [6] describes the details of use of IPsec Security Associations (SA) for protection of MIPv6 signaling traffic between the MH and the HA. As for the tunnel data protection, the common approach is to secure IPv6 tunnels with IPsec tunnels. This approach can be applied also to MIPv4.

MIPv4 is the first mobility management solution and presents different limitations, partially, due to implicit limitations of IPv4. Without listing all the issues, we want to consider the fact that MIPv4 requires support in the Foreign Network. This is a major limitation and makes MIPv4 not suitable for ABC scenarios under the requirement that existing access network should be supported: MIPv4 would require support in all possible access network visited by the MH. In addition, flow binding procedures for MIPv4 [5] are still under standardization process, so MIPv4 is not yet compatible with a per-application mobility management.

MIPv6 benefits from both the previous work on MIPv4 and from some features offered by IPv6 itself, so it provides many improvements compared to MIPv4. MIPv6 shares many

(9)

features with UPMT and fulfils many requirements (e.g. multiple CoAs, flow binding update [7]). Anyway, IPv6 connectivity cannot be given as granted for most Internet Service Providers. Since MIPv6 mobility solutions for ABC are limited by the access and transport network infrastructure, MIPv6 is not suitable for ABC scenarios in our vision.

As for MIPv6 security weaknesses, the use of IPsec fully protects the signaling traffic between MH and HA. Nevertheless, the simple substitution of IPv6 tunnels with IPsec tunnel suggested in the base MIPv6 specification leads to handover performances limitation due to the establishment of a new SA. As for the mobility of IPsec SA, please see Section 2.3.3.

2.3.2 Proxy Mobile IPv4 and Proxy Mobile IPv6

Without going into much details about the differences between the two versions, Proxy Mobile IP v4|v6 [12][10] is a localized mobility managements solution that changes the basic MIP v4|v6 approach by moving the mobility management from the terminal to the access routers.

Mobile Nodes (MNs) in a PMIP domain never perceive the movement from two PMIP enabled access routers (called Mobility Access Gateway - MAG), as they are reassigned the same address for the entire session. The MAG notifies every MN movements to a topologically higher entity called Local Mobility Anchor (LMA) which is responsible for maintaining the mobile node’s reachability. In the PMIP solution, the MNs are totally unaware of the mobility management procedures which are in fact performed by the MAG and the LMA.

PMIP is a new and widely exploited IP mobility management solution (for example in 3G mobile networks) and provides different interesting features, among which support for multiple interfaces and support for flow mobility [7]. Nevertheless, its network centric paradigm (common to both v4 and v6 version) makes its use in our vision of ABC scenarios impossible. Indeed, PMIP architecture requires all access routers to implement PMIP functionalities, and this of course cannot be considered for granted. Moreover, PMIPv6 suffers from the same limitation related to the necessity of IPv6 connectivity as in MIPv6.

2.3.3 IKEv2 Mobility and Multi-homing protocol

A different approach based on dynamic update of IPsec SAs is provided by the IKEv2 Mobility and Multi-homing (MOBIKE) protocol [8]. MOBIKE is an extension to the Internet Key Exchange Protocol version 2 [9] (IKEv2) and provides a protocol to dynamically update the IP addresses associated to an already established IPsec SA. Therefore, MOBIKE gives an secure and end-to-end solution to the multi-homing and mobility issue by extending IKEv2 to efficiently manage IPsec in a scenario in which the host has multiple IP addresses or changes the IP address over time.

MOBIKE solves the need of IPsec SA rekeying due to IP address reconfiguration, but it still suffers from some major limitations and does not provide a full solution to mobility and multi-homing. In fact, MOBIKE does not provide rendezvous mechanisms and thus, simultaneous movement and full NAT traversal are not supported. Moreover, since only one pair of SAs can be used simultaneously, load balancing and “make before break” handovers are not supported as well.

(10)

2.3.4 SIP Mobility Support

According to the SIP protocol, an INVITE message is sent by a terminal to its correspondent to setup a communication session. The traditional SIP mechanism to provide terminal mobility during an active session [22] involves not only the mobile host (MH) but also the correspondent host (CH), which is the other party engaged in the call. It foresees that the MT sends another INVITE message to the CT to communicate the information about the new parameters of the communication session after the handover. Although this solution solves the problems of Mobile IP, it has some drawbacks too. The second INVITE (commonly referred to as “Re- INVITE”) is sent end-to-end, and this could lead to high delays. Moreover, the handover procedure relies on the capability of the CT to handle this procedure.

Different SIP-based approaches have been proposed to manage mobility, addressing the shortcomings of the end-to-end “Re-INVITE” mechanism. For example, in [23] it is assumed that the MT connects to the Internet through different ANs and that each of them has its own so-called “Base Station”. The Base Stations are able to handle the vertical mobility and perform a handover, by moving a communication from a base station to the other. Actually, the handover procedure is split in two phases. First the MT contacts the old Base Station and asks to receive/send packets over the new AN, using an INVITE message, which makes use of the JOIN SIP header [24]. For a certain time, media packets will be duplicated and sent over both wireless networks. As soon as the packets reach the MT through the newly activated interface, a re-INVITE message is sent by the MT to the CT through the new Base Station. Then, the media will flow through the new Base Station and over the new Access Network; a SIP BYE message will be sent to close the session with the old Base Station and a REGISTER message will be sent to the user “home” Registrar server to update the user contact information. This solution improves the performance of traditional SIP mechanisms in terms of handover duration and packet loss, but it still requires the involvement of the CT. Also, it requires a complex sequence of SIP transactions (INVITE, “Re-INVITE”, BYE and REGISTER) for each handover and it does not address NAT traversal issues.

Anyway, regardless of the particular SIP based mobility management solution, such mechanisms are applicable only in case of SIP applications, and thus can not surely be used in ABC services.

2.3.5 Host Identity Protocol

A totally different paradigm with respect to traditional mobility management solution is provided by the Host Identity Protocol (HIP) [13]. HIP deals with the mobility and multi-homing problem with a radical architectural enhancement. It solves one known limitation of the Internet architecture by decoupling the double role of both topological locator and network interfaces identifier of the IP addresses. HIP introduces a new layer between transport and network layers so that application socket are no longer bound to IP addresses, but to Host Identities, which are not affected by any underlying addressing change.

Compared to other solutions, HIP seems to be more suited for ABC services. HIP is totally end-to-end but also defines mechanisms for rendezvous services and host discovery. HIP works with NAT and with all existing network infrastructure. In addition, HIP security associations are not looked up by inspecting IP addresses, and thus, handovers without IPsec SA re-keying are supported. As for the support of flow mobility, the first version of an Internet Draft [17] has been recently proposed.

(11)

2.3.6 Flow mobility in MIPv4, MIPv6 and HIP

MIPv4, MIPv6 and HIP solutions were originally conceived to provide host mobility or “per-device” mobility. Quite recently they have started considering the need to separately handle each single application flow (“per-flow” mobility). In particular, as already mentioned in sections 2.3.1 and 2.3.5, MIPv6 has been extended with RFC 6089 [7] (became RFC in January 2011, work started in 2007), while Internet drafts are currently under discussion for MIPv4 ([12]) and HIP ([13]).

2.3.7 Per-application mobility

The need to transport different applications on different access technologies at the same time, and take separate handover decisions for each application has been identified and addressed in [14], [15].

In [14] a per-application mobility management platform was first proposed. The solution is based on address translations on the two endpoints, and it requires that both endpoints are “mobility-aware”. The interoperability with NATs is not discussed and the solution is evaluated by simulation, no real implementation is reported.

In [15], a per-application mobility management based on HIP (Host Identity Protocol) [10] has been proposed. This solution has only been simulated using a network simulator, and no real implementation has been developed.

2.3.8 Mobility Management in 3GPP LTE

The 3GPP has been considering the issue of seamless mobility in its work on the “System Architecture Evolution” (SAE) [18]. The SAE is the core network architecture of 3GPP “Long Term Evolution” (LTE) [19]. Good introductions to SAE can be found in the white papers [20][21]. The Evolved Packet Core (EPC) is the main component of the SAE. It is realized through four new elements: Serving Gateway (SG-W), Packet Data Network (PDN) Gateway (PGW), Mobility Management Entity (MME), Policy and Charging Rules Function (PCRF), as shown in Figure 1.

PDN GW SGW MME PCRF eNodeB

EPC - Evolved Packed Core IP channel

UE

e-UTRAN

Figure 1 Evolved Packet Core (EPC) main components

The node involved in performing the handovers between LTE and other non-3GPP technologies is the PDN-GW. The PDN GW provides connectivity to the UE to external packet data networks and it acts as the anchor for mobility between 3GPP and non-3GPP networks. The interfaces of PDN-GW towards different types of non-3GPP networks are shown in Figure 2 and are named S2a, S2b and S2c. Citing from [21]: “For handover between LTE and other non-3GPP technologies, PMIPv6 (Proxy Mobile IPv6) and client MIPv4 FA mode will be used over the S2a interface while PMIPv6 will be employed over

(12)

the S2b interface. DS-MIPv6 (Dual Stack MIPv6) is the preferred protocol over S2c interface.” EPC –Evolved Packet Core Trusted non 3GPP IP access Untrusted non 3GPP IP access INTERNET PDN GW ePDG UE e-UTRAN Trusted/Untrusted 3GPP/non 3GPP IP access

ePDG: Evolved Packet Data Gateway S2a

S2b S2c

Figure 2 PDN-GW interfaces towards non 3GPP networks

2.4 Discussion and comparison between UPMT, related works

and our ABC requirements

Rather than trying to patch existing solutions in order to fulfill the identified set of requirements, a new mobility management/multi-homing solution has been designed and implemented. In comparison with the above analyzed solutions, UPMT can provide ABC services fulfilling all the requirements listed in section 2.2. Some specific features of UPMT, which can differentiate UPMT from the other solutions are listed hereafter:

1. UPMT provides per-application independent mobility management and multi-homing.

2. UPMT does not require support in the access and transport networks and is fully and natively compatible with all existing NATs.

3. From the networking point of view, UPMT consists of standard and well supported building blocks that makes its implementation easy and can be implemented without requiring modification to the OS Kernel (a preliminary implementation of UPMT has been realized in user space for Linux OS). Note that in order to support legacy applications in a completely transparent way and in order to achieve optimal performances, the full-fledged Linux and Android UPMT implementation does modify the Kernel.

4. UPMT combines the benefits of centralized and distributed mobility management solutions. UPMT supports scenarios with a single AN and with multiple ANs used in parallel to support communication with legacy CHs. UPMT is also compatible with procedures to realize end-to-end mobility in case of communications with UPMT aware CHs (the definition and implementation of such end-to-end scenario is still ongoing).

5. Since UPMT makes use of a virtual interface, support for legacy application is complete. Moreover, there is no possible conflict between virtual IP addresses (“VIpAs”) and real IP addresses. In fact, UPMT forwarding and standard IP

(13)

forwarding are independent and they are performed after the IP packet is filtered on a per-application base, e.g. using “policy routing” features.

6. UPMT uses SIP as signaling message transport. UPMT benefits from this choice because of several standard SIP services that can be reused for UPMT. In particular, MH reachability can be provided through SIP Registration and message forwarding with SIP proxies.

7. UPMT is independent from the particular method for protecting both signaling and data traffic. Even though we will propose a security extension based on IPsec, UPMT is independent from it, and possible solutions based on other security mechanisms (e.g. the Datagram Transport Layer Security protocol - DTLS) can be envisioned.

8. The proposed overlay approach fully decouples the real mobile interfaces and the fixed virtual interface. UPMT stack is totally unaware of what happens in the underlying layers and therefore UPMT does not suffer from some limitations affecting other solutions. For example: (i) UPMT does not depend on any Layer 2 (L2) protocol; (ii) there is no need to intercept and forward ARP o ICMPv6 messages; (iii) the Anchor Node location is not topologically restricted within the home network; (iv) IPsec SAs are bound to virtual IP addresses (“VIpAs”) and never change.

2.4.1 Specific comparison of UPMT against MIPv4

UPMT operates at application level, while MIPv4 at network layer. Some differences worth mentioning are:

1. UPMT is natively NAT friendly without need for new protocol numbers, port registration, NAT extension. This is a direct consequence of the use of IP/UDP encapsulation. Anyway, it has to be noted that IP/UDP encapsulation introduces additional 8 bytes (the length of UDP header) of overhead with respect to MIPv4 (see Section 7.3 for a discussion on overhead of UPMT).

2. UPMT does not require a Foreign Agent (FA), while MIPv4 needs a FA in NATed networks to perform de-tunneling and to share the same (in many cases) unique public IP address among several Mobile Hosts (MHs). Since UPMT uses UDP encapsulation, as long as the tunneled traffic is initiated by the MH, and as long as the MH periodically refreshes the binding at the NAT/router, the MH is always reachable by the AN and it is indeed the other tunnel endpoint

3. The overlay approach fully decouples the "virtual layer" and the "physical layer", and thus UPMT is really "L2 agnostic". MIPv4 requires interaction with ARP, and for example, a MIPv4 Home Agent (HA) might need to proxy ARP messages on behalf of the MH and a MH has to disable ARP broadcasting within a Foreign Network.

4. UPMT and MIPv4 both suffer from triangular routing. Even though, in theory, MIPv4 suffers from triangular routing only in communications from CH to MH, reverse tunneling is often used to avoid Ingress Filtering, and triangular routing affects also packets from MH to CH. This problem is clearly unavoidable when a MH is communicating with a legacy CH, since a packet relay is placed in the path between the MH and the CH. Anyway, the tunneling approach of UPMT is ready to support an “end-to-end” approach where tunnels can be established between two mobile hosts, using the Anchor Nodes only as rendezvous/NAT traversal.

(14)

5. The MIPv4 HA location is topologically restricted within the MH’s home network. In the standard configuration MIPv4 does not allow for multiple HAs, and indeed, the HA represents the only bottleneck since it necessarily has to forward all packets between a MH and its Correspondent Hosts (CHs). UPMT is compatible with a multi AN scenario, i.e. multiple ANs can be used in parallel, and no cooperation between the ANs is needed. This feature results in a better scalability of UPMT against MIPv4 2.4.2 Discussion on HIP with respects to our ABC requirements

We have identified the following shortcomings of HIP with respect to our requirements. Even though a sort of “HIP proxy” can be introduced in communications between a MH and a totally unaware CH, a solution to support legacy CHs equivalent to UPMT CAM and DAM has not been defined so far.

Another limitation is the tight relation between HIP and IPsec. The current HIP architecture relies on IPsec and other transport mechanisms besides ESP are not specified. In order to solve a mobility and multi-homing issue, HIP requires IPsec, which may slowdown a possible large scale deployment. Indeed, not only IPsec base specifications are not fully implemented in all existing operating system, but HIP also requires support for a novel tunnel mode. In facts, HIP makes use of the Bound End to End Tunnel (BEET) which is still under standardization process. Furthermore, even on open sources OSs like Linux or FreeBSD, HIP implementation seems to be still unstable and incomplete. Moreover, when MHs are behind NATs, the standard traversal solution is UDP encapsulation, that is exactly the UPMT proposed tunneling approach.

Another aspect to be taken into account is the transparent support of legacy applications. Some of the possible solutions described in [16] are: virtual interfaces for server applications, local identifiers (in the form of IP addresses) statically bound to DNS names, modified DNS names, interception of DNS request, dynamically linkage of modified socket libraries. Anyway, some of the proposed solutions require ad-hoc countermeasures and can make legacy application support not trivial. Moreover, to fully benefit from HIP mobility and multi-homing solution, the HIP socket API has to be used.

2.4.3 UPMT per-application mobility vs. flow mobility

UPMT provides per-application mobility, i.e. applications flows are handled separately and handover can be performed independently. The capability to separately handle each flow, referred to as “flow binding” or “flow mobility”, has been recently considered by MIPv6, MIPv4 and HIP mobility management solutions, as described in Section 2.3.

We want to note that capability to perform “flow binding” / “flow mobility” is needed to realize to realize application mobility, but it may be not sufficient to offer per-application mobility under the requirements that we have considered for ABC services (i.e. considering the requirement to support legacy applications). In facts, applications flows need to be classified and associated to some kind of local policies that binds the transmitting process to the outgoing interface. As thoroughly described in Section 6.3, the management of application flows is not a trivial problem in case of mobility unaware applications and it involves aspects related to the operating system and to the networking stack implementation.

(15)

2.4.4 UPMT vs. 3GPP LTE mobility management

The mobility management solution envisaged in 3GPP LTE is based on MIPv6, so it depends on the deployment of MIPv6 in the LTE network but also in other non-LTE networks which can be used to handover. The role of the LTE/SAE PDN-GW is similar to the role of the AN in the UPMT proposal.

The UPMT AN does not depend on MIPv6, so it can be considered as a short-medium term alternative for mobility management. UPMT operates as an overlay on top of plain IP networks. An operator willing to offer a pre-LTE mobility solution can do it with UPMT using existing networks.

(16)

3. UPMT Basic Solution

3.1 Networking architecture

The proposed architecture is depicted in Figure 3. The MH is equipped with two (or more) interfaces connected through different access networks. Each interface has an IP address which may be either public or private. The MH will establish one tunnel to the AN for each interface that it may want to use for sending and receiving data. The data to any Correspondent Host (CH) is encapsulated and sent to the AN on one of the tunnels, likewise the data coming from any CH is sent by the AN on one of the tunnels. In the solution discussed in this document, the encapsulation performed at the MH and the AN is UDP/IP encapsulation (see section 3.1.2 for details).

Mobile Host (MH) Correspondent Host (CH) Anchor Node (AN) NAT 1 NAT 2 Anchor NAT IP/UDP Tunnel 2 IP/UDP Tunnel 1

Figure 3 High level network architecture

The internal architecture of the MH is depicted in Figure 4. The Forwarding Agent will handle all the packets sent by the applications running on top of the Mobility Management

(17)

Client (MMC). The interface between applications and the TFA can be either a virtual IP interface in case of legacy applications or the UPMT socket API in case of UPMT aware.

The TFA forwards the data packets on the proper tunnel according to the Per-Application Forwarding Table (PAFT). This forwarding is based on the source and destination IP addresses and TCP/UDP ports. In practice the PAFT maps an application flow into a tunnel (app-flow -> TID) with app-flow = (proto, IP.src, IP.dst, L4.sport, L4.dport), where “proto” is the transport protocol (UDP or TCP), “IP.src” and “IP.dst” are the IP source and destination addresses and “L4.sport” and “L4.dport” are the transport source and destination ports.

Inside the tunnels, the MH uses a Virtual IP Address that is assigned to it by the Anchor Node and is never affected by any IP readdressing of the underlying real network interfaces. In other words, since the IP stack of the real NICs used to transmit/receive packets is hidden to the local applications, an arbitrary number of NICs can be used in parallel (multihoming) and can seamlessly roam from different access networks (mobility) without affecting any active application sessions. The building of the PAFT is a critical aspect: it is easy for UPMT aware applications that will explicitly open the sockets through the UPMT socket API, while we need to introduce a socket identification and classification mechanism for legacy applications. This is realized by a module in kernel space that associates packets to the process IDs of the applications.

The Tunnel Manager performs all the operations to establish, update, refresh and destroy the UDP tunnels between each active interface of the MH and the AN.

Figure 4 Networking architecture of Mobile Host and Anchor Node

In the proposed architecture the AN (see Figure 4), has a threefold role:

• the AN acts as a tunnel broker for the MH. During the association procedure, a VIPA is assigned to the MH. This VIPA identifies the MH at the AN regardless of the particular tunnel through which the traffic is received. Each tunnel is univocally identified by the AN by the tunnel ID couple defined as TID = (IP source address, UDP source port). We call it source address and source port because they are the address and port of the incoming UDP packets (i.e. received by the AN) that “opens” the tunnel. The AN will send back packets on this tunnel with IP destination

(18)

address = received IP source address and UDP destination port = received source UDP port, in order to exploit the “symmetric” NAT traversal approach. Note that when the tunnel crosses a NAT, the IP source address and UDP source port of the packet received by the AN will be the NATed ones. In order to keep the pin-hole open in the NAT, a keep-alive mechanism handled by the client will be used, similar to the one defined in RFC 3948 [32].

• the AN acts as the anchor point for the MH. All the tunnelled packets from MH to CH are decapsulated and forwarded by the AN. The associations between application data flows and the tunnel from which they are received are kept at the AN in the per-Application Forwarding Table (PAFT). The PAFT is used by the AN to route packets coming from CH and destined to MH and its structure in the Mobile Management Server (MMS) is identical to the MMC, as it maps application flows into TIDs.

• the AN performs standard NAT operations on all packets tunnelled by the MH. In particular, after the packet is decapsulated, the virtual address assigned to the MH, which is the IP source address of the packets sent by the MH, is replaced with a public addresses of the Anchor NAT.

3.1.1 Detailed Tunnelling/NAT Operations

In this section we provide a detailed example of tunneling and NAT operations taking into account the scenario depicted in Figure 5. The MH is equipped with two interfaces IF0 and IF1 connected to two different access networks.

Figure 5 Example scenario with IP addressing

Both interfaces have private IP addresses, respectively if0 = 192.168.100.25 and if1 = 10.10.10.25. Both interfaces are connected through a default gateway/NAT with public IP addresses, respectively gw0 = 160.80.100.1 gw1 = 65.0.0.1. The AN has public IP address 45.0.0.1 and the CH is a legacy UDP server with IP address ch0 86.0.0.1. and listening port 3000. The Virtual IP Address assigned by the AN to the MH in the association procedure is vipa0 = 1.2.3.4. The MH has setup two tunnels (referred to as t0 and t1) respectively on the interfaces if0 and if1. The tunnels IDs are tid0 and tid1. The source ports respectively for tid0 and tid1: for the MN 1500 and 1600; for the AN 33000 and 34000. The destination port for both tunnels is 1800.

(19)

Figure 6 shows a generic exchange of two UDP packets between MH and CH. Assume that a legacy application running on the MH sends a UDP packet PCK1 with source port 2000 and destination port 3000, IP source address vipa0 and IP destination address ch0 86.0.0.1, through the virtual interface vif0. This packet is handled by the local Tunnel Forwarding Agent and, according to the local PAFT is forwarded to the AN on tunnel t0. The outer IP/UDP header is formed according to the parameters of tunnel t0.

Figure 6 Basic operations for data exchange

The AN, upon receipt of PCK1, updates the PAFT by inserting the following forwarding rule:

1.2.3.4 ,ch0, 2000; 3000 (UDP), tid0

PCK1 is then processed by the NAT module as follows: (i) the virtual IP source address 1.2.3.4 is replaced with the public address an0 45.0.0.1; (ii) the UDP source port 2000 is replaced with port 40000 chosen by the NAT; (iii) the mapping is stored in the NAT table. Note that all operations performed by the NAT are standard symmetric address and port translations, and no NAT extensions are required. PCK1 is then forwarded to CH

In response to PCK1, CH sends a UDP packet PCK2 with destination IP address an0 and destination UDP port 40000. Upon receipt of PCK2, the AN restores the NAT mapping by replacing: (i) IP destination address an0 with the virtual address 1.2.3.4; (ii) UDP destination port 40000 with 2000.

PCK2 is finally intercepted by the AN Tunnel Forwarding Agent, encapsulated and forwarded back to MH through the proper tunnel t0 according to the specific PAFT entry. 3.1.2 Considerations about IP in UDP tunneling and virtual interfaces

Figure 7 shows the IP in UDP tunneling approach on which UPMT is based. We named the external header as Tunnel header and the encapsulated header (i.e.: the IP header of the application packets sent by the Mobile Host) as Original header.

(20)

• the source IP address is the address of the MH physical interface from which the tunnel is initiated. Most likely, this address is changed by the NAT placed in the access network.

• the destination IP address is the public address of the anchor node.

• the UDP source port is a random port associated to the specific tunnel with the AN. Most likely, this port is changed by the NAT placed in the access network.

• The UDP destination port is the UPMT AN listening port, i.e.: the UDP port on which the AN is listening for tunneled packets.

Figure 7 IP in UDP encapsulation

The Original header is not modified by the UPMT stack and has the Virtual IP address as source IP address, and the CH IP address as destination IP address.

As briefly stated in the previous sections, the mobility service is provided by the tunneling mechanism itself. Indeed, since the Tunnel header can change arbitrarily, the application sessions are never affected by IP readdressing of the physical NICs, as long as one active tunnel can be used within the application or transport timeout (e.g.: TCP timeout). In the same way, since multiple tunnel can be used in parallel for different applications, or even for different flows belonging to the same application, multi-homing is provided.

How mobility and multi-homing is provided is clear, but how can applications be forced to use the Virtual IP address assigned by the AN without modifying them? The idea is to use a virtual interface and force applications to use this interface by modifying the local IP routing configuration (all the details will be given in Section 6). The Virtual interface acts as an abstraction layer that hides all the real physical interfaces so that any possible IP reconfiguration and connectivity loss is hidden to the applications sockets.

3.1.2.a. Why IP in UDP tunneling?

The choice of using IP in UDP encapsulation can be motivated by the following considerations:

1. It provides native protocol independent NAT traversal without requiring new protocol number, port reservation and new protocol design.

2. It provides tunnel multiplexing from the same source address1 with less overhead with respect to other solutions. In particular, let us consider Generic Routing Encapsulation protocol. This tunneling mechanism would requires the KEY option to multiplex different tunnels from the same source address. The resulting overhead for IP+GRE would be 20 + 12 bytes against the 20 + 8 bytes of UDP.

3. It can be easily implemented, even in user space with standard UDP sockets.

1

(21)

4. It is the standard NAT traversal mechanism for IPsec, which can be used to protect tunneled traffic (see S-UPMT, section 5). Moreover, UPMT introduces less overhead then HIP in most of the cases. Indeed, if we consider the most likely scenario of MHs behind NATs, HIP would require the standard ESP NAT traversal mechanisms, which is IP/UDP encapsulation. Again, the resulting overhead would be greater than UPMT. For further details see Section 7.3.

3.2 UPMT functional architecture

Figure 8 provides a simplified representation of the proposed UPMT functional architecture in a mobile host.

A Decision engine module takes decisions considering a set of inputs. The first input to the Decision engine comes from the Classification of flows and applications module. The Interfaces/networks manager module continuously informs the Decision engine on what interfaces are available. Optionally, Quality of Service/Quality of Experience measurements module can gather measurements and report them to the decision engine. Finally, the decision is taken considering a set of Policies. A Graphical User Interface may allow the user to set the policies and to check the status of the system. The output of the Decision engine is used to drive the Mobility Management mechanisms (i.e. the UPMT networking solution partially described in this section) to route the packets on the chosen interface and to perform per-application independent handovers.

Mobility management mechanisms QoS/QoE measurements Interfaces/networks manager Classification of

flows and applications

Policies

Decision engine

Graphical User Interface

Figure 8: ABC modules in the Mobile Host

Let us now discuss the issue of how to identify the flows related to a given application, so that it is possible to route them over a specific network interface according to the ABC policies. The first important design choice is if we want to consider applications that are aware of the ABC services offered by the Operating System or if we want to consider “legacy” applications that are not aware of this advanced network service and will behave as if they are talking over a single network interface. In the former case (ABC aware applications) the applications may take specific actions to drive the interface selection process or at least they can react to input from the mobility management modules in order for example to send a flow using different source and/or destination addresses/ports. In the latter case (legacy application) the application will manage its flows using the “traditional” IP sockets and cannot tolerate any change in the perceived addresses/ports.

(22)

While the identification of IP flows generated by ABC aware application could be trivial, the case of legacy application needs to be discussed. A given application flow can be univocally identified by the IP parameters of the incoming/outgoing packets (protocol, IP src, IP dst, Layer 4 source port, Layer 4 destination port) received/sent by the related application socket. In general, an application will use several flows, each one identified as above. The critical aspect for the support of legacy application is that we cannot classify “a posteriori” a flow as belonging to a given application, but we need to route the flow over a chosen interface since the very first packet of the flow. A non-optimal solution is to use destination IP addresses and/or ports to perform this classification. The disadvantage is that the destination IP address and/or ports need to be known in advance. This is only suited to the support of rather static scenarios where the end-points of the communications are fixed, and can be seen as a “primitive” form of per-application mobility management. On the other hand we want to identify the packets as belonging to a given application without any constraint on the destination IP addresses/ports. In order to support our vision, the classification module needs to provide: (i) efficient association of each IP packet with the process that transmitted it; (ii) asynchronous notifications of every newly created TCP or UDP flow in order to take proper decision before forwarding the packet. The second feature is already provided by the Linux kernel (conntrack module), while in order to achieve the first feature we added a process identifier to the kernel data structure that contains a packet (details will be shown in Section 6).

The Interfaces/networks manager module monitors which interfaces are active and retrieves their IP configuration parameters (e.g. the default gateway of each interface). It follows interface state getting asynchronous notifications of interface disconnections or IP re-addressing. It provides input to the Decision engine module, which applies the decision policies as described in section 6.3.2.b. .The implementation of the Interfaces/networks manager module is dependent on the mobile host Operating System. In our Linux based implementation we started from existing tools (see section 6.2.2.b. ).

The QoS/QoE measurement module provides “per-application” independent active and passive monitoring of the QoS and QoE parameters. It has a special role in a user centric decision making process, since it allows to take into account the perceived quality of each active application. This will lead to more complex policies (i.e. from availability-based policies to measurement-based policies, see section 6.3.2). Currently, this module has not yet been integrated in our UPMT platform.

The Decision engine module works on the base of “Decision policies” (see section 6.3.2.b. ). It allows the mobile host to take mobility management decision. This is a “device-centric” / “user centric” approach as opposed to “network centric” / “operator centric” approaches, where the mobility management decision are taken by the network / by the operator. Nevertheless, this not precludes using UPMT in operator centric business scenarios for ABC services.

3.3 Procedures and information flows

In this section, we first identify and describe at a logical level the four procedures and the associated information flows between the Mobile Host and the Anchor Node. An example sequence diagram is reported in Figure 9, while Table 1 shows the set of messages and their parameters. In section 3.4 we present the proposed mapping into protocols which has been realized in our test-bed.

Association procedure - In order to associate with the MMS, the MMC sends an Association request message. The purpose of this message is initially to receive a virtual

(23)

IP address (VIPA) in the Association response message from the MMS. The association is a soft state and it has to be refreshed with periodic Association request messages. The refresh Association request messages include the already assigned VIPA. The Association request messages can be subject to authentication by the MMS, in this case the procedure could change from a two-way handshaking to a four-way handshaking as the MMS may need to send some challenge to the MMC.

Figure 9 A sample temporal diagram showing a set of information flows

Tunnel establishment - As for the tunnel establishment, we considered two solutions. It is possible to have an “opportunistic” approach where tunnels are simply created by sending the first packet on the tunnel. The second option is to use some form of explicit signaling at the establishment of the tunnel, with a Tunnel Setup request message. Explicit signaling can be used to support some form of authentication (e.g. to accept tunnels only from authorized MMC) Using explicit signaling it is possible to agree on an identifier for the tunnel, shared between the MMC and the MMS. This type of explicit signaling could be realized in several different ways: i) piggyback information on the data packets, for example by reserving a signaling field at the beginning of the UDP payload, just before the tunnelled IP packet; ii) have a similar signaling field to distinguish between tunnel packets carrying a tunnelled IP packet and signaling packets; iii) just to use a tunnelled IP packed with destination IP corresponding to the MMS and destination UDP port directed to a process in the MMS that handles this signaling.

Handover Request - A Handover request message is used to switch a set of flows from one interface to another. The handover request message includes a list of flows and for each flow the target tunnel ID on which the flows needs to be handed off. If the request message is transmitted over a tunnel the target tunnel ID can be omitted for a flow and it

(24)

means that the flow will be switched on the tunnel on which the Handover request message is received. This is the only option if there is no signaling to propagate the tunnel ID back to the MMC during the tunnel setup. A handover request message can be sent while the previous tunnel of the handed over flows is still active, thus supporting the so called “make before break” handover and minimizing the impairments. The Handover request can also be sent as a result of a sudden break of the connection supporting the previous tunnel. In this case, if the new tunnel is not yet active, the setup of the new tunnel and the handover request should ideally be performed at the same time in order to minimize the impairments.

Data transfer - The DATA messages correspond to the tunnel packets that carry the tunnelled IP packet (which can be TCP or UDP or even a different protocol if the MMC NAT is able to handle them). The tunnelled IP packet extracted from the DATA message automatically triggers the association of the corresponding flow in the PAFT (flow/tunnel association table). This process resembles the “learning” process of a NAT box. If needed, DATA messages could be authenticated and/or encrypted using various techniques.

Association request (VIPA) Note that VIPA is missing in the

initial association

Association response (VIPA) This message is sent using the

same UDP socket of the tunnel

Tunnel setup request ()

Tunnel setup response (tunnel ID) This message is sent using

the same UDP socket of the tunnel

Handover request ({[flow ID, tunnel ID]}) This message is sent

on the same UDP socket of the tunnel. Therefore the tunnel ID can be omitted and (if omitted) implicitly derived from the received UDP port number/IP address. Note that a set of couples [flow ID, tunnel ID] can be transported in one single handover request message

Table 1 Messages and their Parameters

Keep alive - Periodic Keep Alive messages are needed for each setup tunnel, in order to keep the NAT pin-holes open. As a rough estimate, the Keep Alive period can be in the order of tens of second. As we have a number of tunnels equivalent to the number of interfaces, this will not be a concern. The solutions to support the keep alive procedure can be borrowed from the ones discussed above for the Tunnel Establishment. Actually using a combined solution for keep alive and tunnels establishment could result in higher efficiency (or at list in a simpler architecture).

3.4 Mapping of the Information Flows into SIP

In this section we provide the proposed mapping of the information flows discussed in section 3.2 into SIP protocol messages. In principle, different protocols can be used to support the UPMT procedures, we used the SIP protocol because its features match very well the UPMT need as for its facility of extension and implementation.

All UPMT messages are mapped into the SIP MESSAGE method. This method is used to exchange arbitrary information between two SIP entities, without setting up a session and is able to deal with retransmissions due to packet losses.

In order to support UPMT we added a new header to carry the Virtual IP Address, called “VIpAddr”. The addition of this new header is not a problem, as the SIP messages with the new header needs will only be exchanged between our MMC and our MMS. The “VIpAddr”

(25)

header is carried in the MESSAGE transporting the Association Request; this MESSAGE is sent outside the tunnels.

Note that all the SIP response messages (the 200 OK messages in the figure) will follow the same path than the corresponding request messages. Therefore the 200 OK response message to the MESSAGE carrying the Association Request will be delivered outside the tunnels. All other 200 OK messages are carried back within the same tunnel of the corresponding request message.

Figure 10 Protocol messages

In the case of Tunnel Setup and Handover Request, we preferred not to define new SIP headers. Rather, the needed information is transported within the body of the MESSAGE, as plain text using JSON. Both the Tunnel Establishment and the Handover Request MESSAGEs are sent inside the tunnels (as the corresponding 200 OK messages). The two procedures can be combined into a single one when it is needed to open a new tunnel and handover a set of the flows on it (e.g. after the sudden failure of an active interface).

Figure 10 reports the same scenario considered in Figure 9 with the protocol messages names. The (partial) content of the SIP messages is shown in Figure 11.

(26)

M1: Association Request – MMC to MMS

REGISTER sip:45.0.0.1 SIP/2.0

Via: SIP/2.0/UDP 192.168.100.25; branch=z9h; TID=Terminal_ID; rport; To: <Terminal_ID>

From: <Terminal_ID>;tag=dba Contact: <sip:Terminal_ID>

MESSAGE sip:45.0.0.1 SIP/2.0

Via: SIP/2.0/UDP 192.168.100.25; branch=z9h; TID=Terminal_ID; rport; To: <sip:45.0.0.1> From: <Terminal_ID>;tag=dba Contact: <sip:Terminal_ID> Content-Length: xx Content-Type: application/text {“mType”:“TunnelSetupReq”,“tunnelType”:“IPinUDP”} M2: Association Response 200 OK – MMS to MMC

M3: Tunnel Setup Request – MMC to MMS

SIP/2.0 200 OK

Via: SIP/2.0/UDP 192.168.100.25; TID=Terminal_ID;received=160.80.100.1 To:< Terminal_ID >

From:< Terminal_ID>; tag=dba VIpAddr:1.2.3.4

Via: SIP/2.0/UDP 192.168.100.25; branch=z9h; TID=Terminal_ID; rport; To: <sip:45.0.0.1> From: <Terminal_ID>;tag=dba Contact: <sip:Terminal_ID> Content-Length: xx Content-Type: application/text {“mType”:“TunnelSetupRes”,“result”:“200 OK”, “tunnelType” : “IPinUDP”, “netTunnelID”:“13673865”}

M4: Tunnel Setup Response – MMS to MMC

M5: Handover Request – MMC to MMS

Via: SIP/2.0/UDP 192.168.100.25; branch=z9h; TID=Terminal_ID; rport; To: <sip:45.0.0.1> From: <Terminal_ID>;tag=dba Contact: <sip:Terminal_ID> Content-Length: xx Content-Type: application/text {“mType”:”HandoverRequest”,

"match":{"syntax":"IPtables", "match":"-p tcp –destination 160.80.81.1 – destinaton-port 80"},

"tunnelID":[“13673865”,"any"] }

(27)

4. UPMT – Scalability Extensions

In the previous section we proposed UPMT, a mobility management solution that provides are the “per-application” handover and the full compatibility with legacy applications, legacy hosts and existing networking infrastructure. A critical issue of the existing proposal is the scalability, as the specification foresee a single Anchor Node (AN) handling the mobility management signalling procedure and acting as “tunnel server” for decapsulation and packet relaying to/from MH/CH. In this section we propose to enhance the basic UPMT solution by defining the UPMT-Distributed AN Mode (DAM).

UPMT-DAM should: 1) provide the means for a MH to use different Access Nodes as needed to distribute load and to optimize performance (e.g. by choosing where possible an AN in the path between the Mobile Host and the Correspondent Host); 2) allow a “fixed” Correspondent Host to play the role of Anchor Node; 3) allow direct communication between Mobile Host bypassing Anchor Nodes whenever possible (the AN would be used as rendezvous point for signalling and to assist in the setup of end-to-end data tunnels). In other words, the idea is that AN used as packet relay should be used only if strictly necessary, i.e. (i) in communications with legacy Correspondent Hosts, (ii) in communications between UPMT aware MHs where at least one MH is behind a “bad” NAT.

As shown in Figure 12 (left), a Mobile Host can be connected using several different access networks, most of which will provide private IP addresses and uses NATs to interwork with the Internet. In the basic UPMT solution (Centralized Ancor Node Mode - CAM), the MH connects to an Anchor Node using IP in UDP tunnels, one per each access network. The MH uses a “Virtual IP Address” VIpA that is assigned to it by the Anchor Node. The Anchor Node provides a “second level” NAT to the Mobile Host, allowing the host to access to the Internet using a public IP address provided by the Anchor Node. The forwarding and tunnelling of packets in the Mobile Host and in the Anchor Node is regulated by a table called “Per Application Forwarding Table” (PAFT), which is able to associate a “socket” to the tunnel used to send packets from the MH to the AN and vice versa.

The UPMT-DAM approach proposed in this paper considers three scenarios for the “distribution” the functionality that was centralized in the basic UPMT solution: 1) Multi-ANs scenario (multiAN) in which MHs can use different ANs in parallel for communication with legacy CHs; 2) MH-to-FH end-to-end scenario (mh2fh) in which UPMT aware mobile hosts (MH) and fixed hosts (FH) communicate directly with each others without necessarily relying on ANs for packet forwarding; 3) MH-to-MH end-to-end scenario (mh2mh) in which

(28)

MHs communicate directly with each others without necessarily relying on ANs for packet forwarding and use different ANs. The multiAN and the mh2fh scenarios are depicted in Figure 12 (right), which shows three tunnels setup between the MH and the AN with solid lines. The MH could switch the tunnels to a second Anchor Node or directly to a Fixed Correspondent Host (tunnels drawn with dashed lines). Mh2mh scenario is depicted in the bottom of Figure 12. Mobile Host (MH) AN1 AN2 AN3 CH1 CH5 Public Internet Anchor Node (AN) Local NAT CH NAT CH2 CH3 CH4 Local NAT Anchor NAT CH NAT Mobile Host (MH) AN1 AN2 (public IPs) AN3 Fixed Host 1 Public Internet Anchor Node (AN) Local NAT Local NAT Anchor NAT Anchor Node (AN) 2

UPMT-CAM UPMT-DAM: multiAN & mh2fh

Mobile Host (MH-L) Access Net L Public Internet Anchor Node (AN) L Local NAT-L Local NAT-R AN-NAT STUN server R SIP Proxy L SIP Proxy R STUN server L Mobile Host (MH-R) UPMT-DAM mh2mh

Figure 12: UPMT Scenarios

4.1 The VIpA Assignment Issue

In the UMPT-CAM solution all traffic for a given Mobile Host is relayed by a single Anchor Node. The Anchor Node assigns the MH a VIpA during the Association Request phase. For the AN, every MH in the UPMT overlay network is univocally identified by a VIpA and thus every inner IP packet carries all the information required to be correctly forwarded without inspecting the external IP/UDP header (the tunnelling approach is shown in Figure 13).

Figure 13: IP in UDP tunneling

In UMPT-DAM, we introduce a set of Anchor Nodes and allow direct communication between MH and UPTM aware Fixed Hosts and among MHs. If we want to keep the hypothesis of a bi-univocal association between a MH and a VIpA, we need to assign it in a coordinated way among the tunnel servers (multi AN, FHs or MHs). The VIpA