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

[Stefano Salsano <[e-mail]>]

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".

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