[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [More] Session Mobility
Hetergeneous transfer is actually a big study issue currently in
MIP and Seamboy. Most of the current work has heterogeneous transfer
as a requirement.
jak
>X-Lotus-FromDomain: HTLUK
>From: amish.chana@orange.co.uk
>To: more@psg.com
>Date: Thu, 20 Sep 2001 10:39:15 +0100
>Subject: RE: [More] Session Mobility
>Content-Disposition: inline
>
>
>Hi,
>
>Mobile IP and Seamoby seem to be aimed at hand-offs/session transfers in a
>homogeneous access network environment. If we have session transfers across
>different access technologies, what are the performance implications of this
>type of hand-off on the path MTU in both the upward/downward direction.
>
>Amish
>
>
>
>
>
>
>"Dana L. Blair" <dblair@cisco.com> on 19/09/2001 18:59:39
>
>
>
>
>To: "James Kempf" <James.Kempf@Sun.COM>
> more@psg.com
> Chris.Burke@motorola.com
>cc: (bcc: Amish CHANA/EN/HTLUK)
>
>
>Subject: RE: [More] Session Mobility
>
>
>
>> -----Original Message-----
>> From: owner-more@ops.ietf.org [mailto:owner-more@ops.ietf.org]On Behalf
>> Of James Kempf
>> Sent: Wednesday, September 19, 2001 1:16 PM
>> To: more@psg.com; Chris.Burke@motorola.com
>> Subject: RE: [More] Session Mobility
>>
>>
>> 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.
>
>I think it's pretty well understood using Mobile IP. I setup an ftp session
>over 802.11, then hand it over to a GSM Circuit Switched data connection
>using Mobile IP registration to the Home Agent. The ftp continues without
>interrupt through the handoff, but of course proceeds much slower over the
>GSM connection.
>
>>
>> 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.
>
>I don't believe there are standard SIP mechanisms yet for
>this type of session mobility. However, I can envision a few extensions to
>facilite this.
>
>thanks,
>Dana
>
>>
>> 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.
>> >***************************************************************
>> ****************
>> >
>> >
>>
>>
>
>
>
>
>
>
>
>*******************************************************************************
>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.
>*******************************************************************************
>
>