IETF 72 – Dublin – SIPPING

Requirements for vertical handover of multimedia sessions

using SIPdraft-niccolini-sipping-siphandover-04

Saverio Niccolini (NEC), S. Salsano (Univ. of Rome “Tor Vergata”),H. Izumikawa (KDDI Labs), R. Lillie (Motorola Labs),

L. Veltri (Univ. of Parma), Y. Kishi (KDDI Labs)

IETF 72 – Dublin – SIPPING

Introduction

• Terminal (“Mobile Host”, MH)• Different network interfaces (e.g. WiFi, 3G,

WiMax, etc.) connected to different Access Networks (AN)– possibly active at same time– each one with different IP addresses

• MH moves, “interface being used” may become not available (or suffering from bad performances, e.g. loss, delays)

• MH wants to keep running sessions active (or achieve better performances)

IETF 72 – Dublin – SIPPING

Reference scenario

Mobile Host (MH)

AN1

AN2

AN3

CH1

CH2

Public Internet

Proxy/Registrar of CH

Proxy/Registrar of MH

NAT

NAT

NAT

IETF 72 – Dublin – SIPPING

IETF 72 – Dublin – SIPPING

Requirements (the basics)

• The handover solution should be as fast as possible– The goal is to provide a "seamless" handover with no perception

from the user point of view• The handover solution should not require a support in the

different access network (no “network level mobility” e.g. MIP/MIPv6)– The access networks are only required to provide IP connectivity

so that mobility support can be rapidly deployable• No special support from Correspondent Hosts (CHs)

– CHs should be basic User Agents (UAs) with basic SIP capabilities• If this requirement is not fulfilled there is the need to change all SIP

terminals to support the handovers of Mobile Host

• The handover solution should be compatible with NATted networks– NAT discovery should not increase the handover delay

IETF 72 – Dublin – SIPPING

Why a new solution?

• There are solutions out there, why do you require a new one?– need to be faster

• service disruption as small as possible, bound to 0

– do not want to rely on network capabilities– do not want to rely on correspondent host capabilities– need to be NAT-independent

• More details in the additional requirements in the draft (here only 15 minutes)– details currently not addressed with available

solutions

IETF 72 – Dublin – SIPPING

References (running code?)• Currently two available (independent) “solution” drafts

– http://tools.ietf.org/html/draft-salsano-sipping-siphandover-solution-02– http://tools.ietf.org/html/draft-izumikawa-sipping-sipbicast-01

• The authors of the solution draft teamed up in the requirement draft to define a common set of requirements

• Solutions to this problem have been designed and implemented• (At least) 3 (known) independent implementations

– NEC Laboratories Europe, University of Rome “Tor Vergata”, KDDI Labs/Motorola

– 2 of them tested interoperability already in 2006• NEC Laboratories University of Rome “Tor Vergata”

• Results of implementation and tests on operational networks documented– PIMRC conference, Sept. 2007– IEEE Wireless Personal Communications, Nov. 2007– IEEE Wireless Communications, Apr. 2008– WCNC 2008, April 2008– Trial with Italian operators

IETF 72 – Dublin – SIPPING

Feedback received and addressed• Differences from Session Mobility ID (draft-shacham-sipping-session-

mobility)?– difference in focus: Shacham's I-D is addressing "service mobility", Niccolini and

Izumikawa I-Ds are addressing "terminal mobility“• It is necessary to consider the solution to minimize the service disruption during

handoff explained in the draft

• Are there any advantages/merits to perform a terminal mobility using SIP?– ease of deployment, no support needed in all terminals/networks, different roles

and utilizations reflected in the requirements– do you want to wait for an ubiquitous deployment of mobile IPv6 to start using

network level mobility keeping your IP address when you roam across networks?• You are fixing some problems with an SBC!!!

– solutions based on an intermediate element are promising without the need to rely on Correspondent Host capabilities reflected in the requirements

– anyway this draft does not hint any solutions, it just says current ones are not enough for the requirements

• What about media like IM, File Transfer using MSRP?– added additional requirement

• Decide which media stream to render when doing bicast– implementation issue out of the scope of SIP/SIPPING?

IETF 72 – Dublin – SIPPING

Conclusions

• Do SIPPING folks agree on requirements?

• Is the work interesting for SIPPING?

• Should this be chartered in SIPPING WG and become a WG item?