Network Topology (logical, datapath)
OpenFlow APs are scattered in the building and we don't always have direct physical connection from our OpenFlow switch to them. This configuration creates multiple OpenFlow islands, which most of the current OpenFlow controllers ('controller applications' to be exact) do not support. We use L2 over IP tunneling software (capsulator) to deal with this situation.
The figure below illustrates how tunneling works in OpenFlow WiFi network. The right column shows the switch adjacency we would like to have and the left column shows the physical topology we deployed. The challenge here is we have many (~30) APs that use tunneling and we need to feed their traffic into the different physical port of our OpenFlow switch. Noiive way to do this is to have 30 of PCs on which run tunneling software. Another naiive way is to have a single PC which have 30 of ethernet interfaces. Both are not practical. Insted we used a single PC with two ethernet interfaces and a VLAN tag switch. The PC running tunneling software feeds the traffic from an AP (say AP number X) to the VLAN tag switch with vlan tag X. The VLAN tag swtich is configured in such a way that it has as many vlans as APs and each vlan has two ports -- a non-tag port and vlan tagged port where all the vlans share a single tagged port which is connected to the tunneling termination PC. That way, the packet from PC with different vlan tag is forwarded to the different non-tag ports.
One caveat is that the VLAN swtich (Quanta in the figure) drops some L2 control packet including 802.1 standard LLDP packet (destination MAC address starts with 01:80:C2), which many OpenFlow controllers use to discover the network topology. Using non-standard LLDP destination can avoid this issue.
For WiFi APs, visit Gates Network OpenFlow WiFi AP Info (restricted access)