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

[Haruki Izumikawa <[e-mail]>]

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

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