Software Defined Networking for 802.11 Wireless Networks Ethanol: Software Defined Networking for 802.11 Wireless Networks Henrique Moura, Gabriel V. C. Bessa, Marcos A. M. Vieira, Daniel F. Macedo E-mails: henriquemoura, gabrielvcbessa, mmvieira, damacedo@dcc.ufmg.br

Software-Defined Networking Separation of control and data planes the controller contains all the logic on how the forwarding table is updated the network device executes the forwarding rules programmed by the controller Simple network devices, intelligence at the controller State of the art: OpenFlow Controls only wired networks

Software-Defined Wireless Networks Programmability of network control Abstraction of the underlying infrastructure from the wireless applications Issues: Supporting a large number of subscribers, frequent station mobility, fine-grained measurement and control, and real-time adaptation

Current challenges for SDWN Variable link characteristics Node mobility Quality of service Virtualization Security User Location

SDWN Challenges – Variable links Wireless networks have different error and data rates, that may vary for every packet transmitted Transmission quality is greatly affected by congestion and interferences IEEE 802.11k (Radio Resource Measurement of Wireless LANs) provides mechanisms for access points and stations to dynamically measure and report available radio resources. Variable link characteristics Node mobility Quality of service Virtualization Security User Location Future work

SDWN Challenges – Node mobility SDWN should: Manage node mobility, controlling which users should associate to a certain access point, and Identify when a handoff to another AP is about to take place Variable link characteristics Node mobility Quality of service Virtualization Security User Location

SDWN Challenges – Node mobility IEEE standards addressing mobility 802.11f Enforcement of unique association throughout an ESS Secure exchange of station’s security context between current and new AP during handoff IEEE 802.21 Handovers between heterogeneous wireless networks IEEE 802.11r Fast BSS Transitions with security key negotiation Variable link characteristics Node mobility Quality of service Virtualization Security User Location

SDWN Challenges – QoS Openflow has basic QoS support Set a flow to a queue Setting “meters” (optional feature) So Openflow as it is does not ensure a minimum QoE to the user It is important to integrate 802.11e feature with DSCP for packet classification purposes SDWN provides global knowledge of flows to and from wireless medium Variable link characteristics Node mobility Quality of service Virtualization Security User Location

SDWN Challenges – QoS IEEE 802.11e Service differentiation Error-correcting mechanisms for delay sensitive applications Only handles QoS parameters inside a BSS The controller should be able to configure the QoS parameters in a condinated way of wired and wireless flows Variable link characteristics Node mobility Quality of service Virtualization Security User Location

SDWN Challenges – Virtualization FlowVisor achieves network segmentation, slicing five dimensions: bandwidth, topology, traffic, device CPU and forwarding tables Wireless networks imposes some restriction to virtualization: Wifi APs do not have forwarding tables Wifi router has a limited number of physical radios, tipically one or two Variable link characteristics Node mobility Quality of service Virtualization Security User Location Future work

SDWN Challenges – Security OpenFlow does not emphasize security Security is an important topic in a wireless environment: Eavesdropping or disruption SDWN could facilitate monitoring Allows a clear vision of the network Supplies means to detect intruders Detect abnormal activities/Rogue APs Variable link characteristics Node mobility Quality of service Virtualization Security User Location Future work

SDWN Challenges – User location Location is important for: Location-aware services Handoff decisions Network security Variable link characteristics Node mobility Quality of service Virtualization Security User Location Future work

Ethanol – SDN for IEEE 802.11 Networks

Ethanol Architecture Two types of devices: Controller Ethanol-enabled APs Does not require changes on the terminals Data collected from clients relies on 802.11 standards

Architecture - Design goals Supports IEEE 802.11 as well as Ethernet NICs; No changes on the terminals 802.11 standards Provides APIs for node mobility, AP virtualization, WLAN security, and QoS (on WiFi and Ethernet)

Class Model

Implementation Ethanol prototype Ethanol controller Linux computer using POX/Openflow handles the Ethanol messages encoded with XML-RPC over HTTPS Ethanol-enabled APs Linux computer with Ubuntu LTS 14.04.2 and Atheros AR9170 802.11n wireless card, with Openvswitch and hostapd Broadcom WRT54GL router running OpenWRT and Openvswitch No modification required on client software. Decision is made on AP side through the Ethanol controller.

Experiments

Load-aware association Connection established Check association Association granted Ethanol controller Connection established Clients should associate with the APs that have the smallest number of clients

Ethanol enables load-aware client association Experiments Load-Aware Client Association Ethanol enables load-aware client association

Algorithm 2 sets a bandwidth limit for each flow Quality of Service When a user´s flow starts, the Ethanol router sends a packet_in event to the controller The controller matches some packet parameter (eg. Source IP address) to a preconfigured table This flow is enqueued to a predefined queue Algorithm 2 sets a bandwidth limit for each flow

Quality of Service 1st setup 2nd setup Ethanol router QoS = 6 10Mbps controller QoS = 1

Ethanol enables QoS traffic Quality of Service 6/10 3/10 6/9 3/9 1/10 1st round 2nd round Ethanol enables QoS traffic

ARP Filtering Cheng et. at. analyzed traces of a WiFi campus network concluded that ARP packets consume almost 10% of the air time of wireless links

ARP Filtering Setup Ethanol router ARP traffic: only to/from client controller 1st round: without arp control 2nd round: arp control activated

Ethanol reduces ARP traffic Experiments ARP Overhead With ARP control activated, we only notice ARP requests from the wireless client and ARP replies to it Ethanol reduces ARP traffic

Conclusions Ethanol extends the SDN concept to allow the programmability of wireless APs It provides an API for the control of AP events, allowing new applications in QoS Mobility control Security Virtualization etc

Future Work Implement a larger subset of the functions Use cases on security and virtualization Evaluate our prototype on larger networks with more APs, clients, and traffic Implement new management algorithms for wireless networks

SDNs don´t solve it all !

Architecture Ethanol API is designed upon an object-oriented approach AccessPoint entity Link entity VirtualAcesssPoint entity Network entity Station entity Flow entity from the OpenFlow specification

Load-aware association When a user is connecting to an AP, the APx sends a association message request to Ethanol controller The controller checks all APs in range of the client Controller requests the number of clients on each AP The connection is accepted if Apx is among the APs with minimum number of clients Clients should associate with the APs that have the smallest number of clients

ARP Filtering When a wireless station wants to transmit, it needs to perform a ARP resolution, so it sends a ARP request (broadcast) through the network This request is intercepted by our controller If the controller knows the requested MAC, it drops the request message and sends a ARP response to the client If the controller does not know the MAC, it floods the network (same process as ARP) When the ARP response arrives at the switch, this message is also intercepted, sent to the controller, the controller drops this message and sends the response only to the client