RE: triggers vs. O/S
>
> Do you feel that we can /cannot define anything in the standard about
the > locally determined triggers?
>
For predictive triggers (Link_Going_Down, etc.) you need some
communication between MN and network attachment points. In such cases
you need a L2 transport and some kind of framing mechanism to delivery
the information. Clients also need to register to receive such
notifications. 802.21 can define a general model for this and the
technology specific mapping can be included in respective technology
specific standards.
For other event based triggers which are local, you likely don't need
such communication, and it comes down to more of a local client side
implementation.
Regards
-Vivek
-----Original Message-----
From: owner-stds-802-21@listserv.ieee.org
[mailto:owner-stds-802-21@listserv.ieee.org] On Behalf Of
Michael.G.Williams@nokia.com
Sent: Thursday, May 06, 2004 9:46 AM
To: vladimir.yanover@ALVARION.COM; STDS-802-21@listserv.ieee.org
Subject: triggers vs. O/S
Vladimir,
There has been presented a notion of triggers delivered locally up the
stack from L1/L2 detection on the mobile or the network attachment
point. There has also been the notion of transmitted triggers which are
sent from the MN or (existing or potential) attachment points, to each
other.
The later will arrive in the L1/L2 of the device and presumably be
delivered in the same fashion as the former.
The delivery fashion will most likely be quite different on Symbian or
Linux or Solaris or Java than on CE or XP or NT. That delivery might be
signal oriented or method oriented or an ABI within the OS network stack
for example.
Do you feel that we can /cannot define anything in the standard about
the locally determined triggers?
Best Regards,
Michael Williams
-----Original Message-----
From: owner-stds-802-21@LISTSERV.IEEE.ORG
[mailto:owner-stds-802-21@LISTSERV.IEEE.ORG]On Behalf Of ext Vladimir
Yanover
Sent: Thursday, May 06, 2004 8:59 AM
To: STDS-802-21@LISTSERV.IEEE.ORG
Subject: Re: contributions for upcoming May 2004 meeting - L2.5 C
oncrete Model ?
Peretz, Mike
I absolutely agree that the standards must not be based on product of
specific vendor.
Unfortunately, viability of this specific applicaton scenario does
depend on
special features
provided [or not] by OS vendors. Probably, there are more scenarios on
the
table?
Vladimir
-----Original Message-----
From: Peretz Feder [mailto:pfeder@lucent.com]
Sent: Thursday, May 06, 2004 4:47 PM
To: Mike MORETON
Cc: Vladimir Yanover; STDS-802-21@listserv.ieee.org
Subject: Re: [802.21] contributions for upcoming May 2004 meeting - L2.5
C
oncrete Model ?
Mike, Vladimir:
There are already enough interested companies that fill the gaps we are
discussing. I don't think we should be alarmed by show stoppers, nor
define
our standards based on a given vendor's
product.
Peretz
Mike MORETON wrote:
> I would expect that if 802.21 forge ahead working on new technology
for
handover, then all the interested companies will come to the party.
>
> I don't think 802.21 should worry too much about what another company
might, or might not have done. If it's significantly different I'd
expect
them to show up and make their presence known
>
>
> Mike.
>
> -----Original Message-----
> From: owner-stds-802-21@listserv.ieee.org
[mailto:owner-stds-802-21@listserv.ieee.org] On Behalf Of Vladimir
Yanover
> Sent: Thursday, May 06, 2004 1:56 PM
> To: STDS-802-21@listserv.ieee.org
> Subject: Re: [802.21] contributions for upcoming May 2004 meeting -
L2.5 C
oncrete Model ?
>
> Yes, Mike
> Does Microsoft have representative in 802.21?
> In 802.16e [where I spend most of my time] it does.
> This detail might be a show stopper for the scenario under discussion.
> Vladimir
>
> -----Original Message-----
> From: Mike MORETON [mailto:mike.moreton@st.com]
> Sent: Thursday, May 06, 2004 1:55 PM
> To: Vladimir Yanover; STDS-802-21@listserv.ieee.org
> Subject: RE: [802.21] contributions for upcoming May 2004 meeting -
L2.5
> C oncrete Model ?
>
> Vladimir,
>
> If Microsoft want to make a proposal based on their experience, and it
> proves to be suitable as a general standard, then the group should
accept
> it.
>
> I don't think the IEEE/IETF should totally abdicate standards setting
to
> Microsoft.
>
> Mike.
>
> -----Original Message-----
> From: owner-stds-802-21@listserv.ieee.org
> [mailto:owner-stds-802-21@listserv.ieee.org] On Behalf Of Vladimir
Yanover
> Sent: Thursday, May 06, 2004 11:03 AM
> To: STDS-802-21@listserv.ieee.org
> Subject: Re: [802.21] contributions for upcoming May 2004 meeting -
L2.5 C
> oncrete Model ?
>
> All,
>
> Thanks to those provided clarifications. I am not a specialist in
Windows.
> My concern is whether Windows has a module placed between, say, IP
> layer and drivers of network adapters and capable of re-routing
packets
> each time to proper adapter [the one connected to the corresponding
> network].
> Seems that the concern has some ground.
> Windows is not the only OS for portable / handheld devices, but
certainly
> significant one.
>
> Vladimir
>
> -----Original Message-----
> From: macsbug@research.att.com [mailto:macsbug@research.att.com]
> Sent: Wednesday, May 05, 2004 10:01 PM
> To: STDS-802-21@listserv.ieee.org
> Cc: macsbug@research.att.com
> Subject: RE: contributions for upcoming May 2004 meeting - L2.5 C
oncrete
> Model ?
>
> It may sound digressing, but...
>
> NDIS driver specification is publicly accessible which, for 802.11,
maps
> roughly to a subset of MLSE primitives and some MIB variables.
> Other parts of NDIS is more generic to other types of interfaces.
>
> Linux Wireless driver extension is now part of regular distributions
and
> provides some 802.11 specific calls as well.
>
> You "MAY" want to glance it for what have been deemed necessary for
the
> OS (or whatever) to learn from NIC cards beyond passing packets as
"what
> has been done" or "what is lacking" perspective, certainly not as a
> model.
>
> 802.21/DNA, etc will not have to be specified but will have to be
> "realized" as part of drivers or OSes, thus these may be of interest.
>
> Byoung-Jo "J" Kim
> macsbug@research.att.com
> AT&T Labs - Research
> http://www.research.att.com/areas/wireless/
>
> tel)732-420-9028
> mobile) 917-853-3830
>
> -----Original Message-----
> From: Ajay Rajkumar [mailto:ajayrajkumar@lucent.com]
> Sent: Wednesday, May 05, 2004 2:28 PM
> To: STDS-802-21@LISTSERV.IEEE.ORG
> Subject: Re: contributions for upcoming May 2004 meeting - L2.5 C
> oncrete Model ?
>
> We are an IEEE standards group. I would think that, the very fact that
> one would
> have to bank on a particular vendor to disclose "what they can
disclose"
> should
> make this a non-starter.
>
> -ajay
> Chair, IEEE 802.21
>
> On 5/5/2004 1:25 PM, Iyer, Prakash wrote:
> > Vladimir - short answer I believe is yes - and improving. A
monitoring
> > Microsoft person should step up and comment to whatever extent they
> can
> > disclose.
> >
> > -----Original Message-----
> > From: owner-stds-802-21@listserv.ieee.org
> > [mailto:owner-stds-802-21@listserv.ieee.org] On Behalf Of Vladimir
> > Yanover
> > Sent: Wednesday, May 05, 2004 9:54 AM
> > To: STDS-802-21@listserv.ieee.org
> > Subject: Re: [802.21] contributions for upcoming May 2004 meeting -
> L2.5
> > C oncrete Model ?
> >
> > Ajay and All,
> >
> > I have a question on the scenario under consideration.
> > Is there a candidate "intelligent entity" in the architecture of
e.g.
> MS
> > Windows? I mean part of Windows that communicates to multiple MACs
> > [network adapters], feels their state [connected/disconnected] and
> > switches binding relationship IP <=> adapter from one adapter to
> > another. I am interested to learn more on the issue.
> >
> > Thanks
> >
> > Vladimir
> >
> > -----Original Message-----
> > From: Ajay Rajkumar [mailto:ajayrajkumar@lucent.com]
> > Sent: Tuesday, May 04, 2004 9:26 PM
> > To: STDS-802-21@LISTSERV.IEEE.ORG
> > Subject: Re: [802.21] contributions for upcoming May 2004 meeting -
> L2.5
> > Concrete Model ?
> >
> >
> > Mike, DJ,
> >
> > It may not be as bad as it sounds. The key in Mike's scenario is
that
> > the laptop is "associated with WLAN" simultaneously with its
ethernet
> > connection.
> > Because
> > of its active association with WLAN an "intelligent entity" above
> > various MACs would have collected sufficient information and then
> > subsequently can make a decision to switch over to WLAN as and when
> LAN
> > connection goes down.
> >
> > In fact, the scenario may be even simpler/faster if the two
interfaces
> > are on the same subnet (DJ's office scenario)!
> >
> > -ajay
> >
> > On 5/4/2004 2:00 PM, Mike MORETON wrote:
> >
> >>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.
> >>>>
> >>>
> >
> >
> > This mail passed through mail.alvarion.com
> >
> >
>
************************************************************************
> > ****
> > ********
> > This footnote confirms that this email message has been scanned by
> > PineApp Mail-SeCure for the presence of malicious code, vandals &
> > computer viruses.
> >
>
************************************************************************
> > ****
> > ********
> > This mail was sent via mail.alvarion.com
> >
> >
>
************************************************************************
> > ************
> > This footnote confirms that this email message has been scanned by
> > PineApp Mail-SeCure for the presence of malicious code, vandals &
> > computer viruses.
> >
>
************************************************************************
> > ************
>
> This mail passed through mail.alvarion.com
>
>
************************************************************************
****
> ********
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals &
computer
> viruses.
>
************************************************************************
****
> ********
> This mail was sent via mail.alvarion.com
>
>
************************************************************************
****
> ********
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals &
computer
> viruses.
>
************************************************************************
****
> ********
>
> This mail passed through mail.alvarion.com
>
>
************************************************************************
****
> ********
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals &
computer
> viruses.
>
************************************************************************
****
> ********
> This mail was sent via mail.alvarion.com
>
>
************************************************************************
****
********
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals &
computer
viruses.
>
************************************************************************
****
********
This mail passed through mail.alvarion.com
************************************************************************
****
********
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals &
computer
viruses.
************************************************************************
****
********
This mail was sent via mail.alvarion.com
************************************************************************
************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals &
computer viruses.
************************************************************************
************