1. Software Defined Networking for 802.11 Wireless Networks
Ethanol:
Software Defined Networking for Wireless Networks
Henrique Moura, Gabriel V. C. Bessa, Marcos A. M. Vieira, Daniel F. Macedo
s: henriquemoura, gabrielvcbessa, mmvieira,

2. 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

3. 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

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

5. 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 k (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

6. 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

7. 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
Handovers between heterogeneous wireless networks
IEEE r
Fast BSS Transitions with security key negotiation
Variable link characteristics
Node mobility
Quality of service
Virtualization
Security
User Location

8. 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 e 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

9. 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

10. 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

11. 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

12. 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

13. Ethanol – SDN for IEEE 802.11 Networks

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

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

16. Class Model

17. 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 and Atheros AR n 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.

18. Experiments

19. 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

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

21. 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

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

23. 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

24. 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

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

26. 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

27. 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

28. 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

29. SDNs don´t solve it all !

31. 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

32. 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

33. 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