Re: [802.21] contributions for upcoming May 2004 meeting - L2.5 C oncrete Model ?
Scope defines only the problem not the solution. Layer 2.5 based solutions have
been discussed in various context within the group.
-ajay
On 5/5/2004 3:43 PM, Johnston, Dj wrote:
> Yes, I think this has been very clear in the scoping discussing we've
> had as a group. Policy engines exist, we don't define them but me might
> feed them with the information they need.
>
> DJ
>
>
> -----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 11:40 AM
> To: STDS-802-21@LISTSERV.IEEE.ORG
> Subject: Re: [802.21] contributions for upcoming May 2004 meeting - L2.5
> C oncrete Model ?
>
>
> That and the various discussion threads brings one point out very
> clearly - 802.21 needs to make a clear distinction between what's
> absolutely needed to improve or enable efficient handovers from a
> cross-802 / cross 802-xG protocol exchange and standardized data
> representation perspective and what is really a matter of software
> implementation. Getting into client software policies and such should
> not be in scope of 802.21 which is where some of these discussions have
> veered off.
>
> -----Original Message-----
> From: owner-stds-802-21@listserv.ieee.org
> [mailto:owner-stds-802-21@listserv.ieee.org] On Behalf Of Ajay Rajkumar
> Sent: Wednesday, May 05, 2004 11:28 AM
> To: STDS-802-21@listserv.ieee.org
> Subject: Re: [802.21] 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.
>>**********************************************************************
>>**
>>************
>