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

[Ashutosh Dutta <[e-mail]>]

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