Re: [Sipping] Request for Open discussion about SIP mobility

[Stefano Salsano <[e-mail]>]

Paul Kyzivat wrote:
> Stefano Salsano wrote:
>> Paul Kyzivat wrote:
>>> I'll try to channel Henry for a moment, and ask why we need to do 
>>> *anything* at the sip level to handle a device moving from one IP 
>>> access network to another.
>>
>> Dear Paul,
>>
>> I think that SIP is already concerned with "devices moving from one IP 
>> access network to another".
>> The re-INVITE mechanisms already described in current SIP RFCs allows 
>> to support terminal mobility, taking care of "devices moving from one 
>> IP access network to another".
> 
> Sip can do lots of things, many of which are probably a bad idea.

Dear Paul,

I think that ability of performing terminal mobility or "application 
level mobility" is one of the major claims of the SIP protocol and one 
thing that the "inventors" of SIP had in mind from the beginning...

> I said I was channeling Henry here, and I will continue for a bit, 
> playing the devil's advocate.
> Why would you want to establish a new sip signaling path just because 
> you have chosen to use a new access network? *Why* won't the IP address 
> you were using with the first access network continue to work with the 
> new access network?
> (I'm sure there are answers to this, but perhaps they need to be flushed 
> out.)

Thank you for these provocative questions... Handling mobility at the 
network layer is for sure an interesting option. I guess we could spend 
days discussing the merits of application layer mobility vs network 
layer mobility...

You definitly need to have an ubiquitous deployment of mobile IPv6 if 
you want to start using network level mobility keeping your IP address 
when you roam across networks... I think this is a very long term 
solution. Or you can choose to use this mobility only on the subset of 
mobile IPv6 enabled networks.

On the other hand, tomorrow morning I can set up for you a demo of a SIP 
based application layer mobility. You will be connected to an SBC that I 
run on my desktop PC (I am not an operator!), you can roam on whatever 
IPv4 network you want with public or private addresses (as long as there 
are no firewalls, but only NATs) you can make and receive phone calls 
and perform seamless handovers (the quality is of course dependent on 
the internet connection between my SBC and the network you roam in, but 
the handover process virtually does not introduce any additional 
degradation)

Of course, I need to send you my VoIP client... because my solution is 
"proprietary" :-(

My point is that it is worth discussing requirements for this types of 
solutions and see if there is interest to go for a standard. This will 
avoid to have a set of non interoperable solutions offered as plugins of 
VoIP clients or as complement of proprietary SBCs...

Best regards,
Stefano

PS by the way the demo solution I mentioned is described in:
"SIP-based mobility management in next generation networks", IEEE 
wireless communications April 2008
http://dx.doi.org/10.1109/MWC.2008.4492982

and in
http://tools.ietf.org/html/draft-salsano-sipping-siphandover-solution-02


> In the case of IPv6 I know there are limits to where IP addresses can be 
> connected. And there is mobile IPv6. So there the question may be "why 
> won't IPv6 mobility be enough to preserve you sip and media sessions as 
> you move from one access network to another?"
> 
> It would seem that often the answer is that the operators of the access 
> networks insist on participating at the application protocol level so 
> that they can charge more and avoid being commoditized, even if what we 
> really need are some good commodity IP access networks. Having been 
> locked out of participating in HTTP they want to avoid repeating that 
> situation with SIP.
> 
>     Paul
> 
>> The point is: do we think that this already defined re-INVITE 
>> mechanism suits all the requirements for having a SIP based terminal 
>> mobility ?
>>
>> In my opinion there at least two big issues with the current 
>> mechanism, that could deserve the investigation of additional 
>> requirements and solutions:
>>
>> 1) The responsibility for supporting the mobility of a Mobile Node 
>> (MN) is assigned to the Corresponding Node (CN). If the CN does not 
>> support (or does not support well) the re-INVITES you cannot offer a 
>> reliable mobility service using SIP. If you are an enterprise and you 
>> want to offer to your employees a SIP based mobility service 
>> supporting handovers you have to be sure that the procedure works well 
>> independently from the remote CN you are talking (not to talk if you 
>> are a service provider and you are selling a SIP based mobility 
>> services...)
>>
>> 2) Performance issues: the current solution is not very well suited 
>> for a seamless handover, comparable in performance with cellular 
>> networks. Mechanisms like bi-casting could improve the performance.
>>
>> Comments are welcome!
>>
>> Best regards,
>> Stefano
>>
>>> Ashutosh Dutta wrote:
>>>> Haruki,
>>>>        I would actually put Shacham et al.'s draft into session 
>>>> mobility category rather than service mobility since it involves 
>>>> transferring an existing session from one device to another device. 
>>>> While there is a need for fast session transfer between devices, 
>>>> fast-handoff for SIP-based terminal mobility needs to be looked into 
>>>> as well, where the existing session continues on the same device 
>>>> after the handoff (the device could be single homed or multi-homed).
>>>>
>>>> Realizing the need for fast-handoff for SIP-based terminal mobility, 
>>>> subsequent to the paper that you had cited below, we did publish few 
>>>> other papers later on that looked into some possibilities of 
>>>> supporting fast-handoff for SIP-based terminal mobility. Let me cite 
>>>> those below. I am also aware of few other papers supporting 
>>>> SIP-based terminal mobility and fast-handoff as well.
>>>>
>>>> 1) A. Dutta, S.Madhani, H. Schulzrinne, O. Altintas, W. Chen, 
>>>> "Optimized Fast-handoff Schemes for Application Layer Mobility 
>>>> Management,"  ACM MC2R November 2002
>>>>
>>>> 2) P-Y Hsieh, A. Dutta, H. Schulzrinne,  "Application Layer Mobility 
>>>> Proxy for Real-time communication," 3G Wireless 2003, San Francisco, CA
>>>>
>>>> 3) A. Dutta, S. Madhani, W. Chen, O. Altintas, H. Schulzrinne, 
>>>> "Fast-handoff Schemes for Application Layer Mobility Management," 
>>>> PIMRC 2004, Barcelona, Spain
>>>>
>>>>
>>>> While there are variations of fast-handoff techniques for network 
>>>> layer mobility (e.g., FMIPV6, HMIPv6, FPMIPv6), I think it is 
>>>> probably a good idea to investigate if existing techniques can 
>>>> support fast-handoff for SIP-based terminal mobility. This need 
>>>> becomes more apparent if a carrier or any application service 
>>>> provider does not want to deploy any MIP variants to support purely 
>>>> SIP-based applications.
>>>>
>>>> Regards
>>>> Ashutosh
>>>>
>>>> Haruki Izumikawa wrote:
>>>>> I agree with the Mary's comment. It should be important to clarify 
>>>>> differences between Shacham's I-D and other I-Ds related to SIP 
>>>>> mobility.
>>>>> I understand that main difference between them is their focus. 
>>>>> While Shacham's I-D is regarding "service mobility", Niccolini's or 
>>>>> my I-D are regarding "terminal mobility". According to the Dutta's 
>>>>> previous paper [1] regarding a terminal mobility using SIP, a 
>>>>> handoff delay of media packet could be at least around several 
>>>>> hundred msec even if the handoff is executed between homogeneous 
>>>>> networks. Such service disruption cannot be acceptable for 
>>>>> real-time multimedia communications. Indeed, the minimization of 
>>>>> the service disruption during the session transfer appears on the 
>>>>> Shacham's I-D as one of the requirement. Yet, its solution seems 
>>>>> not to be found in the I-D. This could be because the service 
>>>>> disruption is not so critical in the service mobility since the 
>>>>> device itself is changed in the service mobility and a user does 
>>>>> not take it so seriously. However, to minimize the service 
>>>>> disruption should be high-priority for the terminal mobility.
>>>>> Therefore, I think it is necessary to consider the solution to 
>>>>> minimize the service disruption during handoff. So what do you think?
>>>>>
>>
>>
> 


-- 
*******************************************************************
Stefano Salsano
Dipartimento Ingegneria Elettronica
Universita' di Roma "Tor Vergata"
Via del Politecnico, 1 - 00133 Roma - ITALY

http://netgroup.uniroma2.it/Stefano_Salsano/

E-mail  : [e-mail]
Cell.   : [phone]
Office  : (Tel.) [phone]  (Fax.) [phone]
*******************************************************************
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP