Software Defined Networking

1. Software Defined Networking What is it, how does it work, and what is it good for? Many slides stolen from Jennifer Rexford, Nick McKeown, Scott Shenker, TeemuKoponen, YotamHarchol and David Hay

2. Agenda • What is Software Defined Networking (SDN)? • What is OpenFlow? How does it work? • Challenges en route to SDN • Research directions

3. What is SDN?

4. The Internet: A Remarkable Story • Tremendous success • from research experiment to global infrastructure • Enables innovation in applications • Web, P2P, VoIP, social networks, virtual worlds • But, the Internet’s infrastructure remained fairly stagnant for decades

5. The Internet’s Landscape constant innovation Applications: Internet Protocols: routing, congestion control, naming, … (TCP/IP, BGP, DNS, OSPF, ECMP,…) stagnant! Technologies: constant innovation

6. Why Can’t We Innovate? • 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 Impacts performance, security, reliability, cost…

7. Networks are Hard 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

8. Traditional Computer Networks Data plane: packet streaming • forward, filter, buffer, mark, • rate-limit, and measure packets

9. Traditional Computer Networks Control plane: distributed algorithms • track topology changes, compute routes, install forwarding rules

10. Traditional Computer Networks Management plane: human time scale • collect measurements and configure the equipment

11. New Paradigm:Software Defined Networking (SDN) logically-centralized control smart, slow API to the data plane (e.g., OpenFlow) dumb, fast switches

12. A Helpful Analogy

13. Mainframes App App App App App App App App App App App Specialized Applications Windows (OS) Linux Mac OS Specialized Operating System or or Open Interface Open Interface Specialized Hardware Microprocessor horizontal open interfaces rapid innovation huge industry vertically integrated closed, proprietary slow innovation small industry

14. Routers/Switches App App App App App App App App App App App Specialized Features Control Plane Control Plane Control Plane or or Specialized Control Plane Open Interface Open Interface Specialized Hardware Merchant Switching Chips horizontal open interfaces rapid innovation vertically integrated closed, proprietary slow innovation

15. How SDN works The OpenFlow protocol

16. OpenFlow Switching OpenFlow Switch specification OpenFlow Switch PC OpenFlow Protocol Secure Channel Controller sw Flow Table hw

17. Controller: Programmability Controller Application Network OS events from switches topology changes, traffic statistics, arriving packets commands to switches (un)install rules, query statistics, send packets

18. Reactive vs. Proactive • Reactive SDN:switches send (first) packets to controller, then controller programs switch's flow table to handle rest of the flow • Problem: source of DoS on controller (packet-in event) • Proactive SDN:Controller programs the switches proactively, according to its own knowledge of the network • Requires smarter approaches than just reacting to network events (global knowledge, discovery, updates…)

19. Flow Table Entry at Switch“Type 0” OpenFlow Switch Rule Action Stats Packet + byte counters • Forward packet to port(s) • Encapsulate and forward to controller • Drop packet • Send to normal processing pipeline Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport + mask

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

21. OpenFlow • Definition in progress • Additional actions • rewrite headers • map to queue/class • encrypt • More flexible header • allow arbitrary matching of first few bytes • Support multiple controllers • load-balancing and reliability

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

23. E.g.: Dynamic Access Control • Inspect first packet of a connection • Consult the access control policy • Install rules to block or route traffic

24. E.g.: Seamless Mobility/Migration • See host send traffic at new location • Modify rules to reroute the traffic

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

26. In-depth Example: Simple Repeater • Simple Network Repeater • forward packets received on port 1 out 2 and vice versa Controller 1 2 Switch

27. Simple Repeater Controller (POX) (Pseudo)-Program defhandle_packetIn(packet): out_port = 2 if packet.in_port == 2: out_port = 1 flow_mod = ofp_flow_mod() flow_mod.match = ofp_match() flow_mod.match.in_port = \ packet.in_port action = ofp_action_output() action.out_port = out_port flow_mod.action = [ action ] flow_mod.buffer_id = \ packet.buffer_id send(flow_mod) Controller 1 2 Switch Flow Table

28. OpenFlow in the Wild • Open Networking Foundation • 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, POX, … • Network deployments • Campuses, research backbone networks • Commercial deployments (e.g., Google backbone)

29. But… Heterogeneous Switches • Number of packet-handling rules (TCAM/memory limits) • Different OpenFlow version support • Range of matches and actions (not all matches and actions are mandatory in the protocol) • Multi-stage pipeline of packet processing (allowed but not defined in the standard) • Vendor-specific features • Offload some control-plane functionality (?) access control MAC look-up IP look-up

30. SDN or OpenFlow? • OpenFlow is not being adapted as-is • Major vendors either completely discard OpenFlow or use a massively changed variant • Doing that requires having the ability to change the protocol on both sides (controller + switch) • Is OpenFlow dead?

31. Challenges

32. Controller Delay and Overhead • Controller is much slower the the switch • Processing packets leads to delay and overhead • Need to keep most packets in the “fast path” packets

33. Distributed Controller For scalability and reliability Controller Application Controller Application Partition and replicate state Network OS Network OS … and: where to put the controller(s)?Taking into account latency, resiliency, load balancing...

34. Testing and Debugging • OpenFlow makes programming possible • Network-wide view at controller • Direct control over data plane • Plenty of room for bugs • Still a complex, distributed system • Need for testing techniques • Controller applications • Controller and switches • Rules installed in the switches

35. Programming Abstractions • Controller APIs are low-level • Thin veneer on the underlying hardware • Need better languages • Composition of modules • Managing concurrency • Querying network state • Network-wide abstractions • Example: • http://www.frenetic-lang.org/ Controller Switches

36. MiniNet

37. MiniNet • Creates scalable SDN (up to hundreds of nodes) using OpenFlow, on a single PC • Allows to quickly create, interact with and customize a SDN prototype with complex topologies, and can be used to emulate real networks – all on your PC • Can work with any kind of OpenFlow controller • Takes seconds to install • Easy to program • Of course, is an open source project

38. MiniNet • Not only for teaching purposes! • Used for the development and testing of networks

39. Innovating with SDN

40. Dealing with Large Tables Palette: Distributing Tables in Software Defined Networks Y. Kanizo, D. Hay and I. Keslassy

41. Access Control in SDN • Consider the following network. • Table at each ingress point Ingress points hold (too) large tables

42. How to Solve this Problem? Idea: Distribute the rules among all switches such that each packet goes through all rules along its path.

43. Palette: Step I Split the large (TCAM) table into smaller tables • identify each smaller table with a unique colour

44. Palette: Step II Assign at most a single colour to each switch s.t. every packet-forwarding path is a “rainbow path”

45. Algorithmic Challenges • Maximizing the number of colours (smaller tables), k • Splitting the large (TCAM) table into k smaller tables • so as to minimize the size of the largest table • http://webee.technion.ac.il/~isaac/p/tr12-05_palette.pdf

46. Rethinking (Routing)Protocols On the Resilience of Routing Tables: J. Feigenbaum, P. B. Godfrey, A. Panda, M. Schapira, S. Shenker, and A. Singla

47. Motivation d

48. Motivation d Routes computed by, say, shortest paths routing alg

49. Motivation Packet i d X Connected in network? Yes forwarding path?No!

50. Routing: Data vs. Control Plane • Routing is a control planeoperation • slow (ms – s) • Packet forwarding is a data plane operation • fast (μs) • Today’s routing protocols • establish connectivity • optimize routes (= shortest paths) • failure ⇒ re-convergence ⇒ dropped packets!