Frenetic : Programming Software Defined Networks

1. Frenetic: Programming Software Defined Networks Jennifer Rexford Princeton University http://www.frenetic-lang.org/ Joint with Nate Foster, David Walker, Rob Harrison, Chris Monsanto, Cole Schlesinger, Mike Freedman, Mark Reitblatt, Joshua Reich

2. Software Defined Networking (SDN) Logically-centralized control Smart, slow API to the data plane (e.g., OpenFlow) Dumb, fast Switches

3. Programming OpenFlow Networks • The Bad • Low-level programming interface • Functionality tied to hardware • Explicit resource control • The Good • Simple data plane abstraction • Logically-centralized architecture • Direct control over switch policies • The Ugly • Non-modular, non-compositional • Programmer faced with challenging distributed programming problem Images by Billy Perkins

4. Language-Based Abstractions • Benefits • Modularity • Portability • Efficiency • Assurance • Simplicity Simple, high-level abstractions are crucial for achieving the vision of software-defined networking.

5. OpenFlow Networks

6. Data-Plane: Simple Packet Handling • Simple packet-handling rules • Pattern: match packet header bits • Actions: drop, forward, modify, send to controller • Priority: disambiguate overlapping patterns • Counters: #bytes and #packets • src=1.2.*.*, dest=3.4.5.*  drop • src = *.*.*.*, dest=3.4.*.*  forward(2) • 3. src=10.1.2.3, dest=*.*.*.*  send to controller

7. Controller: Programmability Application Network OS Events from switches Topology changes, Traffic statistics, Arriving packets Commands to switches (Un)install rules, Query statistics, Send packets

8. E.g.: Server Load Balancing • Pre-install load-balancing policy • Split traffic based on source IP src=0* src=1*

9. Seamless Mobility/Migration • See host sending traffic at new location • Modify rules to reroute the traffic

10. Programming Abstractions for Software Defined Networks

11. Three Main Abstractions Composing modules Reading state Writing policies OpenFlow Switches

12. Reading State: Multiple Rules • Traffic counters • Switch counts bytes and packets matching a rule • Controller application polls the counters • Multiple rules • E.g., Web server traffic except for source 1.2.3.4 • Solution: predicates • E.g., (srcip != 1.2.3.4) && (srcport == 80) • Run-time system translates into switch patterns 1. srcip = 1.2.3.4, srcport = 80 2. srcport = 80

13. Reading State: Unfolding Rules • Limited number of rules • Switches have limited space for rules • Cannot install all possible patterns • Must add new rules as traffic arrives • E.g., histogram of traffic by IP address • … packet arrives from source 5.6.7.8 • Solution: dynamic unfolding • Programmer specifies GroupBy(srcip) • Run-time system dynamically adds rules 1. srcip = 1.2.3.4 2. srcip = 5.6.7.8 1. srcip = 1.2.3.4

14. Reading: Extra Unexpected Events • Common programming idiom • First packet goes to the controller • Controller application installs rules packets

15. Reading: Extra Unexpected Events • More packets arrive before rules installed? • Multiple packets reach the controller packets

16. Reading: Extra Unexpected Events • Solution: suppress extra events • Programmer specifies “Limit(1)” • Run-time system hides the extra events not seen by application packets

17. Frenetic SQL-Like Query Language • Get what you ask for • Nothing more • Nothing less • SQL-like query language • Familiar abstraction • Returns a stream • Intuitive cost model • Minimize controller overhead • Filter using high-level patterns • Limit the # of values returned • Aggregate by #/size of packets Traffic Monitoring Select(bytes) * Where(in:2 & srcport:80) * GroupBy([dstmac]) * Every(60) Learning Host Location Select(packets) * GroupBy([srcmac]) * SplitWhen([inport]) * Limit(1)

18. Composition: Multiple Modules • Networks have multiple policies • Routing • Traffic monitoring • Access control • Challenges • Common set of rules in the switches • Processing the same packets • OpenFlow API is not modular • Programmer must combine the logic

19. Composition: Simple Repeater Simple Repeater def switch_join(switch): # Repeat Port 1 to Port 2 p1 = {in:1} a1 = [out:2] install(switch, p1, DEFAULT, a1) # Repeat Port 2 to Port 1 p2 = {in:2} a2 = [out:2] install(switch, p2, DEFAULT, a2) Controller 1 2 When a switch joins the network, install two forwarding rules.

20. Composition: Web Traffic Monitor Monitor “port 80” traffic def switch_join(switch)): # Web traffic from Internet p = {in:2, srcport:80} install(switch, p, DEFAULT, []) query_stats(switch, p) def stats_in(switch, p, bytes, …) print bytes sleep(30) query_stats(switch, p) 1 2 Web traffic When a switch joins the network, install one monitoring rule.

21. Composition: Repeater + Monitor Repeater + Monitor def switch_join(switch): pat1 = {in:1} pat2 = {in:2} pat2web = {inport:2, srcport:80} install(switch, pat1, DEFAULT, None, [out:2]) install(switch, pat2web, HIGH, None, [out:1]) install(switch, pat2, DEFAULT, None, [out:1]) query_stats(switch, pat2web) def stats_in(switch, xid, pattern, packets, bytes): print bytes sleep(30) query_stats(switch, pattern) Must think about both tasks at the same time.

22. Composition: Frenetic is Modular # Static repeating between ports 1 and 2 def repeater(): rules=[Rule(in:1, [out:2]), Rule(in:2, [out:1])] register(rules) Repeater # Monitoring Web traffic def web_monitor(): q = (Select(bytes) * Where(in:2 & srcport:80) * Every(30)) q >> Print() Monitor # Composition of two separate modules def main(): repeater() web_monitor() Repeater + Monitor

23. Composition: Reactive Run-Time • Microflow-based • Send first packet to the controller • Install rule if possible • Check all policies • Accumulate actions to perform on packet • Check all queries • If no matches: install a rule to handle remaining packets of the flow

24. Composition: Proactive [POPL’12] • Proactive, wildcard rules • Keep packets in the “fast path” • “Cross-product” of predicates • Translate predicates into rules • Convert each predicate to one or more rules • Minimize to produce a smaller set of rules • Reactive specialization • Dynamically expanding the policy as packets arrive in:1 in:2 & srcport=80 in:2 * in:1 in:2 * in:2 & srcport=80 * X =

25. Writing Policy: Avoiding Disruption

26. Writing Policy: Avoiding Disruption • Reasons • Routine maintenance • Unexpected failure • Traffic engineering • Fine-grained security • Invariants • No forwarding loops • No black holes • Access control • Traffic waypointing

27. Writing Policy: Traffic Engineering • Shortest-path routing • Controller computes shortest paths • … based on preconfigured link weights 1 1 1 1 3

28. Writing Policy: Traffic Engineering • Transient loop • Update top switch to forward down • … while bottom switch still forwards up 1  5 1 1 1 3

29. Writing Policy: Path for a New Flow • Rules along a path installed out of order? • Packets reach a switch before the rules do packets Must think about all possible packet and event orderings.

30. Writing Policy: Update Semantics • Per-packet consistency • Every packet is processed by • … policy P1 or policy P2, • E.g., access control, no loopsor blackholes during routing change • Per-flow consistency • Sets of related packets are processed by • … policy P1 or policy P2, • E.g., server load balancing, in-order delivery, … P1 P2

31. Writing Policy: Policy Update • Simple abstraction • Update the entire configuration at once • E.g., per_packet_update(P2) • Cheap verification • If P1 and P2 satisfy an invariant • Then the invariant always holds • Run-time system handles the rest • Constructing schedule of low-level updates • Applying optimizations to limit the number of rules • Using only OpenFlow commands! P1 P2

32. Writing Policy: Two-Phase Commit • Version numbers • Stamp packet with a version number (e.g., VLAN tag) • Unobservable updates • Add rules for P2 in the interior • … matching on version # P2 • One-touch updates • Add rules to stamp packets with version # P2 at the edge • Remove old rules • Wait for some time, thenremove all version # P1 rules

33. Writing Policy: Optimizations • Avoid two-phase commit • Naïve version touches every switch • Doubles rule space requirements • Limit scope of two-phase commit • Affects only a portion of the traffic • Affects only a portion of the topology • Simple policy changes • Extension: strictly adds paths • Retraction: strictly removes paths • Run-time system applies optimizations

34. Frenetic Abstractions Policy Composition Consistent Updates SQL-likequeries OpenFlow Switches

35. Related Work • Programming languages • FRP: Yampa, FrTime, Flask, Nettle • Streaming: StreamIt, CQL, Esterel, Brooklet, GigaScope • Network protocols: NDLog • OpenFlow • Language: FML, SNAC, Resonance • Controllers: ONIX, Nettle, FlowVisor, RouteFlow • Testing: MiniNet, NICE, FlowChecker, OF-Rewind, OFLOPS • OpenFlow standardization • http://www.openflow.org/ • https://www.opennetworking.org/

36. Conclusion • SDN is exciting • Enables innovation • Simplifies management • Rethinks networking • SDN is happening • Practice: useful APIs and good industry traction • Principles: start of higher-level abstractions • Great research opportunity • Practical impact on future networks • Placing networking on a strong foundation

37. Thanks to My Frenetic Collaborators Rob Harrison Nate Foster Mike Freedman Mark Reitblatt Dave Walker Alec Story Chris Monsanto Josh Reich