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

["Elwell, John" <[e-mail]>]

 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Stefano Salsano
> Sent: 12 May 2008 16:10
> To: Paul Kyzivat
> Cc: Ashutosh Dutta; SIPPING LIST; Mary Barnes; Saverio Niccolini
> Subject: Re: [Sipping] Request for Open discussion about SIP mobility
> 
> 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...)
[JRE] This is just another instance of the general problem of B2BUAs
(e.g. SBCs) providing functionality to compensate for endpoints that do
not fully support fairly basic mechanisms in SIP, namely re-INVITE in
this particular case. It is a fact that such middleboxes do exist, and
we can argue about whether they exist for good reasons or not. However,
does the IETF really want to specify such work-arounds for these
problems, rather than trying to address the fundamental problem?

John

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