RE: Another Way to Think about CAPWAP
From: Pat R. Calhoun (pcalhounairespace.com)
Date: Mon, 17 Nov 2003 13:02:10 -0600 (CST)
Title: RE: [Lwapp] Another Way to Think about CAPWAP


<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?

<PRC> Yes... it adds latency, and under load is where you see the difference. It also requires more engineering work at the IETF to try to replicate the 802.11 mac management protocol - and make sure that it keeps up with the various TGs at IEEE.

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> repurposing 802.11 mac messages -> they are used EXACTLY the way the 802.11-1999 standard specifies. There is no intent to change the meaning, or behavior, of 802.11. If this is the intent of anyone in this (proposed) WG, then we should talk.


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?

<PRC> Again, the main issue is how to get a state machine that includes multiple protocols, each with different behaviors and timing characteristics... and yet make it all work. I just don't see it happen.

PatC

Results generated by Tiger Technologies using MHonArc.