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

[Ashutosh Dutta <[e-mail]>]

Paul,
	While application layer mobility has its merits in terms of its ease of 
deployment, its usage is best suited to support SIP-based application. 
However, as Haruki and Stefano have pointed out, we still need to have 
fast-handoff support to make SIP-based mobility more useful to the end 
users.

	Thus, a discussion in this regard could be useful. I am not sure if 
recently formed MEXT WG would like to include SIP-based mobility in 
their charter. Otherwise, these issues can probably best be addressed in 
the SIPPING WG.

Since we are discussing SIP-based mobility vs. MIPv6, here is a pointer 
to a short paper that provides a comparative analysis between SIP-based 
mobility and MIPv6, titled, "Comparative Analysis of Network Layer and 
Application Layer IP Mobility Protocols for IPv6 Networks," that 
appeared in WPMC 2006.

http://www1.cs.columbia.edu/~dutta/research/WP061002.PDF

Regards
Ashutosh


Haruki Izumikawa wrote:
> Dear Stefano,
> 
>  > 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.
> 
> [HI] I agree with you. Fast/Seamless handoff is needed if users enjoy 
> multimedia services over an IP-based mobile network. This requirement is 
> also stated in RFC 4068 (FMIPv6). And, FMIPv6 has been already 
> standardized for suppoting fast handoff. But, I'm afraid when all of 
> access routers worldwide would support FMIPv6, incl. buffering and 
> forwarding functions. Application layer mobility enables the mobility 
> service deployment to be more and more rapidly, which should be one of 
> the merits of application layer mobility.
> 
> Best wishes,
> 
> Haruki
> 
> Stefano Salsano wrote:
>> 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?
>>>>>>>
>>
> 
_______________________________________________
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