1. Enabling Innovation Inside the Network Jennifer Rexford Princeton University http://www.cs.princeton.edu/~jrex http://www.frenetic-lang.org/

2. The Internet: A Remarkable Story Tremendous success –From research experiment to global infrastructure Brilliance of under-specifying –Network: best-effort packet delivery –Hosts: arbitrary applications Enables innovation in applications –Web, P2P, VoIP, social networks, virtual worlds But, change is easy only at the edge…  2

3. Inside the ‘Net: A Different Story… Closed equipment –Software bundled with hardware –Vendor-specific interfaces Over specified –Slow protocol standardization Few people can innovate –Equipment vendors write the code –Long delays to introduce new features 3 Impacts performance, security, reliability, cost…

4. Do We Need Innovation Inside? 4 Many boxes (routers, switches, firewalls, …), with different interfaces.

5. How Hard are Networks to Manage? Operating a network is expensive –More than half the cost of a network –Yet, operator error causes most outages Buggy software in the equipment –Routers with 20+ million lines of code –Cascading failures, vulnerabilities, etc. The network is “in the way” –Especially a problem in data centers –… and home networks 5

6. Creating Foundation for Networking A domain, not a discipline –Alphabet soup of protocols –Header formats, bit twiddling –Preoccupation with artifacts From practice, to principles –Intellectual foundation for networking –Identify the key abstractions –… and support them efficiently To build networks worthy of society’s trust 6

7. Rethinking the “Division of Labor” 7

8. Traditional Computer Networks 8 Data plane: Packet streaming Forward, filter, buffer, mark, rate-limit, and measure packets

9. Traditional Computer Networks 9 Track topology changes, compute routes, install forwarding rules Control plane: Distributed algorithms

10. Traditional Computer Networks 10 Collect measurements and configure the equipment Management plane: Human time scale

11. Shortest-Path Routing Management: set the link weights Control: compute shortest paths Data: forward packets to next hop 11 1 1 3 1 1

12. Shortest-Path Routing Management: set the link weights Control: compute shortest paths Data: forward packets to next hop 12 1 1 3 1 1

13. Inverting the Control Plane Traffic engineering –Change link weights –… to induce the paths –… that alleviate congestion 13 5 1 3 1 1

14. Avoiding Transient Anomalies Distributed protocol –Temporary disagreement among the nodes –… leaves packets stuck in loops –Even though the change was planned! 14 1  5 1 3 1 1

15. Death to the Control Plane! Simpler management –No need to “invert” control-plane operations Faster pace of innovation –Less dependence on vendors and standards Easier interoperability –Compatibility only in “wire” protocols Simpler, cheaper equipment –Minimal software 15

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

17. OpenFlow Networks 17

18. 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 18 1.src=1.2.*.*, dest=3.4.5.*  drop 2.src = *.*.*.*, dest=3.4.*  forward(2) 3. src=10.1.2.3, dest=*  send to controller 1.src=1.2.*.*, dest=3.4.5.*  drop 2.src = *.*.*.*, dest=3.4.*  forward(2) 3. src=10.1.2.3, dest=*  send to controller

19. Controller: Programmability 19 Network OS App #1App #2App #3 Events from switches Topology changes, Traffic statistics, Arriving packets Commands to switches (Un)install rules, Query statistics, Send packets

20. OpenFlow in the Wild Open Networking Foundation –Creating Software Defined Networking standards –Google, Facebook, Microsoft, Yahoo, Verizon, Deutsche Telekom, and many other companies Commercial OpenFlow switches –HP, NEC, Quanta, Dell, IBM, Juniper, … Network operating systems –NOX, Beacon, Floodlight, Nettle, ONIX, POX, Frenetic Network deployments –Eight campuses, and two research backbone networks –Commercial deployments 20

21. Dynamic Access Control Inspect first packet of each connection Consult the access control policy Install rules to block or route traffic 21

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

23. Example Applications Dynamic access control Seamless mobility/migration Server load balancing Using multiple wireless access points Energy-efficient networking Adaptive traffic monitoring Denial-of-Service attack detection Network virtualization 23 See http://www.openflow.org/videos/

24. Challenges of Programming Software Defined Networks 24

25. Programming OpenFlow Networks OpenFlow makes programming possible –Network-wide view at controller –Direct control over data plane The APIs do not make it easy –Low level of abstraction Challenges –Composition –Concurrency –… 25 Controller Switches

26. Modularity: Simple Repeater def repeater(switch): # Repeat Port 1 to Port 2 pat1 = {in_port:1} act1 = [forward(2)] install(switch, pat1, DEFAULT, act1) # Repeat Port 2 to Port 1 pat2 = {in_port:2} act2 = [forward(1)] install(switch, pat2, DEFAULT, act2) def repeater(switch): # Repeat Port 1 to Port 2 pat1 = {in_port:1} act1 = [forward(2)] install(switch, pat1, DEFAULT, act1) # Repeat Port 2 to Port 1 pat2 = {in_port:2} act2 = [forward(1)] install(switch, pat2, DEFAULT, act2) Simple Repeater 12 Controller When a switch joins the network, install two forwarding rules.

27. Composition: Web Traffic Monitor 27 def web_monitor(switch): # Web traffic from Internet pat = {inport:2,tp_src:80} install(switch, pat, DEFAULT, []) query_stats(switch, pat) def stats_in(switch, pat, bytes, …) print bytes sleep(30) query_stats(switch, pat) def web_monitor(switch): # Web traffic from Internet pat = {inport:2,tp_src:80} install(switch, pat, DEFAULT, []) query_stats(switch, pat) def stats_in(switch, pat, bytes, …) print bytes sleep(30) query_stats(switch, pat) Monitor Web (“port 80”) traffic 12 Web traffic When a switch joins the network, install one monitoring rule.

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

29. Concurrency: Switch-Controller Delays Common programming idiom –First packet goes to the controller –Controller installs rules 29 packets

30. Concurrency: Switch-Controller Delays More packets arrive before rules installed? –Multiple packets reach the controller 30 packets

31. Concurrency: Switch-Controller Delays Rules along a path installed out of order? –Packets reach a switch before the rules do 31 Must think about all possible packet and event orderings. packets

32. Frenetic Language and Run-Time System Joint work with Nate Foster, Dave Walker, Chris Monsanto, Mark Reittblatt, Rob Harrison, Mike Freedman, Alec Story, Josh Reich 32 http://www.frenetic-lang.org/

33. Functional Reactive Programming Streams of events –Packets –Switch join/leave –Port status change –Traffic statistics –Commands to switches –Seconds Operations on streams –Filter –Merge –Transform –Split –Accumulate –Lift 33 Event Stream Single Value or Event.......................................................... Declarative programming of OpenFlow networks [Nettle, Frenetic]

34. Database Query Language [ICFP’11] Controller applications read network state –Traffic counters in the switches –Packets sent to the controller Minimize controller overhead –Filter using high-level patterns –Limit the # of values returned –Aggregate by #/size of packets Return an event stream –Time-indexed stream of values Run-time system –Installs rules, reads counters, handles packets, … 34 Select(bytes) * Where(inport:2) * GroupBy([dstmac]) * Every(60) Select(packets) * GroupBy([srcmac]) * SplitWhen([inport]) * Limit(1) Learning Host Location Traffic Monitoring

35. Composition of Modules [ICFP’11] 35 # Static repeating between ports 1 and 2 def repeater(): rules=[Rule(inport:1, [forward(2)]), Rule(inport:2, [forward(1)])] register(rules) # Static repeating between ports 1 and 2 def repeater(): rules=[Rule(inport:1, [forward(2)]), Rule(inport:2, [forward(1)])] register(rules) # Monitoring Web traffic def web_monitor(): q = (Select(bytes) * Where(inport:2 & tp_src:80) * Every(30)) q >> Print() # Monitoring Web traffic def web_monitor(): q = (Select(bytes) * Where(inport:2 & tp_src:80) * Every(30)) q >> Print() # Composition of two separate modules def main(): repeater() web_monitor() # Composition of two separate modules def main(): repeater() web_monitor() Repeater Monitor Repeater + Monitor

36. Compiler/Run-Time System [POPL’12] Two-tiered programming model –Smart controller and dumb switches –Automatically partition a program Network policies change over time –Controller (un)installs rules in switches –Reactive specialization of a policy Rules with wildcard patterns –Wildcards lead to overlapping patterns –Automatic synthesis the low-level rules –Customized to the switch’s capabilities 36 Controller Switches

37. Consistent Writes [HotNets’11] Transition from policy P 1 to P 2 –Security: new access control lists –Routing: new shortest paths without a link –Load balancer: new split over server replicas Transient policy violations –Packets in flight experience a mix of policies –Modifying switch rules is not instantaneous Consistent update semantics –Packets experience either P 1 or P 2 –… but never a mixture of the two –Enables verification of just P 1 and P 2 37 CHANGE We Can Believe In

38. Many Hard Questions Remain Higher-level abstractions –Network-wide policy –Domain-specific languages Heterogeneous components –Mix of end hosts and switches –FPGAs and network processors Distributed controllers –Replication, distribution, and aggregation –Consistency and durability of state Multiple administrative domains –Trust, scalability 38

39. 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 opportunities –Practical impact on future networks –Placing networking on a strong foundation 39