| RE: [Lwapp] Another Way to Think about CAPWAP | <– Date –> <– Thread –> |
|
From: Branislav Meandzija (bran |
|
| 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
-
RE: [Lwapp] Another Way to Think about CAPWAP Branislav Meandzija, November 14 2003
- RE: [Lwapp] Another Way to Think about CAPWAP Branislav Meandzija, November 17 2003
Results generated by Tiger Technologies using MHonArc.