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.
> >