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

[Paul Kyzivat <[e-mail]>]

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.

	Paul

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?
>>
>> [1] Nakajima N., Dutta A., Das S., Schulzrinne H., "Handoff delay 
>> analysis and measurement for SIP based mobility in IPv6," ICC'03, 2003.
>>
>> Best wishes,
>>
>> Haruki
>>
>>
>> Mary Barnes wrote:
>>> And that document is sitting in the RFC editor's queue, so it is
>>> important to consider what additional requirements these other documents
>>> address beyond the ones in that document and the value of additional
>>> solutions beyond those already documented.
>>> Mary.
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On
>>> Behalf Of Paul Kyzivat
>>> Sent: Thursday, May 08, 2008 2:05 PM
>>> To: Saverio Niccolini
>>> Cc: SIPPING LIST
>>> Subject: Re: [Sipping] Request for Open discussion about SIP mobility
>>>
>>> Don't forget draft-shacham-sipping-session-mobility
>>> which I believe predates ther rest of your work.
>>>
>>>     Paul
>>>
>>> Saverio Niccolini wrote:
>>>> Then my question is:
>>>> is SIP mobility something interesting to be investigated for the
>>> group?
>>>> I would like to stimulate discussion around this set of drafts:
>>>> http://www.ietf.org/internet-drafts/draft-izumikawa-sipping-sipbicast-
>>>> 01.txt
>>>> http://tools.ietf.org/html/draft-niccolini-sipping-siphandover-03
>>>> http://tools.ietf.org/html/draft-salsano-sipping-siphandover-solution
>>>>
>>>> It seems to me that they both address the same issue with similar 
>>>> scenarios in mind and similar requirements, in the end they differ for
>>>> the technical solution proposed (as for the standardization 
>>>> requirements if it is an additional header we may need ot go to SIP, 
>>>> but if it is up to changing lines in SDP then it is MMUSIC)
>>>>
>>>> --> if we can get an agreement that the issues/scenario and common
>>>> set of requirements then this would be a good basis for discussion and
>>>> we can rpoceed from there
>>>>
>>>> Anyone having an opinion on this?
>>>>
>>>> Cheers,
>>>> Saverio
>>>>
>>>> ============================================================
>>>> Dr. Saverio Niccolini
>>>> NEC Laboratories Europe, Network Research Division   
>>>> Kurfuerstenanlage 36, D-69115 Heidelberg
>>>> Tel.     [phone]
>>>> Fax:     [phone]
>>>> e-mail:  [e-mail] <-- !!! NEW ADDRESS !!!
>>>> ============================================================
>>>> NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, 
>>>> London W3 6BL Registered in England 2832014
>>>>  
>>>>  
>>>>> -----Original Message-----
>>>>> From: [e-mail]
>>>>> [mailto:[e-mail]] On Behalf Of Paul Kyzivat
>>>>> Sent: Thursday, May 08, 2008 5:32 PM
>>>>> To: Haruki Izumikawa
>>>>> Cc: SIPPING LIST
>>>>> Subject: Re: [Sipping] Request for Open discussion about SIP mobility
>>>>>
>>>>>
>>>>>
>>>>> Haruki Izumikawa wrote:
>>>>>> Dear Stefano,
>>>>>>
>>>>>> Thank you for your interest. I have reviewed your updated
>>>>> I-Ds. As you
>>>>>> pointed, I also think that we share common requirements and
>>>>> scenarios.
>>>>>> I understand the addition of a new SIP header could not be a major 
>>>>>> concern. In fact, I have proposed a new SIP header for
>>>>> bicasting before.
>>>>>> But, I'm afraid that the addition of a new SIP header falls
>>>>> into terms
>>>>>> of reference of SIP WG, not SIPPING WG. How do you feel about it?
>>>>> That is true. But the work could and should start in SIPPING. If it 
>>>>> eventually is decided that a new header is needed then that work 
>>>>> would be shifted to the SIP WG with blessings from SIPPING. Since 
>>>>> there is a huge overlap in participation that should not cause any 
>>>>> difficulty.
>>>>>
>>>>>     Thanks,
>>>>>     Paul
>>>>>
>>>>>> Best wishes,
>>>>>>
>>>>>> Haruki
>>>>>>
>>>>>>
>>>>>> Stefano Salsano wrote:
>>>>>>> Dear Haruki,
>>>>>>>
>>>>>>> thank you for restarting discussion on SIP mobility. I
>>>>> agree with the
>>>>>>> importance to discuss this topic in this WG.
>>>>>>>
>>>>>>> I'd like to bring again to the attention of the WG two related 
>>>>>>> internet drafts that we submitted some time ago and that we've 
>>>>>>> now updated
>>>>>>>
>>>>>>> [1] Requirements for vertical handover of multimedia
>>>>> sessions using
>>>>>>> SIP
>>>>>>> http://tools.ietf.org/html/draft-niccolini-sipping-siphandover-03
>>>>>>>
>>>>>>> [2] A solution for vertical handover of multimedia
>>>>> sessions using SIP
>>>>> http://tools.ietf.org/html/draft-salsano-sipping-siphandover-solution
>>>>>>> -02
>>>>>>>
>>>>>>> Now I would like in particular to focus on the
>>>>> requirements draft [1]
>>>>>>> and to make some comparison with your work.
>>>>>>>
>>>>>>> It seems that the requirements and scenarios we consider
>>>>> are largely
>>>>>>> overlapping (while we take different approaches for solutions).
>>>>>>>
>>>>>>> We have in common the idea of letting the Correspondant
>>>>> Node as much
>>>>>>> as possible not involved in the seamless handover
>>>>> procedure and the
>>>>>>> introduction of some sort of B2BUA to assist in the procedure. We 
>>>>>>> also share the idea that bi-casting can improve the handover and 
>>>>>>> needs to be properly managed.
>>>>>>>
>>>>>>> As you have already outlined in your draft, a difference in the 
>>>>>>> requirements is that you would like not to introduce new 
>>>>>>> headers/parameters while we allow it.
>>>>>>>
>>>>>>> My point here is that the introduction of the new headers in our 
>>>>>>> scenario only concerns the handover-capable mobile device and the 
>>>>>>> intermediate element which is in charge to assist in the handover 
>>>>>>> procedure. Correspondant Node and all other SIP elements are not 
>>>>>>> touched anyhow. I feel that in any case there the need to
>>>>> implement a
>>>>>>> lot of specicif logic to properly handle the bi-casting (not to 
>>>>>>> mention the problem of discovery of intermediate element that you 
>>>>>>> deliberately neglect in your draft to simplify the problem).
>>>>>>> Therefore the addition of a new header may not be the
>>>>> biggest issue.
>>>>>>> Anyway these aspects could be clarified with some deeper 
>>>>>>> technical discussion, which I hope can start in the WG.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Stefano
>>>>>>>
>>>>>>> Haruki Izumikawa wrote:
>>>>>>>> Hello folks,
>>>>>>>>
>>>>>>>> I'd like to have an open discussion about SIP-based
>>>>> mobility in this ML.
>>>>>>>> Mobility managements using SIP have been actively studied and 
>>>>>>>> developed worldwide since "Mobility Support Using SIP"
>>>>> (by Elin and
>>>>>>>> Henning) was published. SIP-based mobility would have strong 
>>>>>>>> advantages such as its great affinity for an application
>>>>> as well as
>>>>>>>> flexibility, i.e., terminal mobility can be optimally
>>>>> supported independent from underlying network.
>>>>>>>> On the other hand, despite many advantages, it is not used for 
>>>>>>>> large-scale commercial yet. In addition, the discussion about 
>>>>>>>> SIP-based mobility in IETF seems to be undynamic.
>>>>>>>> These days, a multimode terminal is getting popular. Each access 
>>>>>>>> networks, e.g., cellular and WLAN, have different
>>>>> characteristics in
>>>>>>>> terms of throughput or delay. In such a heterogeneous
>>>>> network, SIP
>>>>>>>> becomes more useful tool for mobility management because of its 
>>>>>>>> flexibility. The quality of a multimedia service can be
>>>>> adaptively
>>>>>>>> changed in accordance with a nature of an access networks
>>>>> even after
>>>>>>>> changing an access network. I think it is time to resume
>>>>> discussing
>>>>>>>> about SIP-based mobility. For your information, I have
>>>>> submitted I-D
>>>>>>>> regarding seamless session handoff by SIP-based bicasting.
>>>>>>>>
>>>>> http://www.ietf.org/internet-drafts/draft-izumikawa-sipping-sipbicas
>>>>>>>> t-01.txt
>>>>>>>>
>>>>>>>> I would be happy to hear frank opinions of SIP specialists.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Haruki
>>>>>>>>
>>>>>>>>
>>>>> _______________________________________________
>>>>> 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
>>> _______________________________________________
>>> 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