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

[Paul Kyzivat <[e-mail]>]

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.

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

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?
>>>>
> 
> 
_______________________________________________
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