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?