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

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. 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 4

5. 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 5

6. Rethinking the “Division of Labor” 6

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

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

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

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

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. Inverting the Control Plane Traffic engineering –Change link weights –… to induce the paths –… that alleviate congestion 12 5 1 3 1 1

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

14. 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 14

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

16. OpenFlow Networks http://www.openflow.org 16

17. 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 17 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

18. Controller: Programmability 18 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

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

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

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

22. 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 22 See http://www.openflow.org/videos/

23. 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 (e.g., Google backbone) 23

24. Algorithmic Challenges in Software Defined Networking 24

25. Two-Tiered Computational Model 25 Smart, slow Dumb, fast What problems can we solve efficiently in this two-tiered model?

26. Example: Hierarchical Heavy Hitters Measure large traffic aggregates –Understand network usage –Detect unusual activity Fixed aggregation level –Top 10 source IP addresses? –Top 10 groups of 256 IP addresses? Better: –Identify the top IP prefixes, of any size –Contributing a fraction T of the traffic 26

27. 19 12 111 7 52 21 129 9354 00** 000* 0000 0001001000110100010101100111 001*010*011* 01** 40 0*** 0 1*** 40 **** HH: sends more than T= 10% of link cap. 100 27 Heavy Hitters (HH) All IP prefixes Contributing >= T of capacity

28. 19 12 111 7 52 21 129 9354 00** 000* 0000 0001001000110100010101100111 001*010*011* 01** 40 0*** 0 1*** 40 **** HH: HHH: Hierarchical Heavy Hitters (HHH) All IP prefixes Contributing >= T of capacity … excluding descendents 28

29. Computational Model Previous work: custom hardware –Streaming algorithms using sketches –Fast and accurate, but not commodity hardware Our model: simplified OpenFlow –Slow, smart controller  Read traffic counters  Adapt rules installed in the switch –Fast, dumb switch  Ternary match on packet headers  Traffic counters What algorithm should the controller run? 29 ? rulescounters

30. Monitoring HHHes 19 12 111 7 52 21 129 9354 00** 000* 0000 0001001000110100010101100111 001*010*011* 01** 40 0*** 0 1*** 40 **** PriorityPrefix RuleCount 1 000011 2 010*12 3 0***17

31. 19 12 111 7 52 21 129 9354 00** 000* 0000 0001001000110100010101100111 001*010*011* 01** 40 0*** 0 1*** 40 **** 910 3 2 Detecting New HHHs Monitor children of HHH Using at most 2/T rules 31

32. Iteratively Adjust Wildcard Rules Expand: if count > T, install rule for children Collapse: if count < T, remove rule 32 77 70 0 7 25 3 30 3000 00** 000* 0000 0001001000110100010101100111 001*010*011* 01** 80 0*** PriorityPrefix RuleCount 1 0***80 2 ****0

33. Iteratively Adjust Wildcard Rules 33 77 70 0 7 25 3 30 3000 00** 000* 0000 0001001000110100010101100111 001*010*011* 01** 80 0*** PriorityPrefix RuleCount 1 00**77 2 01**3 3 ****0 Expand: if count > T, install rule for children Collapse: if count < T, remove rule

34. Iteratively Adjust Wildcard Rules 34 77 70 0 7 25 3 30 3000 00** 000* 0000 0001001000110100010101100111 010* 011* 01** 80 0*** Expand: if count > T, install rule for children Collapse: if count < T, remove rule PriorityPrefix RuleCount 1 000*70 2 001*7 3 ****3

35. Using Leftover Rules Monitoring children of all HHHs –Threshold fraction T of traffic (e.g., T=0.1) –At most 2/T rules (e.g., 20 rules) Often need much less –Some HHH are very large –So, may have fewer than 1/T HHHs Using the extra rules –Monitor nodes close to the threshold –Most likely to become new HHHs soon! 35

36. Experimental Results CAIDA packet traces –Trace of 400,000 IP packets/second –Measuring HHHes for T=0.05 and T=0.10 –Time intervals of 1 to 60 seconds Accuracy –Detect and measure ~9 out of 10 HHHes –Large traffic aggregates are stable Speed –Take a few intervals to find new HHHs –Meanwhile, report coarse-grain results 36 12 111 000* 0000 0001

37. Stepping Back Other monitoring problems –Multi-dimensional HHH –Detecting large changes –Denial-of-Service attack detection Changing the computational model –Efficient, generic support for traffic monitoring –Good for many problems, rather than perfect for one Other kinds of problems –Flexible server load balancing –Latency-equalized routing –… 37

38. Making SDN Work Better Distributed controllers –Improve scalability, reliability, performance –Need: efficient distributed algorithms Distributed policies –Spread rules over multiple switches –Need: policy transformation algorithms Verifying network properties –Test whether the rules satisfy invariants –Need: efficient verification algorithms Many more interesting problems! 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 research opportunity –Practical impact on future networks –Placing networking on a strong foundation 39