Software Defined Networks: History, Hype, and Hope

1. Software Defined Networks:History, Hype, and Hope Scott Shenker with Martín Casado, TeemuKoponen, Nick McKeown (and many others….)

2. Caveat Audiens • I have a startup in area (Nicira) • Feel free to regard everything I am saying as the self-serving comments of a greedy, lying entrepreneur… • Some of you have heard parts of this talk before • First part: people who know nothing about SDN • Second part: people who know more about SDN than I do

3. Roots of SDN • ~2004: Research on new management paradigms • RCP, 4D[Princeton, CMU,….] • SANE, Ethane [Stanford/Berkeley] • Industrial efforts with similar flavor (not published) • 2008: Software-Defined Networking (SDN) • NOX Network Operating System [Nicira] • OpenFlow switch interface [Stanford/Nicira] • 2011: Open Networking Foundation (~69 members) • Board: Google, Yahoo, Verizon, DT, Msoft, F’book, NTT • Members: Cisco, Juniper, HP, Dell, Broadcom, IBM,…..

4. Current Status of SDN • SDN widely accepted as “future of networking” • ~1000 engineers at latest Open Networking Summit • Commercialized, in production use (few places) • Much more acceptance in industry than in academia • There is an insane level of SDN hype, and backlash • SDN doesn’t work miracles, merely makes things easier • Think of SDN as a programming model • But the real question is: why the rapid adoption? • And that requires more history…starting with the Internet

5. Key to Internet Success: Layers Applications …built on… Reliable (or unreliable) transport …built on… Best-effort global packet delivery …built on… Best-effort local packet delivery …built on… Physical transfer of bits

6. The Importance of Layering • Decomposed delivery into fundamental components • Independent but compatible innovation at each layer • The Internet has been an amazing success… • …but an academic failure

7. Built an Artifact, Not a Discipline • Other fields in “systems”: OS, DB, etc. • Teach basic principles • Are easily managed • Continue to evolve  • Networking: • Teach big bag of protocols • Notoriously difficult to manage • Evolves very slowly

8. Why Is Networking Behind Other Fields? • Networks originally had single goal: Deliver packets • Resulting designs were conceptually very simple • Ethernet • IP • TCP/UDP • But the success of the Internet had a downside • Just delivering packets is no longer enough!

9. New Requirements on Packet Delivery • Isolation • Traffic engineering • Packet processing • Payload analysis • ….

10. Which Led to New Control Mechanisms • Isolation: VLANs, ACLs • Traffic engineering: MPLS, weighted routing, ECMP • Packet processing: Firewalls, NATs, middleboxes • Payload analysis: Deep packet inspection (DPI) • ….

11. A More Complex “Control Plane” • Mechanisms designed and deployed independently • Resulting in greatly increased network complexity… • …but only primitive control functionality • The control plane became an ad hoc mess • Stark contrast to the elegantly modular “data plane” • The infrastructure still works... • Only because of our great ability to master complexity • This ability to master complexity is both a blessing… • …and a curse!

12. A Simple Story About Complexity • ~1985: Don Norman visits Xerox PARC • Talks about user interfaces and stick shifts

13. What Was His Point? • The ability to master complexity is valuable • But not the same as the ability to extract simplicity • Each has its role: • When first getting systems to work, master complexity • When making system easy to use, extract simplicity • You will never succeed in extracting simplicity • If you don’t recognize it is a different skill set than mastering complexity

14. What Is My Point? • Networking has never made the distinction… • And therefore has never made the transition from mastering complexity to extracting simplicity • Still focused on mastering complexity • Networking “experts” are those that know all the details • Extracting simplicity lays the intellectual foundations • This is why networking has weak foundation • We are still building the artifact, not the discipline

15. Forcing People To Make The Transition • We are really good at mastering complexity • And it has worked for us for decades, why change? • A personal lesson in loving complexity too much • Networking has now hit its complexity limits • Large datacenters, particularly multitenant environments • 100,000s machines; 10,000s switches; 10,000s customers • The era of ad hoccontrol mechanisms is over • So how do you “extract simplicity”?

16. AnExampleTransition: Programming • Machine languages: no abstractions • Had to deal with low-level details • Mastering complexity was crucial • Higher-level languages: OS and other abstractions • File system, virtual memory, abstract data types, ... • Modern languages: even more abstractions • Object orientation, garbage collection,... Abstractions key to extracting simplicity

17. “The Power of Abstraction” “Modularity based on abstraction is the way things get done” − Barbara Liskov Abstractions Interfaces Modularity

18. What About Networking Abstractions? • Layers are great abstractions, for the data plane • We have no abstractions for the control plane! • That’s why the control plane is such a mess! • How do we find those abstractions? • Define the control plane problem…. • ….and then decompose it.

19. For Any Task, The Control Plane Must: • Operate without communication guarantees • A distributed system with arbitrary failures • Compute the configuration of each physical device • Switch, router, middlebox: complete forwarding tables • “Configuration” here means filling in tables by any means • Operate within given network-level protocol • Must live with the capabilities of IP, Ethernet, etc.

20. This Seems Normal To Us • Another sign of how much we love complexity • No other field would deal with such a problem!

21. Programming Analogy • What if programmers had to: • Specify where each bit was stored • Explicitly deal with all internal communication errors • Within a programming language with limited expressability • Programmers would redefine problem by: • Defining higher level abstractions for memory • Building on reliable communication abstractions • Using a more general language • Abstractions provide clean separation of concerns • How can we do this for networking?

22. Concerns/Problems to be Separated • Operate without communication guarantees Need an abstraction for distributed state • Compute the configuration of each physical device Need an abstraction that simplifies configuration • Operate within given network-level protocol Need an abstraction for general forwarding model

23. 1. Distributed State Abstraction • Shield mechanisms from vagaries of distributed state • While allowing access to this state • Proposed abstraction: global network view • Annotated network graph provided through an API • Will later talk about ways to scale this…. • Control mechanism is now program using API • No longer a distributed protocol, now just a graph algorithm • Distributed state issues hidden behind abstraction

24. 2. Specification Abstraction • Control program should express desired behavior • It should not be responsible for implementing that behavior on physical network infrastructure • Requires configuring the forwarding tables in each switch • Proposed abstraction: abstractview of network • Abstract view models only enough detail to specify goals • This is “network virtualization” • Abstract view is “virtual network”

25. Simple Example: Access Control A Abstract Network View B A Global Network View B

26. 3. Forwarding Abstraction • Two related goals: • Freedom from dataplane limitations • Freedom from vendor-specific solutions • OpenFlow is current proposal for forwarding • Uses flow entries of the form: <header, action> • Design details concern exact nature of: • Header matching • Allowed actions

27. My Talk in One Sentence • SDN is defined precisely by these abstractions • Distributed state • Specification • Forwarding • Abstractions make it easier to build control plane • Just write control program to API, not design new protocol • Just specify goals, not how to implement them • SDN is not a particular set of mechanisms, it is any realization of these abstractions • But what would such a system look like?

28. Realizing These SDN Abstractions • The core challenge is to turn a fully distributed control problem into a more centralized one • This involves designing a common distribution layer • Gathers information from network elements (topology) • Disseminates control commands to network elements • Must be scalable and flexible (not tied to control task) • This is done by a “Network Operating System” • Runs on servers in network (replicated for resilience) • NOX, ONIX, Trema, Beacon, some proprietary systems

29. Software Defined Network (SDN) Traditional Control Mechanisms Network of Switches and/or Routers e.g. routing, access control Control Program Global Network View Distributed algorithm running between neighbors Complicated task-specific distributed algorithm Network OS

30. Specification Abstraction • Abstraction is a simplified view/model of network • Only enough details to specify intent • No need to have enough details for implementation! • Requires a new shared layer: • Map abstract configuration to physical configuration

31. Software Defined Network Abstract Network View Network Virtualization Control Program Global Network View Network OS

32. Simple Example: Access Control A Abstract Network View B A Global Network View B

33. Software Defined Network Control Program Abstract Network View Network Virtualization Global Network View Network OS

34. Major Change in Paradigm • Control program: Configuration= Function(view) • Applied to abstract network view • Easier to write, verify, maintain, reason about, …. • Logically centralized, abstract, stateless • Requires sophisticated systems support to achieve • No reduction in overall system complexity

35. Clean Separation of Concerns • Control program: map behavior to abstract view • Driven by Task Semantics • Net Virtualization: abstract view to global view • Driven by Specification Abstraction • NOS: global view to physical switches • API: driven by Distributed State Abstraction • Switch interface: driven by Forwarding Abstraction

36. Common Questions about SDN? • Is SDN less scalable, secure, resilient,…? • Is SDN incrementally deployable? • Can SDN be extended to the WAN? • Can you troubleshoot an SDN network? • Is OpenFlow the right fwding abstraction?

37. Common Questions about SDN? • Is SDN less scalable, secure, resilient,…? No • Is SDN incrementally deployable? Yes • Can SDN be extended to the WAN?Yes • Can you troubleshoot an SDN network?Yes • Is OpenFlow the right fwding abstraction? No

38. Why Isn’t SDN Less Scalable, etc.? • In terms of mechanism, SDN is similar to today • If you look at where state is passed • But the programmatic interface is radically different • The interface extracts the simplicity, lets SDN platform manage the complexity for you….

39. Why Is SDN Incrementally Deployable? • Can implement most control functionality at edge • Access control, QoS, mobility, migration, monitoring… • Controllable switch in host software • Hypervisor or OS: Open vSwitch (OVS) • Can build SDN using OVS with no hardware change! • Physical switch infrastructure can be simple/legacy • Provides big reliable crossbar • Enables incremental deployment of SDN • Might never need OpenFlow in hardware switches….

40. How Do You Scale SDN to WANs? • Build system out of two logical components: • Logical servers: highly-available, high-capacity • Logical xBars: distributed unit of switching w/ fwding table • Use locality to create hierarchical structure • Levels: physical switches, PoPs, Regional, National, etc. • Each level’s abstract view is a logical xBar • Use Function(view) to configure each layer below • Recursive application of same code • No iteration, bounded depth of computation • Transactional changes, no disruption during convergence

41. How to Troubleshoot SDN Platforms? • SDN simplifies specification of behavior • That’s the whole goal • SDN platform responsible for implementing spec. • That’s the whole challenge • That’s where the bugs will be….at least for now • How do we know when the platform is misbehaving? • Current research: localize problem in layer and time • Correspondence checking: semantics same at each layer • Replay simulator: identify minimal set of triggering events

42. Is OpenFlow the Answer? • There are two key interfaces (headers) • Host tells the network what service it wants • Packet tells a switch how to handle it • OpenFlow uses a single standard to handle both • Must be general enough to express host requirements • But simple enough to implement cheaply • OpenFlow is destined to fail in both respects….. • MPLS split these two interfaces • Complex host-network interface at edge (full header) • Simple packet-switch interface in core (label)

43. From OpenFlow to Fabrics • Fabric: a unified set of forwarding elements that offers a delivery interface • Maps general headers to output port • Internal headers decoupled from external headers • Probably something MPLS-like • Edge of fabric can use software • Internally can use very simple hardware • Fabrics are now being used in datacenters…. • SDN should embrace them as internal forwarding model • With a more general mapping at edge

44. The Hope What are the larger implications of SDN?

45. Separating Control and Data Planes • Changes the deployment model • Can buy the control plane separately from the switches • Changes the business model • Commodity hardware • 3rd party control software • Changes the testing model • Unit test hardware • Simulator to analyze large-scale control planes • Changes balance of power between HW and SW

46. Networking is Now a Software Problem • Think of control plane as a program, not a protocol • We are programming the network, not designing it • Focus on modularity and abstractions, not packet headers • Open-source or proprietary, but notstandardized by IETF • Networking is now (largely) an edge problem • Core remains simple • Edge handles complexity • Software is fast enough at the edge (Open vSwitch) • Software lends itself to clean abstractions

47. Networking as an Academic Discipline • Clean abstractions lead to increased rigor • WAN extensions are an example • Networking can now become more of a science

48. GratopelaatençãoPerguntas?