RE: [More] Session Mobility

[James Kempf <James.Kempf@Sun.COM>]

If by "session mobility" you are talking about moving a mobile host's
traffic from one interface to another (e.g. GSM to 802.11), then
this is currently a topic of active discussion and debate in the 
Mobile IP and Seamoby working groups. There has been some preliminary
work, but the problem is by no means completely understood.

If you mean moving a SIP session from
one host to another, then I believe SIP has mechanisms for this
(REGISTER with the new host as the SIP URL), though I am not that familiar with
the details of SIP that I could provide an outline of how it might
work.

If you mean something different from the above, then I need to
refer back to Erik Nordmark's comments on this requirement
from earlier this year,  namely that implementing some sort
of generalized session mobility may be very difficult especially
if it is not clearly defined what is meant by session mobility.

		jak

>From: Burke Chris-CCB007 <Chris.Burke@motorola.com>
>To: more@psg.com
>Subject: RE: [More] Session Mobility
>Date: Wed, 19 Sep 2001 10:17:51 -0500
>
>There are various ways of implementing mobility.
>
>Consider a cell phone - it has a kind of session mobility in that the route 
used by the voice traffic virtual circuit changes as the user moves among cell 
sites. Currently the cell sites are homogeneous but theoretically a mix of 
different technologies could be used (e.g. GSM and 802.11) and similar hand-off 
techniques could be employed regardless of the access technology. There's still 
only one administrative domain ("the carrier") and the entire system looks like 
"one network". Handoff would be under control of infrastructure equipment, but 
would require coordinated execution of handoff protocols within the subscriber 
equipment. This scheme is appealing to some carriers.
>
>One can also, as you suggest, make session mobility the responsibility of the 
subscriber equipment and design the solution for multiple administrative domains 
and multiple access technologies using multi-homing etc.
>
>Research effort (and even product development) is ongoing at various companies 
and universities around both approaches.
>
>Chris
>
>-----Original Message-----
>From: amish.chana@orange.co.uk [mailto:amish.chana@orange.co.uk]
>Sent: Wednesday, September 19, 2001 2:52 AM
>To: more@psg.com
>Subject: [More] Session Mobility
>
>
>
>Hi,
>
>With reference to the section on session mobility, which requires the ability 
to
>transfer and maintain sessions across different access technologies. What
>thoughts do others on this mailing list have with respect to the requirements
>and complexity potential solutions may have on the network?
>Are these requirements really necessary?
>Should session mobility (depending on the type of service) not be the
>responsibility of the mobile terminal rather than the network?
>
>IMHO somes of these requirements could be addressed and realised by some of the
>work on end-point multi-homing being performed by other WGs. SCTP,
>draft-ohta-e2e-multihoming-02.txt and the multi6 WG may offer solutions to the
>Session Mobility requirments without requiring the need for additional network
>functionality.
>
>As an example, the application sessions mentioned in the draft (http, ssl, tcp,
>telnet, ftp) and the ability to transfer them from
>a IMT-2000 RAN to a 802.11 LAN or other access technology could be achieved 
with
> multi-homing. Supporting, session
>transfers within the network requires a network element to maintain session
>state information. Failure of this element
>would impact all currently active sessions. In a multi-homed end-point scenario
>the failure of the access network elements
>does not impact sessions.
>
>
>Regards,
>Amish
>
>
>
>
>*******************************************************************************
>Important. This E-mail is intended for the above named person and may be
>confidential and/or legally privileged. If this has come to you in error you
>must take no action based on it, nor must you copy or show it to anyone; please
>inform the sender immediately.
>*******************************************************************************
>
>