Data Plane Programmability the next step in SDN Giuseppe Bianchi CNIT / University of Roma Tor Vergata Credits to: M. Bonola, A. Capone, C. Cascone, S. Pontarelli, D. Sanvito, M. Spaziani Brunella, V. Bruschi EU Support: Beba BEhavioural BAsed forwarding Giuseppe Bianchi OpenFlow’s platform The SDN/OpenFlow Model agnostic «program»: (abstract) Flow table è Very elegant and performing Match 1 à Act A ð Switch as a «sort of» programmable device Match 2 à Act B ð Line-rate/fast-path (HW) performance ð Can be «repurposed» as switch, router, Controller firewall, etc è …but… ð Static rules Run-time deployment ð All intelligence in controller (flow-mod) ð Lack of flexibility and espessivity: more of a config than a program! Not yet «programmed» Pre- Match implemented primitives Match 1 à Act A actions Match 2 à Act B Networking-specific programmable device OpenFlow (HW/SW) switch Giuseppe Bianchi 1
The NVF model (opposite extreme) Ordinary SW program è Ultra flexible (possibly closed src) ð C/C++ coding Specific NF è …but BIG price to pay… ð Poor performance (slow path) VM ð No NF programming abstraction à Portability only at VM level Run-time deployment à NF may be completely deploy VM = migrate proprietary BOTH NF program AND prog. environment Virtualization (e.g. hypervisor) General purpose computing platform X86, ARM, etc Giuseppe Bianchi Abstract programming What we’d like to do? API (e.g. XFSM-based, more later), Platform agnostic «program» è Same SDN-like model ð Based on abstractions NF as script in ð Native line-rate «netlanguage» (e.g. XFSM) ð Portable!! (platform independent) è But much closer to the NFV Controller programming needs ð MUCH more expressive and flexible than OpenFlow Run-time deployment è Price to pay: ð Need for network-specific HW/SW (inject netlanguage script) «netlanguage processor» à But still general purpose processor! Not yet «programmed» Pre-implemented Pre- Match «netlanguage» implemented primitives execution engine actions @ fast-path Networking-specific programmable device (HW/SW) switch: not x86/ARM but a general purpose netputing device! Giuseppe Bianchi 2
What we’d like to do? OpenFlow / SDN Our view / SDN Central control à still decides how SMART! SMART! switches shall «behave» Control- Control- plane plane OpenFlow Extended ß Forwarding rules ß Forwarding behavior: switch switch ß Forwarding rules AND how they should change or adapt to «events» Data-plane Data-plane Smart switches à DUMB! SMART! can dynamically update flow tables at wire speed Describe forwarding behavior! Giuseppe Bianchi What we’d like to do? OpenFlow / SDN Our view / SDN Central control à still decides how SMART! SMART! Behavioral Forwarding in a nutshell: switches shall «behave» Dynamic forwarding rules/states à Control- Control- plane plane some control tasks back (!) into the switch OpenFlow Extended ß Forwarding rules ß Forwarding behavior: (hard part: via platform-agnostic abstractions) switch switch ß Forwarding rules AND how they should change or adapt to «events» Data-plane Data-plane Smart switches à DUMB! SMART! can dynamically update flow tables at wire speed Describe forwarding behavior! Giuseppe Bianchi 3
Towards data plane programmability: state of the art Giuseppe Bianchi OpenFlow evolutions è Pipelined tables from v1.1 ð Overcomes TCAM size limitation ð Multiple matches natural à Ingress/egress, ACL, sequential L2/L3 match, etc. è Extension of matching capapilities ð More header fields ð POF (Huawei, 2013): complete matching flexibility! è Openflow «patches» for (very!) specific processing needs and states ð Group tables, meters, synchronized tables, bundles, typed tables (sic!), etc ð Not nearly clean, hardly a «first principle» design strategy ð A sign of OpenFlow structural limitations? Giuseppe Bianchi 4
Programming the data plane: The P4 initiative (2014) è SIGCOMM CCR 2014. Bosshart, ETH McKeown, et al. P4: Programming VLAN protocol-independent packet processors ð Dramatic flexibility improvements in packet processing pipeline IPV6 L2S IPV4 à Configurable packet parser à parse graph à Target platform independence à compiler maps onto switch details L2D TCP UDP à Reconfigurability à change match/process fields during pipeline è Feasible with HW advances ð Reconfigurable Match Tables, SIGCOMM 2013 ACL ð Intel’s FlexPipe TM architectures è P4.org: Languages and compilers Table Graph ð Further support for «registry arrays» and counters meant to persist across multiple packets à Though no HW details, yet Giuseppe Bianchi Programming the data plane: The P4 initiative (2014) è SIGCOMM CCR 2014. Bosshart, ETH McKeown, et al. P4: Programming VLAN protocol-independent packet processors OpenFlow 2.0 proposal? ð Dramatic flexibility improvements in packet processing pipeline Stateful processing, but only «inside» a packet IPV6 L2S IPV4 à Configurable packet parser à parse graph processing pipeline! à Target platform independence à compiler maps onto switch details L2D TCP UDP à Reconfigurability à change match/process fields Not yet (clear) support for stateful processing during pipeline «across» subsequent packets in the flow è Feasible with HW advances “[…] extend P4 to express stateful processing”, ð Reconfigurable Match Tables, SIGCOMM 2013 ACL ð Intel’s FlexPipe TM architectures Nick McKeown talking about P4 @ OVSconf Nov 7, 2016 è P4.org: Languages and compilers Table Graph ð Further support for «registry arrays» and counters meant to persist across multiple packets à Though no HW details, yet Giuseppe Bianchi 5
OpenState, 2014 è Our group, SIGCOMM CCR 2014; surprising finding: an OpenFlow switch can «already» support stateful evolution of the forwarding rules ð With almost marginal (!) architecture modification OpenFlow / SDN OpenState / SDN Central control à SMART! SMART! still decides how switches shall Control- Control- plane plane «behave» OpenFlow OpenState ß Forwarding rules ß Forwarding behavior: switch switch ß Forwarding rules AND how they should change or adapt to «events» Data-plane Data-plane DUMB! SMART! Smart switches à can dynamically update flow tables at wire speed Giuseppe Bianchi Our findings at a glance è Any control program that can be described by a Mealy (Finite State) Machine is already (!) compliant with OF1.3 è MM + Bidirectional flow state handling requires minimal hardware extensions to OF1.1+ Details in G. Bianchi, M. Bonola, A. Capone, C. Cascone, “ OpenState: programming platform-independent stateful OpenFlow applications inside the switch ”, ACM SIGCOMM Computer Communication Review, vol. 44, no. 2, April 2014. Giuseppe Bianchi 6
Our findings at a glance è Any control program that can be described by a Mealy (Finite State) Candidate for inclusion in (as early as!) Machine is already (!) compliant with OpenFlow 1.6 OF1.3 Ongoing discussion in ONF à very concrete, fine tuning of details è MM + Bidirectional flow state handling requires minimal hardware Pragmatism and compatibility with OpenFlow à extensions to OF1.1+ key asset for being considered Details in G. Bianchi, M. Bonola, A. Capone, C. Cascone, “ OpenState: programming platform-independent stateful OpenFlow applications inside the switch ”, ACM SIGCOMM Computer Communication Review, vol. 44, no. 2, April 2014. Giuseppe Bianchi Remember OF match/action API Programmabile logic Vendor-implemented Matching Action Rule 1. FORWARD TO PORT 2. ENCAPSULATE&FORWARD 3. DROP 4. … Extensible Pre-implemented matching engine Switch MAC MAC Eth VLAN IP IP IP TCP TCP Port src dst type ID Src Dst Prot sport dport Giuseppe Bianchi 7
What is the OF abstraction, formally? è Packet header match = “ Input Symbol ” in a finite set I= { i 1 , i 2 , …, i M }. ð One input symbol = any possible header match ð Possible matches pre-implemented; cardinality depends on match implementation ð Theoretically, it is irrelevant how the Input Symbols’ set I is established à i.e. each input symbol = Cartesian combination of multiple header field matches, further including “wildcard” matches; à E.s. incoming packet destination port = 5238 AND source IP address is 160.80.82.1, and the VLAN tag is 1111, etc. è OpenFlow actions = “ Output Symbols ” in finite set O= { o 1 , o 2 , …, o N } ð Pre-implemented actions è OpenFlow’s match/action abstraction: a map T : I à O ð all what the third party programmer can specify! Giuseppe Bianchi Reinterpreting (and extending) the OpenFlow abstraction è OpenFlow map is trivially recognized to be a very special and trivial case of a Mealy Finite State Machine è T : {default-state} × I à {default-state} × O , è i.e. a Finite State Machine with output, where we only have one single (default) state! è By adding (per-packet) retrieval and update of states, OpenFlow can be turned it into a Mealy machine executor!! Giuseppe Bianchi 8
Recommend
More recommend
