1

Software Defined Networks:

History, Hype, and Hope

Scott Shenkerwith 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…

…built on…

…built on…

…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

GlobalNetwork View

Abstract NetworkView

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: <header, action>

• 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 MechanismsNetwork of Switches and/or Routers

Distributed algorithm running between neighborsComplicated 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 ProgramNetwork Virtualization

Software Defined Network

32

Simple Example: Access Control

GlobalNetwork View

Abstract NetworkView

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- 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 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

48

Grato pela atenção

Perguntas?