1. Introduction to OpenFlow / SDN & its effects on the future of Internet Mohammad Moghaddas moghaddas.it@gmail.com www.1cisco.com 2012, July

2. Welcome

3. Goals of this Seminar By the end, everyone should know: – Knowledge about OpenFlow/SDN What these are How they relate What’s available now Where it’s going How it’s used – OpenFlow/SDN and You How you can use it How you can build on top of what’s available How you can build something completely new Have fun!

4. Original Question How can researchers on college campuses test out new ideas in a real network, at scale?  We like to do new experiments: Mobility management New naming/address schemes Network access control New features of Cloud Computing Virtualization features ….

5. Problem Many good research ideas on college campuses… No way to test new ideas at scale, on real networks, with real user traffic Many good research ideas on college campuses… No way to test new ideas at scale, on real networks, with real user traffic Consequence: Almost no technology transfer

6. Research problems Well known problems Security, mobility, availability Well known problems Security, mobility, availability Incremental ideas Fixing BGP, multicast, access control, Mobile IP, data center networks. Incremental ideas Fixing BGP, multicast, access control, Mobile IP, data center networks. More radical changes Energy management, VM mobility, … More radical changes Energy management, VM mobility, …

7. The only test network large enough to evaluate future Internet technologies at scale, is the Internet itself.

8. Today’s Networks are Defined by the “Box” Hardware, Operating System, and Applications Built Into a “Box”. Cannot Mix and Match Barrier to Entry

9. Vertically integrated Closed, proprietary Slow innovation Small industry Specialized Operating System Specialized Operating System Specialized Hardware Specialized Hardware App Specialized Applications Specialized Applications Horizontal Open interfaces Rapid innovation Huge industry Microprocessor Open Interface Linux Mac OS Mac OS Windows (OS) Windows (OS) or Open Interface

10. Vertically integrated Closed, proprietary Slow innovation App Horizontal Open interfaces Rapid innovation Control Plane Control Plane Control Plane Control Plane Control Plane Control Plane or Open Interface Specialized Control Plane Specialized Control Plane Specialized Hardware Specialized Hardware Specialized Features Specialized Features Merchant Switching Chips Merchant Switching Chips Open Interface

12. What is SDN?

13. Specialized Packet Forwarding Hardware Ap p Specialized Packet Forwarding Hardware Ap p Specialized Packet Forwarding Hardware Ap p Specialized Packet Forwarding Hardware Ap p Specialized Packet Forwarding Hardware Operating System Operating System Operating System Operating System Operating System Operating System Operating System Operating System Operating System Operating System Ap p 13 Current Internet Closed to Innovations in the Infrastructure Closed

14. Specialized Packet Forwarding Hardware Ap p Specialized Packet Forwarding Hardware Ap p Specialized Packet Forwarding Hardware Ap p Specialized Packet Forwarding Hardware Ap p Specialized Packet Forwarding Hardware Operating System Operating System Operating System Operating System Operating System Operating System Operating System Operating System Operating System Operating System Ap p Network Operating System App “Software Defined Networking” approach to open it

15. Software Defined Network (SDN) Global Network View Network Virtualization Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Network OS Abstract Network View Control Programs Control Programs

16. Software Defined Network (SDN) Global Network View Network Virtualization Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Abstract Network View Control Programs Control Programs firewall.c … if( pkt->tcp->dport == 22) dropPacket(pkt); … firewall.c … if( pkt->tcp->dport == 22) dropPacket(pkt); … Packet Forwarding Packet Forwarding Network OS 1. 2. 3. 4. 5. 6.… 7.… 1. 2. 3. 4. 5. 6.… 7.… 1. 2. 3. 4. 5. 6.… 7.… 1. 2. 3. 4. 5. 6.… 7.… 1. 2. 3. 4. 5. 6.… 7.… 1. 2. 3. 4. 5. 6.… 7.… 1. 2. 3. 4. 5. 6.… 7.… 1. 2. 3. 4. 5. 6.… 7.… 1. 2. 3. 4. 5. 6.… 7.… 1. 2. 3. 4. 5. 6.… 7.…

17. With SDN we will: 1.Formally verify that our networks are behaving correctly. 2.Identify bugs, then systematically track down their root cause.

18. How do other industries do it?

19. Making ASICs Work Specification Functional Description (RTL) Testbench & Vectors Functional Verification Logical Synthesis Static Timing Place & Route Design Rule Checking (DRC) Layout vs Schematic (LVS) Layout Parasitic Extraction (LPE) Manufacture & Validate

20. Making Software Work Static Code Analysis Invariant Checker Interactive Debugger Model Checking Run-time Checker Specification Testbench Functional Description (Code)

21. Example: New Data Center Cost 200,000 servers Fanout of 20  10,000 switches $5k vendor switch = $50M $1k commodity switch = $10M Savings in 10 data centers = $400M

22. Making Networks Work (Today) traceroute, ping, tcpdump, SNMP, Netflow …. er, that’s about it.

23. Why debugging networks is hard Complex interaction – Between multiple protocols on a switch/router. – Between state on different switches/routers. Multiple uncoordinated writers of state. Operators can’t… – Observe all state. – Control all state.

24. Networks are kept working by “Masters of Complexity” A handful of books Almost no papers No classes A handful of books Almost no papers No classes

25. Philosophy of Making Networks Work YoYo “You’re On Your Own” YoYo Ma “You’re On Your Own, Mate”

26. With SDN we will: 1.Formally verify that our networks are behaving correctly. 2.Identify bugs, then systematically track down their root cause.

27. Three Methods Static Checking “Independently checking correctness” Automatic Testing “Is the datapath behaving correctly?” Interactive Debugging “Finding bugs, and their root cause, in an operational network”

28. Static checking Independently checking correctness Peyman Kazemian Hongyi ‘James’ Zeng George Varghese (UCSD)

29. Motivations In today’s networks, simple questions are hard to answer: – Can host A talk to host B? – What are all the packet headers from A that can reach B? – Are there any loops in the network? – Is Group X provably isolated from Group Y? – What happens if I remove a line in the config file? 29

30. Software Defined Network (SDN) Global Network View Network Virtualization Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Abstract Network View Control Programs Control Programs Packet Forwarding Packet Forwarding Network OS 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … Static Checker 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … “A can talk to B” “Guests can’t reach PatientRecords” “A can talk to B” “Guests can’t reach PatientRecords” Policy

31. How it works Header Space Analysis

32. Header Space Analysis 1 2 3 4 1 2 3 4 Port ID

33. Header Space Analysis 1 2 3 4 1 2 3 4 Port ID

34. Use Cases Can host A talk to B? 34 Box 1 Box 2 Box 3 Box 4 A B T 1 (X,A) T 2 (T 1 (X,A)) T 4 (T 1 (X,A)) T 3 (T 2 (T 1 (X,A)) U T 3 (T 4 (T 1 (X,A)) T -1 3 T -1 4 T -1 2 T -1 1 All Packets sent from A can use to communicate with B

35. Use Cases Is there a loop in the network? – Inject an all-x text packet from every switch-port – Follow the packet until it comes back to injection port 35 Box 1 Box 2 Box 3 Box 4 T 1 (X,P) T 2 (T 1 (X,P)) T 3 (T 2 (T 1 (X,P))) T 4 (T 3 (T 2 (T 1 (X,P)))) Original HS Returned HS T -1 4 T -1 3 T -1 2 T -1 1

36. Use Cases Is the loop infinite? 36 Finite LoopInfinite Loop?

37. Header Space Analysis Consequences 1.Finds all packets from A that can reach B 2.Find loops, regardless of protocol or layer 3.Can prove that two groups are isolated Proves if network adheres to policy Works on existing networks and SDNs

38. Stanford Backbone Hassell tool 1.Reads Cisco IOS Configuration 2.Checks reachability, loops and isolation 3.10 mins for Stanford Backbone 4.Easily made parallel: 1 sec is feasible Hassell is available for free, for you to run

39. Stanford backbone network 39 ~750K IP fwd rule. ~1.5K ACL rules. ~100 Vlans. Vlan forwarding. ~750K IP fwd rule. ~1.5K ACL rules. ~100 Vlans. Vlan forwarding.

40. Stanford backbone network Loop detection test – run time < 10 minutes on a single laptop. 40 Vlan RED Spanning Tree Vlan RED Spanning Tree Vlan BLUE Spanning Tree

41. Performance 41 Generating TF Rules~150 sec Loop Detection Test (30 ports)~560 sec Average Per Port~18 sec Min Per Port~ 8 sec Max Per Port~ 135 sec Reachability Test (Avg)~13 sec Performance result for Stanford Backbone Network on a single machine: 4 core, 4GB RAM.

42. What is OpenFlow?

43. Short Story: OpenFlow is an API Control how packets are forwarded Implementable on COTS hardware Make deployed networks programmable – not just configurable Makes innovation easier Goal (experimenter’s perspective): – No more special purpose test-beds – Validate your experiments on deployed hardware with real traffic at full line speed

44. OpenFlow: a pragmatic compromise + Speed, scale, fidelity of vendor hardware + Flexibility and control Leverages hardware inside most switches today Vendors don’t need to expose implementation

45.  Put an open platform in hands of researchers/students to test new ideas at scale through production networks.  An open development environment for all researchers  Give access to flow tables in switches: - lookup tables, access control list, etc.. - Control packet forwarding in routers and switches.

46. How Does OpenFlow Work?

47. Ethernet Switch

48. Data Path (Hardware) Control Path Control Path (Software)

49. Data Path (Hardware) Control Path OpenFlow OpenFlow Controller OpenFlow Protocol (SSL/TCP)

50. Controller PC Hardware Layer Software Layer Flow Table MAC src MAC dst IP Src IP Dst TCP sport TCP dport Action OpenFlow Firmware **5.6.7.8***port 1 port 4port 3 port 2 port 1 1.2.3.45.6.7.8 OpenFlow Flow Table Abstraction

51. OpenFlow Basics Flow Table Entries Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport RuleActionStats 1.Forward packet to port(s) 2.Encapsulate and forward to controller 3.Drop packet 4.Send to normal processing pipeline 5.Modify Fields Packet + byte counters

52. Examples Switching * Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Action * 00:1f:.. *******port6 Flow Switching port3 Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Action 00:20..00:1f..0800vlan11.2.3.45.6.7.841726480port6 Firewall * Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Forward ********22drop

53. Examples Routing * Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Action *****5.6.7.8***port6 VLAN Switching * Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Action ** vlan1 ***** port6, port7, port9 00:1f..

54. http://geni.net

55. GENI OpenFlow deployment (2010) 83 Universities/Research centers & 2 National Backbones

57. http://groups.geni.net/geni/wiki/ProtoGENIFlashClient

58. Switches

59. Linux based Software Switch Release concurrently with specification Kernel and User Space implementations Note: no v1.0 kernel-space implementation Limited by host PC, typically 4x 1Gb/s Not targeted for real-world deployments Useful for development, testing Starting point for other implementations Available under the OpenFlow License (BSD Style) at http://www.openflowswitch.org Stanford Reference Implementation

60. Wireless Access Points Two Flavors: – OpenWRT based (Busybox Linux) v0.8.9 only – Vanilla Software (Full Linux) Only runs on PC Engines Hardware Debian disk image Available from Stanford Both implementations are software only.

61. NetFPGA NetFPGA-based implementation – Requires PC and NetFPGA card – Hardware accelerated – 4 x 1 Gb/s throughput Maintained by Stanford University $500 for academics $1000 for industry Available at http://www.netfpga.org

62. Linux-based Software Switch Released after specification Not just an OpenFlow switch; also supports VLAN trunks, GRE tunnels, etc Kernel and User Space implementations Limited by host PC, typically 4x 1Gb/s Available under the Apache License (BSD Style) at http://www.openvswitch.org Open vSwitch

63. OpenFlow Vendor Hardware more to follow... NEC IP8800 HP ProCurve 5400 Juniper MX-series Cisco Catalyst 6k Core Enterprise Campus/DC Circuit Switch Wireless Pronto Prototype Product Ciena CoreDirector WiMAX (NEC) Cisco Cat3750 Arista 7100 series (Q4 2010) 63

64. HP ProCurve 5400 Series Praveen Yalagandula Jean Tourrilhes Sujata Banerjee Rick McGeer Charles Clark Chassis switch with up to 288 ports of 1G or 48x10G (+ other interfaces available) Line-rate support for OpenFlow Deployed in 23 wiring closets at Stanford Limited availability for Campus Trials Contact HP for support details

65. NEC IP8800 24x/48x 1GE + 2x 10 GE Line-rate support for OpenFlow Deployed at Stanford Available for Campus Trials Supported as a product Contact NEC for details: Don Clark (don.clark@necam.com)don.clark@necam.com Atsushi Iwata (a-iwata@ah.jp.nec.com)a-iwata@ah.jp.nec.com Hideyuki Shimonishi Jun Suzuki Masanori Takashima Nobuyuki Enomoto Philavong Minaxay Shuichi Saito Tatsuya Yabe Yoshihiko Kanaumi (NEC/NICT) Atsushi Iwata (NEC/NICT)

66. Umesh Krishnaswamy Michaela Mezo Parag Bajaria James Kelly Bobby Vandalore Juniper MX Series Up to 24-ports 10GE or 240-ports 1GE OpenFlow added via Junos SDK Hardware forwarding Deployed in Internet2 in NY and at Stanford Prototype Availability TBD

67. Flavio Bonomi Sailesh Kumar Pere Monclus Various configurations available Software forwarding only Limited deployment as part of demos Availability TBD Work on other Cisco models in progress Cisco 6500 Series

68. – The individual controllers and the FlowVisor are applications on commodity PCs (not shown) Demo Infrastructure with Slicing Flows OpenFlow switches WiMax Packet processors WiFi APs Be sure to check out the demos in www.openflow.org

69. OpenFlow Demonstration Overview Network Virtualization FlowVisor Hardware Prototyping OpenPipes Load Balancing PlugNServe Energy Savings ElasticTree Mobility MobileVMs Traffic Engineering Aggregation Wireless Video OpenRoads TopicDemo

70. FlowVisor Creates Virtual Networks OpenFlow Switch OpenFlow Switch OpenFlow Switch OpenFlow Protocol FlowVisor OpenPipes Demo OpenRoads Demo OpenFlow Protocol PlugNServe Load-balancer OpenPipes Policy FlowVisor slices OpenFlow networks, creating multiple isolated and programmable logical networks on the same physical topology. Each demo described here runs in an isolated slice of Stanford’s production network.

71. Plumbing with OpenFlow to build hardware systems OpenPipes Partition hardware designs Test Mix resources

72. Goal: Load-balancing requests in unstructured networks Plug-n-Serve : Load-Balancing Web Traffic using OpenFlow OpenFlow means…  Complete control over traffic within the network  Visibility into network conditions  Ability to use existing commodity hardware What we are showing  OpenFlow-based distributed load-balancer  Smart load-balancing based on network and server load  Allows incremental deployment of additional resources This demo runs on top of the FlowVisor, sharing the same physical network with other experiments and production traffic.

73. ElasticTree: Reducing Energy in Data Center Networks The demo: Hardware-based 16-node Fat Tree Your choice of traffic pattern, bandwidth, optimization strategy Graph shows live power and latency variation Shuts off links and switches to reduce data center power Choice of optimizers to balance power, fault tolerance, and BW OpenFlow provides network routes and port statistics

74. Available at http://NOXrepo.orghttp://NOXrepo.org Open Source (GPL) Modular design, programmable in C++ or Python High-performance (usually switches are the limit) Deployed as main controller in Stanford NOX Controller Martin Casado Scott Shenker Teemu Koponen Natasha Gude Justin Pettit

75. www.geni.net www.openflow.org www.openflowswitch.org www.noxrepo.org www.opennetworking.org www.cisco.com/go/one onrc.stanford.edu www.usenix.org http://www.techrepublic.com References

76. Thank you!