RE: [802.21] contributions for upcoming May 2004 meeting - L2.5 Concrete Model ?
Hi all,
The issue here is what we need to achieve from the handover. Are we aiming
at session continuity or just IP connectivity.
For the IP connectivity, it means the terminal/MT need to monitor the status
of the interfaces, and pick the right interface to use. This may require the
trigger mechanisms we have seen in the previous meetings. For example, if my
LAN interface is down, the LINK DOWN indication should activate my WLAN
interface, etc. This may have already been implemented in/could be easily
added to our daily used OS, as pointed out by others. But, simply this does
not really guarantee the session continuity. The application/session may
need to be restarted for the service access. For most of users who don't
require long term connectivity, it should be sufficient, but this is not the
"seamless handover" stated in the PAR, and would not support applications
like VoIP, streaming, etc.
To maintain the session continuity, IP layer, or upper layer schemes has to
be employed. This is where the MIP/SIP kind of solution comes in. Therefore,
the triggers, etc should work with the upper layer here. Of course another
simpler case is where the two interfaces of the MT use the same IP address.
But this is not always possible, and the handover means network devices,
switch, etc, could update their records fast enough.
As pointed out by DJ, the choice of the interface when multiple connectivity
are present could be solved by a policy based scheme or user intervention at
the terminal side.
For all the above, I think the L2.5 or alike model would be necessary for
the .21, and we do have quite a lot to work on.
As for the detail connectivity establishment after the trigger/decision, .21
may not need to specify, since it is more or less media dependant. For
example, the procedure for .11 may require 11i, or WPA, etc, which is not
available in .3 or other network. So, this aspect could be left to the
individual working group to solve, and .21 only need to specify the
requirements/end results.
Cheers
Cheng Hong
> -----Original Message-----
> From: owner-stds-802-21@LISTSERV.IEEE.ORG
> [mailto:owner-stds-802-21@LISTSERV.IEEE.ORG] On Behalf Of
> Iyer, Prakash
> Sent: Wednesday, May 05, 2004 2:35 AM
> To: Mike MORETON; STDS-802-21@LISTSERV.IEEE.ORG
> Subject: RE: [802.21] contributions for upcoming May 2004
> meeting - L2.5 Concrete Model ?
>
>
> The whole premise of MBB handovers presumes you have access
> to both WLAN and Ethernet. With that presumption, and also
> presuming that WPA/TGi gets widely adopted (i.e. no issues
> with VPN tunnels over WLAN and split tunneling over WLAN and
> LAN etc.), I am not sure if there is a significant problem to
> be solved here. It is quite possible to maintain link
> associations (i.e. IP connectivity) over both links today and
> have the client's local routing stack either switch between
> the links or maintain dual-homed connectivity. Windows XP
> enables the latter today using a combination of routing
> metrics (lower value implies more preferred NIC) and LPM
> based routing (which supercedes metrics). We can debate if
> this kind of policy management makes sense or not, but that
> outside the scope of this group. A dialog with OS vendors
> seems more worthwhile.
>
> Let's look at 2 transition scenarios assuming dual
> connectivity is feasible and allowed by policy:
>
> * Transition from LAN to WLAN (as in when you undock or pull
> out an Ethernet cable): In this case, a local trigger that
> speeds up a LINK DOWN indication by a few usec / msec could
> help the network stack update its routing tables faster.
> 802.21 could research and recommend some Ethernet PHY/MAC
> events that could be used to generate a proactive LINK DOWN
> trigger, but everything else is really a client stack
> implementation issue.
>
> * Switch to Ethernet from WLAN (based on a link preference).
> This is already handled seamlessly in OSes like XP. For
> example, what XP would do is maintain all ongoing WLAN
> connections over the still active WLAN interface, while
> updating the routing table metrics to let new app sessions
> favor the LAN interface
>
> Bottom line is that I see the need for 802.21 to do very
> little to enable the scenario being discussed here. -Prakash
>
> -----Original Message-----
> From: owner-stds-802-21@listserv.ieee.org
> [mailto:owner-stds-802-21@listserv.ieee.org] On Behalf Of Mike MORETON
> Sent: Tuesday, May 04, 2004 11:00 AM
> To: STDS-802-21@listserv.ieee.org
> Subject: Re: [802.21] contributions for upcoming May 2004
> meeting - L2.5 Concrete Model ?
>
> Dj,
>
> I'm typing this at home, and my laptop is currently connected
> to ethernet, while also being associated with WLAN. It
> doesn't seem to be a problem (as long as I don't disconnect
> the etherenet!) but just being associated may not provide
> enough information for a fast handoff.
>
> Mike.
>
>
> -----Original Message-----
> From: owner-stds-802-21@LISTSERV.IEEE.ORG
> [mailto:owner-stds-802-21@LISTSERV.IEEE.ORG] On Behalf Of Johnston, Dj
> Sent: Tuesday, May 04, 2004 5:46 PM
> To: STDS-802-21@LISTSERV.IEEE.ORG
> Subject: RE: [802.21] contributions for upcoming May 2004
> meeting - L2.5 Concrete Model ?
>
> I always assumed that we might have to forego a make before
> break LAN-WLAN handoff, unless the user, or an over elaborate
> dock eject handle provided the predictive information.
>
> Of course, if I was docked, and in some 'high performance'
> mode, I might keep the WLAN associated, just in case we undocked.
>
> To respond to Daniel's point, I think this is a primary
> scenario. It is the scenario that motivated me to propose the
> study group work in the first place. I suffer from a lack of
> effective LAN-WLAN handoff several times a day. Fixing it is
> likely to provide a good improvement to the user experience
> of docking laptops.
>
> DJ
>
>
> -----Original Message-----
> From: owner-stds-802-21@listserv.ieee.org
> [mailto:owner-stds-802-21@listserv.ieee.org] On Behalf Of
> Mani, Mahalingam (Mahalingam)
> Sent: Tuesday, May 04, 2004 9:33 AM
> To: STDS-802-21@listserv.ieee.org
> Subject: Re: [802.21] contributions for upcoming May 2004
> meeting - L2.5 Concrete Model ?
>
>
> As standards stand today it is not simple. Special case
> configurations can make this scenario simple (such as a
> common mobility-aware bridge for WLAN and wireline).
>
> In general, wire-line to wireless seamless handoff is less
> trivial (as some smart heuristic is needed to overcome
> break-before-make issue - especially w.r.t. latency-sensitive
> sessions and applications) than WLAN-to-wireline
> make-before-make paradigm.
>
> -mani
> > -----Original Message-----
> > From: owner-stds-802-21@LISTSERV.IEEE.ORG [mailto:owner-stds-802-
> > 21@LISTSERV.IEEE.ORG] On Behalf Of S. Daniel Park
> > Sent: Monday, May 03, 2004 10:37 PM
> > To: 'Gupta, Vivek G'; stds-802-21@IEEE.ORG
> > Subject: RE: contributions for upcoming May 2004 meeting - L2.5
> Concrete
> > Model ?
> >
> > My intentional scenario is a mobile office.
> > We have to use a wired connection with several management
> applications
>
> > on the PC. It is to enhance the security aspect and central
> > contralability especially authentication, thus I generally use a
> > ethernet to access internet in my office. Let's assume we
> are about to
> > leave our desk toward meeting room or elsewhere for a while and we
> > still need to maintain our connection and
>
> > application. Then we need to switch our interface to the WLAN
> > automatically if it's available.
> >
> > it's too simple ? or anything else ?
> >
> >
> > Regards.
> >
> > - Daniel (Soohong Daniel Park)
> > - Mobile Platform Laboratory, SAMSUNG Electronics.
> >
> > > -----Original Message-----
> > > From: owner-stds-802-21@LISTSERV.IEEE.ORG
> > > [mailto:owner-stds-802-21@LISTSERV.IEEE.ORG] On Behalf Of Gupta,
> > > Vivek G
> > > Sent: Saturday, May 01, 2004 12:01 AM
> > > To: S. Daniel Park; stds-802-21@ieee.org
> > > Subject: RE: contributions for upcoming May 2004 meeting - L2.5
> > > Concrete Model ?
> > >
> > >
> > > Daniel,
> > >
> > > Can you comment on the application under consideration
> and the usage
>
> > > scenario when transitioning between wired Ethernet and Wi-Fi. It
> would
> > > be interesting to see if "make before break" is required
> in such a
> > > case or if "break before make" can give the same user experience.
> > > Local
> L2
> > > triggering can help in this case, but it may be more of a local
> client
> > > side implementation issue.
> > >
> > > We plan to have an update on our triggers proposal for the May
> > > meeting, which should help out with some of this.
> > >
> > > Best Regards
> > > -Vivek
> > >
> > > Vivek Gupta
> > > Technical Editor, 802.21
> > >
> > > -----Original Message-----
> > > From: owner-stds-802-21@listserv.ieee.org
> > > [mailto:owner-stds-802-21@listserv.ieee.org] On Behalf Of
> S. Daniel
> > > Park
> > > Sent: Thursday, April 29, 2004 11:32 PM
> > > To: stds-802-21@IEEE.ORG
> > > Cc: 'S. Daniel Park'
> > > Subject: contributions for upcoming May 2004 meeting -
> L2.5 Concrete
>
> > > Model ?
> > >
> > > Hi 802.21 folks
> > >
> > > Aside from the ARID, I am opening another issue on the L 2.5 (not
> > > sure it is a general term. but I just heard it from the DJ when
> > > attending the previous .21 meeting).
> > >
> > > Before mentioning that, I am saying one reference which is a
> > > handover between 802.3 (called Ethernet) and 802.11. This
> scenario
> > > is may included in the .21 technical requirement document
> and will
> > > be presented in coming .21 meeting on May.
> > >
> > > We (Samsung electronics) are developing this solution in
> our several
>
> > > device such as laptop, hand-help PC and PDA, and it will be done
> > > soon (maybe until the next month). Of course it is not
> lab scale. I
> > > mean it is a real commercial product.
> > >
> > > Above all, for this solution, I have to consider both L2
> and L3 at
> > > the same time and almost functions are being implemented above L2
> > > (e.g., extended device driver with L2 triggering). Thus
> I'd like to
> > > call that as L2.5 but I don't have any concrete definition and
> > > function (reference) model now. If I can get L2.5, it
> would be very
> > > useful.
> > >
> > > I am wondering how we can clarify the definition of L2.5
> and it is a
>
> > > inside scope of the .21 WG ?
> > >
> > > Or is anyone defining the reference model or related work about L
> > > 2.5 ?
> > >
> > > If yes, I would see it in this meeting.
> > >
> > > I believe it will be a valuable model for doing a media
> independent
> > > handover among several L2 techniques.
> > >
> > > Thanks in advance.
> > >
> > > - Daniel (Soohong Daniel Park)
> > > - Mobile Platform Laboratory, SAMSUNG Electronics.
> > >
>
>