phd proposal: toward open and programmable infrastructure for smarter wireless network

Toward Open and Programmable Infrastructure

for Smarter Wireless Network

Mostafa Uddin

Advisor: Dr. Tamer Nadeem

4/2/15

2

80% of Enterprise Apps are Deployed in the

Cloud

Smart devices reach 30% of the global

population by 2013, it is expected to grow 60%

by 2019

We have been seeing tons of innovation in applications, devices, computing and storage,

Growth of Network Usage

Unending, exponential growth in the people, devices and servers connecting to the network requires a new approach

Data Center Enterprise Network

3

Rapid growth of mobile data traffic

Higher Volume of Wireless Traffic

Large Number ofMobile devices

4

Better Visibility and Control

Wireless Traffic

+

Wide verity of traffic

Provide optimal performance and high quality of experience (QoE) to the end-user

5

Wireless Network Services

Air-time resourcemanagement

InterferenceManagement

Mobilitymanagement

Managing multiple wireless technology

6

Pushing SDN to Network Edge

Internet

SDN Controller

Extend standard SDN framework to the end-devices. Provide extensible and programmable abstraction of the wireless network.

weSDN

+

Shared medium

Control + Manage

7

Contribution Extend SDN framework all the way to the end-

devices (i.e., mobile devices, APs) Create open modules and APIs to provide

extensible and programmable abstraction of the wireless network.

Create new services based on the extension of the SDN framework

– Application-awareness networking, WLAN virtualization, Security at network edge, Mobility management.

8

Outline SDN Background Related Work

SDN in Cellular SDN in WiFi

weSDN: Wireless Extension of SDN weSDN services. pTDMA: WLAN Virtualization TrafficVision: Application-awareness networking Proposed work plan

weSDN Framework weSDN Services

9

SDN Background: Data Plane and Control Plane

Data Plane:

→ Fwding state + Packet header → forwarding decision

→ Fast(nano-scale) and local.

Control Plane:

→ Compute the forwarding state for the data plane.

→ Routing, Isolation, Traffic engineering.

Control Plane mess is the root cause of SDN.

10

SDN Background: Traditional Network and SDN

Network OS

ForwardingPacket

ForwardingPacket

ForwardingPacket Forwarding

Packet

Global Network View

Dijkstra IS-IS New!

Customized Hardware

Customized NetworkOS

Dijkstra

Distributedsystem

IS-IS

Distributedsystem Open Interface to

Packet forwarding (OpenFlow protocol)

11

SDN Background: Traditional Network and SDN

Network OS

ForwardingPacket

ForwardingPacket

ForwardingPacket Forwarding

Packet

Global Network View

Dijkstra IS-IS New!

Customized Hardware

Customized NetworkOS

Dijkstra

Distributedsystem

IS-IS

Distributedsystem Open Interface to

Packet forwarding (OpenFlow protocol)

12

SDN Background: Decoupling is the solution

13

SDN Background: SDN Architecture

Control Plane (SDN Controller)

Application plane ( Routing , Access Control etc.)

Southbound-API (e.g., openFlow protocol)

Data Plane

Northbound-API (e.g., Network topology)

OpenFlow switch

14

SDN Background: OpenFlow

OpenFlow Switch (i.e., OVS)

OpenFlowProtocol (SSL/TCP)

15

SDN Background: Flow Table

16



weSDN: Wireless Extension of SDN weSDN services pTDMA: WLAN Virtualization TrafficVision: Application-awareness networking Proposed work plan


17

Related Work: SDN in Cellular

WHY?WHY?

John Donovan (Senior executive VP of AT&T) says

“75% of network will be SDN by 2020.”

18

Related Work: Objectives in Cellular

Efficiently and seamlessly

Mobility handling

Adding new servicesEasily,

Fast, inexpensive

Real-time updates offine-grained packet-

handling

Different subscriber

3G, LTE, Wi-Fi, Femtocell

19

Related Work on Cellular SDN: SoftCell

Internet

No change

Controller

Commodity hardware

+ SoftCell software

No change

Scalable Support of Fine-Grained Service Policies

20

Related Work on Cellular SDN: OpenRadio

Wireless Network OS

Global Network View

Open interface to heterogeneouswireless infrastructure

Connectivity/Mobility Netflix/CDN

If pkt = x: forward to WiFI APIf pkt = y: forward to LTE AP

and allocate speed 1Mbps

If pkt = x: schedule low priorityIf pkt = y: schedule high

priority and allocate 40% airtime

3G Wi-FiLTE

21





22

Related Work: SDN in Wi-Fi

Centralized solution of WLAN from industries (e.g. Cisco Aruba, Meru)

– Channel Allocation, Radio resource management, interference reduction, authentication

Closed and Proprietary

Ajay Malik (Senior VP of Aruba) says

“Wireless network must truly embrace open standards for enterprises to reap the performance benefits of Software-Define Networking”

23

Related work on Wi-Fi SDN: Odin

Complex for traffic management, apply policies

and create new service

Do not use OpenFlow

Don't have fine-grainedControl over traffic

SWAN, similar work as Odin

Maintain a virtual AP for each client device

24

Related work on Wi-Fi SDN: DysonClients and APs uses open APIs to

send pertinent information such as radio channel conditions to a central controller.

Controller create global view of the network.

The global view and historical information allow the controller to apply policies.

Not flexible and general as SDN

Only works on MAC layer

Services:Associations, handling VoIP clients, reserving airtime for specific users, and optimizing handoffs for mobile clients

Can not have fine-grainedReal-time traffic managemnt

25

Related work on Wi-Fi SDN: COAP

A cloud-based centralized framework to configure, coordinate and manage individual home APs using an open API implemented by these commodity APs.

Can not have fine-grainedReal-time traffic managemnt Control Plane is not flexible

26

Summary of the related work

No generalized framework, only targeting to solve specific problem using SDN concept.

No extension on the OpenFlow, for supporting the wireless network devices.

No intension of bringing the client devices under the control of SDN framework.

Not providing any new NB-APIs for the development of third-party network applications.

27





28

weSDN: OverviewExtends control capability all the

way to end device1. In OpenFlow ext., we extended the standard OpenFlow to provide new APIs for wireless network.

2. In OpenFlow protocol ext., we extend the OpenFlow protocol to support new statistics and action/configuration cmd for wireless.

3. In client devices, we use Local Controller to reduce in-band communication between Client device and weSDN controller.

4. Extend the NB-API to provide wireless network topology including client devices.

29

weSDN: Architecture

OpenFlow extension components of the AP and Client devices

30

weSDN: Flow Manager

FlowManger is a Software OpenFlow Switch with extension for wireless

1. Collect traffic flow statistics

2. Ensure correct QoS marking.

3. Collect per-client or per-flow wireless statistics such as RSSI, data rate, TX mode and drop count.

31

weSDN: SchedulerScheduler is Linux Qdisc with the capability of starts/stopsdequeueing of the outgoing flow based on the airtime schedule.

1. Starts or stops dequeueing of the outgoing flow based on the airtime schedule.

2. Interact with the wireless driver to control the dequeueing event based on the number of packets exists in the driver buffer.

32

weSDN: Local ControllerLocal Controller is a user space software that interact with the Flow Manager, Scheduler, and Linux wireless driver.

1.Provides application-awareness and generates flow-to-application mappings.

2.We extend the OVS APIs (i.e. netlink APIs) so that local controller can read per-flow wireless stats from the flow manager.

3. The local controller insertsa flow rule corresponding to each socket into OVS.

4. Interact with wireless driver (weSDN ext.) to configure power-save settings, transmission(TX) rate, TX power.

33

weSDN: SDN Controller The interaction between wireless AP and the SDN control plane happens through OpenFlow protocol ext. over out-band wired control channel

The interaction between weSDN controller and the Local Controller happens over In-band wireless control channel

1. Provide per-application policies and QoS profile.

2. Local controller aggregate running application resource and QoS requirement to the weSDN controller.

3. weSDN controller provide proper action to the Local controller for resource management

34

weSDN: Features of the Framework

Cohesive framework in managing both wire and wireless network.

Real-time, fine-grained control over the wireless resource management.

Ensure end-to-end QoS policy. Enhance the guaranteed network performances of

the client devices.

35





36

weSDN Services: WLAN Virtualization

WLAN virtualization enable effective sharing of wireless resources by a diverse set of users with diverse requirement

employeesguest

Enterprise WLAN

parents kids

Home WLAN

weSDN provide virtualization capability through controlling both uplink and downlink wireless resource

37

weSDN Services:Application-Awareness Networking

application type +flow type → middleboxes (QoS, Policy, Resource Management)

weSDN Control Plane

App-awareness

weSDN use the OpenFlow ext. to collect real-time traffic flow features and identify the flow types.

QoS PolicyVarious mobile applications with various traffic types (e.g Skype,

Facebook)

38

weSDN Services: Securing Network Edge

weSDN framework provide transparent and configuration technique of securing the wireless traffic between the mobile and the AP.

weSDN Control Plane

Security App

SecuringUnencrypted

trafficObfuscating

Eavesdropping

Sensitive apps(e.g. Health app)

39

weSDN Services: Multiple Network Interfaces

Require a Dynamic and Programmable system to

leverage all network interfaces

TCP/IP

OVS

WiFi LTE

vp

Wi-fi Driver

WiFi firmware

LTE Driver

LTE firmware

qdisc

Local Controller

Flow Manager

In client devices, Flow Manager with local

controller can provide to use multiple network interfaces

40

weSDN Services: Mobile ↔ SDN ↔ Cloud

In wireless, network condition between Mobile (Client) ↔ SDN (network) are highly dynamic

Mobile cloud application require guaranteed networkPerformance.

SDN controller need to provide performance guaranteeto clients knowing the app demand from the cloudserver.

41





42

pTDMA: WLAN Virtualization

#42

Now-a-days People bring their own devices in the workplaces (i.e., BYOD)

Require new WLAN management and BYOD Policies

• pTDMA is a simple prototype of weSDN for WLAN virtualization service.

– Manage airtime share between network instances (their clients) that collocate in space and channel.

– Assigning separate airtime slices among different network instances.

WLAN Virtualization is a popular solution in enterprise for BYOD concept

43

pTDMA: Scheduling

#43

Allocate large enough time window to transmit and receive multiple packets.

Schedule multiple clients in a common slot to maximize channel utilization.

The interval between consecutive time windows should be based on applications’ traffic pattern & demand.

50:50 airtime share between employee network and guest network.

Every time window is fixed of 10ms.

44

pTDMA: Implementation Flow Manager: – OVS Stat extension: burst duration, burst rate and inter-burst time.Scheduler:

– Receive time window from the local controller to start/stop dequeueing.

– Time Window: e.g. [Start time, active duration, sleep duration]

(e.g. 05:30:30, 10ms, 30ms)Local Controller:

– Identify flows correspond to each application.– Read per-flow statistics from Flow Manager.– Control the scheduler.

Global Controller:– provide per-slice, per-user, per-application policies and QoS profiles.– Collect 'aggregated' airtime demand of the running applications and

QoS requirements.– Apply proper action back to the local controller(e.g. Scheduling )

#44

45

pTDMA: Experiment

#45

We formed two network slices

“employee” network with 2 devices

“guest” network with 6 devices

Applied following pTDMA schedule with 50:50 airtime share between two slices

– 3:1 airtime ratio btw an employee and a guest.(but all devices are connected to one AP)

E1E2

G2

G3

G4

G5

G6

E1E2

E1E2

E1E2

G1G2

G3G4

G5G6 ....

0ms 10 20 30 40 50 60

G1

~3x In non-pTDMA, client sleeps 28% of the time.

In pTDMA, client sleeps 80% of the time

46





47

TrafficVision: Application-awareness

Dynamic Port Number

SDN Control PlaneDPIEngine

Different Applicationand different flow

types

Require different QoS, Security, and resources

Real-time identifying ofApps and its various flow types

Application-awarenessNetworking

48

TrafficVision: DPI

SDN Control PlaneDPIEngine

OpenFlow mirror packets from data

layer and send to SDN control plane.

Most applications now use HTTPs

Application encryption

DPI uses packet signature to detect application

Significant Overhead

49

TrafficVision: SDN solution toApplication-awareness

Real-time and fine-grained “application-awareness” system at Network edge

Wi-Fi/Cellular AP(extended openflow switch)

weSDNController

Network Service(TV Engine)

ApplicationPlane

Traffic Management App

NB API

ML learning techniqueWith new features.

Flow type detection accuracy75-89% to 85-98%

50

TrafficVision: TV Engine

weSDN Controller

Wi-Fi / Cellular

OpenFLow ext.

TV Engine

OpenFlow protocol ext.

OpenFlow ext.

Feature collected at network edge: Light traffic Volume

No overhead of packet mirroring (i.e., don not use packet capture tools).

Real-time features collection.

51





52

Proposed Work Plan: weSDN Testbed

Cross-compile and deploy OpenFlow switch in the Android smartphone and tablets (linux based platform). [complete]

Run Floodlight SDN controller in a laptop. [completed].

Cross-compile and deploy OpenWrt including OpenFlow switch in wireless router (Linksys E3000, a/b/g/n). [not completed]

53

Proposed Work Plan: Flow Manager

Extend “netdev provide”And “datapath” for

supporting Wireless network interfaces

[completed]

Extend the kernel module “mac80211” and “cfg80211”To create API for Flow ManagerTo collect Statistics.[not completed]

54

Proposed Work Plan: Local Controller

Use the Traffic Control (tc) tool to control the enqueue/dequeue action of the scheduler. [completed]

Develop interaction with the SDN controller to get policies, actions, and QoS settings for the traffic flows. In addition provide network requirement and traffic statistics to the SDN controller. [partially completed]

Create new APIs for the mac80211 to allow local controller to interact and configure the wireless driver. [not completed]

Make the local controller interact with the wireless configuration tools such wpa supplicant, iw. [not completed]

55

Proposed Work Plan: Scheduler Extend the scheduler to interact with the wireless driver to

control the dequeue event based on the number packets in the driver buffer. [partially complete]

Implement the Linux multiq qdisc as a basis of the scheduler to support the four 802.11 QoS queues in the driver while preventing head-of-line blocking. [completed]

Provide APIs to the local controller for configuring the qdisc and wireless driver. [completed]

56

Proposed Work Plan: SDN Controller (Floodlight)

Extend the Northbound API to have new APIs for controlling and programming wireless APs and client devices. [not complete]

Extend OpenFlow protocol to collect wireless channel statistics per-device from wireless APs. [completed]

57





58

Proposed Work Plan: TrafficVision

1. Evaluate and compare our system with OpenDPI, which is a open source DPI based solution for detecting the applications from the packet’s signature.

2. Develop and evaluate a traffic load-balancing or traffic management application that uses our TrafficVision system.

59

Proposed Work Plan: Security at Network Edge

weSDN Control Plane

Security App

SecuringUnencrypted

trafficObfuscating

1. Leveraging the weSDN framework to apply security policy on the sensitive app's traffic.

2. Real-time detection of unencrypted traffic from sensitive apps and apply IPsec tunneling between AP and client device using Flow Manager.

3. Transparently apply traffic obfuscating or traffic shaping technique to hide the side-channel information of the apps..

60

Proposed Work Plan: Multiple Wireless Interfaces

TCP/IP

OVS

WiFi LTE

vp

Wi-fi Driver

WiFi firmware

LTE Driver

LTE firmware

qdisc

Local Controller

Flow Manager

1. Monitor Wireless channel status in real-time by the local controller.

2. Develop an algorithm in the local controller on utilizing different wireless interfaces, based on running apps requirement.

3. Evaluate the system using real-world application based on users' QoE.

qdisc

61

Proposed Work Plan: Network Diagnosis at end-devices

1. The OpenFlow has very extensible and programmable way of logging events of packet handling and network activity.

2. We plan to extend the OpenFlow logging system to log wireless network activity.

3. Thus, based on the logging messages, we plan to build a network diagnosis system for the end-devices.

62

Timeline

Task Task Status Expected ScheduleWeSDN testbed Completed (75%) Spring'15

WeSDN implementation Completed (80%) Spring'15 -Summer'15

TrafficVision Completed(90%) Spring'15-Summer'15

Security App Not Completed Fall'15

Mobility Management Not Completed Spring'16

Thesis Writing Not Completed Spring'16-Summer'16

63

Publication List

1. Mostafa Uddin, Ahmed Salem, Ilho Nam, and Tamer Nadeem, ”Wearable Sensing Framework for Human Activity Monitoring.” ACM WearSys, MobiSys 2015.

2. Mostafa Uddin, and Tamer Nadeem, ”Harmony: Content Resolution using Acoustic Channel.”

IEEE INFOCOM 2015.

3. Jeongkeun Lee, Mostafa Uddin, JeanTourrilhes, Souvik Sen, Sujata Banerjee, Manfred

Arndt, Kyu-Han Kim, Tamer Nadeem, ”meSDN: mobile extension of SDN.” ACM MCS

2014.

4. Mostafa Uddin, and Tamer Nadeem, ”SpyLoc: A Light Weight Localization System for

Smartphones.” IEEE SECON 2014.

5. Mostafa Uddin, Ajay Gupta, Kurt Maly, Tamer Nadeem, Sandip Godambe, Arno Zaritsky,

”SmartSpaghetti: Accurate and Robust Tracking of Human’s Location.” IEEE-EMBS

International Conferences on Biomedical and Health Informatics, 2014.

Papers

64

Publication List (Cont.)

6. Mostafa Uddin, Ajay Gupta, Kurt Maly, Tamer Nadeem, Sandip Godambe, Arno Zaritsky,

” SmartSpaghetti: Use of Smart Devices to Solve Health Care Problems.” International

Workshop on Biomedical and Health Informatics, 2013.

7. Mostafa Uddin, and Tamer Nadeem, ”RF-Beep: A light ranging scheme for smart devices.”

IEEE PerCom 2013.

8. Mostafa Uddin, and Tamer Nadeem, ”A2PSM: Audio AssistedWi-Fi Power Saving Mechanism

for Smart Devices.” ACM HotMobile 2013.

9. Mostafa Uddin, and Tamer Nadeem, ”MagnoTricorder: What You Need To Do Before

Leaving Home.” ACM HomeSys, UbiComp 2012.

10. Mostafa Uddin, and Tamer Nadeem, ”EnergySniffer: Home Energy Monitoring System

using Smart Phones.” IEEE IWCMC, 2012.

Papers

65


1. Igor Pernek, Mostafa Uddin and Jack Fernando Bravo Torres, ”Report of HotMobile

2012” IEEE Pervasive Computing.

2. Mostafa Uddin and Tamer Nadeem, ”HotMobile 2012 Poster: MachineSense: Detecting

and Monitoring Active Machines using Smart Phone.” ACM SIGMOBILE MC2R.

3. Mostafa Uddin and Tamer Nadeem, ”HotMobile 2012 Poster: Audio-WiFi: Audio Channel

Assisted WiFi Network for Smart Phones.” ACM SIGMOBILE MC2R.

ArticlesArticles

66


1. Mostafa Uddin, Ashish Kshirsagar, and Tamer Nadeem, ”SafeWLAN: A WLAN-based

SDN Approach for Securing WLAN Traffic.” ACM HotMobile 2015.

2. Mostafa Uddin and Tamer Nadeem, ”SpyLoc: a Light Weight Localization System for

Smartphones.” In Proceedings of MobiCom’13.

3. Jeongkeun Lee, Mostafa Uddin, Jean Tourrilhes, Souvik Sen, Sujata Banerjee,Manfred

Arndt, Tamer Nadeem, ”Extending SDN for mobile device.” ACM HotMobile, 2014 .

4. Mostafa Uddin and Tamer Nadeem, ”Audio-WiFi: Audio Channel AssistedWiFi Network

for Smart Phones.” IEEE INFOCOM, 2012 .

5. Mostafa Uddin and Tamer Nadeem, ”EnergySniffer: Home Energy Monitoring System

using Smart Phones.” IEEE INFOCOM, 2012 .

6. Mostafa Uddin and Tamer Nadeem, ”MachineSense: Detecting and Monitoring Active

Machines using Smart Phones.” ACM HotMobile, 2012 .

Posters/Demos

67

TimelineTask Task Status Expected Schedule

WeSDN testbed Completed (75%) Spring'15

WeSDN implementation Completed (80%) Spring'15 -Summer'15

TrafficVision Completed(90%) Spring'15-Summer'15

Security App Not Completed Fall'15

Mobility Management Not Completed Spring'16

Thesis Writing Not Completed Spring'16-Summer'16

Thank You

68

Back-up Slides

SDN enable AP

Replace with openflow switch(OVS)

pTDMA: Downlink Control and Power Saving

#70

1. pTDMA leverage WMM-PS to indirectly confine the downlink traffic to the time window.

2. pTDMA allows to efficiently utilize the WMM-PS to have more sleeping time without sacrificing the throughput performance.

WMM Power Save in a Wi-Fi Network Wi-Fi legacy power save

TVEngine: TrafficVision ControlLayer

Core Idea: Classify network traffic based on flow statistics, not on the payload content

Three major task: 1) Collect and store flow statistics of packet sizes and packet arrival time from OVS.2) Extract high order statistics and spatio-temporal features.3) Apply ML classifier to identify application and flow type.

phd proposal: toward open and programmable infrastructure for smarter wireless network

Technology