Lwapp Mailing List: RE: [Lwapp] Another Way to Think about CAPWAP

[Branislav Meandzija (bran]

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.

<PRC> Incorrect. On the AP you need to break down the message, create a new 
one, and again when receiving the reply from the AC. This is not required if 
you are simply tunneling the mac management packet to the AC.

BM - Do you think the microseconds that this will take will make a difference?
--
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> I see. I find it rather interesting to note that APs actually already 
have an 802.11 stack and not processing them, but rather tunneling them to a 
centralized controller will somehow lower chances of interoperability vs. 
creating a new protocol stack.

<PRC> Intercepting these packets are calling a function with the packet so that 
they get tunneled instead of calling a function to create a new request doesn't 
seem like a huge difference in how difficult it is to implement (in fact, I'd 
argue that tunneling is safer because you really can't screw something up - 
you're simply forwarding the request). Oh, and tunneling the packets also 
allows you to automagically handle any new 802.11 extensions that get created.

<PRC> I guess you can safely assume that I respectfully disagree.


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.

<PRC> Well other APs don't currently interoperate with my system - that's kind 
of the point of the proposed WG. But I think that I understand your point here. 
You're proposing SNMP as a method of sending link layer information to the AC. 
If this is in fact what you are saying, I think that there is some gross 
mis-use of protocol being proposed here. We need something compact, fast and 
requires low cpu overhead. Last time I checked out my switch's SNMPv3 source 
code, it really didn't meet any of those three requirements (why do I have a 
feeling I'm about to get an e-mail informing me that there's an implementation 
of SNMPv3 that fits in 4k ;-).

BM - Just designing an LWAPP SNMP MIB is a distinct possibility and the 
shortest path to getting the standard done. Another possibility if there is a 
religious war is to start with a separation of the application and the 
transport aspects here. The main LWAPP RFC would be application. The main 
transport mapping RFC could be LWAPP over SNMP. But perhaps other transport 
options could be given?

Branislav

PatC