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

[Paulo Francisco (paulo]

Title: RE: [Lwapp] Another Way to Think about CAPWAP

 

We should actually be creating at least 2 separate categories for
interchange:
Control - Configuration,statistics, events, actions - This could be a
TCP based stream to provide immediate indication as to whether the AP-AC
connection has been lost. Encrypted if necessary.

<PRC> I guess you'd better provide your definition of immediate, because
TCP doesn't provide this.

Data - This could be UDP/IP_in_IP encapsulation to avoid congestion. If
the packet is lost the original client will most likely re-transmit.
<PRC> Right - so don't forward 802.11 mac mgmt frames, and reconstruct
a protocol that does the same thing that 802.11 mac, except extend it
for every standard the IEEE publishes.

[PF>] Well.. I would hope it wouldn’t be quite that bad. I would expect any future protocols to have some similarity at least in terms of control functions to those provided by 802.11 . Further,  I don’t truly believe that every single aspect of the packet is actual meaningful to the AC. Some are only meaningful to the AP so why send them up? With that in mind an abstraction protocol (even if at this point it truly mimics 802.11 in its payload) may actually be what will keep us from having to re-design this entire infrastructure next time IEEE introduces a new protocol and an new access mechanism comes on the market.This would accomplish true separation between APs and ARs models (even if you’re required to do 802.1d at the APs)

As expressed by other participants in this thread, if all we’re doing is defining a transport mechanism for un-translated frames across a medium, we can then probably simply identify the message set and use a tried-and-tested existing protocol (with embedded security if need be).

I mean, you’re already going to have to define message sets outside of the 802.11 specification, particularly for discovery and configuration so why stop half way? Why not simply finish remapping the rest of the operations and obtain true separation.
 

PatC
-----Original Message-----
From: Yang, Lily L [mailto:lily.l.yang [at] intel.com]
Sent: Monday, November 17, 2003 7:29 PM
To: Rama Krishna Prasad; James Kempf; Pat R. Calhoun; Paulo Francisco;
Jim Murphy; Branislav Meandzija; LWAPP
Subject: RE: [Lwapp] Another Way to Think about CAPWAP

BTW, while we are on it, may I ask why UDP is assumed here? I know that
is what LWAPP uses, but I don't really know why though. Why isn't
reliability needed for LWAPP, given that configuration messages are
mission critical for the WLAN operation.

-----Original Message-----
From: lwapp-admin [at] frascone.com [mailto:lwapp-admin [at] frascone.com] On
Behalf Of Rama Krishna Prasad
Sent: Monday, November 17, 2003 4:19 PM
To: James Kempf; Pat R. Calhoun; Paulo Francisco; Jim Murphy; Branislav
Meandzija; LWAPP
Subject: Re: [Lwapp] Another Way to Think about CAPWAP

I think, breaking down the problem into secure transport and
signaling/configuration
is very good.
Secure transport can be achieved by IPSEC/IKE or even L2TPoverIPSEC.
This group can concentrate on defining signaling/configuration protocol
based on UDP, that is
required to signal messages from AP and configuration information from
AC to AP.

Rama Krishna
Intoto Inc.
www.intotoinc.com


----- Original Message -----
From: "James Kempf" <kempf [at] docomolabs-usa.com>
To: "Pat R. Calhoun" <pcalhoun [at] airespace.com>; "Paulo Francisco"
<paulo [at] chantrynetworks.com>; "Jim Murphy"
<jmurphy [at] trapezenetworks.com>; "Branislav Meandzija"
<bran [at] arraycomm.com>; "LWAPP" <lwapp [at] frascone.com>
Sent: Monday, November 17, 2003 3:11 PM
Subject: Re: [Lwapp] Another Way to Think about CAPWAP


> >There is also the tunnel setup protocol, which is what LWAPP
basically
> > is.
>
> So considering the alternatives, here is how they would set up:
>
> IP in IP - no setup protocol.
>
> IPsec  - IKE for key exchange, then everything going between the two
> endpoints to the indicated port is encrypted using ESP. If transport
mode is
> used, there's no tunnel overhead. One could also use the new BEET
(Bound End
> to End Tunnel) mode to reduce transport overhead for tunnel mode, but
that
> is currently somewhat controversial among IETF security folks.
>
> TLS over UDP - TLS to set up on the indicated port, then everything is
> encrypted at the transport layer.
>
> L2 tunnel - no setup protocol (so far as I am aware, perhaps 802 has
> something though).
>
> The charter requires an existing tunnel mechanism to be used, so two
out of
> the three would already have a mechanism. Perhaps there are more
mechanisms
> I'm missing?
>
> Or is there something else required to set up the tunnel besides
agreeing on
> a port number and encapsulation format?
>
> >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.
>
> Is this to keep the state machine synchronized between the two sides?
Or is
> there some other reason for it?
>
>             jak
>
> _______________________________________________
> Lwapp mailing list
> Lwapp [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/lwapp

_______________________________________________
Lwapp mailing list
Lwapp [at] frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp