Giuseppe Bianchi

Platform-independent Wireless Device ReconfigurationWhat can we learn from SDN?

Anything we may hand back to SDN? Giuseppe Bianchi

CNIT / University of Roma Tor Vergata

Credits to: Wireless MAC processor I. Tinnirello, P. Gallo, D. Garlisi, F. Giuliano, F. GringoliOpenstate M. Bonola, A. Capone, C. Cascone

Giuseppe Bianchi

Software-Defined Radiofrom radios with behavior fixed in

hardware to radios with behavior determined by software

20+ years long research path; excellent technologiesAirBlue, CalRadio, GNURadio, RUNIC, SORA, USRP,

WARP, …

So far, niche exploitationE.g. militaryBut commercial transition seems now here

Giuseppe Bianchi

Software-Defined RadioUnfortunately… [quoting Partridge, 2011]

… [we] are all imperfectly prepared to take advantage.

Research on vital questions has been extremely variablewith wonderful work (such as finding the right mix of programmable

hardware to support high performance signal processing in radios)undermined by almost complete neglect - such as how to

describe radio behavior independent of platform […].

C. Partridge, Realizing the future of Wireless Data communication, 2011

Giuseppe Bianchi

Meanwhile, standards & vendors …

One-size-fits-all protocolsE.g. 802.11 WLANPacking as many amendments as possible into one protocol

802.11e QoS, 802.11p vehicular, 802.11s mesh, 802.11v mgmt, 802.11z direct link enhancements, 802.11aa multimedia, 802.11ae QoS mgmt, 802.11ah M2M, etc

Rationale: must fit several largely different contexts and scenarios

Aftermath: years to finalize, backward compatibility, compromises, …

Giuseppe Bianchi

One size hardly fits allcontext matters!

Dynamic spectrum accessVery diverse situations (e.g. countries) very diverse environmental conditions

» Dense/sparse, hidden terminals, legacy deployments, etcDifferent propagation characteristics

» Sub-GHz, THzNiche environments with specific needs

home, industrial, M2M, …Adaptation to specific context or applications

Virtualization, access network sharingMulti-tenancyMultiple coexisting applications

» M2M and H2H over same access network…And many more…

Diverse needs diverse design!

Giuseppe Bianchi

Everything would be much easier if…

Please Install this radio protocol stack

Whole radio protocol stack as a sort of JAVA applet

Hello, may I associate?

[using a legacy protocol, e.g. DCF]

Monitor and detect Context changes (interf., traffic, hidden nodes, neighbors, etc)

Here’s a new context specific protocol stack! Let’s reconfigure

terminals to best fit new condition

How to make this vision come true? Either a platform-agnostic radio programming language, or… all devices of the same vendor…

Giuseppe Bianchi

Multi-tenancy would become trivial

Operator A Operator B

Custom

stack

A Custom stack B

Change of context conditions Change of context conditions

Giuseppe Bianchi

For instance: MAC protocols’ time slicing

Time «slice» dedicated to OPA, best effort traffic chooses DCF-like

trivial idea, isolation guaranteed, any (custom) MAC protocol in any tenant’ slice…but today hard to implement (and non standard)

Time «slice» dedicated to OPA, guaranteed traffic chooses TDM-like

Giuseppe Bianchi

In the mean time, in another (wired) galaxy…

The rise of Software Defined NetworkingOpenFlow, 2008SDN, 2010Market hype, 2012

Almost 2 B$ SDN companies acquisition» Mainly Nicira, but also Contrail, Big Switch, Cariden,

Vyatta, …

Compare timing and $$$ with SDR take up…

Giuseppe Bianchi

Why SDN = $$$SDN: programmable central control of

network operation and trafficOpen, vendor-netural, APIs

Northbound, southbound (mainly OpenFlow)Easy and fast deployment and innovation

PacketForwarding

PacketForwarding

PacketForwarding

Device-level, standard-based, interface – southbound API

Controller

Data plane

Net «app»

Net «app»

Net «OS»Network-wide, standard-based, interface – northbound API

Giuseppe Bianchi

Which SDN breakthrough? Control/data plane separation?

Nah…A key feature, but not nearly new

Well established in POTS, SNMP, etcVery well established in wireless as well

» Entrerprise WLAN, CAPWAP since 2003, …

SDN real breakthrough: viable vendor-neutral programming abstractions!

Node behavior

Description(formal)

Network Entity

e.g. Switch

Any vendor, any size, any HW/SW platform…

Giuseppe Bianchi

OpenFlow: a compromise[original quotes: from OF 2008 paper]

Best approach: “persuade commercial name-brand equipment vendors to provide an open, programmable, virtualized platform on their switches and routers”Plainly speaking: open the box!! No

way…

Viable approach: “compromise on generality and seek a degree of switch flexibility that isHigh performance and low costCapable of supporting a broad range of

researchConsistent with vendors’ need for

closed platforms.A successful compromise, indeed… ask Nicira …

Giuseppe Bianchi

OpenFlow: just one abstraction

good for switches, not for «all»

SwitchPort

MACsrc

MACdst

Ethtype

VLANID

IPSrc

IPDst

IPProt

TCPsport

TCPdport

MatchingRule Action

1. FORWARD TO PORT2. ENCAPSULATE&FORWARD3. DROP4. …Extensible

Vendor-implementedProgrammabile logic

Pre-implemented matching engine

Giuseppe Bianchi

Back to the wireless galaxy…

Research stuck to the “best approach”: “persuade commercial name-brand equipment vendors to provide a same open programmable platform on their Wireless NICs”Plainly speaking: let’s all use, e.g., WARP!! No way…

Viable approach: “compromise on generality and seek a degree of Wireless NIC flexibility that isHigh performance and low costCapable of supporting a broad range of researchConsistent with vendors’ need for closed

platforms.

But which «right compromise»? Describing a wireless device behavior is NOT

as «easy» as abstracting a flow table…

Giuseppe Bianchi

Let’s focus on MAC protocolsOur work

Infocom 2012, Context 2012, Wintech 2013

Simpler to address than «full» SDR, but already not nearly trivial

How to provide a platform-agnostic description of MAC protocols whichDoes not require open source devicesStill permits to operate at ms time scales

Must run in the (closed source) NIC…

Giuseppe Bianchi

Learn from computing systems? 1: Instruction sets

perform elementary tasks on the platformA-priori given by the platformCan be VERY rich in special purpose computing platforms

» Crypto accelerators, GPUs, DSPs, etc

2: Programming languages sequence of such instructions + conditionsConvey desired platform’s operation or algorithm

3: Central Processing Unit (CPU)execute program over the platformUnaware of what the program specifically doesFetch/invoke instructions, update registers, etc

Clear decoupling between: - platform’s vendor implements (closed source!) instruction set & CPU - programmer produces SW code in given language

Let’s MIMIC all this!

Giuseppe Bianchi

ACTIONS frame management, radio control, time scheduling

TX frame, set PHY params, RX frame, set timer, freeze counter, build header, forge frame, switch channel, etc

EVENTSavailable HW/SW signals/interrupts

Busy channel signal, RX indication, inqueued frame, end timer, etc

CONDITIONSboolean/arithmetic tests on available registers/info

Frame address == X, queue length >0, ACK received, power level < P, etc

1: Which elementary MAC tasks?(“our” instruction set!)

Giuseppe Bianchi

Just “one” possible API convenient on our commodity platform

“others” possible as well improved/extended tailored to more capable radio HW

Our point, so far: have a specified set of actions/events/conditions, not “which” specific one)

Implemented APIPlatform: Broadcom Airforce54g commodity card

Giuseppe Bianchi

Convenient “language”: XFSMeXtended Finite State MachinesCompact way for composing available acts/ev/cond

to form a custom MAC protocol logic

2: How to compose MAC tasks?(“our” programming language!)

Origin state Destination

stateconfig action()

Destinationstate

EVENT(condition)Action()

Destinationstate

Giuseppe Bianchi

Actions:set_timer, stop_timer, set_backoff, resume_backoff, update_cw, switch_TX, TX_start

Events:END_TIMER, QUEUE_OUT_UP, CH_DOWN, CH_UP, END_BK, MED_DATA_CONF

Conditions:medium, backoff, queue

XFSM example: legacy DCFsimplified for graphical convenience

Giuseppe Bianchi

MAC engine: specialized XFSM executor (unaware of MAC logic)Fetch stateReceive eventsVerify conditionsPerform actions and state transition

Once-for-all implemented in NIC (no need for open source)“close” to radio resources = straightforward real-time

handlingDifferent MAC protocol = different “XFSM program”!

3: How to run a MAC program? (MAC engine – XFSM onboard executor - our CPU!)

Giuseppe Bianchi

Is this viable? Implemented on an ultra-cheap commodity WLAN NIC

Real world card: Broadcom Airforce54g 4311/4318 Poor resources: general purpose processor (88 MHz),

4KB data memory, 32 KB code memory More recently, also implemented on WARP (but this was not a challenge!)

Implementation at a glance: Original 802.11 firmware deleted (we do NOT want yet

another firmware MAC to hack!) Replaced with [once for all developed in assembly language]:

Implementation of actions, events, conditions in part reusing existing HW facilities:

» HW configuration registers for radio resource and event handling» Frequency, power, channel sensing, frame forging facilities, etc» Available HW events (packet queued, plcp end, rx end, rx correct frame, crc failure, timer

expiration, carrier sense, etc) MAC engine: XFSM executor Several annoyting technical hurdles addressed (e.g. lack of support of interrupt handling)

Developed “machine language” for MAC engine

Giuseppe Bianchi

MAC Programs MAC description:

XFSM

XFSM tables

Transitions«byte»-code event, condition, action

Portable over different vendors’ devices, as long as API is the same!!

Pack & optimize in WMP «machine-language» bytecode

A

C

B

T(A,B)T(B,C)

T(C,A) T(C,B)

ABC

A B C

T(A,B)T(B,C)T(C,A) T(C,B)

ABC

MAC protocol specification:XFSM design

(e.g. Eclipse GMF)

Machine-readable code

Custom language compiler

Code injection in radio HW platform

MAC Engine

MAC Bytecode

Giuseppe Bianchi

Machine Language Example (DCF, 544 bytes)

Giuseppe Bianchi

Wireless MAC Processor: Overall architecture

MAC Engine: XFSM executor

Memory blocks: data, prog

Registers: save system state (conditions);

Interrupts block passing HW signals to Engine (events);

Operations invoked by the engine for driving the hardware (actions)

Giuseppe Bianchi

From MAC Programs to MAClets

Upload MAC program on NIC from remoteWhile another MAC is runningEmbed code in ordinary packets

WMP Control Primitives load(XFSM) run(XFSM)verify(XFSM)switch(XFSM1, XFSM2, ev,

cond) Further primitives

Synchro support for distributed start of same MAC operation

Distribution protocol

“Bios” state machine: DEFAULT protocol (e.g. wifi) which all terminals understand

Giuseppe Bianchi

Multi-threaded MACSeamless switch from one MAC program to another in negligible time

less than 0.2 us over such cheap hardware!(plus channel switching time if required)

Giuseppe Bianchi

AP Virtualization with MAClets

Two operators on same AP/infrastructureA: wants TDM, fixed rateB: wants best effort DCF

Trivial with MAClets!Customers of A/B download

respective TDM/DCF MAClets! Isolation via MAClet design

Time slicing DESIGNED INTO the MAClets! (static or dynamic)

DCF SUSPEND

Timer expiration

Beacon reception & conversely

Giuseppe Bianchi

Controller’s architectureused OMF as SDN controller…

(!)Measurement processCollects statistics for context estimationResource ControllerManages device (load, control)

Experiment ControllerNetwork-wide orchestration

Giuseppe Bianchi

Public-domain Supported by the FLAVIA EU FP7 project

http://www.ict-flavia.eu/ Ongoing integration in the CREW EU FP7 federated testbed

http://www.ict-flavia.eu/

Public domain release Project page: http://wmp.tti.unipa.it Download: https://github.com/ict-flavia/Wireless-MAC-Processor Developer team:

ilenia.tinnirello@tti.unipa.it domenico.garlisi@dieet.unipa.it fabrizio.giuliano@dieet.unipa.it francesco.gringoli@ing.unibs.it

Released distribution: Binary image for WMP You DO NOT need it open source!

Remember the “hard-coded” device philosophy… Conveniently mounted and run on Linksis or Alix

Source code for everything else Manual & documentation, sample programs

Giuseppe Bianchi

Back again to the wired galaxy…Aftermath: XFSM as a very

appropriate abstraction for wireless MAC protocols’ programming

Openflow: compromise, which permits «only» to program stateless flow tables

Crazy idea? OpenFlow + XFSM?

Giuseppe Bianchi

OF’s remote intelligence…

Network OS

Controller Application(smart = states)

Events from switchesTopology changes,Traffic statistics,Arriving packets

Commands to switches(Un)install rules,Query statistics,Send packets

Forwarding device (dumb)

Winning SDN idea for network-wide states and «big picture» decisions

Poor idea for local states/decision, (way!) better handled locally

(less delay, less signalling load)

The real cause: OF does not permit to «program» stateful rule changes (remember, OF was a compromise)

Giuseppe Bianchi

Example: how you’d implement an OF port

knocking firewall? knock «code»: 5123, 6234, 7345, 8456

IPsrc=1.2.3.4

Port=5123

Flow 1.2.3.4: encapsulate & forward

DROP

controller

Port 5123? Store state,1° knock OK

Giuseppe Bianchi

Example: how you’d implement an OF port

knocking firewall? knock «code»: 5123, 6234, 7345, 8456

IPsrc=1.2.3.4

Port=6234

Flow 1.2.3.4: encapsulate & forward

DROP

controller

Port 6234? Store state,2° knock OK

Giuseppe Bianchi

Example: how you’d implement an OF port

knocking firewall? knock «code»: 5123, 6234, 7345, 8456

IPsrc=1.2.3.4

Port=7345

Flow 1.2.3.4: encapsulate & forward

DROP

controller

Port 7345? Store state,3° knock OK

Giuseppe Bianchi

Example: how you’d implement an OF port

knocking firewall? knock «code»: 5123, 6234, 7345, 8456

IPsrc=1.2.3.4

Port=8456

Flow 1.2.3.4: encapsulate & forward

DROP

controller

Port 8456? Store state,OPEN

Add flow entry for 1.2.3.4:22

Giuseppe Bianchi

Example: how you’d implement an OF port

knocking firewall? knock «code»: 5123, 6234, 7345, 8456

IPsrc=any Port=anyDROP

controller

ALL packets of ALL flowsMust be forwarded to controller!!Until flow entry installed!

Giuseppe Bianchi

Controller implementation for port knocking: Mealy

Machine(simpler form of XFSM)

DEFAULT

Stage 1

Stage 2

Stage 3 OPEN

Port=6234Drop()

Port!=6234Drop()

Port!=5123Drop()

Port=5123Drop()

Port=7345Drop()

Port=8456Drop()

Port!=7345Drop()

Port!=8456Drop()

Port=22Forward()

Port!=22Drop()

1 state machine for all flows (same knocking sequence)N states, one per (active) flow

Giuseppe Bianchi

Can transform in a flow table? Yes!

state eventDEFAULTSTAGE-1

Port=5123Port=6234

STAGE-2STAGE-3

Port=7345Port=8456

OPEN Port=22OPEN

*Port=*Port=*

Match fields Actionsaction Next-statedropdrop

STAGE-1STAGE-2

dropdrop

STAGE-3OPEN

forward OPENdropdrop

OPENDEFAULT

Metadata (any bit string)

Header field(port #)

If next state were an OF instruction, this would be a STANDARD OF1.3+ flow table! TCAM implementation

Giuseppe Bianchi

And what about flow states?

Flow key stateIPsrc= … …Ipsrc= … …

… … …… … …

IPsrc=1.2.3.4IPsrc=5.6.7.8

STAGE-3OPEN

IPsrc= no match DEFAULTIPsrc= … … … … …

Just a (Hash) Table, e.g. dleft/cuckoo hashNo need for TCAM (though useful extension for static matches)

Giuseppe Bianchi

Putting all togetherIPsrc=1.2.3.4

Flow key stateIPsrc= … …Ipsrc= … …

… … …… … …

IPsrc=1.2.3.4IPsrc=5.6.7.8

STAGE-3OPEN

IPsrc= no match DEFAULTIPsrc= … …

State Table

… … …

Port=8456

state eventDEFAULTSTAGE-1

Port=5123Port=6234

STAGE-2STAGE-3

Port=7345Port=8456

OPEN Port=22OPEN

*Port=*Port=*

XFSM TableMatch fields Actions

action Next-statedropdrop

STAGE-1STAGE-2

dropdrop

STAGE-3OPEN

forward OPENdropdrop

OPENDEFAULT

IPsrc=1.2.3.4 Port=8456 STAGE-3

OPENFlow key state

IPsrc= … …Ipsrc= … …

… … …… … …

IPsrc=1.2.3.4IPsrc=5.6.7.8

Write:OPENOPEN

IPsrc= no match DEFAULTIPsrc= … …

State Table

… … …

IPsrc=1.2.3.4 Port=8456

1) State lookup

2) XFSM state transition

3) State update

Giuseppe Bianchi

Cross-flow state handling

MACdst MACsrcFlow key state

48 bit MAC addr Port #lookup

State Table

MACdst MACsrcFlow key state

48 bit MAC addr Port #update

State Table

state eventPort# *

action Next-stateforward In-port

XFSM Table

DIFFERENT lookup/update scope

Field 1 Field 2 Field N

Flowkey selector Read/write signal

Yes but what about MAC learning, multi-port protocols (e.g., FTP), bidirectional flow handling, etc?

Giuseppe Bianchi

Aftermath: a nice surprise! OpenFlow can support states and state transitions!

With marginal modifications! See Openstate, ACM CCR, April 2014

Bringing control back inside the switchAt wire speedVia platform independent abstractionA new perspective towards SDN control/data plane separation?

» Controller DECIDES, but switch can now ENFORCE! A lot faster!

Proof of concept implementationsSoftware: O(days) on SoftSwitch (OFv1.3)Hardware: in progress, first prototype at 10 Gbps without any problems

Reuses existing commodity hardware!

Extensions: bidirectional flow handling!Example: to implement learning MAC

Giuseppe Bianchi

Conclusions Finite state machines: «the» programming abstraction for network

devices?Wireless AND wired!

Plenty of new research directions in wirelessHow to platform-agnostic program wireless PHY and cross-layer?How to exploit programmable devices in the cognitive control loop?

We focuses so far on the «act» phase of the cognitive loop: how and when to decide MAC protocol reconfiguration?

And in OpenFlow as wellSo far proof of concept for Mealy Machines only

Can we move towards «full» XFSM?Network switch = generic computing device?

And new directions in SDN, as wellWhat does control/data plane separation really means?