1. Software Defined Networking COMS 6998-10, Fall 2014 Instructor: Li Erran Li (lierranli@cs.columbia.edu) http://www.cs.columbia.edu/~lierranli/coms 6998-10SDNFall2014/ 9/29/2014: SDN Programming Language

2. Outline Announcements – Homework 2 will be posted on Thursday, due in 18 days Review of previous lecture Project ideas on scalable controller for cellular WAN SDN programming language – Maple: generic programming language syntax such as Java, Python – NetKAT: domain specific programming language 29/29/14 Software Defined Networking (COMS 6998-10)

3. Review of Previous Lecture How do we design scalable software defined networks? – Design scalable controllers – Offload control plane processing to switches How do we design scalable controllers? – Flat structure multiple controllers – Recursive controller design – Hierarchical controller design 39/29/14 Software Defined Networking (COMS 6998-10)

4. Review of Previous Lecture (Cont’d) How to offload control plane processing to switches? – Offload to switch control plane Controller proactively generates the rules and distributes them to authority switches Authority switches keep packets always in the data plane and ingress switches reactively cache rules – Offload to switch data plane Try to stay in data-plane, by default Provide enough visibility: for significant flows & sec-sensitive flows; Otherwise, aggregate or approximate statistics 49/29/14 Software Defined Networking (COMS 6998-10)

5. Review of Previous Lecture (Cont’d) How do we divide tasks among controller instances? Partition – Controller instances with different computations tasks – Controller instances have only subsets of the NIB – Switches connect to a subset of controller instances Aggregation – Reduce fidelity of information 59/29/14 Software Defined Networking (COMS 6998-10)

6. Review of Previous Lecture (Cont’d) How to maintain network information base (NIB)? – Replicated transactions (SQL) storage for strong consistency (more static information) – One-hop memory-based DHT for weak consistency (more dynamic information) 69/29/14 Software Defined Networking (COMS 6998-10)

7. Following packets Review of Previous Lecture (Cont’d) Ingress Switch Authority Switch Egress Switch First packet Redirect Forward Feedback: Cache rules Hit cached rules and forward Offload to switch control plane Source: Minlan Yu 79/29/14 Software Defined Networking (COMS 6998-10)

8. Review of Previous Lecture (Cont’d) Rule cloning – ASIC clones a wildcard rule as an exact match rule for new microflows – Timeout or output port by probability 89/29/14 Software Defined Networking (COMS 6998-10)

9. Review of Previous Lecture (Cont’d) Rule cloning – ASIC clones a wildcard rule as an exact match rule for new microflows – Timeout or output port by probability 99/29/14 Software Defined Networking (COMS 6998-10)

10. Review of Previous Lecture (Cont’d) Rule cloning – ASIC clones a wildcard rule as an exact match rule for new microflows – Timeout or output port by probability 109/29/14 Software Defined Networking (COMS 6998-10)

11. Review of Previous Lecture (Cont’d) Local actions – Rapid re-routing: fallback paths predefined  Recover almost immediately – Multipath support: based on probability dist. Adjusted by link capacity or loads 119/29/14 Software Defined Networking (COMS 6998-10)

12. Outline Announcements – Homework 2 will be posted on Thursday, due in 18 days Review of previous lecture Project ideas on scalable controller for cellular WAN SDN programming language – Maple: generic programming language syntax such as Java, Python – Frenetic: domain specific programming language 129/29/14 Software Defined Networking (COMS 6998-10)

13. LTE Cellular Network Architecture access core Packet Data Network Gateway Serving Gateway Internet Serving Gateway Base Station (BS) User Equipment (UE) 139/29/14 Software Defined Networking (COMS 6998-10)

14. Current Mobile WANs Organized into rigid and very large regions Minimal interactions among regions Centralized policy enforcement at PGWs Two Regions 14 9/29/14Software Defined Networking (COMS 6998-10)

15. Mobile WANs Problems Suboptimal routing in large carriers –Lack of sufficiently close PGW is a major cause of path inflation Scalability and reliability –The sheer amount of traffic and centralized policy enforcement Ill-suited to adapt to the rise of new applications –E.g., machine-to-machine –All users’ outgoing traffic traverses a PGW to the Internet, even for reaching a user served by a close base station in a neighbor region 15 9/29/14Software Defined Networking (COMS 6998-10)

16. SoftMoW Motivation Question: How to make the packet core scalable, simple, and flexible for hundreds of thousands of base stations and hundreds of millions of mobile users? Mobile networks should have fully connected core topology, small logical regions, and more egress points Operators should leverage SDN to manage the whole network with a logically-centralized controller: –Directs traffic through efficient network paths that might cross region boundaries –Handles high amount of intra-region signaling load from mobile users –Supports seamless inter-region mobility and optimizes its performance –Performs network-wide application-based such as region optimization 16 9/29/14Software Defined Networking (COMS 6998-10)

17. SoftMoW Solution Hierarchically builds up a network-wide control plane –Lies in the family of recursive SDN designs (e.g. XBAR, ONS’13) In each level, abstracts both control and data planes and exposes a set of “dynamically-defined” logical components to the control plane of the level above. –Virtual Base stations (VBS), Gigantic Switches (GS), and Virtual Middleboxes (VMB) 17 Core Net GS Latency Matrix RadioAccess Network VBS Union of Coverage Policy VMB Sum of capacities 9/29/14Software Defined Networking (COMS 6998-10)

18. New Dynamic Feature: In each level, the control logic can modify its logical components for optimization purposes –E.g., merge/spilt and move operations 18 SoftMoW Solution Move and Split Merge/Split 9/29/14Software Defined Networking (COMS 6998-10)

19. First Level-SoftMoW Architecture Replace inflexible and expensive hardware devices (i.e., PGW, SGW) with SDN switches Perform distributed policy enforcement using middle-box instances Partition the network into independent and dynamic logical regions A child controller manages the data plane of each regions Bootstrapping phase: based on location and processing capabilities of child controllers Bootstrapping phase: based on location and processing capabilities of child controllers 19 9/29/14Software Defined Networking (COMS 6998-10)

20. Second Level-SoftMoW Architecture A parent runs a global link discovery protocol –Inter-region links are not detected by BDDP and LLDP A parent participates in the inter-domain routing protocol A parent builds virtual middlebox chains and egress- point policies, and dictates to GSs 20 9/29/14Software Defined Networking (COMS 6998-10)

21. Hierarchical Traffic Engineering Latency (P1,E2)=300 Latency (P1,E4)=100 Web Voice GS Rules 21 A parent pushes a global label into each traffic group Child controllers perform label swapping o Ingress point: pop the global label and push some local labels for intra- region paths o Egress point: pop the local labels and push back the global label Push W Pop W Push W Push W2 Push W1 Pop W2 Pop W Pop W1 9/29/14Software Defined Networking (COMS 6998-10)

22. Time-of-day Handover Optimization Handover graph 22 Q: How can an operator reduce inter-region handovers in peak hours? Abstraction update GS Rule: Move Border VBS 1 coordination 9/29/14Software Defined Networking (COMS 6998-10)

23. Project Ideas Implement a G-switch driver/agent : acts as a shim to allow a G-switch to act like an actual OF switch. –This driver helps to connect any OF controller as a G- switch to its parent OF controller. In this way, installing rule-actions into G-switches and setting up paths on abstract topology becomes like the physical topology. –Driver should translate the messages or states received from the parent OF controller to the underlying topology and periodically pulls states from the local NIB to expose to the parent. Implement HazelCast on a single controller –Show performance improvement on various applications such as traffic engineering, routing, and failure recovery over the standard in-memory data structures for a single controller. 23 9/29/14Software Defined Networking (COMS 6998-10)

24. Project Ideas (Cont’d) Implement recursive link discovery protocol and the necessary translations in the shim. Implement RamCloud on a single controller –Show performance improvement on various applications such as traffic engineering, routing, and failure recovery compared with the standard NIB. Implement an orchestration layer to provide global network view –Use ZooKeeper to dynamically assign controllers to data plane switches as the network becomes larger on top of a single/flat controller. Implement the hierarchical control plane 24 9/29/14Software Defined Networking (COMS 6998-10)

25. Outline Announcements – Homework 2 will be posted on Thursday, due in 18 days Review of previous lecture Project ideas on scalable controller for cellular WAN SDN programming language – Maple: generic programming language syntax such as Java, Python – Frenetic: domain specific programming language 259/29/14 Software Defined Networking (COMS 6998-10)

26. A Key Source of Complexity in Openflow Controllers onPacketIn(p): examine p and decide what to do with p.Step 1 construct and install OF rules so that similar packets are processed at switches with same action. Step 2 26 Source: Andreas Voellmy, Yale 9/29/14 Software Defined Networking (COMS 6998-10)

27. Simple, generic solution using exact matches onPacketIn(p): examine p and decide what to do with p.Step 1 insert rule with “exact match” for p, i.e. match on ALL attributes, with action determined above. Step 2 Every flow incurs flow setup delay. 27 Source: Andreas Voellmy, Yale 9/29/14 Software Defined Networking (COMS 6998-10)

28. Step 1Step 2 p.TcpDst=22 ? dropdrop match:{TcpDst=22} action:drop send to next hop for p.EthDst match:{EthDst=p.EthDst} action:nextHop(p) yes no priority:HIGH priority:LOW tcpDst!=22 Source: Andreas Voellmy, Yale 289/29/14 Software Defined Networking (COMS 6998-10)

29. EthDst:A, TcpDst:8 0 Controller Switch EthDst:A, TcpDst:2 2 LowEthDst:APort 1 If p.TcpDst=22: insert rule {prio:HIGH, match:{TcpDst=22}, action:drop } Else: insert rule {prio:LOW, match:{EthDst=p.EthDst},action:nextHop(p.EthDst) 299/29/14 Software Defined Networking (COMS 6998-10)

30. OF Switches User Level Under the hood OF Controller Library Step 1. Make Decisions Step 2. Generate Rules 30 Source: Andreas Voellmy, Yale 9/29/14 Software Defined Networking (COMS 6998-10)

31. Algorithmic Policy OF Switches OF Controller Library Step 1. Make Decisions Step 2. Generate Rules User Level Under the hood 31 Source: Andreas Voellmy, Yale 9/29/14 Software Defined Networking (COMS 6998-10)

32. Algorithmic Policies Function in a general purpose language that describes how a packet should be routed, not how flow tables are configured. Conceptually invoked on every packet entering the network; may also access network environment state; hence it has the form: Written in a familiar language such as Java, Python, or Haskell 32 Source: Andreas Voellmy, Yale 9/29/14 Software Defined Networking (COMS 6998-10)

33. Example Algorithmic Policy in Java Route f(Packet p, Env e) { if (p.tcpDstIs(22)) return null(); else { Location sloc = e.location(p.ethSrc()); Location dloc = e.location(p.ethDst()); Path path = shortestPath(e.links(), sloc,dloc); if (p.ethDstIs(2) return null(); else return unicast(sloc,dloc,path); } Does not specify flow table configutation 33 Source: Andreas Voellmy, Yale 9/29/14 Software Defined Networking (COMS 6998-10)

34. How to implement algorithmic policies? Naive solutions -- process every packet at controller or use only exact match rules -- perform poorly Static analysis to determine layout of flow tables is possible, but has drawbacks: – Static analysis of program in general-purpose language is hard and is typically conservative – System becomes source-language dependent 34 Source: Andreas Voellmy, Yale 9/29/14 Software Defined Networking (COMS 6998-10)

35. Maple ’ s approach: runtime tracing PrioMatchAction 1tcpDst:22 ToControlle r 0ethDst:2discard 0ethDst:4, ethSrc:6port 30 PrioMatchAction 1tcpDst:22 ToControlle r 0ethDst:2discard 0ethDst:4, ethSrc:6port 30 PrioMatchAction 1tcpDst:22 ToControlle r 0ethDst:2discard 0ethDst:4, ethSrc:6port 30 1. Maple observes the dependency of f on packet data. 2. Build a trace tree (TT), a partial decision tree for f. 3. Compile flow tables (FTs) from a trace tree. 35 Source: Andreas Voellmy, Yale 9/29/14 Software Defined Networking (COMS 6998-10)

36. Route f(Packet p, Env e) { if (p.tcpDstIs(22)) return null(); else { Location dloc = e.location(p.ethDst()); Location sloc = e.location(p.ethSrc()); Path path = shortestPath( e.links(),sloc,dloc); if (p.ethDstIs(2) return null(); else return unicast(sloc,dloc,path); } EthDest:1, TcpDst:80 Assert(TcpDst, 22) false Read(EthD st) Read(EthSr c) path1 4 6 Policy 36 Source: Andreas Voellmy, Yale 9/29/14 Software Defined Networking (COMS 6998-10)

37. EthDst:1, TcpDst:2 2 4 6 ? true null true Assert(TcpDst,22) Policy Trace Tree false Route f(Packet p, Env e) { if (p.tcpDstIs(22)) return null(); else { Location dloc = e.location(p.ethDst()); Location sloc = e.location(p.ethSrc()); Path path = shortestPath( e.links(),sloc,dloc); if (p.ethDstIs(2) return null(); else return unicast(sloc,dloc,path); } Assert(TcpDst, 22) Read(EthD st) Read(EthSr c) path1 37 Source: Andreas Voellmy, Yale 9/29/14 Software Defined Networking (COMS 6998-10)

38. Compile recorded executions into flow table tcpDst==2 2 False ethDst 2 drop 4 port 30 ethSrc 6 drop True match:{tcpDst==22} action:ToController match:{ethDst:4,ethSrc:6} action:[port 30] Priority barrier rule: 1 2 3 38 Source: Andreas Voellmy, Yale 9/29/14 Software Defined Networking (COMS 6998-10)

39. Basic compilation: in-order traversal & barrier rules accumulated match: {} {tcpDst:22} (prio:3,{tcpDst:22},action:drop) {} {ethDst:2} {ethDst:4} {ethDst:4, ethSrc:6} (prio:0,{ethDst:4, ethSrc:6},action:[port 30]) (prio:1,{ethDst:2},action:drop) (prio:2,{tcpDst:22},action:ToController) Priority := 0Priority := 1Priority := 2Priority := 3 barrier rule: tcpDst==2 2 ethDst 2 null 4 port 30 6 null True ethSrc False 39 Source: Andreas Voellmy, Yale 9/29/14 Software Defined Networking (COMS 6998-10)

40. Basic compilation example result Trace tree method converts arbitrary algorithmic policies into correct forwarding tables that effectively use wildcard rules. Deficiencies: – More priorities levels than necessary – More rules than necessary Annotate TT nodes with extra information to improve compilation (prio:3,{tcpDst:22},action:drop) (prio:0,{ethDst:4, ethSrc:6},action:[port 30]) (prio:1,{ethDst:2},action:drop) (prio:2,{tcpDst:22},action:ToController) No effect Can use priority 0 40 Source: Andreas Voellmy, Yale 9/29/14 Software Defined Networking (COMS 6998-10)

41. Optimization 1: Annotate TT nodes with completeness tcpDst==2 2 False ethDst 2 drop 4 port 30 ethSrc 6 drop True {} {tcpDst:22} (prio:2,{tcpDst:22},action:drop) {} {ethDst:2}{ethDst:4} {ethDst:4, ethSrc:6} (prio:0,{ethDst:4, ethSrc:6},action:[port 30]) (prio:1,{ethDst:2},action:drop) no barrier complete 41 Source: Andreas Voellmy, Yale 9/29/14 Software Defined Networking (COMS 6998-10)

42. Optimization 2: Annotate nodes with priority dependencies tcpDst==2 2 False ethDst 2 drop 4 port 30 ethSrc 6 drop True {} {tcpDst:22} (prio:1,{tcpDst:22},action:drop) {} {ethDst:2} {ethDst:4} {ethDst:4, ethSrc:6} (prio:0,{ethDst:4, ethSrc:6},action:[port 30]) (prio:0,{ethDst:2},action:drop) 1 42 Source: Andreas Voellmy, Yale 9/29/14 Software Defined Networking (COMS 6998-10)

43. Improved compilation result (prio:1,{tcpDst:22},action:drop) (prio:0,{ethDst:4, ethSrc:6},action:[port 30]) (prio:0,{ethDst:2},action:drop) 43 Source: Andreas Voellmy, Yale 9/29/14 Software Defined Networking (COMS 6998-10)

44. Maple Status Maple has been implemented in Haskell using the McNettle Openflow controller, which implements Openflow 1.0. The implementation includes several other features: – Incremental TT compilation, to avoid full recompilation on every update. – Trace reduction, to ensure traces and trace trees do not contain redundant nodes. – Automatic and user-specified invalidation, to support removing and updating TT and FT when network state cha nges. 44 Source: Andreas Voellmy, Yale 9/29/14 Software Defined Networking (COMS 6998-10)

45. Summary: Contributions Algorithmic policies provide a simple, expressive programming model for SDN, eliminating a key source of errors and performance problems. Maple provides a scalable implementation of algorithmic policies through several novel techniques, including: – runtime tracing of algorithmic policies, – maintaining a trace tree and compiling TT to flow tables to distribute processing to switches; – using TT annotations to implement compiler optimizations such as rule and priority reductions. 45 Source: Andreas Voellmy, Yale 9/29/14 Software Defined Networking (COMS 6998-10)

46. Outline Announcements – Homework 2 posted due in 18 days – Next lecture: first half by Josh Reich from Princeton on Pyretic Review of previous lecture SDN programming language – Maple: generic programming language syntax such as Java, Python – Frenetic: domain specific programming language 469/29/14 Software Defined Networking (COMS 6998-10)

47. Key questions: What are the right abstractions for programming software-defined networks? How can we engineer trustworthy implementations that provide assurance? 47 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

48. Modular Abstractions 48 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

49. Combining Functionality Challenges: Writing, testing, and debugging programs Reusing code across applications Porting applications to new platforms Controller Platform Monitor + Route + Load Balance + Firewall One monolithic application 49 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

50. Route PatternActions dstip=10.0.0.1Fwd 1 dstip=10.0.0.2Fwd 2 PatternActions srcip=1.2.3.4Count Monitor + PatternActions srcip=1.2.3.4, dstip=10.0.0.1Fwd 1, Count srcip=1.2.3.4, dstip=10.0.0.2Fwd 2, Count srcip=1.2.3.4Count dstip=10.0.0.1Fwd 1 dstip=10.0.0.2Fwd 2 Route + Monitor 50 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

51. + PatternActions srcip=1.2.3.4, dstip=10.0.0.1Fwd 1, Count srcip=1.2.3.4, dstip=10.0.0.2Fwd 2, Count srcip=1.2.3.4Count dstip=10.0.0.1Fwd 1 dstip=10.0.0.2Fwd 2 Route + Monitor PatternActions tcpdst = 22Drop *Fwd ? Firewall PatternActions srcip=1.2.3.4, tcpdst = 22Count, Drop srcip=1.2.3.4, dstip=10.0.0.1Fwd 1, Count srcip=1.2.3.4, dstip=10.0.0.2Fwd 2, Count srcip=1.2.3.4Count tcpdst = 22Drop dstip=10.0.0.1Fwd 1 dstip=10.0.0.2Fwd 2 Route Monitor Firewall ++++ 51 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

52. Modular Applications Controller Platform MonitorRouteLoad BalanceFirewall Benefits: Easier to write, test, and debug programs Can reuse modules across applications Possible to port applications to new platforms One module for each task 52 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

53. Beyond Multi-Tenancy Relatively straightforward to split rule, bandwidth, and network events across these modules Slice 1Slice 2Slice 3 Slice N... Controller Platform Each module controls a different portion of the traffic 53 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

54. Modules Affect the Same Traffic How should we combine a collection of such modules into a single application? Controller Platform MonitorRouteLoad BalanceFirewall Each module partially specifies handling of all traffic 54 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

55. Language-Based Approach Design languages based on modular programming abstractions, and engineer efficient implementations using a compiler and run-time system Compiler + Run-Time System Controller Platform MonitorRouteLoad BalanceFirewall 55 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

56. Language Constructs [POPL ’ 12, NSDI ’ 13] 56 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

57. Parallel Composition Controller Platform MonitorRoute PatternActions dstip=3.4.5.6Fwd 1 dstip=6.7.8.9Fwd 2 PatternActions srcip=1.2.3.4Count + PatternActions srcip=1.2.3.4, dstip=3.4.5.6Fwd 1, Count srcip=1.2.3.4, dstip=6.7.8.9Fwd 2, Count srcip=1.2.3.4Count dstip=3.4.5.6Fwd 1 dstip=6.7.8.9Fwd 2 57 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

58. Sequential Composition Controller Platform Load BalanceRoute PatternActions dstip=10.0.0.1Fwd 1 dstip=10.0.0.2Fwd 2 PatternActions srcip=*0dstip:=10.0.0.1 srcip=*1dstip:=10.0.0.2 ; PatternActions srcip=*0dstip:=10.0.0.1, Fwd 1 srcip=*1dstip:=10.0.0.2, Fwd 2 58 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

59. Dividing Traffic Over Modules Load BalanceRoute ; MonitorRoute + if then else if then dstport=80 dstport=22 else Drop Predicates specify which packets traverse which modules, using ingress port and packet-header fields 59 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

60. The NetKAT Language field ::= switch | inport | srcmac | dstmac |... val ::= 0 | 1 | 2 | 3 |... a,b,c ::= true (* true constant *) | false (* false constant *) | field = val (* test value *) | a 1 | a 2 (* disjunction *) | a 1 & a 2 (* conjunction *) | ! a (* negation *) p,q,r ::= filter a (* filter by predicate *) | field := val (* modify value *) | p 1 + p 2 (* parallel composition *) | p 1 ; p 2 (* sequential composition *) | p * (* iteration *) Syntactic sugar: if a then p 1 else p 2 = filter a ; p 1 + filter ! a ; p 2 60 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

61. Example NetKAT Program open NetKAT.Std (* a simple repeater *) let repeater : policy = <:netkat< if port = 1 then port := 2 + port := 3 + port := 4 else if port = 2 then port := 1 + port := 3 + port := 4 else if port = 3 then port := 1 + port := 2 + port := 4 else if port = 4 then port := 1 + port := 2 + port := 3 else drop >> let _ = run_static repeater 9/29/14 Software Defined Networking (COMS 6998-10) 61

62. Example NetKAT Program (Cont’d) open NetKAT.Std let forwarding : policy = <:netkat< if ip4Dst = 10.0.0.1 then port := 1 else if (* destination is 10.0.0.2, forward out port 2, etc. *)... else drop >> 9/29/14 Software Defined Networking (COMS 6998-10) 62

63. Example NetKAT Program (Cont’d) open NetKAT.Std open Forwarding let firewall : policy = <:netkat< if (ip4Src = 10.0.0.1 && ip4Dst = 10.0.0.2 && tcpSrcPort = 80 || ip4Src = 10.0.0.2 && ip4Dst = 10.0.0.1 && tcpDstPort = 80) then $forwarding else drop 9/29/14 Software Defined Networking (COMS 6998-10) 63

64. Example: Topology Abstraction Abstract topology Physical topology It is often useful to write programs in terms of a simplified abstract network topology Benefits: Information hiding: limit what each module sees Protection: limit what each module does Reuse: write code for appropriate interface Example: load balancer 64 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

65. Simplest example of topology abstraction Can be used in many applications, including access control, load balancing, distributed middleboxes, etc. Abstract Network Physical Network Example: “ One Big Switch ” (ingress; raise; application; lower; fabric; egress) Implementation: 65 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

66. Formal Reasoning 66 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

67. Program Equivalence A A B B Given a program and a topology: Formally, does the following equivalence hold? ( filter switch = A ; firewall; routing + filter switch = B ; routing) ~ ( filter switch = A ; routing + filter switch = B ; firewall ; routing) Want to be able to answer questions like: “ Will my network behave the same if I put the firewall rules on A, or on switch B (or both)? ” 67 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

68. NetKAT Equational Theory Boolean Algebra a | (b & c) ~ (a | b) & (a | c) a | true ~ true a | ! a ~ true a & b ~ b & a a & ! a ~ false a & a ~ a Packet Algebra f := n ; f ’ := n ’ ~ f ’ := n ’ ; f := n if f ≠ f ’ f := n ; f ’ = n ’ ~ f ’ = n ’ ; f := n if f ≠ f ’ f := n ; f = n ~ f := n f = n ; f := n ~ f = n f := n ; f ’ = n ’ ~ f := n ’ f = n; f = n ’ ~ filter drop if n ≠ n ’ Kleene Algebra p + (q + r) ~ (p + q) + r p + q ~ q + p p + filter false ~ p p + p ~ p p ; (q ; r) ~ (p ; q) ; r p; (q + r) ~ p ; q + p ; r (p + q) ; r ~ p ; r + q ; r filter true ; p ~ p ~ p ; filter true filter false ; p ~ filter false p ; filter false ~ filter false filter true + p ; p * ~ p * filter true + p * ; p ~ p * p + q ; r + r ~ r ⟹ p * ; q + r ~ r p + q ; r + q ~ q ⟹ p ; r * + q ~q 68 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

69. NetKAT and Kleene Algebras Theorems Soundness: programs related by the axioms are equivalent Completeness: equivalent programs are related by the axioms Decidabilty: program equivalence is decidable (PSPACE) Its foundations rest upon canonical mathematical structure: Regular operators ( +, ;, and * ) encode paths through topology Boolean operators ( &, |, and ! ) encode switch tables The design of NetKAT is not an accident! This is called a Kleene Algebra with Tests [Kozen ’ 96] 69 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

70. NetKAT Verification Model programs and topologies in the Z3 SMT solver Encode network-wide function as the transitive closure of the sequential composition of the program and topology Verify reachability properties automatically 70 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

71. Machine-Verified Controllers 71 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

72. Inductive pred : Type := | OnSwitch : Switch -> pred | InPort : Port -> pred | DlSrc : EthernetAddress -> pred | DlDst : EthernetAddress -> pred | DlVlan : option VLAN -> pred |... | And : pred -> pred -> pred | Or : pred -> pred -> pred | Not : pred -> pred | All : pred | None : pred Inductive act : Type := | ForwardMod : Mod -> PseudoPort -> act |... Inductive pol : Type := | Policy : pred -> list act -> pol | Union : pol -> pol -> pol | Restrict : pol -> pred -> pol |... Certified Software Systems Recent Successes seL4 [SOSP ’ 09] CompCert [CACM ’ 09] F* [ICFP ’ 11, POPL ’ 12, ’ 13] Tools Textbooks Certified Programming with Dependent Types Write code Lemma inter_wildcard_other : forall x, Wildcard_inter WildcardAll x = x. Proof. intros; destruct x; auto. Qed. Lemma inter_wildcard_other1 : forall x, Wildcard_inter x WildcardAll = x. Proof. intros; destruct x; auto. Qed. Lemma inter_exact_same : forall x, Wildcard_inter (WildcardExact x) (WildcardExact x) = WildcardExact x. Proof. intros. unfold Wildcard_inter. destruct (eqdec x x); intuition. Qed. Prove correct Extract code (** val handle_event : event -> unit Monad.m **) let handle_event = function | SwitchConnected swId -> handle_switch_connected swId | SwitchDisconnected swId -> handle_switch_disconnected swId | SwitchMessage (swId, xid0, msg) -> (match msg with | PacketInMsg pktIn -> handle_packet_in swId pktIn | _ -> Monad.ret ()) (** val main : unit Monad.m **) let main = Monad.forever (Monad.bind Monad.recv (fun evt -> handle_event evt)) Certified binary 72 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

73. NetKAT Flow tables OpenFlow messages Compiler Run-time system Optimizer Each level of abstraction formalized in Coq Machine-checked proofs that the transformations between levels preserve semantics Code extracted to OCaml and deployed with real switch hardware Certified NetKAT Controller 73 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

74. NetKAT Compiler Correctness Theorem Overview Compiler: maps NetKAT programs to flow tables Optimizer: eliminates “ empty ” and “ shadowed ” rules Formalization Highlights Library of algebraic properties of flow tables New tactic for proving equalities on bags Key invariant: all packet patterns “ natural ” Theorem compile_correct : forall opt pol sw pt pk bufId, SemanticsPreserving opt -> netcore_eval pol sw pt pk bufId = flowtable_eval (compile pol sw) sw pt pk bufId. 74 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

75. OpenFlow 1.0 Specification 42 pages......of informal prose...and C struct definitions...diagrams and flow charts 75 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

76. Featherweight OpenFlow Syntax Semantics Key Features: Models all features related to packet forwarding and all essential asynchrony Supports arbitrary controllers 76 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

77. Forwarding Definition Pattern_inter (p p':Pattern) := let dlSrc := Wildcard_inter EthernetAddress.eqdec (ptrnDlSrc p) (ptrnDlSrc p') in let dlDst := Wildcard_inter EthernetAddress.eqdec (ptrnDlDst p) (ptrnDlDst p') in let dlType := Wildcard_inter Word16.eqdec (ptrnDlType p) (ptrnDlType p') in let dlVlan := Wildcard_inter Word16.eqdec (ptrnDlVlan p) (ptrnDlVlan p') in let dlVlanPcp := Wildcard_inter Word8.eqdec (ptrnDlVlanPcp p) (ptrnDlVlanPcp p') in let nwSrc := Wildcard_inter Word32.eqdec (ptrnNwSrc p) (ptrnNwSrc p') in let nwDst := Wildcard_inter Word32.eqdec (ptrnNwDst p) (ptrnNwDst p') in let nwProto := Wildcard_inter Word8.eqdec (ptrnNwProto p) (ptrnNwProto p') in let nwTos := Wildcard_inter Word8.eqdec (ptrnNwTos p) (ptrnNwTos p') in let tpSrc := Wildcard_inter Word16.eqdec (ptrnTpSrc p) (ptrnTpSrc p') in let tpDst := Wildcard_inter Word16.eqdec (ptrnTpDst p) (ptrnTpDst p') in let inPort := Wildcard_inter Word16.eqdec (ptrnInPort p) (ptrnInPort p') in MkPattern dlSrc dlDst dlType dlVlan dlVlanPcp nwSrc nwDst nwProto nwTos tpSrc tpDst inPort. Definition exact_pattern (pk : Packet) (pt : Word16.T) : Pattern := MkPattern (WildcardExact (pktDlSrc pk)) (WildcardExact (pktDlDst pk)) (WildcardExact (pktDlTyp pk)) (WildcardExact (pktDlVlan pk)) (WildcardExact (pktDlVlanPcp pk)) (WildcardExact (pktNwSrc pk)) (WildcardExact (pktNwDst pk)) (WildcardExact (pktNwProto pk)) (WildcardExact (pktNwTos pk)) (Wildcard_of_option (pktTpSrc pk)) (Wildcard_of_option (pktTpDst pk)) (WildcardExact pt). Definition match_packet (pt : Word16.T) (pk : Packet) (pat : Pattern) : bool := negb (Pattern_is_empty (Pattern_inter (exact_pattern pk pt) pat)). /* Fields to match against flows */ struct ofp_match { uint32_t wildcards; /* Wildcard fields. */ uint16_t in_port; /* Input switch port. */ uint8_t dl_src[OFP_ETH_ALEN]; /* Ethernet source address. */ uint8_t dl_dst[OFP_ETH_ALEN]; /* Ethernet destination address. */ uint16_t dl_vlan; /* Input VLAN. */ uint8_t dl_vlan_pcp; /* Input VLAN priority. */ uint8_t pad1[1]; /* Align to 64-bits. */ uint16_5 dl_type; /* Ethernet frame type. */ uint8_t nw_tos; /* IP ToS (DSCP field, 6 bits). */ uint8_t nw_proto; /* IP protocol or lower 8 bits of ARP opcode. */ uint8_t pad2[2]; /* Align to 64-bits. */ uint32_t nw_src; /* IP source address. */ uint32_t nw_dst; /* IP destination address. */ uint16_t tp_src; /* TCP/UDP source port. */ uint16_t tp_dst; /* TCP/UDP destination port. */ }; OFP_ASSERT(sizeof(struct ofp_match) == 40); Record Pattern : Type := MkPattern { dlSrc : Wildcard EthernetAddress; dlDst : Wildcard EthernetAddress; dlType : Wildcard EthernetType; dlVlan : Wildcard VLAN; dlVlanPcp : Wildcard VLANPriority; nwSrc : Wildcard IPAddress; nwDst : Wildcard IPAddress; nwProto : Wildcard IPProtocol; nwTos : Wildcard IPTypeOfService; tpSrc : Wildcard TransportPort; tpDst : Wildcard TransportPort; inPort : Wildcard Port }. Detailed model of matching, forwarding, and flow table update 77 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

78. Asynchrony “ In the absence of barrier messages, switches may arbitrarily reorder messages to maximize performance. ” “ There is no packet output ordering guaranteed within a port. ” Definition InBuf := Bag Packet. Definition OutBuf := Bag Packet. Definition OFInBuf := Bag SwitchMsg. Definition OFOutBuf := Bag CtrlMsg. Essential asynchrony: packet buffers, message reordering, and barriers 78 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

79. PriorityPredicateAction PriorityPredicateAction 10SSHDrop 5dst_ip = H1Fwd 1 5dst_ip = H2Fwd 2 PriorityPredicateAction 5dst_ip = H1Fwd 1 PriorityPredicateAction 5dst_ip = H1Fwd 1 5dst_ip = H2Fwd 2 update re-ordering PriorityPredicateAction 10SSHDrop PriorityPredicateAction 10SSHDrop 5dst_ip = H1Fwd 1 ⊆ ⊆ ⊆ Distributed Programming : non-atomic table updates Asynchrony (Cont’d) 79 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

80. Controllers : abstract type of controller state f in : f out : Controller Parameters Ultimately we want to prove theorems about controllers that implement the NetKAT run-time system......but we didn ’ t want to bake specific controllers into Featherweight OpenFlow! Controller model: fully abstract 80 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

81. (H 1, )(S 1,pt 1, ) (S 2,pt 1, )(H 2, ) ≈ ≈ ≈ ≈ ≈ ≈ ≈ ≈ add rules Weak Bisimulation Theorem fwof_abst_weak_bisim : weak_bisimulation concreteStep abstractStep bisim_relation. 81 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

82. Frenetic OX implemented using OCaml embedding predicates and policies queries OCaml OpenFlow Platform similar to Nox, Pox, Floodlight, etc. predicates policies queries stream of snapshots over time predicates policies queries predicates policies queries Frenetic Ox The System 82 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

83. Frenetic DSL Frenetic OX implemented using Domain-specific language predicates and policies monitoring mac learning network address translation OCaml embedding predicates and policies queries OCaml OpenFlow Platform similar to Nox, Pox, Floodlight, etc. Frenetic Ox The System 83 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

84. Conclusion Modularity is a key concern in the design of any language NetKAT provides rich abstractions for building modular network programs, including parallel and sequential composition operators By leveraging recent advances in formal methods, can build trustworthy compilers, run-time systems, and verification tools Implementation status: Stand-alone controller platform implemented in OCaml Sophisticated, proactive compiler for OpenFlow rules Large parts of the system formally verified in Coq Experimental support for OpenFlow 1.3 84 Source: Nate Foster, Cornell 9/29/14 Software Defined Networking (COMS 6998-10)

85. Questions? 859/29/14 Software Defined Networking (COMS 6998-10)