OpenFlow Guru Parulkar parulkar@stanford

1. OpenFlowGuru Parulkarparulkar@stanford.edu Stanford OpenFlow team: Nick McKeown, Guido Appenzeller, Glen Gibb, David Underhill, David Erickson, Adam Covington, Brandon Heller, Rob Sherwood, Masayoshi Kobayashi, Srinivasan Seetharaman, Yiannis Yiakoumis OpenFlowSwitch.org

2. Agenda • High Level Rationale • OpenFlow Basics • OpenFlow Demo • Generalization of Flow • Separation of Data and Control Paths • Virtualized OpenFlow Infrastructure • OpenFlow Deployment and Trials

3. Big Changes on the Horizon • Proliferation of mobile wireless • devices, networks, and services • Computing and storage moving into the cloud • Emergence of sensor networks and services • Society’s increasing dependence • Architectural limitations of current network requires change Each individually can lead to a very different type of Future Internet infrastructure and services

4. The Big Picture Handheld UI Secure mobile browser Energy efficient Secure OS HW Platform Applications PocketSchool, Virtual Worlds, Augmented Reality WEB/Computing Substrate Network of VMs, Mobile VMs Economics Data Substrate PRPL Virtual Data System Network Substrate OpenFlow Radio technologyMulti-Gb/s, 99% coverage

5. Key Networking Infrastructures: Problems • Cellular infrastructure -- supports mobility well • Designed for voice and circuit • Too many vertically integrated complex protocol stacks • Closed for (third party) innovations • With proliferation of data services, needs to converge with Internet • Internet -- the default data network infrastructure • Not designed for mobility, security, manageability, … • Supports innovations at the edges but not within the network itself • WiFi networks -- higher data rate at short range • Not designed for cellular style mobility • Allows easier experimentation -- unlicensed band and less expensive

6. Internet Ossification High Barrier to Entry ArchWeaknesses Lack of data& control path sep Complex ASICsMassive sw Increasinglycomplexdata path • Not a conspiracy -- just a fact of life • Research community has been staring at this problem for several years Resistant to change Industry, IETF, … Add complexity to addressweaknesses

7. OpenFlow Model Diverse applications Diverse transport layers Ethernet IP X Y Z Flow layer Diverse link layers Diverse physical layers Allow lots of innovation Routing, Mobility, Naming/Addressing, Access Control, Management, Monitoring…

8. Staged Approach • Define OpenFlow feature • Add OpenFlow to commercial switches and APs • Deploy at Stanford • 2009: Run NSF-funded trials on 6 college campuses • 2010: Deploy on many college campus networks • Community creates lots of open-source software so researchers can build on each other’s work (We’re part-way into Stage 2) OpenFlowSwitch.org

9. Agenda • High Level Rationale • OpenFlow Basics • OpenFlow Demo • Generalization of Flow • Separation of Data and Control Paths • Virtualized OpenFlow Infrastructure • OpenFlow Deployment and Trials

10. Rule (exact & wildcard) Flow 1. Rule (exact & wildcard) Rule (exact & wildcard) Rule (exact & wildcard) OpenFlow Basics (1) Default Action Statistics Statistics Statistics Statistics Action Action Action Flow 2. Flow 3. Flow N. Exploit the flow table in switches, routers, and chipsets OpenFlowSwitch.org

11. Rule (exact & wildcard) OpenFlow Basics (2) Statistics Action As general as possible e.g. Port, VLAN ID, L2, L3, L4, … As wide as possible Count packets & bytes Expiration time/count Small number of fixed actions e.g. unicast, mcast, map-to-queue, drop Extended via virtual ports e.g. tunnels, encapsulate, encrypt OpenFlowSwitch.org

12. OpenFlow Basics OpenFlow Switch specification Net Services PC OpenFlow Switch OpenFlow Protocol API SSL Controller Secure Channel sw • Add/delete flow entries • Encapsulated packets • Controller discovery Flow Table hw

13. OpenFlow UsageDedicated OpenFlow Network Statistics Statistics Statistics Action Action Action Rule Rule Rule Chip’s code OpenFlow Protocol Controller PC OpenFlow Switch OpenFlow Switch OpenFlow Switch OpenFlowSwitch.org Chip

14. Usage examples Chip’s code: • Static “VLANs” • His own new routing protocol: unicast, multicast, multipath, load-balancing • Network access control • Home network manager • Mobility manager • Energy manager • Packet processor (in controller) • IPvChip • Network measurement and visualization • … OpenFlowSwitch.org

15. OpenFlow and Mobility • Lots of interesting questions • Management of flows • Control of switches • Access control of users and devices • Tracking user location and motion • Lots of radio networks:WiFi, WiMax, LTE, … • Dumb access points • User choice

16. Deployment on Stanford campus • 100 of WiFi APs in 4 buildings & outdoor locations • A few Mobile WiMAX femto-cellbase stations • Deployed in this autumn • All are OpenFlow enabled & connected by OpenFlow switches • Plan to have a project class in this autumn/winter quarter WiFi AP (two radios/box) We are ready for innovation in our network! Mobile WiMAX AP

17. OpenFlow Target Domains • Enterprise • Original target • Data Center • Growing and looking for OpenFlow like solution • Mobile Cellular • Convergence of cellular and IP • Backbone • Unification of L1-L3 and Circuit and Packet

18. OpenFlow Demo OpenFlowSwitch.org

19. SIGCOMM 2008 Demo

20. Agenda • High Level Rationale • OpenFlow Basics • OpenFlow Demo • Generalization of Flow • Separation of Data and Control Paths • Virtualized OpenFlow Infrastructure • OpenFlow Deployment and Trials

21. Types of action • Allow/deny flow • Route & re-route flow • Isolate flow • Make flow private • Remove flow • What is a flow? • Application flow • All http • John’s traffic • All packets to China • … We need flexible definitions of a flow We don’t need many types of action Specific actions should easily evolve

22. Unicast 1. Multicast 2.

23. Multipath • Load-balancing • Redundancy 3. • Waypoints • Middleware • Intrusion detection • … 4.

24. Separation of Controlfrom Datapath

25. Operators, users, 3rd party developers, researchers, … New function! • Simpler Control & Management • Easy evolution • Rapid innovation • Open-source? • Thousands of developers • Scales with Moore’s Law • Choose ratio of control to datapath

26. Allow or deny flow? Whose flow is it? How to route flow?

27. DPI Passive Measurement Try doing this in your network :-)

28. Agenda • High Level Rationale • OpenFlow Basics • OpenFlow Demo • Generalization of Flow • Separation of Data and Control Paths • Virtualized OpenFlow Infrastructure • OpenFlow Deployment and Trials

29. Controller Step 1: Separate VLANs for Production and Research Traffic Flow Table Research VLANs Production VLANs Normal L2/L3 Processing OpenFlowSwitch.org

30. Step 2: Virtualize OpenFlow Switch Flow Table Flow Table Flow Table Controller A Researcher A VLANs Controller B Researcher B VLANs Controller C Researcher C VLANs Production VLANs Normal L2/L3 Processing OpenFlowSwitch.org

31. Virtualizing Control OpenFlow Hypervisor & Policy Control Heidi’s Controller Craig’s Controller Aaron’s Controller OpenFlow Protocol OpenFlow Switch OpenFlow Protocol OpenFlow Switch OpenFlow Switch OpenFlowSwitch.org

32. Virtualized OpenFlow Substrate Heidi’s Controller Craig’s Controller Net Services Net Services Net Services Aaron’s Controller API API API OpenFlow Protocol Hypervisor & Policy Control OpenFlow Switch OpenFlow Protocol OpenFlow Switch OpenFlow Switch

33. Many Open Questions! • Scalability of a controller • Load-balancing over redundant controllers • Federation, hierarchy and aggregation • Protecting the controller against DDOS Our goal is to enable the research community to explore all these questions OpenFlowSwitch.org

34. Agenda • High Level Rationale • OpenFlow Basics • OpenFlow Demo • Generalization of Flow • Separation of Data and Control Paths • Virtualized OpenFlow Infrastructure • OpenFlow Deployment and Trials

35. Path to Broader Impact: Networking Substrate • Easy to enable this capability on existing products • Don’t need to build our own boxes which is a major barrier • Eight switch vendors enabling this capability • Cisco, HP, NEC, Juniper, and others • We are starting to demonstrate the key capabilities • ACM SIGCOMM08 • GENI Engineering Conference • Supercomputing… • We plan to deploy or are deploying • on our campus: two buildings at Stanford (HP/Cisco) • on other campuses in US and Japan • in national nets: US (Internet2, NLR), Japan (JGN2plus), Europe, … And enable researchers and network operators to innovate on topHope OpenFlow takes off -- on a path of no return

36. Value of OpenFlow to Researchers and CIOs • Experiment with your network ideas at scale in your own network • By developing a network service • In a production network with real users and applications Something you haven’t been able to do • Try new network management and control ideas in a production network with real users and applications • Liberate yourself from the grips of the vendor

37. Goals of OpenFlow Trials • Empower researchers and CIOs to create innovative network services • Trials are less about OpenFlow and more about network services • Innovative network services represent significant opportunities for making contributions and creating value • An opportunity that haven’t existed for many years before • NSF wants to empower its researchers to take advantage of this opportunity • NICT may want to do the same for Japanese researchers • Stanford will be happy to support Japanese trials

38. OpenFlow Trial Interest • 20 Universities already shown interest • And the number is growing • T-Labs in CA and Berlin • DoCoMo Labs in CA • Research networks in Europe • A few campuses in Europe • A few universities from Japan and Korea

39. NSF Funded Trials in US: 1st Phase • Six out of 20 campuses interested • Support from CIO and strong research interest • Commitment to deploy in production networks • NSF to provide $300k of seed funding • For equipment and support of network admin in CIO office • Equipment vendors to provide support and subsidiary • NEC and HP committed; Juniper and Cisco are likely too • Stanford to provide reference implementations and support of these reference implementations • Stanford will submit proposal to NSF in January • Trials to begin in April 2009 for 18 months

40. http://OpenFlowSwitch.org OpenFlowSwitch.org

41. Thanks… (It takes a village) OpenFlowSwitch.org

42. Juniper • OpenFlow added to Junos SDK • First platform: MX-480 carrier class Ethernet • 24-ports 10GE or 240-ports 1GE • Hardware forwarding • Deployed in Internet2 in NY and at Stanford Umesh Krishnaswamy Michaela Mezo Parag Bajaria James Kelly Bobby Vandalore OpenFlowSwitch.org

43. HP • Experimental feature on ProCurve 5400-series • 144-ports of 1GE, hardware forwarding • OpenFlow added by HP Labs and ProCurve group • In 23 wiring closets in CS Building at Stanford Praveen Yalagandula Jean Tourrilhes Sujata Banerjee Rick McGeer Charles Clark OpenFlowSwitch.org

44. NEC Hideyuki Shimonishi Jun Suzuki Masanori Takashima Nobuyuki Enomoto Philavong Minaxay Shuichi Saito Tatsuya Yabe Yoshihiko Kanaumi Atsushi Iwata NEC/NICT NEC/NICT • Experimental feature on IP8800 series router • 24-ports of 1GE, 2-ports of 10GE, hardware forwarding • OpenFlow added by NEC team in Japan • NEC announced plans for OpenFlow products • Deployed at Stanford and in JGN2plus in Tokyo OpenFlowSwitch.org

45. Cisco • Experimental feature on Catalyst 6509 • Software forwarding • Deployed at Stanford Pere Monclus Sailesh Kumar Flavio Bonomi OpenFlowSwitch.org

46. Nicira Martin Casado Scott Shenker Teemu Koponen Natasha Gude Justin Pettit Controller • Created NOX controller • Available at http://NOXrepo.org (GPL) • Deployed at Stanford OpenFlowSwitch.org

47. Internet2 Team Chris Small Matt Zekauskas Installing Juniper MX-480 in NY OpenFlowSwitch.org

48. Stanford Team OpenFlowSwitch.org