Saverio, Additional requirements : (a) Vertical handover should not put excessive load on the access network preventing it to serve existing MHs/sessions. For instance, multiple MHs in the 3G AN approaching a hot spot should not bring down a Wi-Fi network during/after the handover. (b) MH should not ping pong between access networks during handover. Terminal Mobility and Session Mobility can be intertwined. When two ANs are available to the MH, it may choose to keep the voice session in AN1 and handover the video to AN2 or move them both to AN2 and transfer the video part to another MH. As a desirable requirement, splitting of signaling and media between different ANs may be possible. Sec 2, within the description of Terminal mobility you mention IP subnets. I think you meant IP ANs unless you used in the sense of NATs. Other comments : First paragraph, "...access network can become not available anymore.." -> access network can become unavailable. Sec 2, network level mobility bullet, "...to recognize an available bandwidth" -> to recognize lack of bandwidth Sec 3, "technologies and difference bandwidth/delay" -> "technologies and different bandwidth/delay" Sec 4, "in the same moment" -> "..at the same moment" Thanks, Serhad > -----Original Message----- > From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf > Of Saverio Niccolini > Sent: Monday, November 24, 2008 8:56 AM > To: sipping@xxxxxxxx > Subject: Re: draft-niccolini-sipping-siphandover-05.txt > > Dear all, > > among the contributors it was discussed that is actually good to > keep the discussion on the mailing list to gather more general > feedback from everybody and more specific one from the people > willing to actively contribute (people like John Elwell, Zaheduzzaman > Sarker and Hassnaa Moustafa demonstrated interest in this). > > So far we have received the following comments, that we are going to > take care of: > -- we should state clearly that terminal mobility has a requirement > to be able to support a "make before break" style of handover even > if it possible to use the solution to also do "break before make", > we should be able to formalize what "make before break" means > at protocol level in a clear way to be able to write requirements > for this > -- provide more detailed summary of work in 3GPP to avoid people > to look for and read the related 3GPP documents > -- add an additional requirement that is to minimize the packet loss > (or avoid it at all) and the reordering problem during an handover > > What is still unclear: > -- we should look at SIP-based terminal mobility requirement in general > with vertical handover being one use case > --> what are the requirements missing in the draft for looking at > SIP-based terminal mobility requirement in general? > > Any comments? > > Thanks, > Saverio > > ============================================================ > Dr. Saverio Niccolini > Manager, Real-Time Communications Group > NEC Laboratories Europe, Network Research Division > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-118 > Fax: +49 (0)6221 4342-155 > e-mail: saverio.niccolini@xxxxxxxxxxxx <-- !!! NEW ADDRESS !!! > ============================================================ > NEC Europe Limited Registered Office: NEC House, 1 Victoria > Road, London W3 6BL Registered in England 2832014 > > > > > -----Original Message----- > > From: sipping-bounces@xxxxxxxx > > [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Ashutosh Dutta > > Sent: Monday, November 24, 2008 2:57 PM > > To: Anton Tveretin > > Cc: sipping@xxxxxxxx > > Subject: Re: draft-niccolini-sipping-siphandover-05.txt > > > > > > Anton Tveretin wrote: > > > Dear All, > > > Here is my contribution to the problem list. I hope this might help. > > > 1. "Hanging TCP" problem: if, at the time of handover, > > there is a TCP > > > connection between nodes, this might cause sending packets to the > > > wrong host (i.e. IP address of the MH changes, and previous IP is > > > assigned to that host). This is also a security hole. > > > > Just a clarification. SIP-based terminal mobility could be > > most useful for SIP-based sessions, where media is mostly > > RTP/UDP (e.g., Interactive VoIP, RTP-based streaming). There > > are additional complexities to support TCP-based application > > (e.g., tcpchat) using SIP-based terminal mobility, although > > not impossible. However, SIP-based terminal mobility cannot > > be used for applications that are not initiated using SIP > > signaling (e.g., FTP, Telnet). > > > > We had a draft discussing this issue a while back in 2001. > > > > http://www.argreenhouse.com/SIP-mobile/sip_draft4. > > > > One can potentially use any MIP-based solution to avoid such > > complexity to support terminal mobility for TCP-based application. > > > > > 2. (Related to the previous): How can the CH find out that it is > > > connected to the same host (MH), but with different IP address, and > > > not something else? This is especially important for TLS > > connections. > > > 3. Handover collision problem, i.e. during handover process, the CH > > > also changes its IP address. I don't see any solution for this > > > problem. IMO the connection will be lost. > > > > Simultaneous mobility problem is a good one. There is > > currently a draft in MEXT discussing this specific issue in > > addition to few papers that have addressed this specific > > issue. It also lists some of the solutions. > > We should add this one as a requirement. > > > > http://tools.ietf.org/html/draft-wong-mext-simultaneous-ps-01 > > > > Since we are discussing the requirement draft, we should not > > be discussing possible solutions yet. > > > > > > Thanks > > Ashutosh > > > > > Sincerely yours. > > > _______________________________________________ > > > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > > Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip > > > Use sip@xxxxxxxx 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 sip-implementors@xxxxxxxxxxxxxxx for questions on current sip > > Use sip@xxxxxxxx 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 sip-implementors@xxxxxxxxxxxxxxx for questions on current sip > Use sip@xxxxxxxx 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 sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
