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

[Haruki Izumikawa <[e-mail]>]

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

[HI] I know the advantages of network-level mobility since I had studied 
MIP/MIPv6 for years. One of the merits of MIP should be making the 
mobility of a terminal transparent to an application by keeping the same 
IP address. This scheme is useful to run existing applications. I think 
MIP is enough technology to deal with the mobility only when a handoff 
occurs in homogeneous network and non-realtime application is used.

However, MIP has limitations in my view. For example, an available 
bandwidth and delay may well differ significantly among heterogeneous 
networks, such as wireless LAN and cellular. So, I think an application, 
especially a realtime application, needs to recognize, for example, an 
available bandwidth and delay before or during handoff to adjust a 
transmitting rate or buffer space to a target network. Since MIP makes 
the mobility transparent to the upper layer, it is difficult to do it. 
And, the realtime stream can be aborted or interrupted just after handoff.

On the other hand, SIP has an affinity for applications, which can make 
handoff more flexible. So I believe that SIP is worth discussing as a 
technique to support the terminal mobility for a terminal that runs a 
realtime application in heterogeneous networks.

In my view, both network and application layer mobility are necessary, 
and they have different roles.

I would be happy to hear views of many.

Regards,

Haruki


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

-- 
Haruki Izumikawa
KDDI R&D Laboratories

_______________________________________________
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