Frenetic: Programming Software Defined Networks

Jennifer Rexford

Princeton University

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

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

Software Defined Networking (SDN)

2

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

Logically-centralized control

Switches

Smart,slow

Dumb,fast

Programming OpenFlow Networks

3

Images by Billy Perkins

• The Good– Simple data plane abstraction– Logically-centralized architecture– Direct control over switch policies

• The Bad– Low-level programming interface– Functionality tied to hardware– Explicit resource control

• The Ugly– Non-modular, non-compositional– Programmer faced with challenging

distributed programming problem

Language-Based Abstractions

• Benefits– Modularity– Portability– Efficiency– Assurance– Simplicity

Simple, high-level abstractions are crucial for achieving the vision of software-defined networking.

OpenFlow Networks

5

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

6

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

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

Controller: Programmability

7

Network OS

Application

Events from switchesTopology changes,

Traffic statistics,Arriving packets

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

Send packets

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

9

Programming Abstractions for Software Defined Networks

10

Three Main Abstractions

11

Reading state

OpenFlowSwitches

Writingpolicies

Composing modules

Reading State: Multiple Rules

• Traffic counters– Switch counts bytes and packets matching a rule– Controller application polls 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

12

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

13

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

14

packets

Reading: Extra Unexpected Events

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

15

packets

Reading: Extra Unexpected Events

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

16

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

17

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

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

Limit(1)

Learning Host Location

Traffic Monitoring

Composition: Multiple Modules

• Networks have multiple policies–Routing–Traffic monitoring–Access control

• Challenges–Common set of rules in the switches–Processing the same packets

• OpenFlow API is not modular–Programmer must combine the logic

18

Composition: Simple Repeater

def switch_join(switch): # Repeat Port 1 to Port 2 p1 = {in:1} a1 = [out:2] install(switch, p1, DEFAULT, a1) # Repeat Port 2 to Port 1 p2 = {in:2} a2 = [out:2] install(switch, p2, DEFAULT, a2)

def switch_join(switch): # Repeat Port 1 to Port 2 p1 = {in:1} a1 = [out:2] install(switch, p1, DEFAULT, a1) # Repeat Port 2 to Port 1 p2 = {in:2} a2 = [out:2] install(switch, p2, DEFAULT, a2)

Simple Repeater

1 2

Controller

When a switch joins the network, install two forwarding rules.

Composition: Web Traffic Monitor

20

def switch_join(switch)): # Web traffic from Internet p = {in:2, srcport:80} install(switch, p, DEFAULT, []) query_stats(switch, p) def stats_in(switch, p, bytes, …) print bytes sleep(30) query_stats(switch, p)

def switch_join(switch)): # Web traffic from Internet p = {in:2, srcport:80} install(switch, p, DEFAULT, []) query_stats(switch, p) def stats_in(switch, p, bytes, …) print bytes sleep(30) query_stats(switch, p)

Monitor “port 80” traffic

1 2

Web traffic

When a switch joins the network, install one monitoring rule.

Composition: Repeater + Monitor

def switch_join(switch): pat1 = {in:1} pat2 = {in:2} pat2web = {inport:2, srcport:80} install(switch, pat1, DEFAULT, None, [out:2]) install(switch, pat2web, HIGH, None, [out:1]) install(switch, pat2, DEFAULT, None, [out:1]) query_stats(switch, pat2web)

def stats_in(switch, xid, pattern, packets, bytes): print bytes sleep(30) query_stats(switch, pattern)

def switch_join(switch): pat1 = {in:1} pat2 = {in:2} pat2web = {inport:2, srcport:80} install(switch, pat1, DEFAULT, None, [out:2]) install(switch, pat2web, HIGH, None, [out:1]) install(switch, pat2, DEFAULT, None, [out:1]) query_stats(switch, pat2web)

def stats_in(switch, xid, pattern, packets, bytes): print bytes sleep(30) query_stats(switch, pattern)

Repeater + Monitor

Must think about both tasks at the same time.

Composition: Frenetic is Modular

22

# Static repeating between ports 1 and 2def repeater(): rules=[Rule(in:1, [out:2]), Rule(in:2, [out:1])] register(rules)

# Static repeating between ports 1 and 2def repeater(): rules=[Rule(in:1, [out:2]), Rule(in:2, [out:1])] register(rules)

# Monitoring Web trafficdef web_monitor(): q = (Select(bytes) * Where(in:2 & srcport:80) * Every(30)) q >> Print()

# Monitoring Web trafficdef web_monitor(): q = (Select(bytes) * Where(in:2 & srcport:80) * Every(30)) q >> Print()

# Composition of two separate modulesdef main(): repeater() web_monitor()

# Composition of two separate modulesdef main(): repeater() web_monitor()

Repeater

Monitor

Repeater + Monitor

Composition: Reactive Run-Time

• Microflow-based– Send first packet to

the controller– Install rule if possible

• Check all policies– Accumulate actions to

perform on packet

• Check all queries– If no matches: install a

rule to handle remaining packets of the flow

23

Composition: Proactive [POPL’12]

• Proactive, wildcard rules– Keep packets in the “fast path”

• “Cross-product” of predicates

• Translate predicates into rules– Convert each predicate to one or more rules– Minimize to produce a smaller set of rules

• Reactive specialization– Dynamically expanding the policy as packets arrive 24

in:1in:2*

in:2 & srcport=80*

X

in:1in:2 & srcport=80in:2*

=

Writing Policy: Avoiding Disruption

Writing Policy: Avoiding Disruption

Reasons• Routine maintenance• Unexpected failure• Traffic engineering• Fine-grained security

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

Writing Policy: Traffic Engineering

• Shortest-path routing–Controller computes shortest paths–… based on preconfigured link weights

27

1

1

3

1

1

Writing Policy: Traffic Engineering

• Transient loop–Update top switch to forward down–… while bottom switch still forwards up

28

1 5

1

3

1

1

Writing Policy: Path for a New Flow

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

29Must 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 during routing change

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

P1

P2

Writing Policy: Policy Update

• Simple abstraction– Update the entire configuration at once– E.g., per_packet_update(P2)

• 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– Applying optimizations to limit the number of rules– Using only OpenFlow commands!

31

P1

P2

Writing Policy: Two-Phase Commit

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

Writing Policy: Optimizations

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

• Limit scope of two-phase commit– Affects only a portion of the traffic– Affects only a portion of the topology

• Simple policy changes– Extension: strictly adds paths– Retraction: strictly removes paths

• Run-time system applies optimizations33

Frenetic Abstractions

34

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, Nettle, FlowVisor, RouteFlow– Testing: MiniNet, NICE, FlowChecker, OF-Rewind,

OFLOPS

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

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 36

Thanks to My Frenetic Collaborators

37

Nate Foster Dave Walker Chris Monsanto Mark Reitblatt

Mike FreedmanRob Harrison Alec Story Josh Reich