Enabling Innovation Inside the Network

Joint with Nate Foster, David Walker, Rob Harrison, Chris Monsanto, Cole Schlesinger, Mike Freedman, Mark Reitblatt, Joshua Reich

Jennifer RexfordPrinceton University

http://www.cs.princeton.edu/~jrex

2

What is Networking?

end-hosts need to communicate

3

What is Networking?

Ethernet switches connect them

4

What is Networking?

which decide how packets should be forwarded

Control Plane

5

What is Networking?

and actually forward them

Data Plane

6

What is Networking?

7

What is Networking?

servers

8

What is Networking?

connected by routers

9

w/ similar data planes

What is Networking?

connected by routers

10

What is Networking?

connected by routers

but completely different control planes

plug-and-play

structured and optimized

11

What is Networking?

12

What is Networking?

we need gateway to bridge them

13

What is Networking?

and load balancing for servers

14

What is Networking?

there are other ISPs

15

What is Networking?

requiring inter-domain routers

16

What is Networking?

and a firewall to handle malicious

traffic

17

What is Networking?

and mobile endpoints

18

What is Networking?

requiring wireless basestations

19

What is Networking?

and more middleboxes for

billing, lawful intercept, DPI

20

What is Networking?

Ad absurdum

21

This is a Control Plane Issueeach color represents a different set of control-

plane protocols and algorithms

22

This is a Control Plane Issuewhose implementation

may vary by vendor and model

23

Software Defined Networks

24

decouple control and data planes

Software Defined Networks

25

decouple control and data planesby providing open standard API

Software Defined Networks

26

(Logically) Centralized Controller

Controller Platform

27

Protocols Applications

Controller PlatformController Application

28

Payoff

• Cheaper equipment• Faster innovation• Easier management

29

Entire backbone

runs OpenFlow

A Major Trend in Networking

Bought for $1.2 x 109

(mostly cash)

30

But How Should We Program SDNs?

Controller Platform

Controller ApplicationNetwork-wide visibility and control

Direct control via open interface

Today’s controller APIs are tied to the underlying hardware

OpenFlow Networks

31

Data Plane: 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

32

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

Control Plane: Programmability

33

Events from switchesTopology changes,Traffic statistics,Arriving packets

Commands to switches(Un)install rules,Query statistics,Send packets

Controller Platform

Controller Application

E.g.: Server Load Balancing• Pre-install load-balancing policy• Split traffic based on source IP

src=0*

src=1*

Seamless Mobility/Migration• See host sending traffic at new location• Modify rules to reroute the traffic

35

Programming Abstractions for Software Defined Networks

36

Network Control Loop

37

Readstate

OpenFlowSwitches

Writepolicy

Compute Policy

38

Reading State

SQL-Like Query Language

Reading State: Multiple Rules

• Traffic counters– Each rule counts bytes and packets– Controller can poll the counters

• Multiple rules– E.g., Web server traffic except for source 1.2.3.4

• Solution: predicates– E.g., (srcip != 1.2.3.4) && (srcport == 80)– Run-time system translates into switch patterns

39

1. srcip = 1.2.3.4, srcport = 802. srcport = 80

Reading State: Unfolding Rules

• Limited number of rules– Switches have limited space for rules– Cannot install all possible patterns

• Must add new rules as traffic arrives– E.g., histogram of traffic by IP address– … packet arrives from source 5.6.7.8

• Solution: dynamic unfolding– Programmer specifies GroupBy(srcip)– Run-time system dynamically adds rules

40

1. srcip = 1.2.3.41. srcip = 1.2.3.42. srcip = 5.6.7.8

Reading: Extra Unexpected Events

• Common programming idiom– First packet goes to the controller– Controller application installs rules

41

packets

Reading: Extra Unexpected Events

• More packets arrive before rules installed?– Multiple packets reach the controller

42

packets

Reading: Extra Unexpected Events

• Solution: suppress extra events– Programmer specifies “Limit(1)”– Run-time system hides the extra events

43

packets

not seen byapplication

Frenetic SQL-Like Query Language

• Get what you ask for– Nothing more, nothing less

• SQL-like query language– Familiar abstraction– Returns a stream– Intuitive cost model

• Minimize controller overhead– Filter using high-level patterns– Limit the # of values returned – Aggregate by #/size of packets

44

Select(bytes) *Where(in:2 & srcport:80) *GroupBy([dstmac]) *Every(60)

Select(packets) *GroupBy([srcmac]) *

SplitWhen([inport]) *Limit(1)

Learning Host Location

Traffic Monitoring

45

Computing Policy

Parallel and Sequential Composition

Abstract Topology Views

46

Combining Many Networking Tasks

Controller Platform

Monitor + Route + FW + LB

Monolithic application

Hard to program, test, debug, reuse, port, …

47

Modular Controller Applications

Controller Platform

LBRout

eMonit

orFW

Easier to program, test, and debugGreater reusability and portability

A module for each task

48

Modules Affect the Same Traffic

Controller Platform

LBRout

eMonit

orFW

How to combine modules into a complete application?

Each module partially specifies the handling of the traffic

49

Parallel Composition [ICFP’11, POPL’12]

Controller Platform

Route on dest

prefix

Monitor on source

IP+

dstip = 1.2/16 fwd(1)dstip = 3.4.5/24 fwd(2)

srcip = 5.6.7.8 countsrcip = 5.6.7.9 count

srcip = 5.6.7.8, dstip = 1.2/16 fwd(1), countsrcip = 5.6.7.8, dstip = 3.4.5/24 fwd(2), countsrcip = 5.6.7.9, dstip = 1.2/16 fwd(1), countsrcip = 5.6.7.9, dstip = 3.4.5/24 fwd(2), count

• Spread client traffic over server replicas– Public IP address for the service– Split traffic based on client IP– Rewrite the server IP address

• Then, route to the replica

Example: Server Load Balancer

clients

1.2.3.4

load balancer

server replicas

10.0.0.1

10.0.0.2

10.0.0.3

51

Sequential Composition [NSDI’13]

Controller Platform

RoutingLoad Balancer >>

dstip = 10.0.0.1 fwd(1)dstip = 10.0.0.2 fwd(2)

srcip = 0*, dstip=1.2.3.4 dstip=10.0.0.1srcip = 1*, dstip=1.2.3.4 dstip=10.0.0.2

srcip = 0*, dstip = 1.2.3.4 dstip = 10.0.0.1, fwd(1)srcip = 1*, dstip = 1.2.3.4 dstip = 10.0.0.2, fwd(2)

52

Dividing the Traffic Over Modules

• Predicates– Specify which traffic traverses which

modules– Based on input port and packet-header

fields

Routing

Load Balancer

Monitor

Routing

dstport != 80

dstport = 80 >>

+

53

High-Level Architecture

Controller Platform

M1 M2 M3Composition

Spec

54

Partially Specifying Functionality

• A module should not specify everything– Leave some flexibility to other modules– Avoid tying the module to a specific

setting

• Example: load balancer plus routing– Load balancer spreads traffic over

replicas– … without regard to the network paths

Load Balancer

Routing>>

Avoid custom interfaces between the modules

55

Abstract Topology Views [NSDI’13]

• Present abstract topology to the module– Implicitly encodes the constraints – Looks just like a normal network– Prevents the module from overstepping

55Real network Abstract view

56

Separation of Concerns

• Hide irrelevant details– Load balancer doesn’t see the internal

topology or any routing changes

Routing view Load-balancer view

57

High-Level Architecture

Controller Platform

View Definitions

M1 M2 M3Composition

Spec

58

Supporting Topology Views

• Virtual ports– (V, 1): [(P1,2)]– (V, 2): [(P2, 5)]

• Simple firewall policy– in=1 out=2

• Virtual headers– Push virtual ports– Route on these ports– From (P1,2) to (P2,5)

V1 2

firewall

routing

P1 P2

1 122

3 3

4

4

5

59

Writing State

Consistent Updates

Writing Policy: Avoiding Disruption

Invariants• No forwarding loops• No black holes• Access control• Traffic waypointing

Writing Policy: Path for New Flow

• Rules along a path installed out of order?– Packets reach a switch before the rules do

61Must think about all possible packet and event orderings.

packets

Writing Policy: Update Semantics

• Per-packet consistency– Every packet is processed by– … policy P1 or policy P2 – E.g., access control, no loops

or blackholes

• Per-flow consistency– Sets of related packets are processed by– … policy P1 or policy P2,– E.g., server load balancer, in-order delivery,

…

P1

P2

Writing Policy: Policy Update

• Simple abstraction– Update entire configuration at once

• Cheap verification– If P1 and P2 satisfy an invariant– Then the invariant always holds

• Run-time system handles the rest– Constructing schedule of low-level updates– Using only OpenFlow commands!

63

P1

P2

Writing Policy: Two-Phase Update

• Version numbers– Stamp packet with a version number (e.g., VLAN tag)

• Unobservable updates– Add rules for P2 in the interior– … matching on version # P2

• One-touch updates– Add rules to stamp packets

with version # P2 at the edge

• Remove old rules– Wait for some time, then

remove all version # P1 rules

64

Writing Policy: Optimizations

• Avoid two-phase update– Naïve version touches every switch– Doubles rule space requirements

• Limit scope – Portion of the traffic– Portion of the topology

• Simple policy changes– Strictly adds paths– Strictly removes paths 65

Frenetic Abstractions

66

SQL-likequeries

OpenFlowSwitches

ConsistentUpdates

Policy Composition

Related Work

• Programming languages– FRP: Yampa, FrTime, Flask, Nettle– Streaming: StreamIt, CQL, Esterel, Brooklet, GigaScope– Network protocols: NDLog

• OpenFlow– Language: FML, SNAC, Resonance– Controllers: ONIX, POX, Floodlight, Nettle, FlowVisor– Testing: NICE, FlowChecker, OF-Rewind, OFLOPS

• OpenFlow standardization– http://www.openflow.org/– https://www.opennetworking.org/

67

Conclusion

• SDN is exciting– Enables innovation– Simplifies management– Rethinks networking

• SDN is happening– Practice: useful APIs and good industry traction– Principles: start of higher-level abstractions

• Great research opportunity– Practical impact on future networks– Placing networking on a strong foundation

68

Frenetic Project

http://frenetic-lang.org

• Programming languages meets networking– Cornell: Nate Foster, Gun Sirer, Arjun Guha, Robert Soule,

Shrutarshi Basu, Mark Reitblatt, Alec Story

– Princeton: Dave Walker, Jen Rexford, Josh Reich, Rob Harrison, Chris Monsanto, Cole Schlesinger, Praveen Katta, Nayden Nedev

Short overview at http://www.cs.princeton.edu/~jrex/papers/frenetic12.pdf