Platform-independent Wireless Device Reconfiguration What can we learn from SDN? Anything we may hand back to SDN?

Platform-independent Wireless Device Reconfiguration What 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. Gringoli OpenstateM. Bonola, A. Capone, C. Cascone

Software-Defined Radio • from radios with behavior fixed in hardware to radios with behavior determined by software • 20+ years long researchpath; excellenttechnologies • AirBlue, CalRadio, GNURadio, RUNIC, SORA, USRP, WARP, … • So far, niche exploitation • E.g. military • But commercial transition seems now here

Software-Defined Radio • Unfortunately… [quoting Partridge, 2011] • … [we] are all imperfectly prepared to take advantage. • Research on vital questions has been extremely variable • with 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, Realizingthe future of Wireless Data communication, 2011

Meanwhile, standards & vendors … • One-size-fits-allprotocols • E.g. 802.11 WLAN • Packingasmanyamendmentsaspossibleintooneprotocol • 802.11e QoS, 802.11p vehicular, 802.11s mesh, 802.11v mgmt, 802.11z direct link enhancements, 802.11aa multimedia, 802.11ae QoSmgmt, 802.11ah M2M, etc • Rationale: must fitseverallargelydifferentcontexts and scenarios • Aftermath: years to finalize, backwardcompatibility, compromises, …

Onesizehardlyfitsallcontextmatters! • Dynamicspectrumaccess • Very diverse situations(e.g. countries) • very diverse environmentalconditions • Dense/sparse, hiddenterminals, legacydeployments, etc • Differentpropagationcharacteristics • Sub-GHz, THz • Nicheenvironmentswith specificneeds • home, industrial, M2M, … • Adaptation to specificcontext or applications • Virtualization, access network sharing • Multi-tenancy • Multiple coexistingapplications • M2M and H2H over sameaccess network… • And many more… Diverse needs diverse design!

Everythingwould be mucheasierif… Monitor and detectContextchanges (interf., traffic, hiddennodes, neighbors, etc) Here’s a new contextspecificprotocolstack! Please Install this radio protocolstack Hello, may I associate? Let’sreconfigureterminals to best fit new condition [using a legacyprotocol, e.g. DCF] Whole radio protocolstack as a sort of JAVA applet How to make this vision come true? Either a platform-agnostic radio programminglanguage, or… alldevices of the samevendor…

Multi-tenancywouldbecometrivial Operator B Operator A Change of contextconditions Change of contextconditions Custom stack A Custom stack B

For instance: MAC protocols’ time slicing Time «slice» dedicated to OPA, best efforttraffic chooses DCF-like Time «slice» dedicated to OPA, guaranteedtraffic chooses TDM-like trivial idea, isolationguaranteed, any (custom) MAC protocol in anytenant’ slice… buttoday hard to implement (and non standard)

In the mean time, in another (wired) galaxy… • The rise of Software Defined Networking • OpenFlow, 2008 • SDN, 2010 • Market hype, 2012 • Almost 2 B$ SDN companies acquisition • MainlyNicira, butalsoContrail, Big Switch, Cariden, Vyatta, … Compare timing and $$$ with SDR take up…

Why SDN = $$$ • SDN: programmablecentral control of network operation and traffic • Open, vendor-netural, APIs • Northbound, southbound (mainlyOpenFlow) • Easy and fast deployment and innovation Net «app» Net «app» Controller Network-wide, standard-based, interface – northbound API Net «OS» Device-level, standard-based, interface – southbound API Data plane Packet Forwarding Packet Forwarding Packet Forwarding

Which SDN breakthrough? • Control/data planeseparation? • Nah… • A keyfeature, butnotnearly new • Wellestablished in POTS, SNMP, etc • Verywellestablished in wireless aswell • Entrerprise WLAN, CAPWAP since 2003, … • SDN realbreakthrough: viablevendor-neutralprogrammingabstractions! Nodebehavior Description (formal) Network Entity e.g. Switch Anyvendor, anysize, any HW/SW platform…

OpenFlow: a compromise[originalquotes: 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 ﬂexibility that is • High performance and low cost • Capable of supporting a broad range of research • Consistent with vendors’ need for closed platforms. A successful compromise, indeed… ask Nicira…

OpenFlow: just oneabstractiongood for switches, not for «all» Programmabile logic Vendor-implemented Matching Rule Action • FORWARD TO PORT • ENCAPSULATE&FORWARD • DROP • … • Extensible Pre-implementedmatchingengine Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport

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 ﬂexibility that is • High performance and low cost • Capable of supporting a broad range of research • Consistent with vendors’ need for closed platforms. Butwhich «right compromise»? Describing a wireless devicebehavioris NOT as «easy» asabstracting a flow table…

Let’s focus on MAC protocols • Our work • Infocom 2012, Context 2012, Wintech 2013 • Simpler to address than «full» SDR, butalreadynotnearlytrivial • How to provide a platform-agnosticdescription of MAC protocolswhich • Doesnotrequire open source devices • Stillpermits to operate atms time scales • Must run in the (closed source) NIC…

Learn from computingsystems? Let’s MIMIC allthis! • 1: Instruction setsperform elementary tasks on the platform • A-priori given by the platform • Can be VERY rich in special purpose computing platforms • Crypto accelerators, GPUs, DSPs, etc • 2: Programming languages sequence of such instructions + conditions • Convey desired platform’s operation or algorithm • 3: Central Processing Unit (CPU)execute program over the platform • Unaware of what the program specifically does • Fetch/invoke instructions, update registers, etc Cleardecouplingbetween: • - platform’s vendor implements (closed source!) instruction set & CPU • - programmer produces SW code in givenlanguage

1: Whichelementary MAC tasks?(“our” instruction set!) • ACTIONS • frame management, radio control, timescheduling • TX frame, set PHY params, RX frame, set timer, freezecounter, buildheader, forge frame, switchchannel, etc • EVENTS • available HW/SW signals/interrupts • Busychannelsignal, RX indication, inqueued frame, end timer, etc • CONDITIONS • boolean/arithmetictests on availableregisters/info • Frame address == X, queuelength >0, ACK received, powerlevel < P, etc

Implemented APIPlatform: Broadcom Airforce54g commodity card Just “one” possible API convenient on ourcommodityplatform “others” possibleaswell improved/extended tailoredto more capable radio HW Ourpoint, so far: have a specified setofactions/events/conditions, not “which” specificone)

2: Howto compose MAC tasks?(“our” programminglanguage!) • Convenient “language”: XFSMeXtended Finite State Machines • Compact way for composing available acts/ev/condto form a custom MAC protocol logic Originstate Destinationstate • configaction() EVENT (condition) Action() Destinationstate Destinationstate

XFSM example: legacy DCFsimplifiedforgraphicalconvenience 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

3: Howtorun a MAC program? (MAC engine – XFSM onboardexecutor -our CPU!) • MAC engine: specialized XFSM executor (unaware of MAC logic) • Fetch state • Receive events • Verify conditions • Perform actions and state transition • Once-for-all implemented in NIC (no need for open source) • “close” to radio resources = straightforward real-time handling • Different MAC protocol = different “XFSM program”!

Is this viable? • Implemented on an ultra-cheap commodity WLAN NIC • Real world card: BroadcomAirforce54g 4311/4318 • Poorresources: general purpose processor (88 MHz), 4KB data memory, 32 KB code memory • More recently, alsoimplemented on WARP (but this wasnot a challenge!) Implementationat 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 configurationregisters for radio resource and eventhandling • Frequency, power, channelsensing, frame forgingfacilities, etc • Available HW events (packetqueued, plcp end, rx end, rxcorrect frame, crcfailure, timer expiration, carriersense, etc) • MAC engine: XFSM executor • Several annoyting technical hurdles addressed (e.g. lack of support of interrupt handling) • Developed “machine language” for MAC engine

MAC Programs • MAC description: • XFSM • XFSM  tables • Transitions • «byte»-code event, condition, action • Portable over differentvendors’ devices, as long as API is the same!! • Pack & optimize in WMP «machine-language» bytecode MAC protocolspecification: XFSM design (e.g. Eclipse GMF) C Machine-readable code Custom languagecompiler B A A T(A,B) B T(B,C) C T(C,A) T(C,B) Code injectionin radio HW platform B A MAC Engine MAC Bytecode A T(A,B) C B T(B,C) C T(C,A) T(C,B)

MachineLanguageExample(DCF, 544 bytes)

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) Wireless MAC Processor: Overall architecture

From MAC Programs to MAClets • Upload MAC programon NIC from remote • Whileanother MAC isrunning • Embed code in ordinarypackets • WMP Control Primitives • load(XFSM) • run(XFSM) • verify(XFSM) • switch(XFSM1, XFSM2, ev, cond) • Furtherprimitives • Synchrosupport for distributed start of same MAC operation • Distribution protocol “Bios” state machine: DEFAULT protocol (e.g. wifi) which all terminals understand

Multi-threaded MAC Seamlessswitch from one MAC program to another in negligible time less than 0.2 us over such cheap hardware! (plus channelswitching time ifrequired)

AP Virtualization with MAClets • Two operators on same AP/infrastructure • A: wants TDM, fixed rate • B: 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) Timer expiration DCF SUSPEND Beacon reception & conversely

Controller’sarchitectureused OMF as SDN controller… (!) Measurementprocess Collectsstatistics for contextestimation Resource Controller Managesdevice (load, control) Experiment Controller Network-wide orchestration

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

Back again to the wiredgalaxy… • Aftermath: XFSM as a very appropriate abstraction for wireless MAC protocols’ programming • Openflow: compromise, whichpermits «only» to programstateless flow tables • Crazy idea? OpenFlow + XFSM?

OF’s remote intelligence… Winning SDN idea for network-wide states and «big picture» decisions Poor idea for localstates/decision, (way!) betterhandledlocally (less delay,lesssignallingload) Controller Application (smart = states) Network OS Events from switches Topology changes, Traffic statistics, Arriving packets Commands to switches (Un)install rules, Query statistics, Send packets Forwarding device (dumb) The real cause: OF doesnotpermit to «program» statefulrulechanges(remember, OF was a compromise)

Example: howyou’dimplement an OF portknocking firewall? knock «code»: 5123, 6234, 7345, 8456 DROP IPsrc=1.2.3.4 Port=5123 Flow 1.2.3.4: encapsulate & forward Port 5123? Store state,1° knock OK controller

Example: howyou’dimplement an OF portknocking firewall? knock «code»: 5123, 6234, 7345, 8456 DROP IPsrc=1.2.3.4 Port=8456 Flow 1.2.3.4: encapsulate & forward Add flow entry for 1.2.3.4:22 Port 8456? Store state,OPEN controller

Example: howyou’dimplement an OF portknocking firewall? knock «code»: 5123, 6234, 7345, 8456 DROP IPsrc=any Port=any ALL packets of ALL flows Must be forwarded to controller!! Until flow entry installed! controller

Controller implementation for portknocking: MealyMachine(simplerform of XFSM) Port=7345 Drop() Port=8456 Drop() Port=22 Forward() Port!=5123 Drop() Port=5123 Drop() Port=6234 Drop() DEFAULT Stage 1 Stage 2 Stage 3 OPEN Port!=7345 Drop() Port!=8456 Drop() Port!=6234 Drop() Port!=22 Drop() 1 state machine for allflows (sameknockingsequence) N states, one per (active) flow

Can transform in a flow table? Yes! Match fields Actions state event action Next-state DEFAULT Port=5123 drop STAGE-1 STAGE-1 Port=6234 drop STAGE-2 STAGE-2 Port=7345 drop STAGE-3 STAGE-3 Port=8456 drop OPEN OPEN Port=22 forward OPEN OPEN Port=* drop OPEN * Port=* drop DEFAULT Ifnext state were an OF instruction, this would be aSTANDARD OF1.3+ flow table! TCAM implementation Metadata (any bit string) Headerfield (port #)

And whatabout flow states? Flow key state IPsrc= … … … … … Ipsrc= … … … … … IPsrc=1.2.3.4 STAGE-3 IPsrc=5.6.7.8 OPEN IPsrc= … … … … … IPsrc= no match DEFAULT Just a (Hash) Table, e.g. dleft/cuckoohash No need for TCAM (thoughusefulextension for staticmatches)

State Table Puttingalltogether Flow key state IPsrc=1.2.3.4 Port=8456 IPsrc= … … … … … Ipsrc= … … … … … IPsrc=1.2.3.4 STAGE-3 IPsrc=5.6.7.8 OPEN 1) State lookup IPsrc= … … … … … IPsrc= no match DEFAULT XFSM Table Match fields Actions state event action Next-state DEFAULT Port=5123 drop STAGE-1 IPsrc=1.2.3.4 Port=8456 STAGE-3 STAGE-1 Port=6234 drop STAGE-2 STAGE-2 Port=7345 drop STAGE-3 STAGE-3 Port=8456 drop OPEN 2) XFSM state transition OPEN Port=22 forward OPEN OPEN Port=* drop OPEN * Port=* drop DEFAULT State Table Flow key state IPsrc= … … … … … IPsrc=1.2.3.4 Port=8456 OPEN Ipsrc= … … … … … IPsrc=1.2.3.4 Write:OPEN 3) State update IPsrc=5.6.7.8 OPEN IPsrc= … … … … … IPsrc= no match DEFAULT

Cross-flow state handling • Yes butwhatabout MAC learning, multi-portprotocols (e.g., FTP), bidirectional flow handling, etc? State Table MACdst MACsrc lookup Flow key state 48 bit MAC addr Port # XFSM Table state event action Next-state Port# * forward In-port State Table MACdst MACsrc update Flow key state 48 bit MAC addr Port # DIFFERENT lookup/update scope Field 1 Field 2 Field N Read/writesignal Flowkeyselector

Aftermath: a nicesurprise! • OpenFlow can supportstates and state transitions! • With marginalmodifications! • SeeOpenstate, ACM CCR, April 2014 • Bringing control back inside the switch • At wirespeed • Via platformindependentabstraction • A new perspectivetowards SDN control/data planeseparation? • Controller DECIDES, butswitch can now ENFORCE! A lotfaster! • Proof of conceptimplementations • Software: O(days) on SoftSwitch (OFv1.3) • Hardware: in progress, first prototypeat 10 Gbpswithoutanyproblems • Reusesexisting commodity hardware! • Extensions: • bidirectional flow handling! • Example: to implementlearning MAC

Conclusions • Finite state machines: «the» programmingabstraction for network devices? • Wireless AND wired! • Plenty of new researchdirections in wireless • How to platform-agnosticprogram wireless PHY and cross-layer? • How to exploit programmabledevices in the cognitive control loop? • Wefocuses so far on the «act» phase of the cognitive loop: how and when to decide MAC protocolreconfiguration? • And in OpenFlowaswell • So far proof of concept for MealyMachinesonly • Can wemovetowards «full» XFSM? • Network switch = genericcomputingdevice? • And new directions in SDN, aswell • Whatdoes control/data planeseparationreallymeans?

Platform-independent Wireless Device Reconfiguration What can we learn from SDN? Anything we may hand back to SDN?