RE: [802.21] contributions for upcoming May 2004 meeting - L2.5 Concrete Model ?
>
> The issue here is what we need to achieve from the handover. Are we
aiming
> at session continuity or just IP connectivity.
>
In context of transitions from wired to wireless networks based on
applications and viable usage scenarios mentioned (mobile office), the
requirement seems to be mostly for automatic/continual IP connectivity.
This will easily take care of more common apps like email, etc. 802.21
can help provide information to facilitate discovery/selection of
networks in this case, but the overall end user experience also depends
in large part on the client side implementation.
There may be certain more esoteric cases in this context (wired to
wireless) where session persistence may be required. My BT headset is
using VoIP through my docked laptop (ethernet..), and I decide to carry
my notebook to a meeting in middle of a voice call. You can use SIP/MIP
etc. in this case and certain 802.21 mechanisms may help out in this
case. Not sure how viable this scenario is. (Might want to use WLAN for
VoIP call even when docked/powered or just use a VoIP handset.....)
So what are the various mechanisms 802.21 can define to help with
handoffs?
- Triggers, specially predictive triggers, which can help reduce
handover latency..
- A model to provide information about all networks, sort of global
network neighborhood, to help with network discovery/selection, etc.
What else?? Let the good ideas keep coming...
How do we decide what gets included in 802.21 spec?
As a rough guideline, any new mechanism we define, that impacts the
technology specific air interface (for wireless networks) should get
included in spec. And by similar logic something which is local only and
does not impact the air interface in any way, possibly does not merit
inclusion in spec (from a normative perspective).
Most of the L2.5 models and policy engines, etc. seem to be local to
client side and implementation specific. Not sure that we need to
include these in a spec, especially from a normative perspective.
Best Regards
-Vivek
-----Original Message-----
From: owner-stds-802-21@listserv.ieee.org
[mailto:owner-stds-802-21@listserv.ieee.org] On Behalf Of Cheng Hong
Sent: Tuesday, May 04, 2004 7:40 PM
To: Iyer, Prakash; 'Mike MORETON'; STDS-802-21@listserv.ieee.org
Subject: 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.
> > >
>
>