CMPE 252A : Computer Networks

1. An Introduction to Software Defined Networking (SDN) & OpenFlow CMPE 252A : Computer Networks Huazhe Wang huazhe.wang@ucsc.edu Some slides are borrowed from http://www.cs.princeton.edu/courses/archive/spr12/cos461/ http://www-net.cs.umass.edu/kurose-ross-ppt-6e/

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… 

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 Impacts performance, security, reliability, cost…

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

5. Traffic engineering: difficult for traditional routing 5 w z u v y x 3 5 2 2 1 3 1 2 1 Q: what if network operator wants u-to-z traffic to flow along uvwz, x-to-z traffic to flow xwyz? A: need to define link weights so traffic routing algorithm computes routes accordingly (or need a new routing algorithm)!

6. Traffic engineering: difficult 5 w z u v y x 3 5 2 2 1 3 1 2 1 Q: what if network operator wants to split u-to-z traffic along uvwz and uxyz (load balancing)? A: can’t do it (or need a new routing algorithm)

7. z x w y v Traffic engineering: difficult 5 3 5 2 2 1 3 1 2 1 w v u y x z Q: what if w wants to route blue and red traffic differently? A: can’t do it (with destination based forwarding, and LS, DV routing)

8. Rethinking the “Division of Labor”

9. Network-layer functions Recall: two network-layer functions: • forwarding: move packets from router’s input to appropriate router output data plane • routing: determine route taken by packets from source to destination • controlplane • Two approaches to structuring network control plane: • per-router control (traditional) • logically centralized control (software defined networking)

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

11. Traditional Computer Networks Per-router control plane: Distributed algorithms Track topology changes, compute routes, install forwarding rules

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

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

14. Software defined networking (SDN) 3. control plane functions external to data-plane switches 4.programmable control applications … load balance access control routing Remote Controller CA control plane data plane CA CA CA CA 1: generalized“ flow-based” forwarding (e.g., OpenFlow) 2. control, data plane separation

15. Software defined networking (SDN) Whyalogically centralized control plane? • easier network management: avoid router misconfigurations, greater flexibility of traffic flows • table-based forwarding allows “programming” routers • centralized “programming” easier: compute tables centrally and distribute • distributed “programming: more difficult: compute tables as result of distributed algorithm (protocol) implemented in each and every router • open (non-proprietary) implementation of control plane

16. Analogy: mainframe to PC evolution* 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 Vertically integrated Closed, proprietary Slow innovation Small industry Horizontal Open interfaces Rapid innovation Huge industry * Slide courtesy: N. McKeown

17. SDN perspective: data plane switches network-control applications load balance … routing Data plane switches • fast, simple, commodity switches implementing generalized data-plane forwarding in hardware • switch flow table computed, installed by controller • API for table-based switch control (e.g., OpenFlow) • defines what is controllable and what is not • protocol for communicating with controller (e.g., OpenFlow) access control control plane northbound API SDN Controller (network operating system) southbound API data plane SDN-controlled switches

18. SDN perspective: SDN controller load balance routing network-control applications SDN controller (network OS): • maintain network state information • interacts with network control applications “above” via northbound API • interacts with network switches “below” via southbound API • implemented as distributed system for performance, scalability, fault-tolerance, robustness … access control control plane SDN Controller (network operating system) northbound API southbound API data plane SDN-controlled switches

19. SDN perspective: control applications load balance network-control apps: • “brains” of control: implement control functions using lower-level services, API provided by SND controller • unbundled: can be provided by 3rd party: distinct from routing vendor, or SDN controller routing network-control applications … access control control plane SDN Controller (network operating system) northbound API southbound API data plane SDN-controlled switches

20. SDN: control/data plane interaction example RESTful API network graph OpenFlow SNMP statistics flow tables Link-state info host info intent switch info Dijkstra’s link-state Routing SDN controller receives OpenFlow message, updates link status info S1, experiencing link failure using OpenFlow port status message to notify controller Dijkstra’s routing algorithm access network graph info, link state info in controller, computes new routes Dijkstra’s routing algorithm application has previously registered to be called when ever link status changes. It is called. … s3 s4 s1 s2 5 1 3 4 2 4 1 3 2 6 … Application interface layer … Network-wide management layer … Communication layer

21. SDN: control/data plane interaction example RESTful API network graph OpenFlow SNMP statistics flow tables Link-state info host info intent switch info Dijkstra’s link-state Routing Controller uses OpenFlow to install new tables in switches that need updating link state routing app interacts with flow-table-computation component in SDN controller, which computes new flow tables needed … s2 s3 s4 s1 5 3 6 4 2 1 5 6 … Application interface layer … Network-wide management layer … Communication layer

22. OpenFlow (OF) defines the communication protocol that enables the SDN Controller to directly interact with the forwarding plane of network devices.

23. OpenFlow data plane abstraction • flow: defined by header fields • generalized forwarding: simple packet-handling rules • Pattern: matchvalues in packet header fields • Actions: drop, forward, modify, matched packet or send matched packet to controller • Priority: disambiguate overlapping patterns • Counters: #bytes and #packets * : wildcard • src=1.2.*.*, dest=3.4.5.*  drop • src = *.*.*.*, dest=3.4.*.*  forward(2) 3. src=10.1.2.3, dest=*.*.*.*  send to controller

24. OpenFlow data plane abstraction • match+action: unifies different kinds of devices • Router • match: longest destination IP prefix • action: forward out a link • Switch • match: destination MAC address • action: forward or flood • Firewall • match: IP addresses and TCP/UDP port numbers • action: permit or deny • NAT • match: IP address and port • action: rewrite address and port

25. Examples Switch Port Switch Port Switch Port MAC src MAC src MAC src MAC dst MAC dst MAC dst Eth type Eth type Eth type VLAN ID VLAN ID VLAN ID IP Src IP Src IP Src IP Dst IP Dst IP Dst IP Prot IP Prot IP Prot TCP sport TCP sport TCP sport TCP dport TCP dport TCP dport Forward Forward Action Destination-based forwarding: 51.6.0.8 * * * * * * * * * port6 IP datagrams destined to IP address 51.6.0.8 should be forwarded to router output port 6 Firewall: * * * * * * * * * 22 drop do not forward (block) all datagrams destined to TCP port 22 drop 128.119.1.1 * * * * * * * * * do not forward (block) all datagrams sent by host 128.119.1.1

26. OpenFlow protocol • operates between controller, switch • TCP used to exchange messages • OpenFlow messages

27. OpenFlow: controller-to-switch messages • features: controller queries switch features, switch replies • configure: controller queries/sets switch configuration parameters • modify-state: add, delete, modify flow entries in the OpenFlow tables • packet-out: controller can send this packet out of specific switch port

28. OpenFlow: switch-to-controller messages • packet-in: transfer packet (and its control) to controller. See packet-out message from controller • flow-removed: flow table entry deleted at switch • port status: inform controller of a change on a port. Fortunately, network operators don’t “program” switches by creating/sending OpenFlow messages directly. Instead use higher-level abstraction at controller

29. 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, OpenDaylight, POX, Pyretic • Network deployments • Eight campuses, and two research backbone networks • Commercial deployments (e.g., Google backbone)

30. Challenges

31. Heterogeneous Switches • Number of packet-handling rules • Range of matches and actions • Multi-stage pipeline of packet processing • Offload some control-plane functionality (?) access control MAC look-up IP look-up

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

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. Evolution of OpenFlow

36. Evolution of OpenFlow P4 OpenFlow 2.0

37. Run OpenFlow Experiments • Mininet • Open vSwitch (OVS)

38. Hedera: Dynamic Flow Scheduling for Data Center Networks Mohammad Al-Fares Sivasankar Radhakrishnan Barath Raghavan* Nelson Huang Amin Vahdat UC San Diego *Williams College Slides modified from https://people.eecs.berkeley.edu/~istoica/classes/cs294/.../21-Hedera-TD.pptx

39. Key insight/idea • Identify large flows and periodically rearrange them to balance the load across core switches Problem MapReduce/Hadoop style workloads have substantial BW requirements ECMP-based multi-paths load balancing often leads oversubscription --> jobs bottlenecked by network Challenges • Estimate bandwidth demand of flows • Find optimal allocation network paths for flows

40. ECMP Paths • Many equal cost paths going up to the core switches • Only one path down from each core switch • Randomly allocate paths to flows using hash • Agnostic to available resources • Long lasting collisions between long (elephant) flows S D

41. Collisions of elephant flows • Collisions possible in two different ways • Upward path • Downward path S1 S2 S3 D2 S4 D1 D4 D3

42. Hedera Scheduler • Detect Large Flows • Flows that need bandwidth but are network-limited • Estimate Flow Demands • Use min-max fairness to allocate flows between src-dst pairs • Place Flows • Use estimated demands to heuristically find better placement of large flows on the ECMP paths 3. Schedule Flows 2. Estimate Flow Demands 1. Detect Large Flows

43. Elephant Detection • Scheduler continually polls edge switches for flow byte-counts • Flows exceeding B/s threshold are “large” • > %10 of hosts’ link capacity (i.e. > 100Mbps) • What if only mice on host? • Default ECMP load-balancing efficient for small flows

44. Demand Estimation • Measured flow rate is misleading • Need to find a flow’s “natural” bandwidth requirement when not limited by the network • find max-min fair bandwidth allocation

45. Demand Estimation • Given traffic matrix of large flows, modify each flow’s size at it source and destination iteratively… • Sender equally distributes bandwidth among outgoing flows that are not receiver-limited • Network-limited receivers decrease exceeded capacity equally between incoming flows • Repeat until all flows converge • Guaranteed to converge in O(|F|) time

46. Demand Estimation

47. Demand Estimation

48. Demand Estimation

49. Demand Estimation

50. Flow Placement Heuristics • Two approaches • Global First Fit: Greedily choose path that has sufficient unreserved b/w • Simulated Annealing: Iteratively find a globally better mapping of paths to flows