Presentation on theme: "Giuseppe Bianchi Platform-independent Wireless Device Reconfiguration What can we learn from SDN? Anything we may hand back to SDN? Giuseppe Bianchi CNIT."— Presentation transcript:
Giuseppe Bianchi 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
Giuseppe Bianchi 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
Giuseppe Bianchi 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
Giuseppe Bianchi Meanwhile, standards & vendors … One-size-fits-all protocols E.g WLAN Packing as many amendments as possible into one protocol e QoS, p vehicular, s mesh, v mgmt, z direct link enhancements, aa multimedia, ae QoS mgmt, ah M2M, etc Rationale: must fit several largely different contexts and scenarios Aftermath: years to finalize, backward compatibility, compromises, …
Giuseppe Bianchi 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!
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
Giuseppe Bianchi For instance: MAC protocols’ time slicing Time «slice» dedicated to OP A, 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 OP A, guaranteed traffic chooses TDM-like
Giuseppe Bianchi 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…
Giuseppe Bianchi 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 Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Device-level, standard-based, interface – southbound API Controller Data plane 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, 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…
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 ﬂ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 …
Giuseppe Bianchi OpenFlow: just one abstraction good for switches, not for «all» Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Matching Rule Action 1. FORWARD TO PORT 2. ENCAPSULATE&FORWARD 3. DROP 4. … Extensible Vendor-implemented Programmabile 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 ﬂexibility 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…
Giuseppe Bianchi 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 s time scales Must run in the (closed source) NIC…
Giuseppe Bianchi Learn from computing systems? 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 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 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 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 API Platform: Broadcom Airforce54g commodity card
Giuseppe Bianchi Convenient “language”: XFSM eXtended Finite State Machines Compact 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 state config action () Destination state EVENT (condition) Action () Destination state
Giuseppe Bianchi 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”! 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 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) A B C A B C T(A,B) T(B,C) T(C,A)T(C,B) A B C 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 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
Giuseppe Bianchi Multi-threaded MAC 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)
Giuseppe Bianchi 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) DCF SUSPEND Timer expiration Beacon reception & conversely
Giuseppe Bianchi 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
Giuseppe Bianchi Public-domain Supported by the FLAVIA EU FP7 project Ongoing integration in the CREW EU FP7 federated testbed Public domain release Project page: Download: https://github.com/ict-flavia/Wireless-MAC-Processorhttps://github.com/ict-flavia/Wireless-MAC-Processor Developer team: 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 switches Topology 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= Port=5123 Flow : 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= Port=6234 Flow : 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= Port=7345 Flow : 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= Port=8456 Flow : encapsulate & forward DROP controller Port 8456? Store state, OPEN Add flow entry for :22
Giuseppe Bianchi Example: how you’d implement an OF port knocking firewall? knock «code»: 5123, 6234, 7345, 8456 IPsrc=anyPort=any DROP controller ALL packets of ALL flows Must be forwarded to controller!! Until flow entry installed!
Giuseppe Bianchi Controller implementation for port knocking: Mealy Machine (simpler form of XFSM) DEFA ULT Stage 1 Stage 2 Stage 3 OPEN Port=6234 Drop() Port!=6234 Drop() Port!=5123 Drop() Port=5123 Drop() Port=7345 Drop() Port=8456 Drop() Port!=7345 Drop() Port!=8456 Drop() Port=22 Forward() Port!=22 Drop() 1 state machine for all flows (same knocking sequence) N states, one per (active) flow
Giuseppe Bianchi Can transform in a flow table? Yes! stateevent DEFAULT STAGE-1 Port=5123 Port=6234 STAGE-2 STAGE-3 Port=7345 Port=8456 OPENPort=22 OPEN * Port=* Match fieldsActions actionNext-state drop STAGE-1 STAGE-2 drop STAGE-3 OPEN forwardOPEN drop OPEN DEFAULT 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 keystate IPsrc= … … Ipsrc= … … … … … IPsrc= IPsrc= STAGE-3 OPEN IPsrc= no matchDEFAULT IPsrc= … … … … … Just a (Hash) Table, e.g. dleft/cuckoo hash No need for TCAM (though useful extension for static matches)
Giuseppe Bianchi Putting all together IPsrc= Flow keystate IPsrc= … … Ipsrc= … … … … … IPsrc= IPsrc= STAGE-3 OPEN IPsrc= no matchDEFAULT IPsrc= … … State Table … … … Port=8456 stateevent DEFAULT STAGE-1 Port=5123 Port=6234 STAGE-2 STAGE-3 Port=7345 Port=8456 OPENPort=22 OPEN * Port=* XFSM Table Match fieldsActions actionNext-state drop STAGE-1 STAGE-2 drop STAGE-3 OPEN forwardOPEN drop OPEN DEFAULT IPsrc= Port=8456STAGE-3 OPEN Flow keystate IPsrc= … … Ipsrc= … … … … … IPsrc= IPsrc= Write:OPEN OPEN IPsrc= no matchDEFAULT IPsrc= … … State Table … … … IPsrc= Port=8456 1) State lookup 2) XFSM state transition 3) State update
Giuseppe Bianchi Cross-flow state handling MACdstMACsrc Flow keystate 48 bit MAC addr Port # lookup State Table MACdstMACsrc Flow keystate 48 bit MAC addr Port # update State Table stateevent Port# * actionNext-state forward In-port XFSM Table DIFFERENT lookup/update scope Field 1Field 2Field 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 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
Giuseppe Bianchi 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?