Controlled Landing

Unintentionally Dynamic

The port problem of wireless clients adds an involuntary dynamic to OpenFlow application development. Generating a dynamic flow that sends packets to port 5 and the connected wireless client can cause complications: If a wireless client then switches to power-saving mode, it might reappear as the sixth client when it logs back in and be connected to WX port 6 in the OpenFlow logic. Developers for the WX have to pay special attention to this possibility.

The administrator of the Zodiac WX cannot manage the flow rules locally but relies on an OpenFlow controller. In the test, I used Floodlight [6] and OpenDaylight [7]. In its early versions, the WX did not work with OpenDaylight, but Northbound fixed that.

The SDN controller configuration is managed in the web interface under Control | Settings (Figure 4). The Auth Bypass setting ensures that the access point excludes packets that are only used to log on wirelessly (they form their own EtherType) from further flow processing. Alternatively, you need to set up a flow manually that passes these packages through.

Figure 4: The SDN controller configuration is also possible in the web interface.

Do It Yourself

As usual with OpenFlow-controlled devices, the admin of the device is also its programmer and has to take care of everything personally. To operate a wireless client with activated Auth Bypass , you need to set up flows for ARP and DHCP. The OpenDaylight version of the flow description is shown in Listing 1.

001 [
002    {
003       "flow" : [
004          {
005             "instructions" : {
006                "instruction" : [
007                   {
008                      "apply-actions" : {
009                         "action" : [
010                            {
011                               "output-action" : {
012                                  "output-node-connector" : "FLOOD"
013                               },
014                               "order" : 0
015                            }
016                         ]
017                      },
018                      "order" : 0
019                   }
020                ]
021             },
022             "priority" : "5",
023             "match" : {
024                "ethernet-match" : {
025                   "ethernet-type" : {
026                      "type" : "0x806"
027                   }
028                }
029             },
030             "table_id" : 0,
031             "id" : "f1"
032          }
033       ]
034    },
035    {
036       "flow" : [
037          {
038             "match" : {
039                "ip-match" : {
040                   "ip-protocol" : "17"
041                },
042                "ethernet-match" : {
043                   "ethernet-type" : {
044                      "type" : "0x800"
045                   }
046                },
047                "udp-destination-port" : "67"
048             },
049             "table_id" : 0,
050             "id" : "DHCP1",
051             "instructions" : {
052                "instruction" : [
053                   {
054                      "order" : 0,
055                      "apply-actions" : {
056                         "action" : [
057                            {
058                               "order" : 0,
059                               "output-action" : {
060                                  "output-node-connector" : "FLOOD"
061                               }
062                            }
063                         ]
064                      }
065                   }
066                ]
067             },
068             "priority" : "10"
069          }
070       ]
071    },
072    {
073       "flow" : [
074          {
075             "match" : {
076                "ip-match" : {
077                   "ip-protocol" : "17"
078                },
079                "ethernet-match" : {
080                   "ethernet-type" : {
081                      "type" : "0x800"
082                   }
083                },
084                "in-port" : "65",
085                "udp-destination-port" : "68"
086             },
087             "table_id" : 0,
088             "id" : "DHCP2",
089             "priority" : "10",
090             "instructions" : {
091                "instruction" : [
092                   {
093                      "order" : 0,
094                      "apply-actions" : {
095                         "action" : [
096                            {
097                               "order" : 0,
098                               "output-action" : {
099                                  "output-node-connector" : "NORMAL"
100                               }
101                            }
102                         ]
103                      }
104                   }
105                ]
106             }
107          }
108       ]
109    }
110 ]

The output port used here is FLOOD, the OpenFlow counterpart to a broadcast. Once the controller has learned which client belongs to which port, it can cause higher priority flows to output the ARP or DHCP packets for a particular client only on its port.

The Zodiac WX is a hybrid OpenFlow switch, which means it supports the NORMAL output action. This follows the saying: Send the package where it belongs according to the forwarding table. For switches, this would be the destination MAC address and applies here.

Because the wireless clients do not use physical ports, another special feature appears that is not seen with other OpenFlow devices: The MAC destination address and the port must match or be made to match.

The assignment follows the order when logging in, as described above. OpenFlow assigns port 1 to the 5GHz client that is logged on first. It also remembers the MAC address of the client. This means that the OpenFlow action output:1 must overwrite the target MAC address for the packet to arrive on the appropriate radio channel.

The already mentioned nnofagent program lists the flows installed by the controller with the -f option and corresponds to the output in the web interface. The access point also supports the OpenFlow Group and Meter properties, with the first action summarizing and the second contributing to throughput control. To list these parameters, use -g (for groups) and -m (for meters).

REST API

The configuration of each network device also includes the configuration of IP addresses and, if applicable, virtual LANs (VLANs), which, however, are not supported by the OpenFlow protocol. Instead, the latest firmware release (1.10 at the time of the test) provides a REST API that allows you to perform these basic configurations.

Therefore, you can develop an SDN controller with the appropriate driver to control the entire configuration of the device, which means that an application on this controller can span entire networks and not just control traffic flows.