RE: [More] Session Mobility

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

It sounds to me then that session mobility primarily refers to the
ability to move the mobile's IP traffic from one interface to
another, perhaps selectively.

The only example I can think of where you may want to move an
application from one device to another is a user on a call on their
office phone who wants to leave and transfer it to their cell phone.
I can't think of why I might want to transfer an ftp session from
one device to another.

		jak
		
>X-Lotus-FromDomain: HTLUK
>From: amish.chana@orange.co.uk
>To: more@psg.com
>Date: Thu, 20 Sep 2001 17:49:37 +0100
>Subject: RE: [More] Session Mobility
>Content-Disposition: inline
>
>
>James,
>
>With regards to moving IP traffic from one device to another and maintaining 
the
>session, could you give some examples of potential applications that may 
require
>this functionality?
>
>Data type applications (e.g. ftp, http, database transactions, telnet) may not
>be possible because the applications need to maintain transaction state
>information. To move the session to a new device would require the application
>to be moved including transport layer protocol's state information. I don't
>think "Mobile Applications" exist as yet - but the concept has potential. Next
>time the message "Low on Virtual Memory" pops-up transfer some apps to another
>computer. ;-)
>
>For streaming services, some minimal state information may have to transferred,
>e.g. authentication keys. This information could be transferred by IR or
>bluetooth between the devices. Session transfer could be accomplished during
>this process. Not impossible, but requires some capabilites on the devices.
>
>Just some ideas.
>Amish
>
>
>
>
>
>
>James Kempf <James.Kempf@Sun.COM> on 20/09/2001 16:55:12
>
>Please respond to James Kempf <James.Kempf@Sun.COM>
>
>
>
>
>To:   more@psg.com
>      Amish CHANA/EN/HTLUK@HTLUK
>cc:
>
>
>Subject:  RE: [More] Session Mobility
>
>
>
>Amish,
>
>>
>>By session mobility I am refering to all possible types of user sessions.  
This
>>section in the draft certainly does not focus on one type of service, e.g. SIP
>>telephony, but applies to all Internet sessions. The draft is also worded such
>>that session mobility has to be the responsibility of the network.
>>
>>I mentioned in my previous email that session mobility "depending on the type
>of
>>service" does not need to be the responsibility of the network and 
multi-homing
>>could address some of the session mobility issues.
>>
>>Managing session mobility on the network would be advantageous for streaming
>>delay-sensitive data. Delay tolerant data could be better served by
>multi-homing
>>where buffering of data that arrives out-of-order and retransmissions are
>>considered acceptable (e.g. http and ftp type sessions).
>>
>>I think the requirements need to be a little flexible, such that session
>>mobility is not only the network's responsibility. Any objections?
>>
>
>No objections, but I still don't see a distinction here between:
>
>1) Moving IP traffic, perhaps selectively  (e.g. just http and not ftp), from
>one interface to another on the same device.
>
>2) Moving IP traffic, perhaps selectively, from one device to another.
>
>The first seems fairly straightforward to implement, and discussion about
>how is well underway in the IETF. I believe there is even a draft
>about how to move selective IP flows from one interface to another.
>
>The second seems fairly difficult to implement, since it requires a case
>by case examination of the application protocols. Most application
>protocols don't allow changing from one device to another, and I
>suspect there will be a fair amount of resistence on the part of
>some application protocol groups to providing support for it.
>
>          jak
>
>
>
>
>
>
>
>
>
>*******************************************************************************
>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.
>*******************************************************************************
>
>