Deploying WLAN Service Withopenflow Technologies

Deploying WLAN Service withOpenFlow Technologies

Huai-Wen Hsu3, Kuei-Li Huang2, Yi-Chih Kao1, Shi-Chun Tsai3, andYi-Bing Lin3

1Information Technology and Service Center, National Chiao Tung University, Hsinchu, Taiwan

2 Information and Communication Lab, Industrial Technology Research Institute, Hsinchu, Taiwan

3 College of Computer Science, National Chiao Tung University, Hsinchu, Taiwan

SUMMARY

In this paper, we proposed a feasible SDN WLANsolution, which leverages OpenFlow technique and provides affordable centralized WLAN service without the proprietary restrictions of centralized thin AP WLAN architecture. Based onan SDN-enabled WLAN architecture with fat APs, we implement and deploy a wireless network test bed, where network administrators can exploit the extensibility and flexibility ofOpenFlow-based SDN switchesand controller. Service providers can develop customized application modules and required features. We build our system with open sources and commercial off-the-shelf (COTS) hardware, and develop a mechanism to control wireless bandwidth. Field experimentalresults show that our SDN wireless bandwidth control application can effectively manage bandwidth in a dynamic and flexible way via the SDN WLAN.

Index Terms—1.Network Management/1.2 Wireless & mobile networks, 5. Management Approach/ 5.1 Centralized Management(Software Defined Network), 7. Methods/ 7.8 Experimental Approach

INTRODUCTION

Wireless local area networks (WLANs) have been widely deployed in enterprises, campuses, offices, and home environments using unlicensed radio bands, thereby users can carry mobile devices to connect to the network through access points (APs). After attaching to an IEEE 802.11 AP, a mobile device can send and receive packets via the wired infrastructure through WLAN.There are two types of APs:fat APs and thin APs. Fat APs are popular in homes and small offices to provide wireless connection to user devices and offer network services such as dynamic host configuration protocols (DHCP) and network address translation (NAT). Thin APs are usually installed with licensed firmware and deployed in large enterprises. They connect to a mobility controller [1] and provide radio connectivity to users. The mobility controller allows centralized authentication and management, and provides network functions to user devices.

Each FAT AP operates as an independent device [2]. But the independent AP architecture suffers from scalability and management problem. It isdifficult to configure and manage a large scale wireless network. Each thin AP operates as a controller-based device, and is usually part of a centrally managed enterprise WLAN network. While FAT APs are popular and much cheaper in price compared with thin AP. Existing unified access management platforms are costly and closed systems, and they typically include LAN switching, WLAN controllers and access points as the entire solution supplied by a single vendor.

At the time when we prepared this work, there were a couple of commercially available SDN WLAN solutions announced. For example, in March 2015, HP acquired Aruba Networks [3] to provide SDN BYOD solution [4]. In July 2015 Fortinet acquired Meru Networks [5] and bring SDN to the WLAN solutions [6]. However, solutions by vendors are proprietary.It is difficult to add new features. The most notable difference of our solution is that we also develop SDN AP operations, administration, and management (OAM) application running on the OpenSource SDN controller. This application enables network administrator to manageSDN APs through SDN switch.

Here, we propose an affordable wireless system with OpenFlow-based software-defined networking (SDN) WLAN architecture, which provides services through SDN switches managed by one or more SDN controllers. Each switch connects to the proposed SDN WLAN controller over an OpenFlow channel with theoptional transport layer security (TLS)protocol [7]. Oursystem adopts fat APs as SDN switches, by installing the fat APs with firmware that supports OpenFlow-based switching functions and OpenWrt [8] firmware. With the refurbished fat APs and SDN controller, we have developed a wireless network service with the flavor of centralized thin AP approach. In addition, this architecture provides a flexible way to manage a WiFi wireless network in several aspects, such as bandwidth, antenna power, etc., based on the advantage that the SDN controller can manage APs dynamically and interactively.

In this work we have identified important issues for related services and successfully deployed and operated it as part of our system for campus visitors’ WLAN services. Overall, the SDN paradigm provides flexibility and leads to a significant CAPEX saving. While for OPEX, the cost is slightly higher, since it needs more efforts for system developing and maintenance. Therefore, to support such type of service, we find that it will be a norm that a network administrator could also be askillful programmer. Therest of the paper is organized as follows. Section 2 describes the OpenFlow and SDN architecture. Section 3 presents an SDN WLANdesign.Section 4demonstratesthe setup of experiments and the results. Section5concludes with some remarks.

2. BACKGROUNDS AND RELATED WORKS

The SDN technology was initiated at the University of California at Berkeley and Stanford University in 2008 [9]. SDN technologyis used to manage backbone network services at internet-based companies such as Google and Internet2. In anSDN architecture, network logic is centrally managed by a programmable SDN controller. The OpenFlow protocol enables communications between the controller and SDN switches. SDN is developed under open standards, thus the underlying infrastructure can be easily expandedto accommodate new applications and network services [10].

2.1SDN architecture

The foundation for building SDN solutions is the OpenFlow protocol standard published by the Open Networking Foundation (ONF) [11]. Later, ONF in September 2013 published OpenFlow-enabled mobile and wireless solution briefs, but still it has not specifically targeted at WLAN [12]. Figure 1 shows that ONF partitions the SDN architecture into three logical layers: the Application Layer, the Control Layer, and the Infrastructure Layer [13].

Figure 1ONF/Software-Defined Network (SDN) architecture

As shown in Figure 1(a), business applications developed in the SDN controller include information technology security, integration of cloud-based databases, etc. Users can purchase these features at quantities suitable for their needs. The SDN controller provides northbound application programming interfaces (APIs: seeFigure 1(b)) to enable various network application functions. Popular open source controllers adopted in the Control Layer (Figure 1(c))include POX [14], Ryu [15], Floodlight [16], OpenDaylight [17], etc. Through southbound APIs(Figure 1(d)), the SDN controller is used to manage the dataplane, i.e., the SDN Switch in the Infrastructure Layer (Figure 1(e)).

2.2SDN based WLANs

For SDN-enabled WLAN, Suresh et al. [18]proposed an SDN framework (named as Odin) to introduce programmability in enterprise wireless local area networks (WLANs). Odin is built on a light virtual AP abstraction that greatly simplifies client management. Odin does not require any client side modifications and its design supports WPA2 Enterprise. Moninet.al [19] present Chandelle system that allows to faster roaming procedure by integrating CAPWAP [20] wireless controller with SDN/OpenFlow controller.Lee et.al [21] propose a novel SDN based high availability (HA) solution for wireless WLANutilizingthe open network operating system (ONOS) controller [22], and make a performance evaluation under a test environment.Lalith [23] uses the Odin software defined networking framework to demonstrate that,by using a set of abstractions, it is possible to express common enterprise WLAN services as network applications.Leiet.al [24] construct software access point and deploy an SDN based campus WLAN framework (called SWAN) to providemore flexibility and expandability. An SWAN protocol is used by SWAN controller to invoke commands on the agents and collect statistics from them.Thus network operators candesign programs to manage and configure the network.

DESIGN OF OUR PROPOSED SYSTEM

In this section, we firstbriefly describe the advantages and limitations of the traditional thin AP WLANs and then elaborate on our SDN WLAN architecture based on fat AP to address the issues of thin AP.

3.1Limitations of thin AP WLAN architecture

Figure2illustrates a typical thin AP WLANarchitecture.The APs (Figure 2(a)) are deployed in several service areas. A service area consists of one or more layer 2 switches (Figure 2(b)) that connect to core switch (Figure 2(c)) through a fiber network, and provide the network connection for thin APs. The core switch provides inter-vlan routing. The WAN Gateway (Figure 2(d)) performs the "traffic directing" functions and works as an entry/exit point to the Internet.

A typical wireless service is governed by a core mobility controller (Figure 2(e)) that manages APs and provides thin AP authentication services, by which all security policies are centrally managed, enforced, and configured. Also, it can dynamically allocate AP’s radio channels to avoid conflict and to enhance performance.

When a user connects to the thin AP WLAN, the DHCP server (Figure 2(f)) automatically leases a private IP to user’s mobile device. One can enter the user name and password to access the login portal (Figure 2(g)), and the authentication is done by the Radius Server (Figure 2(h)).The Intrusion Detection System/Firewall (IDS/FW) (Figure 2(i)) provides network security service, and the network traffic is filtered by the IDS/FW before the mobile device can utilize the IP and Port translation service on the NAT Server (Figure 2(j)) for Internet connection.

Figure 2an example of thin AP WLAN

However, in a thin AP WLAN, network administrators cannot easily develop new features. Since the thin AP WLAN is proprietary, both of APs and mobility controller are usually provided by the same network equipment vendor. This issue motivates us to implement the SDN mechanism proposed next.

3.2ProposedSDN WLAN Architecture

Since fat APs are widely available, they are much cheaper than thin APs. We propose an SDN WLAN architectureby replacingthe firmware of fat APs with OpenWrtfirmware to make them function as SDN APs so that they can connect to an SDN controller andcan bemanaged by the SDN controller. Therefore, the fat APs are responsible solely for sending and receiving signals. By developing OAM modules on the SDN controller, network administrators can overcome the limitations of ill-coordinated fat APs. On the other hand, the SDN controller provides an open platform architecture that allows deployment of new management features that cannot be conveniently achieved by a traditional thin AP WLAN.

Figure 3illustrates our SDN WLAN architecture. Firmware of each SDN switch (Figure3(b))is upgraded with Linux-basedOpenWrtBARRIER BREAKER (release 14.07) and installed with OpenVSwitch.The core switch (Figure3(l))connects to the SDN controller (Figure3(c))to manageeach switch via a channel withthe optional TLS protocol. The DHCP/NAT Server (Figure 3(m)), connects to the core switch toprovide DHCP/NAT functions and Internet access. Each service area hosts one or more SDN switches, which connect to the SDN core switch via VXLAN tunnels and multiple APs (Figure 3(a)), which are installed with Linux-based OpenWrt BARRIER BREAKER (release 14.07) and OpenVSwitch. The SDN controller (Figure 3(c)) contains application modules from which network applications can be expanded. For the current version it includesAccess Controller (AC) module (Figure3(d)) with redirect function, andUser Flow Management (UFM) module (Figure3(e)).The Wireless AP(WAP) controller(Figure3(f)) containsOAM module(Figure3(g)) andREST services (Figure3(h)).The Radius Server (Figure3(i)) connects tothe Login Portal (Figure3(j)), whichlinks to SDN core switch. All of the information data will be storedin a central database (DB) (Figure 3(k)) and managed with a Web UI (Figure 3(n)) over the two Controllers.In Figure3, the SDN controller reliability can be improved by clustering two SDN controllers in active/hot standby modes.These features are typically found in the mobility controllerof the thin AP architecture.

Figure3Proposed SDN WLAN Architecture

Within the SDN WLAN architecture, weupgrade the non-SDN switches with firmware that supports OpenFlow-based SDN switching functions, and install OpenWrt-supported fat APs with OpenWrt firmware. This SDN WLAN enables authentication via our modules. For detailswe refer tothe article [8], which shows how to modify the fat APs, reconfigure according to network environment and verify the desired functions through OAM functions. We thus can compile the OpenWrt firmware, upload the firmware and then modify the AP configuration.

3.3Network Operation

When auser connects to the SDN AP (Figure 3(a)), the DHCP server (Figure3(i)) will provide a private IP. As the first packet is received by the switch (Figure 3(b)), the switch will match the packet MAC address with a flow table.This attempt will fail, and the switch will direct the packet to the SDN controller (Figure3(c)) via the OpenFlow protocol with packet header encapsulation. The SDN controller receives the packet header and checks the database (Figure3(k)) to determine whether the user’s device has been previously authenticated. Since it has not, no authentication recordis found. Therefore, the redirect function in Access Controller module (Figure3(d)) changes the destination IP address in the packet header to the IP address of the Login Portal (Figure 3(j)) and returns it to the SDN controller. After a TCP/IP three-way handshake, the end user will see the Login Portal web page. If the user accepts the “End User Agreement”, he/she is authenticated via the Login server (Figure3(j)). The authentication information and the MAC address of the device will be stored in the DB (Figure3(k)) for future authentications. A flow entry, including a match field record containing the MAC address of the user device, is created in the flow table. Before this flow entry is removed, a user can access the Internet without login through the NAT for IP & Port translation (Figure3(m)). To ensure that this new network architecture does providestable services, a primitive OAM module (Figure3(g)) is developed such that the network administrators can easily monitor AP status.

3.4OAM functions

To meet the network management requirements for an SDN WLAN, we develop a client agent software and install it via SSH on every AP to capture system information of the AP, such as user statistics, and network usage statistics. When this agent receives a query command from the WAPcontroller to look up information about the AP, the agent issues the “iwinfo wlan0 info” command, which is built in the OpenWrt running on the AP. The information received by the WAP controller from APs are parsed and displayed through a web based interface as in Figure 4.

Through the Web UI, we can monitor the AP status as in Figure 4(a), the Client status as in Figure 4(b) and Configurations of AP and Controller as in Figure 4(c). Figure 4(d) shows flow statistics of users.

(a) Access point status

The information received include: MAC Address (AP MAC: C8:D3:A3:5C:XX:XX), AP channel management (Channel: 1), AP transmission power (Txpower: 20 dBm), SSID management (SSID: "NCTU-Free"), user connection statistics for APs, user bandwidth slicing and data transfer statistics.

(b) Client status

(d) Flow statistics of users

Figure 4Illustration of OAM functionalities

3.5Wireless Bandwidth Control Application

A wireless bandwidth control application is an OAM application module on top of an SDN controller, which provides network administrators a function to configure bandwidth control policies on APs. The bandwidth control function on the AP can be enabled by installing the traffic control module into the OpenWrt on the APs. This module can be utilized to configure queues maintained in the kernel space of OpenWrt. Basically, bandwidth control on AP is port-based. That is, each port associates with a number of queues and each defines its own queueing policies such as guarantee bit rate and maximum bit rate. To realize flexible bandwidth control on an AP, we adopt client agent software [25] and install it via SSH on the AP to configure queueing policies. The client agent maintains and manages queues through the traffic control module and provides the queue information to the wireless bandwidth control application through the OpenFlow interface so as to install special flow entries into the SDN flow table for bandwidth control.

As shown in Table 1, packets matching the first flow entry are sent to port 2 and queued in queue 1 of port 2, while the second flow entry guides packets heading for the host with IP address 192.168.1.2 to port 2 yet queued in queue 2 of port 2. As shown in Table 2, a packet flow which matches the first flow entry in Table 1 is allowed 2 megabit per second guaranteed bit rate and limited to 3 megabit per second maximum bit rate; a packet flow matching the second flow entry is with 1 megabit per second guaranteed bit rate and 4 megabit per second maximum bit rate.Therefore, the wireless bandwidth control application co-working with the client agent can provide network administrator a configuration interface to enforce and dynamically adjust the wireless bandwidth policies on APs.

Table 1Flow Entries with Enqueue Actions

Table 2Queue Configuration

EXPERIMENTAL RESULTS

This section conducts measurements on the performance and cost of the proposed SDN WLAN. In our system, we adopt OpenFlow protocol version 1.0, because of the popularity and support of hardware vendors.