RE: [Lwapp] Another Way to Think about CAPWAP
From: Branislav Meandzija (branarraycomm.com)
Date: Fri, 14 Nov 2003 19:56:31 -0600 (CST)
[PF>] True, but as demonstrated by DIRAC and a few similar
implementations an abstraction protocol is very much doable. While it is
true that some of the message set will be pure duplicates of 802.11
messages [and maybe with the current scope of definitions this is
definitely true], it does stand to reason that it isn't hard to imagine
that other technologies would provide a similar set of functionality
(user associate notification, disconnect user, etc)  . All it takes is
to identify the set of parameters that make sense to an AC (what does it
actually need to know) [DIRAC] actions, events and statistics and you
should be able to achieve the goal of portability.

<PRC> ok - so you take an 802.11 message, decompose it, create a request,
send it to the AC, the AC responds, the AP breaks it apart, creates an 802.11
response and then sends it to the user.

<PRC> Unnecessarily complex. The message set is already there? Why re-ivent it?
You'll only end up increasing latency.
--
BM - The solutions are actually not that different in performance as the 802.11
message break down needs to happen somewhere, either in the AP, or the AC. The
difference is that instead of using a cross-technology management standard 
and architecture, the solution you describe proposes a strap-on protocol in 
between 
the AP and AC.
--
Such specification
IMO would definitely assist in the goal of defining interoperability, as
it could definitely leverage AP functionality implemented by the AP
vendor. Conversion of APs to support the interoperability would become a
simple matter of implementing the translation protocol.  As an add-on
module it would not require many changes to the 802.11 stack other than
interface points.

<PRC> FWIW, my system works great, we got WiFi certified and are completely
interoperable with all clients out there... so I'm not sure that I follow.
The nice thing about using the 802.11 mac mgmt messages is that you already
have guaranteed interoperability - you're relying on an existing protocol and
just processing it in another system.

--
BM - How do other vendor's AP's and AP managers interoperate with your system? 
If they
want to fit in, both AP and management solution vendors would have to add 802.11
message processing functionality between AP and AC. If a management standard 
was used, 
management vendors would just need to support the data model (e.g. MIB) and 
provide 
applications, and AP vendors would just need to extend their data model (e.g. 
MIB) 
and data model instrumentation. That would seem simpler than repurposing 802.11 
mac
mngmt messages for AP/AC communication, and doing custom hacks in the AP and 
the manager.

Branislav

Branislav


Results generated by Tiger Technologies using MHonArc.