The LWAPP Comeback

It turns out the lightweight access point protocol (LWAPP) -- a methodology for controlling so-called dumb access points from a switch -- is alive and well at the Internet Engineering Task Force (IETF).

In fact, an IETF group is recommending LWAPP as the protocol of choice for CAPWAP, the umbrella specification for the control and provisioning of WiFi access points.

You can read all about it in deep -- and tedious -- detail here.

But the crux of the biscuit is:

"LWAPP has the most complete base protocol and is flexible enough to be extended or modified by the working group. We therefore recommend LWAPP be used as the basis for the CAPWAP protocol."

Unstrung predicted that LWAPP might get just such a shot in the arm after Cisco Systems Inc. (Nasdaq: CSCO) bought Airespace, as the protocol was originally that startup's baby. (See The Switch Fix Is In.)

But it's still not particularly clear when this work might result in a standardized control mechanism for APs. Best not to hold your breath!

— DanWAP JonesWAP, Site Editor, Unstrung

xip 12/5/2012 | 2:56:14 AM
re: The LWAPP Comeback Does this mean that LWAPP is the way forward? I guess airespace products will continue to be supported.

Can somebody comment on this please?

Thanks in Advance
joset01 12/5/2012 | 2:56:13 AM
re: The LWAPP Comeback Hard to say for sure yet, but if the IETF goes forward with LWAPP and Cisco integrates it into its product line, then we're closer to a standard for controlling APs.

wifihammer 12/5/2012 | 2:56:09 AM
re: The LWAPP Comeback Dan, you are right if that standard is the Airespace architecture with little room for inovation. If the LWAPP protocol is adopted, what other switch vendor would foolish enough to adopt it? AP vendors may want a part of Cisco's AP market share, but switch vendors won't benefit from that. Switch vendors would need a standards change to implement a new feature.

Cisco pulled a fast one in the CAPWAP WG by claiming IPR on all the proposals that were put forward including those that were authored by other companies.

See http://www.ietf.org/ietf/IPR/c... for the statement.

You can read all about the fun and games on the CAPWAP archive at http://mail.frascone.com/piper... It really starts getting fun around August of this year ;-)

Personally, I like the SLAPP submission that just call for discovery and download of code into commodity APs. That way you could change switch vendors and keep all the same APs.
whithercisco 12/5/2012 | 2:56:05 AM
re: The LWAPP Comeback Check this out from the IETF recommendation draft.

Wasn't GRE proposed originally by Aruba and later also incorporate by the Cisco WLSM solution?

It looks like the recommendation was to use LWAPP control plane but GRE for data plane. This sounds like a mix between LWAPP and GRE. But as usual the slick marketing dudes at Ciscospace seem to claim victory for LWAPP.

Dan - what are your thoughts on this?

LWAPP's layer 3 data encapsulation meet's the working group
objectives. However, The evaluation team recommends the use of a
standards based protocol for encapsulation of user data between the
WTP and AC. GRE or L2TP could make good candidates as standards
based encapsulation protocols for data tunneling.

Using a standard gives the opprotunity for code reuse, whether it is
off-the-shelf microcode for processors, code modules that can be
purchased for real time operating systems, or open-source
implementations for Unix based systems. In addition, L2TP and GRE
are designed to encapsulate multiple data types, increasing
flexibility for supporting future wireless technologies.
whithercisco 12/5/2012 | 2:56:05 AM
re: The LWAPP Comeback More stuff from the draft that makes LWAPP security questionable IMHO.

LWAPP's security mechanisms appear satisfactory and could serve CAPWAP going forward. However, the evaluation team recommends adoption of a standard security protocol for the control channel.

The evaluation team recommends that whatever security protocol is specified for CAPWAP, that it's use cases must be described in detail. LWAPP does a good job of this with it's proposed, proprietary method. If an updated specification is developed, it should contain at least one mandatory authentication and cipher method. For example, pre-shared key and x.509 certificates could be specified as mandatory authentication methods and AES CCMP could be selected as a mandatory cipher.

Given the possibilities for code reuse, industry reliance on TLS and the future for TLS, DTLS may be a wise alternative to a security method specific to CAPWAP. In addition, use of DTLS would likely expidite the approval of CAPWAP as a proposed standard over the use of CAPWAP specific security mechanisms.
Sign In