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 research path; excellent technologies 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, Realizing the future of Wireless Data communication, 2011

Meanwhile, standards & vendors … One-size-fits-all protocols E.g. 802.11 WLAN Packing 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, …

One size hardly fits all context matters! Dynamic spectrum access Very diverse situations (e.g. countries) very diverse environmental conditions Dense/sparse, hidden terminals, legacy deployments, etc Different propagation characteristics Sub-GHz, THz Niche environments with specific needs home, industrial, M2M, … Adaptation to specific context or applications Virtualization, access network sharing Multi-tenancy Multiple coexisting applications M2M and H2H over same access network… And many more… Diverse needs  diverse design!

Everything would be much easier if… Monitor and detect Context changes (interf., traffic, hidden nodes, neighbors, etc) Here’s a new context specific protocol stack! Please Install this radio protocol stack Hello, may I associate? [using a legacy protocol, e.g. DCF] Let’s reconfigure terminals to best fit new condition Whole radio protocol stack as a sort of JAVA applet How to make this vision come true? Either a platform-agnostic radio programming language, or… all devices of the same vendor…

Multi-tenancy would become trivial Operator B Operator A Change of context conditions Change of context conditions Custom stack A Custom stack B

For instance: MAC protocols’ time slicing Time «slice» dedicated to OPA, best effort traffic  chooses DCF-like Time «slice» dedicated to OPA, guaranteed traffic  chooses TDM-like trivial idea, isolation guaranteed, any (custom) MAC protocol in any tenant’ slice… but today 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 Mainly Nicira, but also Contrail, Big Switch, Cariden, Vyatta, … Compare timing and $$$ with SDR take up…

Why SDN = $$$ SDN: programmable central control of network operation and traffic Open, vendor-netural, APIs Northbound, southbound (mainly OpenFlow) 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 plane separation? Nah… A key feature, but not nearly new Well established in POTS, SNMP, etc Very 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…

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 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 one abstraction good for switches, not for «all» Programmabile logic Vendor-implemented Matching Rule Action FORWARD TO PORT ENCAPSULATE&FORWARD DROP … Extensible Pre-implemented matching engine 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 flexibility that is High performance and low cost Capable of supporting a broad range of research Consistent with vendors’ need for closed platforms. But which «right compromise»? Describing a wireless device behavior is NOT as «easy» as abstracting a flow table…

Let’s focus on MAC protocols Our 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 which Does not require open source devices Still permits to operate at ms time scales Must run in the (closed source) NIC…

Learn from computing systems? Let’s MIMIC all this! 1: Instruction sets perform 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 Clear decoupling between: - platform’s vendor  implements (closed source!) instruction set & CPU - programmer  produces SW code in given language

1: Which elementary MAC tasks? (“our” instruction set!) 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 EVENTS available HW/SW signals/interrupts Busy channel signal, RX indication, inqueued frame, end timer, etc CONDITIONS boolean/arithmetic tests on available registers/info Frame address == X, queue length >0, ACK received, power level < P, etc

Implemented API Platform: Broadcom Airforce54g commodity card 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)

2: How to compose MAC tasks? (“our” programming language!) Convenient “language”: XFSM eXtended Finite State Machines Compact way for composing available acts/ev/cond to form a custom MAC protocol logic Origin state Destination state config action() EVENT (condition) Action() Destination state Destination state

XFSM example: legacy DCF simplified for graphical convenience 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: How to run a MAC program 3: How to run a MAC program? (MAC engine – XFSM onboard executor - 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: 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

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 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 T(A,B) T(B,C) T(C,A) T(C,B) A B C T(A,B) T(B,C) T(C,A) T(C,B) A B C

Machine Language Example (DCF, 544 bytes)

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)

From MAC Programs to MAClets Upload MAC program on NIC from remote While another MAC is running Embed 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

Multi-threaded MAC less than 0.2 us over such cheap hardware! Seamless 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)

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’s architecture used OMF as SDN controller… (!) Measurement process Collects statistics for context estimation Resource Controller Manages device (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 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 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?

OF’s remote intelligence… 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) 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 does not permit to «program» stateful rule changes (remember, OF was a compromise)

Port 5123? Store state, 1° knock OK Example: how you’d implement an OF port knocking 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

Port 6234? Store state, 2° knock OK Example: how you’d implement an OF port knocking firewall? knock «code»: 5123, 6234, 7345, 8456 DROP IPsrc=1.2.3.4 Port=6234 Flow 1.2.3.4: encapsulate & forward Port 6234? Store state, 2° knock OK controller

Port 7345? Store state, 3° knock OK Example: how you’d implement an OF port knocking firewall? knock «code»: 5123, 6234, 7345, 8456 DROP IPsrc=1.2.3.4 Port=7345 Flow 1.2.3.4: encapsulate & forward Port 7345? Store state, 3° knock OK controller

Example: how you’d implement an OF port knocking firewall Example: how you’d implement an OF port knocking 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: how you’d implement an OF port knocking firewall Example: how you’d implement an OF port knocking 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 port knocking: Mealy Machine (simpler form of XFSM) DEFAULT Stage 1 Stage 2 Stage 3 OPEN Port=6234 Drop() Port!=6234 Port!=5123 Port=5123 Port=7345 Port=8456 Port!=7345 Port!=8456 Port=22 Forward() Port!=22 1 state machine for all flows (same knocking sequence) N states, one per (active) flow

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

And what about flow states? Flow key state IPsrc= … … Ipsrc= … … … … … IPsrc=1.2.3.4 IPsrc=5.6.7.8 STAGE-3 OPEN IPsrc= no match DEFAULT Just a (Hash) Table, e.g. dleft/cuckoo hash No need for TCAM (though useful extension for static matches)

Putting all together State Table 1) State lookup XFSM Table 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=1.2.3.4 Port=8456 OPEN IPsrc= … … … … … 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 but what about MAC learning, multi-port protocols (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/write signal Flowkey selector

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 switch At wire speed Via platform independent abstraction A new perspective towards SDN control/data plane separation? Controller DECIDES, but switch can now ENFORCE! A lot faster! Proof of concept implementations Software: 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

Conclusions Finite state machines: «the» programming abstraction for network devices? Wireless AND wired! Plenty of new research directions in wireless How 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 well So 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 well What does control/data plane separation really means?