Stanford University

1. POMI 2020 Stanford University POMI2020: Network SubstrateSoftware-defined Networks, and OpenFlowNSF Site Visit, June 2010Nick McKeownSachin KattiMonica LamRamesh JohariGuru Parulkar

2. POMI Research Agenda Infrastructure Applications Handheld Data & Computing Substrate PrPl, Junction and Concierge UI Secure mobile browser Economics Network Substrate Software Defined Network & OpenFlow Cinder: Energy aware, secure OS HW Platform Radio technology

3. Outline We set out to address two “barriers to innovation” in the network… Barrier 3: There is abundant capacity available, but it is closed and unavailable Barrier 4: The network infrastructure is closed and will remain ossified

4. What do we mean when we say the network is “closed and ossified”?

5. Million of linesof source code Billions of gates The Ossified Network Routing, management, mobility management, access control, VPNs, … Feature Feature 5400 RFCs Barrier to entry Operating System Specialized Packet Forwarding Hardware Bloated Power Hungry Many complex functions baked into the infrastructure • OSPF, BGP, multicast, differentiated services,Traffic Engineering, NAT, firewalls, MPLS, redundant layers, … • An industry with a “mainframe-mentality”, reluctant to change

6. Glacial process of innovation made worse by captive standards process Deployment Idea Standardize Wait 10 years Driven by vendors Owners/operators largely locked out Lowest common denominator features Glacial innovation Unlikely to change without external help

7. Example where change is needed Cellular industry • Recently made transition to IP • Billions of mobile users • Need to securely extract payments and hold users accountable • IP is dreadful at both, yet hard to change

8. Telco Operators e.g. AT&T, DT, NTT, … • Global IP traffic will grow 5x by 2013 • End-customer monthly bill remains unchanged • Therefore, CAPEX and OPEX need to be reduced 5x by 2013 • But in practice, reduces by <20% per year Q: How can operators reduce cost? Q: How can they differentiate their service?

9. The SDN Approach* Separate control from the datapath • i.e. separate policy from mechanism Datapath: Define minimal network instruction set • A set of “plumbling primitives” • A vendor-agnostic interface: OpenFlow Control: Define a network-wide OS • An API that others can develop on * With Scott Shenker, Martin Casado and many others

10. Restructured Network Feature Feature Network OS Operating System Specialized Packet Forwarding Hardware Operating System Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Specialized Packet Forwarding Hardware Operating System Specialized Packet Forwarding Hardware Operating System Specialized Packet Forwarding Hardware Operating System Specialized Packet Forwarding Hardware

11. 2. At least one Network OSprobably many.Open- and closed-source 3. Well-defined open API The “Software-defined Network” Feature Feature 1. Open interface to hardware Network OS OpenFlow Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware

12. OpenFlow Basics Narrow, vendor-agnostic interface to control switches, routers, APs, basestations.

13. Step 1: Separate Control from Datapath Network OS OpenFlow Switch OpenFlow Switch OpenFlow Switch OpenFlow Switch

14. Step 2: Cache flow decisions in datapath “If header = x, send to port 4” “If header =y, overwrite header with z, send to ports 5,6” “If header = ?, send to me” Flow Table OpenFlow Switch OpenFlow Switch OpenFlow Switch OpenFlow Switch

15. Plumbing Primitives • Match arbitrary bits in headers: • Match on any header; or new header • Allows any flow granularity • Actions: • Forward to port(s), drop, send to controller • Overwrite header with mask, push or pop • Forward at specific bit-rate Data Header Match: 1000x01xx0101001x

16. 2. At least one Network OSprobably many.Open- and closed-source 3. Well-defined open API The “Software-defined Network” Feature Feature 1. Open interface to hardware Network OS OpenFlow Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware

17. Isolated “slices” Many operating systems, or many versions Feature Feature Feature Feature Network Operating System 1 Network Operating System 2 Network Operating System 3 Network Operating System 4 Open interface to hardware Open interface to hardware Virtualization or “Slicing” Layer (FlowVisor) Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware

18. Our Strategy Barrier: The network infrastructure is closed and will remain ossified Strategy: The Software Defined Network • Add OpenFlow to switches, routers, WiFi APs, basestations, … deploy in our network • Use SDN for our own research • Study how to apply to different types of network • Enable others to do research in their network • (Work with GENI community to deploy widely)

19. Some research examples

20. Ethane, a precursor to OpenFlowCentralized, reactive, per-flow control Controller Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Host B Host A Simple Packet Forwarding Hardware Flow Switch [Ethane, Sigcomm ‘07]

21. FlowVisor Creates Virtual Networks FlowVisor PlugNServe Load-balancer OpenFlow Wireless Demo OpenPipes Demo OpenFlow Protocol OpenFlow Protocol OpenPipes Policy OpenFlow Switch OpenFlow Switch OpenFlow Switch Multiple, isolated slices in the same physical network [Paper in submission] [Sigcomm 2009 – Best Demo]

22. Demo Infrastructure with Slicing

23. OpenPipesPartition hardware designs across a network [Sigcomm 2009 – 2nd Best Demo] [Paper in submission]

24. Load-balancing as Network Primitive Goal: Minimize http response time over campus network Approach: Route over path to jointly minimize <path latency, server latency> Load-Balancer Internet “Pick path & server” Network OS OpenFlow Switch OpenFlow Switch OpenFlow Switch OpenFlow Switch OpenFlow Switch [Sigcomm 2009 Demo] [Paper in preparation]

25. Intercontinental VM Migration Moved a VM from Stanford to Japan without changing its IP. VM hosted a video game server with active network connections. [Sigcomm 2008– Best Demo]

26. Converging Packet and Circuit Networks Goal: Common control plane for “Layer 3” and “Layer 1” networks Approach: Add OpenFlow to all switches; use common network OS Feature Feature NOX OpenFlow Protocol OpenFlow Protocol WDM Switch IP Router IP Router TDM Switch WDM Switch [Supercomputing 2009 Demo] [OFC 2010]

27. ElasticTree • Goal: Reduce energy in data center networks • Approach: • Reroute traffic • Shut off links and switches to reduce power DC Manager “Pick paths” Network OS [NSDI 2010]

28. ElasticTree • Goal: Reduce energy in data center networks • Approach: • Reroute traffic • Shut off links and switches to reduce power DC Manager “Pick paths” Network OS X X X X X [NSDI 2010]

29. Making a Network Application Friendly “Create a chat room” “Send to all participants” “Encrypt data” “Min. bandwidth is 6Mbps” Phone2Phone Apps Junction “Create a multicast group” “Encrypt a flow” “Calculate multicast routing” “Assign flow rate” Network OS OpenFlow Switch OpenFlow Switch OpenFlow Switch OpenFlow Switch [SIGCOMM’10 APSys Workshop] [SIGCOMM’10 MobiHeld Workshop]

30. Will SDN happen?

31. We now believe SDN will happen It is starting in big data centers • Driven by cost and control • Unable to cope with virtualization, multi-tenancy… • We are trying to “steer” them in same direction Growing interest by ISPs, cellular operators (GENI: Deploying on college campuses)

32. Example: New Data Center Cost 200,000 servers Fanout of 20 a 10,000 switches $5k vendor switch a $50M $1k commodity switch a $10M Savings in 10 data centers = $400M Control More flexible control Quickly improve and innovate Enables “cloud networking” We believe large data centers will use SDN.

33. POMI Progress OpenFlow added to many devices • Switches, routers, APs, basestations, transport switches, chips Many research experiments have validated the approach Deployments happening on college campuses

34. Self Assessment + Good progress on basic architecture + “Slicing” very promising + Research experiments validate the approach - The networking industry is very entrenched - To break down the barrier, it takes a lot of engineering. + More deployments than we expected - Difficult to scale to meet interest/demand

35. Outline We set out to address two “barriers to innovation” in the network… Barrier: The network infrastructure is closed and will remain ossified Barrier: There is abundant capacity available, but it is closed and unavailable

36. What does it take to….. Open the wireless infrastructure so users can choose any free spectrum, any network, or many networks, any time?

37. Sprint WiMAX AT&T 3G Any network….

38. Sprint WiMAX AT&T 3G Many networks….

39. What does it take to give users choice?

40. Technology and contracting Contracts are limited or enabled by technology This has a first order impact on network economics [ Example: BGP and interdomain routing ] • What technology is needed to enable anew form of contract? • Are there countervailing economic forces thatmight prevent efficient use of new technology?

41. Application: Learning to share Can wireless providers learn to share? Technologies such as OpenFlow Wireless andradio virtualization enable users to make choices. Will providers let them? Central requirement is complementarity:Profit-maximizing providers must find collectiveaction in their own best interest. Examples:Geographical complementarity (roaming).Overcoming high fixed costs (tower sharing).

42. How do we give users choice?

43. Wish List • Instantaneous contracts with any physical network, independent of its owner or radio technology • A network-independent way to choose a network, and to control mobility

44. Design Choice • Establish my own instantaneous contracts and control the network (hard), or • Delegate to an entity in the infrastructure • A service provider • My own agent Conceptually the same; we start by delegating

45. Requirement Technical • Radio-independent control layer • A method for a service provider to control my flows on my behalf Business • An incentive for infrastructure owners to open access to service providers

46. “AT&T” “Vodafone” New Service Billing, Mobility New Service Billing, Mobility New Service Feature Feature Network OS Network OS Network OS Network OS “Slicing” Layer OpenFlow AP OpenFlow Switch OpenFlow Switch OpenFlow Switch OpenFlow BS

47. Consequences Radio-independent control layer • Service provider controls user flows • Easy handover between physical networks • Can use several networks simultaneously • Service innovation by service providers A method to share the physical infrastructure • Isolation between service providers • Short-term or long-term lease of rights-of-way

48. AT&T Service Layer: Authentication, Billing, Mobility Management, Routing, … Network Layer: Wireline Network Radio Network: Spectrum, Radios

49. Separating the service from the network Service Layer: Authentication, Billing, Mobility Management, Routing, … Separation/Virtualization Network Layer: Wireline Network Radio Network: Spectrum, Radios

50. Service provider controls a slice across physical networks “AT&T” Service Service Service Service Separation/Virtualization Network Network Network Network Radio Network: Spectrum, Radios