CAPWAP networking protocol (RFC #5415) protocol as all Wi-Fi engineers would know is a widely used networking protocol that enables a central WLAN controller to manage a collection of Wireless Access Points, and most of the WLAN industry is using the CAPWAP in their solutions the same way.
However, if we see little more into the CAPWAP semantics, CAPWAP networking protocol is designed very flexibly, and can be leveraged advantageously in multiple wireless scenarios and deployments.
One such deployment scenario, I can think of is selective data path forwarding from an edge WLAN controller to a remote WLAN controller.
But, what are the applications of such a deployment scenario? The answer can be a application where a corporate employee connecting to a public W-Fi network (managed by a telecom WLAN controller) needs to access the corporate network managed by the corporate WLAN controller. For this to happen, the employee’s data traffic needs to be routed by the telecom controller to corporate controller.
Although, there are other widely used existing methods to achieve it, such as EOGRE and EOIP, but they do not provide the CAPWAP benefits to the WLAN controller.
When I say, CAPWAP benefits to the remote WLAN controller, the examples are:
Since CAPWAP header has intrinsic support of fragmentation, Outer IP fragmentation can be avoided/minimized on the network between Edge and a Remote WLAN controller whenever the IP frame carrying CAPWAP encapsulated payload exceeds the MTU of a particular network segment.
CAPWAP header has multiple fields, such as Wireless Information, and Radio field that can be filled appropriately while forwarding the data packets to the remote WLAN controller. The remote controller, in turn, can use this wireless information to build instant wireless statistics, client location tracking, etc.
CAPWAP networking protocol has full fledge support of robust security based on DTLS mechanism, so there is no need of special security mechanism, such as IPSEC. Also, a remote WLAN controller already deploys the software/hardware engine to decrypt the DTLS encrypted CAPWAP packets if it supports CAPWAP to manage wireless Access Points.
So, how to extend the CAPWAP to forward Client data packets received on Edge controller to the Remote WLAN controller?
Fairly easy to implement, the edge and the remote WLAN controller can be statically configured with information, such as Edge and remote controller IP Address, to form static CAPWAP data tunnel between them after doing a DTLS handshake.
Once the CAPWAP data tunnel is established between the two controllers, static/dynamic traffic mapping can be configured on the edge controller based on traffic type, SSID, etc. to forward the required data traffic via the inter-controller CAPWAP data tunnel.