Presentation on theme: "1 Software Defined Networks: History, Hype, and Hope Scott Shenker with Martín Casado, Teemu Koponen, Nick McKeown (and many others….)"— Presentation transcript:
1 Software Defined Networks: History, Hype, and Hope Scott Shenker with Martín Casado, Teemu Koponen, 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 Best-effort global packet delivery Best-effort local packet delivery 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 hoc control mechanisms is over -So how do you “extract simplicity”?
16 An Example Transition: 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 1. Operate without communication guarantees Need an abstraction for distributed state 2. Compute the configuration of each physical device Need an abstraction that simplifies configuration 3. 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: abstract view 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 Global Network View Abstract Network View A B A 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: Design details concern exact nature of: -Header matching -Allowed actions
27 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? My Talk in One Sentence
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 Control Program Software Defined Network (SDN) Network OS Global Network View Traditional Control Mechanisms Network of Switches and/or Routers Distributed algorithm running between neighbors Complicated task-specific distributed algorithm e.g. routing, access control
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 Network OS Global Network View Abstract Network View Control Program Network Virtualization Software Defined Network
32 Simple Example: Access Control Global Network View Abstract Network View A B A B
33 Network OS Global Network View Abstract Network View Control Program Network Virtualization Software Defined Network
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 -3 rd 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 not standardized 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