[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [More] Session Mobility
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.
*******************************************************************************