Composing Software Defined
Networks
Jennifer Rexford
Princeton University
With Joshua Reich, Chris Monsanto, Nate Foster, & David Walker
Software Defined Networking (SDN)
Network-wide
visibility and
control
Controller Application
Controller Platform
Direct control via
open interface
But, how should we write controller applications?
2
Combining Many Networking Tasks
Monolithic
application
Route + Monitor + FW + LB
Controller Platform
Hard to program, test, debug, reuse, port, …
3
Modular Controller Applications
A module for
each task
Route
Monitor
FW
LB
Controller Platform
Easier to program, test, and debug
Greater reusability and portability
4
Beyond Multi-Tenancy
Each module controls a
different portion of the traffic
Slice 1
Slice 2
... Slice n
Controller Platform
Relatively easy to partition rule space, link
bandwidth, and network events across modules
5
Modules Affect the Same Traffic
Each module
partially specifies
the handling of
Monitor
the traffic
Route
FW
LB
Controller Platform
How to combine modules into a complete application?
6
Parallel Composition [ICFP’11, POPL’12]
srcip = 5.6.7.8  count
srcip = 5.6.7.9  count
dstip = 1.2/16  fwd(1)
dstip = 3.4.5/24  fwd(2)
Monitor on
source IP
+
Route on
dest prefix
Controller Platform
srcip = 5.6.7.8, dstip = 1.2/16  fwd(1), count
srcip = 5.6.7.8, dstip = 3.4.5/24  fwd(2), count
srcip = 5.6.7.9, dstip = 1.2/16  fwd(1), count
srcip = 5.6.7.9, dstip = 3.4.5/24  fwd(2), count
7
Example: Server Load Balancer
• Spread client traffic over server replicas
– Public IP address for the service
– Split traffic based on client IP
– Rewrite the server IP address
10.0.0.1
• Then, route to the replica
10.0.0.2
1.2.3.4
clients
load balancer
10.0.0.3
server replicas
Sequential Composition [new!]
srcip = 0*, dstip=1.2.3.4  dstip=10.0.0.1
srcip = 1*, dstip=1.2.3.4  dstip=10.0.0.2
Load
Balancer
>>
dstip = 10.0.0.1  fwd(1)
dstip = 10.0.0.2  fwd(2)
Routing
Controller Platform
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)
9
Sequential Composition: Gateway
• Left: learning switch on MAC addresses
• Middle: ARP on gateway, plus simple repeater
• Right: shortest-path forwarding on IP prefixes
10
Dividing the Traffic Over Modules
• Predicates
– Specify which traffic traverses which modules
– Based on input port and packet-header fields
dstport != 80
Monitor
+
Routing
dstport = 80
Load
Balancer
>>
Routing
11
High-Level Architecture
M1
M2
M3
Composition
Spec
Controller Platform
12
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
13
Avoid Custom Interfaces
• Each module generates a partial spec
– What it needs to see and control
– What it can leave unspecified
Load
Balancer
“I modify dstip but don’t
need to pick the path”
Routing
• Unwieldy solution
– New syntax and work for the programmer
– Complex interaction between modules
– Enforcement of “contract” by the controller
14
Abstract Topology Views
• Present abstract topology to the module
– Concise: implicitly encodes the constraints
– General: can represent a variety of constraints
– Intuitive: looks just like a normal network
– Safe: prevents the module from overstepping
Real network
Abstract view
15
Separation of Concerns
• Hide irrelevant details
– Load balancer doesn’t see the internal
topology or any routing changes
Routing view
Load-balancer view
16
High-Level Architecture
View
Definitions
M1
M2
M3
Composition
Spec
Controller Platform
17
Implementation Alternatives
• Option #1: virtualize the OpenFlow API
– Many API calls, few high-level constructs
– Modules map between topology views
– Nested virtualization becomes expensive
• Option #2: language-based solution
– High-level core language for writing modules
– High-level specification of network views
– Compiler performs syntactic transformations
18
Supporting Topology Views
• Virtual ports
1
– (V, 1): [(P1,2)]
– (V, 2): [(P2, 5)]
2
V
firewall
• Simple firewall policy
– in=1 out=2
• Virtual headers
– Push virtual ports
– Route on these ports
– From (P1,2) to (P2,5)
1
2
P1
3
1
4
2
P2
3
5
4
routing
19
Conclusions
• Modularity is crucial
– Ease of writing, testing, and debugging
– Separation of concerns, code reuse, portability
• Language abstractions
– Parallel and sequential composition
– Abstract topology views
– Virtual packet headers
• Ongoing work
– Prototype system and more applications
– Richer data-plane models (e.g., OpenFlow 1.3)
20
Frenetic Project
• 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
http://frenetic-lang.org
Short overview at http://www.cs.princeton.edu/~jrex/papers/frenetic12.pdf