1. Enabling Innovation Inside the Network Joint with Nate Foster, David Walker, Rob Harrison, Chris Monsanto, Cole Schlesinger, Mike Freedman, Mark Reitblatt, Joshua Reich Jennifer Rexford Princeton University http://www.cs.princeton.edu/~jrex

2. What is Networking? end-hosts need to communicate 2

3. What is Networking? Ethernet switches connect them 3

4. What is Networking? which decide how packets should be forwarded Control Plane 4

5. What is Networking? and actually forward them Data Plane 5

6. What is Networking? 6

7. servers 7

8. What is Networking? connected by routers 8

9. w/ similar data planes What is Networking? connected by routers 9

10. What is Networking? connected by routers but completely different control planes 10 plug-and-play structured and optimized

11. What is Networking? 11

12. What is Networking? we need gateway to bridge them 12

13. What is Networking? and load balancing for servers 13

14. What is Networking? there are other ISPs 14

15. What is Networking? requiring inter-domain routers 15

16. What is Networking? and a firewall to handle malicious traffic 16

17. What is Networking? and mobile endpoints 17

18. What is Networking? requiring wireless basestations 18

19. What is Networking? and more middleboxes for billing, lawful intercept, DPI 19

20. What is Networking? Ad absurdum 20

21. This is a Control Plane Issue each color represents a different set of control-plane protocols and algorithms 21

22. This is a Control Plane Issue whose implementation may vary by vendor and model 22

23. Software Defined Networks 23

24. decouple control and data planes Software Defined Networks 24

25. decouple control and data planes by providing open standard API Software Defined Networks 25

26. (Logically) Centralized Controller Controller Platform 26

27. Protocols  Applications Controller Platform 27 Controller Application

28. Payoff Cheaper equipment Faster innovation Easier management 28

29. Entire backbone runs OpenFlow A Major Trend in Networking Bought for $1.2 x 10 9 (mostly cash) 29

30. But How Should We Program SDNs? 30 Controller Platform Controller Application Network-wide visibility and control Direct control via open interface Today’s controller APIs are tied to the underlying hardware

31. OpenFlow Networks 31

32. Data Plane: 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 32 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

33. Control Plane: Programmability 33 Events from switches Topology changes, Traffic statistics, Arriving packets Commands to switches (Un)install rules, Query statistics, Send packets Controller Platform Controller Application

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

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

36. Programming Abstractions for Software Defined Networks 36

37. Network Control Loop 37 Read state OpenFlow Switches Write policy Compute Policy

38. Reading State SQL-Like Query Language 38

39. Reading State: Multiple Rules Traffic counters –Each rule counts bytes and packets –Controller can poll 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 39 1. srcip = 1.2.3.4, srcport = 80 2. srcport = 80

40. 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 40 1. srcip = 1.2.3.4 2. srcip = 5.6.7.8

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

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

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

44. 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 44 Select(bytes) * Where(in:2 & srcport:80) * GroupBy([dstmac]) * Every(60) Select(packets) * GroupBy([srcmac]) * SplitWhen([inport]) * Limit(1) Learning Host Location Traffic Monitoring

45. Computing Policy Parallel and Sequential Composition Abstract Topology Views 45

46. Combining Many Networking Tasks 46 Controller Platform Monitor + Route + FW + LB Monolithic application Hard to program, test, debug, reuse, port, …

47. Modular Controller Applications 47 Controller Platform LB Route Monitor FW Easier to program, test, and debug Greater reusability and portability A module for each task

48. Modules Affect the Same Traffic 48 Controller Platform LB Route Monitor FW How to combine modules into a complete application? Each module partially specifies the handling of the traffic

49. Parallel Composition [ICFP’11, POPL’12] 49 Controller Platform Route on dest prefix Monitor on source IP + dstip = 1.2/16  fwd(1) dstip = 3.4.5/24  fwd(2 ) srcip = 5.6.7.8  count srcip = 5.6.7.9  count srcip = 5.6.7.8, dstip = 1.2/16  fwd(1), count srcip = 5.6.7.8, dstip = 3.4.5/24  fwd(2 ), count srcip = 5.6.7.9, dstip = 1.2/16  fwd(1), count srcip = 5.6.7.9, dstip = 3.4.5/24  fwd(2), count

50. Spread client traffic over server replicas –Public IP address for the service –Split traffic based on client IP –Rewrite the server IP address Then, route to the replica Example: Server Load Balancer clients 1.2.3.4 load balancer server replicas 10.0.0.1 10.0.0.2 10.0.0.3

51. Sequential Composition [NSDI’13] 51 Controller Platform Routing Load Balancer >> dstip = 10.0.0.1  fwd(1) dstip = 10.0.0.2  fwd(2 ) srcip = 0*, dstip=1.2.3.4  dstip=10.0.0.1 srcip = 1*, dstip=1.2.3.4  dstip=10.0.0.2 srcip = 0*, dstip = 1.2.3.4  dstip = 10.0.0.1, fwd(1) srcip = 1*, dstip = 1.2.3.4  dstip = 10.0.0.2, fwd(2 )

52. Dividing the Traffic Over Modules Predicates –Specify which traffic traverses which modules –Based on input port and packet-header fields 52 Routing Load Balancer Monitor Routing dstport != 80 dstport = 80 >> +

53. High-Level Architecture 53 Controller Platform M1 M2 M3 Composition Spec

54. Partially Specifying Functionality A module should not specify everything –Leave some flexibility to other modules –Avoid tying the module to a specific setting Example: load balancer plus routing –Load balancer spreads traffic over replicas –… without regard to the network paths 54 Load Balancer Routing >> Avoid custom interfaces between the modules

55. Abstract Topology Views [NSDI’13] Present abstract topology to the module –Implicitly encodes the constraints –Looks just like a normal network –Prevents the module from overstepping 55 Real networkAbstract view

56. Separation of Concerns Hide irrelevant details –Load balancer doesn’t see the internal topology or any routing changes 56 Routing viewLoad-balancer view

57. High-Level Architecture 57 Controller Platform View Definitions M1 M2 M3 Composition Spec

58. Supporting Topology Views Virtual ports –(V, 1): [(P1,2)] –(V, 2): [(P2, 5)] Simple firewall policy –in=1  out=2 Virtual headers –Push virtual ports –Route on these ports –From (P1,2) to (P2,5) 58 V 1 2 firewall routing P1 P2 1 1 2 2 3 3 4 4 5

59. Writing State Consistent Updates 59

60. Writing Policy: Avoiding Disruption Invariants No forwarding loops No black holes Access control Traffic waypointing

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

62. Writing Policy: Update Semantics Per-packet consistency –Every packet is processed by –… policy P1 or policy P2 –E.g., access control, no loops or blackholes Per-flow consistency –Sets of related packets are processed by –… policy P1 or policy P2, –E.g., server load balancer, in-order delivery, … P1 P2

63. Writing Policy: Policy Update Simple abstraction –Update entire configuration at once 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 –Using only OpenFlow commands! 63 P1 P2

64. Writing Policy: Two-Phase Update 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, then remove all version # P1 rules 64

65. Writing Policy: Optimizations Avoid two-phase update –Naïve version touches every switch –Doubles rule space requirements Limit scope –Portion of the traffic –Portion of the topology Simple policy changes –Strictly adds paths –Strictly removes paths 65

66. Frenetic Abstractions 66 SQL-like queries OpenFlow Switches Consistent Updates Policy Composition

67. 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, POX, Floodlight, Nettle, FlowVisor –Testing: NICE, FlowChecker, OF-Rewind, OFLOPS OpenFlow standardization –http://www.openflow.org/http://www.openflow.org/ –https://www.opennetworking.org/https://www.opennetworking.org/ 67

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

69. Frenetic Project http://frenetic-lang.org Programming languages meets networking –Cornell: Nate Foster, Gun Sirer, Arjun Guha, Robert Soule, Shrutarshi Basu, Mark Reitblatt, Alec Story –Princeton: Dave Walker, Jen Rexford, Josh Reich, Rob Harrison, Chris Monsanto, Cole Schlesinger, Praveen Katta, Nayden Nedev Short overview at http://www.cs.princeton.edu/~jrex/papers/frenetic12.pdf