| RE: Another Way to Think about CAPWAP | <– Date –> <– Thread –> |
|
From: Pat R. Calhoun (pcalhoun |
|
| Date: Mon, 17 Nov 2003 15:58:24 -0600 (CST) | |
So if the protocol is just a tunnel for 802.11 MAC management messages, why
do we need an IETF WG to define a new protocol? The only issue is agreeing
what the tunnel should be (IP in IP, IPsec ESP, TLS over UDP, an L2 tunnel,
etc.) for interoperability. The functional interface between the AP and AC
is where a protocol would be defined, and if it is just a tunnel interface,
the functional interface is in the AC, and consists of decoding 802.11 MAC
management frames and recoding the responses, which is not a network
interface.
<PRC> There is also the tunnel setup protocol, which is what LWAPP basically
is. LWAPP also consists of an in-band configuration protocol to the AP - allowing
a state machine to use the same control mechanism from the AC to the AP.
PatC
- RE: Another Way to Think about CAPWAP, (continued)
- RE: Another Way to Think about CAPWAP Jim Murphy, November 14 2003
- RE: Another Way to Think about CAPWAP Pat R. Calhoun, November 14 2003
- RE: Another Way to Think about CAPWAP Pat R. Calhoun, November 17 2003
- RE: Another Way to Think about CAPWAP Pat R. Calhoun, November 17 2003
- RE: Another Way to Think about CAPWAP Pat R. Calhoun, November 17 2003
-
Re: Another Way to Think about CAPWAP James Kempf, November 17 2003
- Re: Another Way to Think about CAPWAP Rama Krishna Prasad, November 17 2003
-
RE: Another Way to Think about CAPWAP Pat R. Calhoun, November 17 2003
- Re: Another Way to Think about CAPWAP James Kempf, November 17 2003
Results generated by Tiger Technologies using MHonArc.