RE: [802.21] contributions for upcoming May 2004 meeting - L2.5 Concrete Model ?
Hi Vivek,
<snip>
> >
> > 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.....)
I think there are quite some other use cases for the session persistence,
e.g. streaming ,etc. The baseline is that with .21 the session should not be
cut off and established again during the handover. That is what I understand
from this "seemless handover" scope.
> 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.
In this sense, the .21 would be only working on Over the air part, and
triggers, e.g. those from L2 to upper layer (MIP, etc) would be excluded
from the spec, since it's also not impacting the air interface. I thought
this was the major drive for setting up the WG.
Cheers
Cheng Hong
> 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.
> > > >
> >
> >
>
>