Software Defined Networking

What is it, how does it work, and what is it good for?

Many slides stolen from Jennifer Rexford, Nick McKeown, Scott Shenker, Teemu Koponen, Yotam

Harchol and David Hay

Agenda

• What is Software Defined Networking (SDN)?

• What is OpenFlow? How does it work?

• Challenges en route to SDN

• Research directions

What is SDN?

The Internet: A Remarkable Story

• Tremendous success

– from research experiment to global infrastructure

• Enables innovation in applications

– Web, P2P, VoIP, social networks, virtual worlds

• But, the Internet’s infrastructure remained fairly stagnant for decades

The Internet’s Landscape

Applications:

Internet Protocols:

routing, congestion control, naming, …

(TCP/IP, BGP, DNS, OSPF, ECMP,…)

Technologies:

constant innovation

stagnant!

constant innovation

Why Can’t We Innovate?

• Closed equipment

– software bundled with hardware

– vendor-specific interfaces

• Over specified

– slow protocol standardization

• Few people can innovate

– equipment vendors write the code

– long delays to introduce new features

Impacts performance, security, reliability, cost…

Networks are Hard to Manage

• Operating a network is expensive

– more than half the cost of a network

– yet, operator error causes most outages

• Buggy software in the equipment

– routers with 20+ million lines of code

– cascading failures, vulnerabilities, etc.

• The network is “in the way”

– especially a problem in data centers

– … and home networks

Traditional Computer Networks

Data plane: packet

streaming

forward, filter, buffer, mark, rate-limit, and measure packets

Traditional Computer Networks

track topology changes, compute routes, install forwarding rules

Control plane: distributed algorithms

Traditional Computer Networks

collect measurements and configure the equipment

Management plane: human time scale

New Paradigm: Software Defined Networking (SDN)

API to the data plane (e.g., OpenFlow)

logically-centralized control

switches

smart, slow

dumb, fast

A Helpful Analogy

12

vertically integrated closed, proprietary

slow innovation small industry

Specialized Operating System

Specialized Hardware

App App App App App App App App App App App

Specialized Applications

horizontal open interfaces rapid innovation huge industry

Microprocessor

Open Interface

Linux Mac OS

Windows (OS) or or

Open Interface

Mainframes

vertically integrated closed, proprietary

slow innovation

App App App App App App App App App App App

horizontal open interfaces rapid innovation

Control Plane

Control Plane

Control Plane

or or

Open Interface

Specialized Control Plane

Specialized Hardware

Specialized Features

Merchant Switching Chips

Open Interface

Routers/Switches

How SDN works

The OpenFlow protocol

15

OpenFlow Switch

Flow Table

Secure Channel

PC

hw

sw

OpenFlow Switch specification

OpenFlow Switching

Controller

Controller: Programmability

17

Network OS

Controller Application

events from switches topology changes, traffic statistics, arriving packets

commands to switches (un)install rules, query statistics,

send packets

Reactive vs. Proactive

• Reactive SDN: switches send (first) packets to controller, then controller programs switch's flow table to handle rest of the flow

– Problem: source of DoS on controller (packet-in event)

• Proactive SDN: Controller programs the switches proactively, according to its own knowledge of the network

– Requires smarter approaches than just reacting to network events (global knowledge, discovery, updates…)

Flow Table Entry at Switch “Type 0” OpenFlow Switch

Switch Port

MAC src

MAC dst

Eth type

VLAN ID

IP Src

IP Dst

IP Prot

TCP sport

TCP dport

Rule Action Stats

1. Forward packet to port(s) 2. Encapsulate and forward to controller

3. Drop packet 4. Send to normal processing pipeline

+ mask

Packet + byte counters

Data-Plane: Simple Packet Handling

• Simple packet-handling rules

– Pattern: match packet header bits

– Actions: drop, forward, modify, send to controller

– Priority: disambiguate overlapping patterns

– Counters: #bytes and #packets

1. src=1.2.*.*, dest=3.4.5.* drop 2. src = *.*.*.*, dest=3.4.*.* forward(2) 3. src=10.1.2.3, dest=*.*.*.* send to

controller

OpenFlow

• Definition in progress

• Additional actions

rewrite headers

map to queue/class

encrypt

• More flexible header

allow arbitrary matching of first few bytes

• Support multiple controllers

load-balancing and reliability

Example OpenFlow Applications

• Dynamic access control

• Seamless mobility/migration

• Server load balancing

• Network virtualization

• Using multiple wireless access points

• Energy-efficient networking

• Adaptive traffic monitoring

• Denial-of-Service attack detection

See http://www.openflow.org/videos/

E.g.: Dynamic Access Control

• Inspect first packet of a connection

• Consult the access control policy

• Install rules to block or route traffic

E.g.: Seamless Mobility/Migration

• See host send traffic at new location

• Modify rules to reroute the traffic

E.g.: Server Load Balancing

• Pre-install load-balancing policy

• Split traffic based on source IP

25

src=0*

src=1*

In-depth Example: Simple Repeater

• Simple Network Repeater

– forward packets received on port 1 out 2 and vice versa 26

1 2

Controller

Switch

Simple Repeater

Priority Pattern Action Counters

DEFAULT IN_PORT:1 OUTPUT:2 (0,0)

DEFAULT IN_PORT:2 OUTPUT:1 (0,0)

27

def handle_packetIn(packet): out_port = 2 if packet.in_port == 2: out_port = 1 flow_mod = ofp_flow_mod() flow_mod.match = ofp_match() flow_mod.match.in_port = \ packet.in_port action = ofp_action_output() action.out_port = out_port flow_mod.action = [ action ] flow_mod.buffer_id = \ packet.buffer_id send(flow_mod)

Controller (POX) (Pseudo)-Program

Flow Table

1 2

Controller

Switch

OpenFlow in the Wild

• Open Networking Foundation

– Google, Facebook, Microsoft, Yahoo, Verizon, Deutsche Telekom, and many other companies

• Commercial OpenFlow switches

– HP, NEC, Quanta, Dell, IBM, Juniper, …

• Network operating systems

– NOX, Beacon, Floodlight, POX, …

• Network deployments

– Campuses, research backbone networks

– Commercial deployments (e.g., Google backbone)

But… Heterogeneous Switches

• Number of packet-handling rules (TCAM/memory limits)

• Different OpenFlow version support

• Range of matches and actions (not all matches and actions are mandatory in the protocol)

• Multi-stage pipeline of packet processing (allowed but not defined in the standard)

• Vendor-specific features

• Offload some control-plane functionality (?)

29

access control

MAC look-up

IP look-up

SDN or OpenFlow?

• OpenFlow is not being adapted as-is

• Major vendors either completely discard OpenFlow or use a massively changed variant

• Doing that requires having the ability to change the protocol on both sides (controller + switch)

• Is OpenFlow dead?

30

Challenges

31

Controller Delay and Overhead

• Controller is much slower the the switch

• Processing packets leads to delay and overhead

• Need to keep most packets in the “fast path”

32

packets

Distributed Controller

33

Network OS

Controller Application

Network OS

Controller Application

For scalability and reliability

Partition and replicate state

… and: where to put the controller(s)?

Taking into account latency, resiliency, load balancing...

Testing and Debugging

• OpenFlow makes programming possible

– Network-wide view at controller

– Direct control over data plane

• Plenty of room for bugs

– Still a complex, distributed system

• Need for testing techniques

– Controller applications

– Controller and switches

– Rules installed in the switches 34

Programming Abstractions

• Controller APIs are low-level

– Thin veneer on the underlying hardware

• Need better languages

– Composition of modules

– Managing concurrency

– Querying network state

– Network-wide abstractions

• Example:

– http://www.frenetic-lang.org/

35

Controller

Switches

MiniNet

36

MiniNet

• Creates scalable SDN (up to hundreds of nodes) using OpenFlow, on a single PC

• Allows to quickly create, interact with and customize a SDN prototype with complex topologies, and can be used to emulate real networks – all on your PC

• Can work with any kind of OpenFlow controller

• Takes seconds to install

• Easy to program

• Of course, is an open source project

37

MiniNet

• Not only for teaching purposes!

• Used for the development and testing of networks

38

Innovating with SDN

Dealing with Large Tables

Palette: Distributing Tables in Software Defined Networks

Y. Kanizo, D. Hay and I. Keslassy

Access Control in SDN

• Consider the following network.

– Table at each ingress point

Ingress points hold (too) large tables

41

How to Solve this Problem?

Idea: Distribute the rules among all switches such that each packet goes through all rules along its path.

42

Palette: Step I

Split the large (TCAM) table into smaller tables

– identify each smaller table with a unique colour

43

Assign at most a single colour to each switch s.t. every packet-forwarding path is a “rainbow path”

Palette: Step II

Algorithmic Challenges

• Maximizing the number of colours (smaller tables), k

• Splitting the large (TCAM) table into k smaller tables

– so as to minimize the size of the largest table

• http://webee.technion.ac.il/~isaac/p/tr12-05_palette.pdf

Rethinking (Routing) Protocols

On the Resilience of Routing Tables:

J. Feigenbaum, P. B. Godfrey, A. Panda, M. Schapira, S. Shenker, and A. Singla

Motivation

d

Motivation

d

Routes computed by, say, shortest paths routing alg

Motivation

i d X

forwarding path? No!

Pack

et

• Routing is a control plane operation

– slow (ms – s)

• Packet forwarding is a data plane operation

– fast (μs)

• Today’s routing protocols

1. establish connectivity

2. optimize routes (= shortest paths)

• failure ⇒ re-convergence ⇒ dropped packets!

Routing: Data vs. Control Plane

How to Solve this Problem?

Idea: Push (only!) connectivity to the data plane

– immediately react to failures

– optimize routes on a longer time scale

51

Forwarding Model

• Packet for node d arrives at node i

i d

• Outgoing edge is a function of

- set of live edges

- incoming edge

fid: Ei x P(Ei) -> Ei

• Forwarding is t-resilient iff for any (at most) t edge failures:

– existence of path from i to d ⇒ loop-free forwarding from to d

• Perfect resilience ≣ t →∞

Resilient Forwarding

Big Gap!

Thm: Cannot always provide perfect resilience

Thm: Can always protect against one failure

What Next?

• Conditions for k-resilience?

– restricted failure models?

• Resilience for specific families of graphs?

• Randomized forwarding rules?

• ... ?

Full paper available online as YALE/DCS/TR1454 See also [Liu-Panda-Singla-Godfrey-S-Shenker, NSDI 2013]

Conclusion

• SDN is revolutionizing networking

• Rethinking networking

– open interfaces to the data plane

– separation of control and data

– leveraging techniques from distributed systems

• Significant momentum, many challenges

– in both research and industry 56

Thank You