1

Towards Programmable Towards Programmable Enterprise WLANs With Enterprise WLANs With

OdinOdin

Written By Written By Lalith SureshLalith Suresh, Julius , Julius Schulz-Zander, Ruben Merz, Anja Schulz-Zander, Ruben Merz, Anja

Feldmann, and Teresa VazaoFeldmann, and Teresa Vazao

Presented By Michael OverPresented By Michael Over

2

OutlineOutline

AbstractAbstract IntroductionIntroduction Odin Framework DesignOdin Framework Design ApplicationsApplications Odin Framework ImplementationOdin Framework Implementation EvaluationEvaluation ConclusionConclusion

3

AbstractAbstract

Odin – an SDN framework to introduce Odin – an SDN framework to introduce programmability in enterprise WLANsprogrammability in enterprise WLANs

Enterprise WLANs need to support a Enterprise WLANs need to support a wide range of serviceswide range of services

Unique challenges with WLANsUnique challenges with WLANs AP de-associations made by clientsAP de-associations made by clients Association state machine + Broadcast Association state machine + Broadcast

nature of wireless medium = Must keep nature of wireless medium = Must keep track of a large number of state changestrack of a large number of state changes

4

AbstractAbstract

To address challenges, Odin builds To address challenges, Odin builds on a light virtual AP abstractionon a light virtual AP abstraction

No client side modifications No client side modifications required, supports WPA2 Enterpriserequired, supports WPA2 Enterprise

Enterprise WLAN services can be Enterprise WLAN services can be implemented as Odin network implemented as Odin network applicationsapplications

A prototype implementation A prototype implementation demonstrates Odin’s feasibilitydemonstrates Odin’s feasibility

5

OutlineOutline

AbstractAbstractIntroductionIntroduction Odin Framework DesignOdin Framework Design ApplicationsApplications Odin Framework ImplementationOdin Framework Implementation EvaluationEvaluation ConclusionConclusion

6

IntroductionIntroduction

Modern 802.11 Enterprise WLANs range from Modern 802.11 Enterprise WLANs range from a few dozen to thousands of APs serving a a few dozen to thousands of APs serving a multitude of client devicesmultitude of client devices

Large deployments provide resilience, fault-Large deployments provide resilience, fault-tolerance, fail-over capabilities, and scalabilitytolerance, fail-over capabilities, and scalability

Common features include authentication, Common features include authentication, authorization and accounting, policy authorization and accounting, policy management, mobility management, management, mobility management, interference management with client re-interference management with client re-associations, load balancing, and QoS associations, load balancing, and QoS guaranteesguarantees

Centralized management typicalCentralized management typical

7

IntroductionIntroduction Odin – a prototype software defined Odin – a prototype software defined

networking (SDN) framework for networking (SDN) framework for enterprise WLANsenterprise WLANs

Objective: Empower network operators to Objective: Empower network operators to program and deploy typical enterprise program and deploy typical enterprise WLAN services and features as network WLAN services and features as network applicationsapplications

802.11 Challenges:802.11 Challenges: Clients make AP association decisionsClients make AP association decisions Association state machine at AP combined Association state machine at AP combined

with the broadcast nature of wireless medium with the broadcast nature of wireless medium requires keeping track of continuous state requires keeping track of continuous state changeschanges

8

IntroductionIntroduction To simplify the programming model, Odin To simplify the programming model, Odin

builds on a light virtual access point (LVAP) builds on a light virtual access point (LVAP) abstractionabstraction

LVAPs virtualize association state and LVAPs virtualize association state and separate them from the physical APseparate them from the physical AP

Multiple clients connected to an AP are Multiple clients connected to an AP are treated as a set of logically isolated clients treated as a set of logically isolated clients connected to different ports of a switchconnected to different ports of a switch

Prevents directly handling association state Prevents directly handling association state and facilitates mobility management -> and facilitates mobility management -> handoff clients without triggering the re-handoff clients without triggering the re-association mechanismassociation mechanism

9

IntroductionIntroduction

Odin is a work in progressOdin is a work in progress Assumption: It targets fully Assumption: It targets fully

centralized and reasonably sized centralized and reasonably sized deployments with one controllerdeployments with one controller

No client side modifications No client side modifications required, design supports WPA2 required, design supports WPA2 EnterpriseEnterprise

Odin is fully transparent to the clientOdin is fully transparent to the client

10

OutlineOutline

AbstractAbstract IntroductionIntroductionOdin Framework DesignOdin Framework Design ApplicationsApplications Odin Framework ImplementationOdin Framework Implementation EvaluationEvaluation ConclusionConclusion

11

Odin Framework DesignOdin Framework Design

Simple and powerful abstractions needed Simple and powerful abstractions needed for high level services in enterprise for high level services in enterprise WLANsWLANs

802.11 clients associate or re-associate 802.11 clients associate or re-associate with any AP based on local decisionswith any AP based on local decisions

Design Goal: Prevent the programmer Design Goal: Prevent the programmer from keeping track of such changesfrom keeping track of such changes Light Virtual Access Points (LVAP)Light Virtual Access Points (LVAP) Fixed link between clients and infrastructureFixed link between clients and infrastructure

12

Odin Framework DesignOdin Framework Design

13

Odin Framework DesignOdin Framework Design

AssociationAssociation Response

Access Point (AP)

Access Point (AP)

)( )(

Probe Request

)( ) Probe Response (SSID)

Probe Response (SSID)

14

Odin Framework DesignOdin Framework Design Odin makes use of Light Virtual Access Odin makes use of Light Virtual Access

Points (LVAPs):Points (LVAPs): Start similar to standard APs with Probe Start similar to standard APs with Probe

RequestsRequests APs respond with Probe Response messagesAPs respond with Probe Response messages Handshake association occurs with one APHandshake association occurs with one AP

Key Difference: With LVAPs, every client Key Difference: With LVAPs, every client receives a unique BSSID to connect toreceives a unique BSSID to connect to

Each physical AP hosts an LVAP for Each physical AP hosts an LVAP for each connected clienteach connected client

15

Odin Framework DesignOdin Framework Design Removing a client LVAP from a Removing a client LVAP from a

physical AP and spawning it on physical AP and spawning it on another achieves a hand offanother achieves a hand off No re-association neededNo re-association needed No additional messagesNo additional messages No special software or hardware No special software or hardware

needed at the clientneeded at the client Provides clients a consistent link to Provides clients a consistent link to

the networkthe network Odin application programmer need Odin application programmer need

not be concerned with how the not be concerned with how the client’s link to the network changesclient’s link to the network changes Endpoint of link always corresponds to Endpoint of link always corresponds to

client IP and MAC addresses with the client IP and MAC addresses with the unique BSSID assigned by Odinunique BSSID assigned by Odin

16

OutlineOutline

AbstractAbstract IntroductionIntroduction Odin Framework DesignOdin Framework DesignApplicationsApplications Odin Framework ImplementationOdin Framework Implementation EvaluationEvaluation ConclusionConclusion

17

ApplicationsApplications

Seamless Seamless

MobilityMobility

18

ApplicationsApplications Load Balancing – dynamic re-Load Balancing – dynamic re-

assignment of clients to different APsassignment of clients to different APs Most existing work requires special Most existing work requires special

software on the client used by the software on the client used by the infrastructure to control associationsinfrastructure to control associations

Handoffs with LVAPs are inexpensive Handoffs with LVAPs are inexpensive and fast; reassociation based load and fast; reassociation based load balancing can be easily implementedbalancing can be easily implemented

Executing handoffs every 100 ms did Executing handoffs every 100 ms did not result in any TCP throughput not result in any TCP throughput degradation at the clientdegradation at the client

19

ApplicationsApplications

Hidden Terminal MitigationHidden Terminal Mitigation Several approaches exist – adaptive Several approaches exist – adaptive

RTS/CTS, tight scheduling, … Most RTS/CTS, tight scheduling, … Most require client modificationsrequire client modifications

Odin application: centralized view of Odin application: centralized view of the network and control over the the network and control over the association state of a clientassociation state of a client

Can provide per client Can provide per client measurements of link impairments measurements of link impairments (hidden/exposed terminals, (hidden/exposed terminals, collisions, etc.)collisions, etc.)

20

OutlineOutline

AbstractAbstract IntroductionIntroduction Odin Framework DesignOdin Framework Design ApplicationsApplications

Odin Framework Odin Framework ImplementationImplementation

EvaluationEvaluation ConclusionConclusion

21

Odin Framework Odin Framework ImplementationImplementation

Odin Master implemented on top of Odin Master implemented on top of Floodlight OpenFlow controllerFloodlight OpenFlow controller

Invokes commands on the agents – Invokes commands on the agents – add/remove LVAPs and query for add/remove LVAPs and query for statisticsstatistics

The master, through Floodlight, uses the The master, through Floodlight, uses the OpenFlow protocol to update forwarding OpenFlow protocol to update forwarding tables on the AP and switchestables on the AP and switches

Odin applications run as a thread on top Odin applications run as a thread on top of the Odin Masterof the Odin Master

22

Odin Framework Odin Framework ImplementationImplementation

Odin agents run on physical access Odin agents run on physical access pointspoints

Agents record information about Agents record information about clients and communicate with the clients and communicate with the Master over the Odin control Master over the Odin control channelchannel

The first step to realize LVAPs is for The first step to realize LVAPs is for Odin agents to track probe request Odin agents to track probe request frames generated by clientsframes generated by clients

23

Odin Framework Odin Framework ImplementationImplementation

LVAP: four-tuple {mac_addressclient, ip_v4_addressclient, lvap_bssidclient, lvap_ssidclient}

24

Odin Framework Odin Framework ImplementationImplementation

AuthenticationAuthentication WPA2 Enterprise – Client handshakes WPA2 Enterprise – Client handshakes

with AP and authentication server to with AP and authentication server to negotiate a session keynegotiate a session key With Odin, session key can be accounted With Odin, session key can be accounted

for in LVAP state; when an AP is to host for in LVAP state; when an AP is to host an LVAP, session key is installedan LVAP, session key is installed

Guest Wi-Fi – Client assigned own Guest Wi-Fi – Client assigned own LVAP only after it has authenticated LVAP only after it has authenticated against the systemagainst the system

25

OutlineOutline

AbstractAbstract IntroductionIntroduction Odin Framework DesignOdin Framework Design ApplicationsApplications Odin Framework ImplementationOdin Framework Implementation

EvaluationEvaluation ConclusionConclusion

26

EvaluationEvaluation

Experiments performed with LVAPsExperiments performed with LVAPs Testbed: a single client, two APs on Testbed: a single client, two APs on

the same subnet, and servers to run the same subnet, and servers to run the OpenFlow controllerthe OpenFlow controller

Client is given static IP address and Client is given static IP address and authenticated is disabled; all tests authenticated is disabled; all tests averaged over 10 runsaveraged over 10 runs

Three experiments: Layer 2 Delay in Three experiments: Layer 2 Delay in Re-Association, Single Handoff Re-Association, Single Handoff Impact on HTTP Download, and Impact on HTTP Download, and LVAP-Handoff BenchmarkLVAP-Handoff Benchmark

27

EvaluationEvaluation

First experiment: Layer 2 Delay in Re-First experiment: Layer 2 Delay in Re-association using noisy wireless settingassociation using noisy wireless setting

Client is associated with one AP, then Client is associated with one AP, then handed off to anotherhanded off to another

With Odin, handoff delay is less than 1msWith Odin, handoff delay is less than 1ms What about a more heavily loaded What about a more heavily loaded

network?network?

28

EvaluationEvaluation

Second experiment: Handoff during Second experiment: Handoff during HTTP downloadHTTP download

Handoff corresponds to an Odin LVAP Handoff corresponds to an Odin LVAP migrationmigration

Over a regular 802.11 setup, the Over a regular 802.11 setup, the throughput drops to zero over several throughput drops to zero over several seconds before recoveringseconds before recovering

Using Odin, the throughput is Using Odin, the throughput is unaffected in spite of the LVAP unaffected in spite of the LVAP handoffhandoff

29

EvaluationEvaluation

30

EvaluationEvaluation

Third experiment: Test many Third experiment: Test many handoffs with Odinhandoffs with Odin

LVAP-handoffs repeated at a fixed LVAP-handoffs repeated at a fixed intervalinterval

Throughput degradation measuredThroughput degradation measured

31

EvaluationEvaluation

32

OutlineOutline

AbstractAbstract IntroductionIntroduction Odin Framework DesignOdin Framework Design ApplicationsApplications Odin Framework ImplementationOdin Framework Implementation EvaluationEvaluation

ConclusionConclusion

33

ConclusionConclusion Odin shows the benefits of introducing Odin shows the benefits of introducing

programmability into the enterprise WLAN programmability into the enterprise WLAN Light Virtual Acess Points (LVAPs) – Light Virtual Acess Points (LVAPs) –

lightweight, cheap, and be used to develop lightweight, cheap, and be used to develop network services efficientlynetwork services efficiently

Future Work:Future Work: Bigger testbed with more users, indoors and Bigger testbed with more users, indoors and

outdoorsoutdoors Further abstractions to support more network Further abstractions to support more network

appsapps Fault-tolerance, fail-over capabilities, and Fault-tolerance, fail-over capabilities, and

policy managementpolicy management

34

QuestionsQuestions

Effect of encryption keys added to LVAPs?Effect of encryption keys added to LVAPs? No measurements for the effect of increased No measurements for the effect of increased

contention on the channel due to increased contention on the channel due to increased beacons? beacons?

Their system is designed for enterprises but Their system is designed for enterprises but they provide experiments only for simple, they provide experiments only for simple, trivial networks; no evaluation for enterprise trivial networks; no evaluation for enterprise networks which are the target of the systemnetworks which are the target of the system

Lower throughput during HTTP download Lower throughput during HTTP download cancels out (and then some) the savings of cancels out (and then some) the savings of being unaffected by AP handoffbeing unaffected by AP handoff

35

Questions?Questions?