You are on page 1of 39

UPMT Universal Per-application Mobility management using Tunnels

Stefano Salsano - Marco Bonola -

Always best connected (ABC)

ABC service concept: automatic selection of the best interface in the mobile device Dates back to the early 2000, but turning ABC services into reality is still a challenge:
Need to change networking equipment, existing applications, networking stacks ? True ABC services require per-application mobility, typical solutions offers per-device mobility

3G offload renews interest in ABC concept

Page 2

UPMT: Universal Per-application Mobility management using Tunnels

Key features
per-application independent management of connectivity (even per-flow) works on existing networks supports private IP networks / NAT works with ALL existing applications no changes in the correspondent hosts

implemented on Linux and Android platforms

Page 3

The problem space for ABC services

IP level Measurements Link level measurements Cost, Security Reputation, Location based

Legacy applications Mobility-aware applications

OS related aspects

Decision policies

Per-application mobility Always Best Connected Per device mobility

(ABC) services Mobility Management

Choice of Mobility Layer: Layer 2 / Network / Shim / Transport / Application

Business scenarios
Operator centric User centric Corporate net. centric Aggregator centric Over-the-top prov. centric
Page 4

Other solutions
None of the existing solutions fully satisfies ABC requirements
Mobile IPv4 Mobile IPv6 Proxy Mobile IP v4|v6 SIP based mobility Host Identity Protocol

Page 5

Basic principles of UPMT

(see figure in next slide)

IP in UDP tunnels from the Mobile Host to the Anchor Node, one tunnel for interface The Anchor Node provides a second level NAT, the Correspondent Hosts are unaware of UPMT Each application can be independently sent over one of the tunnels The applications see a Virtual Interface, they are shielded from any mobility/handover issue and from loss of connectivity on the physical interfaces SIP protocol is used for mobility management signaling between Mobile Host and Anchor Node
Page 6

Basic principles of UPMT

Anchor Node second level Correspondent (AN) NAT Host (CH) IP/UDP Tunnel 1 first level NAT NAT 1

Public Internet

Virtual Interface


IP/UDP Tunnel 2

Mobile Host (MH)

Access Networks
Page 7

UPMT scalability
The basic scenario foresees a centralized Anchor Node
Anchor Node (AN) Corresp. Host Anchor NAT

Local NAT

Public Internet

AN3 AN2 (public IPs) Local NAT


Mobile Host (MH) Page 8

UPMT scalability
Multiple Anchor Nodes can be supported
Anchor Node (AN) 2 Anchor Node (AN) Corresp. Host Corresp. Host Anchor NAT

Local NAT

Public Internet

AN3 AN2 (public IPs) Local NAT


Mobile Host (MH) Page 9

UPMT scalability
A fixed host with UPMT modules can play the role of the Anchor Node !
Anchor Node (AN) Anchor NAT

Local NAT

Public Internet

Fixed Host, e.g. for example:

AN3 AN2 (public IPs) Local NAT


and other over-the-top providers

Mobile Host (MH) Page 10

UPMT scalability
Direct Mobile Host to Mobile Host communication
Anchor Node (AN)

Local NAT

Public Internet

AN3 AN2 (public IPs) Local NAT MH NAT


Mobile Host (MH) Mobile Host (MH) Page 11

UPMT scalability
All together
Anchor Node (AN) 2 Anchor Node (AN) Corresp. Host Anchor NAT

Local NAT

Fixed Host Public Internet

AN3 AN2 (public IPs) Local NAT MH NAT


Mobile Host (MH) Mobile Host (MH) Page 12

IP in UDP tunneling






Tunnel header IP src: real_iface_addr IP dest: AN_addr

Original header IP src: virtual iface IP dst: CH_addr

Protocol independent native NAT traversal Overhead and tunnel multiplexing (with respect to GRE, IPinIP)) Simple user-space implementation is possible

Page 13

UPMT Virtual interface


Virtual interface

Physical IP addresses

IP x

IP y

IP z




Physical interfaces

Virtual interfaces hide IP reconfiguration and connectivity loss of underlying NIC Legacy application see a standard interface, the encapsulation and mobility management is completely hidden
Page 14

Virtual IP addresses
Local Virtual IP address local-VIPA Virtual IP address assigned by the AN

pau-VIPA (Per Association Unique)

Virtual interface

Physical IP addresses

IP x

IP y

IP z




Physical interfaces

The packet will undergo one internal NAT from the local-VIPA to the pau-VIPA assigned by the Anchor Node

Page 15

SIP based signaling

M1: Association Request Register MMC to MMS
REGISTER sip: SIP/2.0 Via: SIP/2.0/UDP; branch=z9h; TID=Terminal_ID; rport; To: <Terminal_ID> From: <Terminal_ID>;tag=dba Contact: <sip:Terminal_ID>

M2: Association Response 200 OK MMS to MMC

SIP/2.0 200 OK Via: SIP/2.0/UDP; TID=Terminal_ID;received= To:< Terminal_ID > From:< Terminal_ID>; tag=dba VIpAddr:

M3: Handover Request MMC to MMS

MESSAGE sip: SIP/2.0 Via: SIP/2.0/UDP; branch=z9h; TID=Terminal_ID; rport; To: <sip:> 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 destinaton-port 80"}, "tunnelID":[13673865,"any"]}

Page 16

Security: S-UPMT
Signaling protection MANDATORY PKI, TLS Data protection OPTIONAL IPSEC
Optional IPSEC, otherwise like HIP what about IPSEC NAT traversal?

What happens after an unpredictable handover (break-before-make)? Need for TLS channel complete re-establishment?
Cant do otherwise: the IP has changed, the socket has been closed..

Need for IPSEC SAs re-establishment?

Complete re-negotiation? MOBIKEv2?
Page 17

S-UPMT: Signaling protection

TLS authentication VIPA exchange IPSEC indication

PHASE 2 (IPSEC supported)

IPSEC SA negotiation inside TLS channel SA bound to VIpAs. See later on.. Signaling protected by IPSEC Data protection by IPSEC


New TLS (TUNNELED) channel Signaling protected by TLS No data protection
Page 18

S-UPMT: IPSEC data protection

IPSEC is applied independently from UDP encapsulation IPSEC SAs are bound to VIpAs that never change NO need for SA re-establishment (like HIP, but we dont require new stack)
Page 19

UPMT-S: Data protection

IPSEC Tunnel mode for MH-AN

UPMT compressed header

IPSEC Transport mode for end2end

Page 20

UPMT modules in a Mobile Host

Graphical User Interface


Classification of flows and applications

Decision engine

Mobility management mechanisms

Interfaces/networks manager

QoS/QoE measurements
Page 21

Classification of flows/applications

A flow is identified by the 5-tuple: (protocol, IP src, IP dst, Layer 4 source port, Layer 4 destination port) The complete 5-tuple is generally known after that a flow is started, but we need to intercept the flow from the very first packet We enhanced Linux kernel so that process IDs are (internally) carried together with the packets

Page 22

Implementation architecture
Tunneling and Connection Tracker in Kernel space
virtual network device per-application forwarding Hash Table NETFILTER integration (input packet hook, conn-track target) Policy Routing integration (pre-filter hook for routing exception)

Kernel module configuration tool UPMTCONF based on NETLINK socket UPMT Control Entity (java) UPMT Signaling Network Monitor (integration with network-manager and DBUS) Application Monitor Our kernel space implementation does not imply new IP stack, nor new APIs toward the application easy user-space implementation
Page 23

Implementation architecture (MH side)

UCE UCE GUI GUI local socket Conn-Tracker Conn-Tracker Proxy Proxy Application Application Monitor Monitor Signaling Signaling Agent Agent Interface function call
UPMT UPMT module module External External module module

UPMT Control UPMT Control Entity Entity JNI


NETLINK socket

UPMT UPMT Configuration Configuration Tool Tool NETLINK socket

Network Network Manager Manager

User Space Kernel

UPMT UPMT Connection Connection Tracker Tracker

Exception Exception filter filter

UPMT UPMT Tunneling Tunneling

Page 24

UPMT packet flow (OUTPUT)

packet from application NOT under UPMT control packet from application under UPMT control Internal signaling and function calls

Page 25


Page 25

UPMT packet flow (INPUT)

Page 26


Page 26

Policies: some examples

Never run bulk transfer applications on expensive and/or resource-limited access nets. When connected as a guest to a wifi that only provide web access, use the wifi only for the browser. For a voice call, use wifi if the quality is OK, move to 3G if the quality on wifi is bad AND the quality on 3G is better.
Page 27

Policies: configuration language

***IP BASED POLICIES*** static wifi0 noUPMT -AN= default ***APPLICATION POLICIES*** application1 noUPMT application2 default firefox priorityList eth0 wifi0 ppp0 any skype static wifi0 ssh priorityList eth+ wifi0 ppp0 application3 priorityList wifi0:ssid=wifi-campus application4 priorityList eth1 wifi+:ssid=!wifi-campus ppp0:apn! application5 myPolicy application6 myPolicy application7 myPolicy ***DEFINION OF USER POLICIES*** myPolicy priorityList eth+ wifi+ ***DEFINION OF SYSTEM POLICIES*** default static any upmtSignalling default
Page 28

Two types of Policies

Interface Availability based policies

Only needs to know up/down status of interfaces and IP configuration parameters Currently supported

Measurement based policies

Link level measurements, IP level measurements / QoE measurements Currently NOT supported (work in progress!)

Page 29

Business scenarios
UPMT can be used in different business scenarios:
Operator centric User centric Corporate Net. centric Aggregator centric Over-the-top Prov. centric

Page 30

GUIs for policies and monitoring

Page 31

User level performances

Page 32

System level performances

MH - Mobile Host

AN Anchor Node



Page 33

Linux and Android implementation

The UPMT implementation is open source

Tunneling and flow classification are implemented in kernel space for performance/scalability
A UPMT Live distribution for Linux is available, it can be configured to be a Mobile Host or an Anchor Node Porting on Android (2.2 Platform), Nexus one terminal
Kernel modules ported, patch for multiple interfaces

Page 34

Work in progress

QoS/QoE measurement based handover

Estimation of available bandwidth and delay MUPPET : Multi Parameter IP Performance Evaluation Tool

End-to-end mobility management (from mobile host to mobile host with no relay on the Anchor Node if possible) Control GUI on Android APIs for UPMT aware applications Header compression mechanisms
Page 35

Take home message

To the best of our knowledge, UPMT is the only implemented solution that provides:
per-application handover support of all legacy applications overlay approach with no support from routers and access network support of NAT support of legacy correspondent host

moreover, it is open source

Page 36

M. Bonola, S. Salsano, A. Polidoro, UPMT: Universal PerApplication Mobility Management using Tunnels, IEEE GLOBECOM 2009 M. Bonola, S. Salsano, Achieving Scalability in the UPMT Mobility Management Solution, Future Network & Mobile Summit 2010, 16 18 June 2010, Florence, Italy. M. Bonola, S. Salsano, Per-application Mobility Management: Performance Evaluation of the UPMT Solution, IWCMC 2011, Istanbul, Turkey, July 2011 S. Salsano, M. Bonola, The UPMT solution, technical report,
Page 37

Work in progress

S. Salsano, M. Bonola, A. Gambitta, A. Bianchi UPMT: PerApplication Mobility Management in Mobile Broadband Networks, submitted to Communication Magazine special issue on Traffic Management for Mobile Broadband Networks M. Bonola, S. Salsano, S-UPMT: a secure Vertical Handover solution based on IP in UDP tunneling and IPsec, to be submitted to Wiley WCMC journal.

Page 38

The UPMT team

Marco Bonola ( Stefano Salsano ( Alessio Bianchi, Andrea Gambitta, Fabio Patriarca, Fabio Ludovici, Enrico Gagliano, Andrea Capitani, Belen Ibanez, Daniele Dedda, Alessandro Tramontozzi, Pier Luigi Ventre, Aurelio Franconeri

Page 39