Software Defined Networking
COMS 6998-10, Fall 2014
Instructor: Li Erran Li
(lierranli@cs.columbia.edu)
http://www.cs.columbia.edu/~lierranli/coms
6998-10SDNFall2014/
9/29/2014: SDN Programming Language
Outline
• Announcements
– Homework 2 will be posted on Thursday, due in 18
days
• Review of previous lecture
• Project ideas on scalable controller for cellular
WAN
• SDN programming language
– Maple: generic programming language syntax such as
Java, Python
– NetKAT: domain specific programming language
9/29/14
Software Defined Networking (COMS 6998-10)
2
Review of Previous Lecture
• How do we design scalable software defined
networks?
– Design scalable controllers
– Offload control plane processing to switches
• How do we design scalable controllers?
– Flat structure multiple controllers
– Recursive controller design
– Hierarchical controller design
9/29/14
Software Defined Networking (COMS 6998-10)
3
Review of Previous Lecture (Cont’d)
• How to offload control plane processing to
switches?
– Offload to switch control plane
• Controller proactively generates the rules and distributes
them to authority switches
• Authority switches keep packets always in the data plane
and ingress switches reactively cache rules
– Offload to switch data plane
• Try to stay in data-plane, by default
• Provide enough visibility: for significant flows & sec-sensitive
flows; Otherwise, aggregate or approximate statistics
9/29/14
Software Defined Networking (COMS 6998-10)
4
Review of Previous Lecture (Cont’d)
How do we divide tasks among controller
instances?
• Partition
– Controller instances with different computations tasks
– Controller instances have only subsets of the NIB
– Switches connect to a subset of controller instances
• Aggregation
– Reduce fidelity of information
9/29/14
Software Defined Networking (COMS 6998-10)
5
Review of Previous Lecture (Cont’d)
• How to maintain network information base
(NIB)?
– Replicated transactions (SQL) storage for strong
consistency (more static information)
– One-hop memory-based DHT for weak
consistency (more dynamic information)
9/29/14
Software Defined Networking (COMS 6998-10)
6
Review of Previous Lecture (Cont’d)
Authority
Switch
Ingress
Switch
Egress
Switch
First packet
Following
packets
Hit cached rules and forward
Offload to switch control plane
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Minlan Yu
7
Review of Previous Lecture (Cont’d)
• Rule cloning
– ASIC clones a wildcard rule as an exact match rule for new
microflows
– Timeout or output port by probability
9/29/14
Software Defined Networking (COMS 6998-10)
8
Review of Previous Lecture (Cont’d)
• Rule cloning
– ASIC clones a wildcard rule as an exact match rule for new
microflows
– Timeout or output port by probability
9/29/14
Software Defined Networking (COMS 6998-10)
9
Review of Previous Lecture (Cont’d)
• Rule cloning
– ASIC clones a wildcard rule as an exact match rule for new
microflows
– Timeout or output port by probability
9/29/14
Software Defined Networking (COMS 6998-10)
10
Review of Previous Lecture (Cont’d)
• Local actions
– Rapid re-routing: fallback paths predefined
Recover almost immediately
– Multipath support: based on probability dist.
Adjusted by link capacity or loads
9/29/14
Software Defined Networking (COMS 6998-10)
11
Outline
• Announcements
– Homework 2 will be posted on Thursday, due in 18
days
• Review of previous lecture
• Project ideas on scalable controller for cellular
WAN
• SDN programming language
– Maple: generic programming language syntax such as
Java, Python
– Frenetic: domain specific programming language
9/29/14
Software Defined Networking (COMS 6998-10)
12
LTE Cellular Network Architecture
Base Station (BS)
Serving Gateway
Packet Data
Network Gateway
Serving Gateway
Internet
User Equipment (UE)
9/29/14
access
core
Software Defined Networking (COMS 6998-10)
13
Current Mobile WANs
• Organized into rigid and very large regions
• Minimal interactions among regions
• Centralized policy enforcement at PGWs
Two Regions
9/29/14
Software Defined Networking (COMS 6998-10)
14
Mobile WANs Problems
• Suboptimal routing in large carriers
– Lack of sufficiently close PGW is a major cause
of path inflation
• Scalability and reliability
– The sheer amount of traffic and centralized
policy enforcement
• Ill-suited to adapt to the rise of new
applications
– E.g., machine-to-machine
– All users’ outgoing traffic traverses a PGW to
the Internet, even for reaching a user served by
a close base station in a neighbor region
9/29/14
Software Defined Networking (COMS 6998-10)
15
SoftMoW Motivation
Question: How to make the packet core scalable, simple,
and flexible for hundreds of thousands of base stations and
hundreds of millions of mobile users?
• Mobile networks should have fully connected core
topology, small logical regions, and more egress points
• Operators should leverage SDN to manage the whole
network with a logically-centralized controller:
– Directs traffic through efficient network paths that
might cross region boundaries
– Handles high amount of intra-region signaling load
from mobile users
– Supports seamless inter-region mobility and
optimizes its performance
– Performs network-wide application-based such as
region optimization
9/29/14
Software Defined Networking (COMS 6998-10)
16
SoftMoW Solution
• Hierarchically builds up a network-wide control plane
– Lies in the family of recursive SDN designs (e.g. XBAR,
ONS’13)
• In each level, abstracts both control and data planes
and exposes a set of “dynamically-defined” logical
components to the control plane of the level above.
– Virtual Base stations (VBS), Gigantic Switches (GS),
and Virtual Middleboxes (VMB)
Latency
Matrix
Union of
Coverage
Sum of
capacities
VBS
GS
VMB
Core Net
9/29/14
RadioAccess
Network
Software Defined Networking (COMS 6998-10)
Policy
17
SoftMoW Solution
• New Dynamic Feature: In each level, the
control logic can modify its logical
components for optimization purposes
– E.g., merge/spilt and move operations
GSW2
GSW1
VBS1
GSW1
VBS1
VBS2
GSW1
GSW3
Merge/Split
9/29/14
GSW2
VBS2
VBS3
GSW2
Move and Split
Software Defined Networking (COMS 6998-10)
VBS3
18
First Level-SoftMoW Architecture
• Replace inflexible and expensive hardware devices (i.e.,
PGW, SGW) with SDN switches
• Perform distributed policy enforcement using middle-box
instances
• Partition the network into independent and dynamic logical
regions
• A child controller manages the data plane of each regions
Events GS Rules &
Actions
Bootstrapping
phase:
based on location
and processing
capabilities of child
controllers
Agent A
Child A
NIB
E2
E3
Boundary
M
1
Region A
E1
M
M
9/29/14
Local
Apps
M
2
4
BS1
M
BS
3
5
M
6
Region B
I1
7
9
BS4
E4
M
M
8
M
10
BS5
2 BSNetworking
Software Defined
(COMS 6998-10)
3
M
BS6
19
Second Level-SoftMoW Architecture
• A parent runs a global link discovery protocol
– Inter-region links are not detected by BDDP and LLDP
• A parent participates in the inter-domain routing protocol
• A parent builds virtual middlebox chains and egresspoint policies, and dictates to GSs
Events GS Rules &
Actions
Agent A
I-Mobility
Manager
Local
Apps
Middlebox Egress
Optimizer Selection
Child A
NIB
E2
E3
Boundary
M 1
Region A
E1
M 3
M 2
M
4
BS19/29/14
6
Region B
I1
7
M
E4
8
M
GS
Protocol
E1
M
9
5
BS2
BS3
10
M
E2
E3
E4
-----
M M
M M
M
BGP
sessions
Parent
NIB
M
Region
Optimizer
2M M
BS4
BS5 BS6
Internal
Software Defined Networking (COMS 6998-10)
VBS1
GSA
Border
VBS
1
I1
GSB
2M M
Border Internal
VBS
2 VBS2
20
Hierarchical Traffic Engineering
• A parent pushes a global label into each traffic group
• Child controllers perform label swapping
o Ingress point: pop the global label and push some local labels for intraregion paths
Events GS Rules &
o Egress point: pop the local labels and push back
the global label
Actions
Push W
I-Mobility
Manager
Middlebox
Optimizer
Agent A
Egress
Selection
Region
Optimizer
Parent
NIB
GS
Protocol
E1
E2
E3
2M M
Latency
(P1,E2)=300
Latency
(P1,E4)=100
GSA
Internal
VBS1
Push W
9/29/14
Border
VBS
1
I1
E2
GSB
E3
Boundary
M 1
Region A
E1
E4
M M
M M
Child A
NIB
Pop W2
Push W
-----
Web
Voice
BGP
sessions
Local
Apps
Pop W1
M 2
Region B
I1
M 3
M
6
7
E4
M
8
M
2M M
GS
Rules
Border Internal
VBS
VBS2
2
M
4
BS1
Pop W
Push W1
Software Defined Networking (COMS 6998-10)
M
5
BS2
Pop W
9
BS3
BS4
M
M
10
BS5
BS6
Push W2
21
Time-of-day Handover Optimization
Q: How can an operator reduce inter-region
handovers in peak
E
A
M
GSA
M M
VBS1
VBS1
VBS2
Border
VBS2
Abstraction update
coordination
Child A
E2
Parent
E3
E4
Child B
E3
Boundary
M
M 1
Region A
E1
E2
Internal
VBS2
VBS2
Handover graph
E1
3M M
GSB
Border
VBS
1
Min Cut
300 Border 1000 Border 2000 Internal
Internal
E4
M 2M
E3
E2
1
hours?
GS
M 2
Region B
I1
M 3
6
7
M
8
M
M M
M M
2M M
GSA
I1
GSB
2M M
GS Rule:
Move Border VBS1
M
4
M
BS1
Internal
VBS1
Border
Border Internal
9/29/14
VBS1
VBS2 VBS
2
New
Software Defined Networking (COMS 6998-10)
Border
9
5
BS2
BS3
Old
Border
BS4
M
M
10
BS5
BS6
22
Project Ideas
• Implement a G-switch driver/agent: acts as a
shim to allow a G-switch to act like an actual OF
switch.
– This driver helps to connect any OF controller as a Gswitch to its parent OF controller. In this way, installing
rule-actions into G-switches and setting up paths on
abstract topology becomes like the physical topology.
– Driver should translate the messages or states received
from the parent OF controller to the underlying topology
and periodically pulls states from the local NIB to
expose to the parent.
• Implement HazelCast on a single controller
– Show performance improvement on various
applications such as traffic engineering, routing, and
9/29/14
Defined
Networking
(COMS 6998-10) in-memory data
failure
recoverySoftware
over
the
standard
23
Project Ideas (Cont’d)
• Implement recursive link discovery protocol and the
necessary translations in the shim.
• Implement RamCloud on a single controller
– Show performance improvement on various
applications such as traffic engineering, routing, and
failure recovery compared with the standard NIB.
• Implement an orchestration layer to provide
global network view
– Use ZooKeeper to dynamically assign controllers to
data plane switches as the network becomes larger on
top of a single/flat controller.
• Implement the hierarchical control plane
9/29/14
Software Defined Networking (COMS 6998-10)
24
Outline
• Announcements
– Homework 2 will be posted on Thursday, due in 18
days
• Review of previous lecture
• Project ideas on scalable controller for cellular
WAN
• SDN programming language
– Maple: generic programming language syntax such as
Java, Python
– Frenetic: domain specific programming language
9/29/14
Software Defined Networking (COMS 6998-10)
25
A Key Source of Complexity in
Openflow Controllers
• onPacketIn(p):
Step 1
examine p and decide what to do with p.
Step 2
construct and install OF rules so that similar packets are
processed at switches with same action.
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Andreas Voellmy, Yale
26
Simple, generic solution using exact
matches
• onPacketIn(p):
Step 1
Every flow incurs flow setup delay.
examine p and decide what to do with p.
Step 2
insert rule with “exact match” for p, i.e. match on ALL
attributes, with action determined above.
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Andreas Voellmy, Yale
27
Step 1
yes
Step 2
match:{TcpDst=22} action:drop
drop
priority:HIGH
p.TcpDst=22
?
tcpDst!=22
no
9/29/14
send to next hop for
p.EthDst
match:{EthDst=p.EthDst}
action:nextHop(p)
Software Defined Networking (COMS 6998-10)
priority:LOW
Source: Andreas Voellmy, Yale
28
Switch
Low
EthDst:A
EthDst:A
,
TcpDst:8
0
Port 1
EthDst:A
,
TcpDst:2
2
Controller
If p.TcpDst=22:
insert rule
{prio:HIGH, match:{TcpDst=22}, action:drop }
Else:
insert rule
{prio:LOW, match:{EthDst=p.EthDst},action:nextHop(p.EthDst)
9/29/14
Software Defined Networking (COMS 6998-10)
29
Step 1. Make Decisions
User Level
Step 2. Generate Rules
OF Controller Library
Under the hood
OF Switches
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Andreas Voellmy, Yale
30
User Level
Algorithmic
Policy
Step
1. Make Decisions
Step 2. Generate Rules
Under the hood
OF Controller Library
OF Switches
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Andreas Voellmy, Yale
31
Algorithmic Policies
• Function in a general purpose language that describes
how a packet should be routed, not how flow tables are
configured.
• Conceptually invoked on every packet entering the
network; may also access network environment state;
hence it has the form:
• Written in a familiar language such as Java, Python, or
Haskell
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Andreas Voellmy, Yale
32
Example Algorithmic Policy in Java
Does not specify flow
table configutation
Route f(Packet p, Env e) {
if (p.tcpDstIs(22))
return null();
else {
Location sloc = e.location(p.ethSrc());
Location dloc = e.location(p.ethDst());
Path path = shortestPath(e.links(), sloc,dloc);
if (p.ethDstIs(2) return null();
else return unicast(sloc,dloc,path);
}
}
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Andreas Voellmy, Yale
33
How to implement algorithmic
policies?
• Naive solutions -- process every packet at controller
or use only exact match rules -- perform poorly
• Static analysis to determine layout of flow tables is
possible, but has drawbacks:
– Static analysis of program in general-purpose
language is hard and is typically conservative
– System becomes source-language dependent
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Andreas Voellmy, Yale
34
Maple’s approach: runtime tracing
1. Maple observes the
dependency of f on packet
data.
3. Compile flow tables
(FTs) from a trace tree.
Match
Action
1
tcpDst:22
ToControlle
r
Prio 0
1
0
0
9/29/14
Prio
Match
Action
ethDst:2
discard
Prio
Match
ToControlle
0
ethDst:4, ethSrc:6
port 30
tcpDst:22
r
1
tcpDst:22
ethDst:2
discard
0
ethDst:2
ethDst:4, ethSrc:6
port 30
0
ethDst:4, ethSrc:6
2. Build a trace tree (TT),
a partial decision tree for
f.
Action
ToControlle
r
discard
port 30
Software Defined Networking (COMS 6998-10)
Source: Andreas Voellmy, Yale
35
Policy
Route f(Packet p, Env e) {
if (p.tcpDstIs(22))
Assert(TcpDst,
22)
EthDest:1,
TcpDst:80
return null();
false
else {
Location dloc =
e.location(p.ethDst());
Read(EthD
st)
Location sloc =
e.location(p.ethSrc());
Path path =
shortestPath(
e.links(),sloc,dloc);
if (p.ethDstIs(2)
return null();
else
return unicast(sloc,dloc,path);
4
Read(EthSr
c)
6
path1
}
}
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Andreas Voellmy, Yale
36
Trace Tree
Policy
Route f(Packet p, Env e) {
Assert(TcpDst
,22)
if (p.tcpDstIs(22))
return null();
EthDst:1,
TcpDst:2
2
Assert(TcpDst,
22)
true
null
true
else {
Location dloc =
e.location(p.ethDst());
Location sloc =
e.location(p.ethSrc());
?
false
Read(EthD
st)
Path path =
shortestPath(
e.links(),sloc,dloc);
4
Read(EthSr
c)
if (p.ethDstIs(2)
return null();
else
return unicast(sloc,dloc,path);
6
}
path1
}
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Andreas Voellmy, Yale
37
Compile recorded executions into flow
table
tcpDst==2
2
3
True
1
False
2
drop
ethDst
4
2
drop
ethSrc
6
port 30
barrier rule:
match:{ethDst:4,ethSrc:6}
match:{tcpDst==22}
action:[port 30]
action:ToController
Priority
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Andreas Voellmy, Yale
38
Basic compilation: in-order traversal &
barrier rules
tcpDst==2
2
Priority := 0
1
2
3
accumulated
match: {}
False
True
{tcpDst:22}
ethDst
null
2
{ethDst:2}
null
(prio:3,{tcpDst:22},action:drop)
{}
4
ethSrc
{ethDst:4}
6
barrier rule:
(prio:2,{tcpDst:22},action:ToController)
port 30
{ethDst:4,
ethSrc:6}
(prio:1,{ethDst:2},action:drop)
(prio:0,{ethDst:4, ethSrc:6},action:[port 30])
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Andreas Voellmy, Yale
39
Basic compilation example result
(prio:3,{tcpDst:22},action:drop)
(prio:2,{tcpDst:22},action:ToController)
Can use priority 0
No effect
(prio:1,{ethDst:2},action:drop)
(prio:0,{ethDst:4, ethSrc:6},action:[port 30])
• Trace tree method converts arbitrary algorithmic policies into
correct forwarding tables that effectively use wildcard rules.
• Deficiencies:
– More priorities levels than necessary
– More rules than necessary
• Annotate TT nodes with extra information to
improve compilation
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Andreas Voellmy, Yale
40
Optimization 1: Annotate TT nodes
with completeness
tcpDst==2
2
{}
False
True
no barrier
{tcpDst:22}
drop
ethDst
complete
complete
{ethDst:2}
2
drop
(prio:2,{tcpDst:22},action:drop)
{}
4
ethSrc
{ethDst:4}
6
complete
port 30
(prio:1,{ethDst:2},action:drop)
{ethDst:4,
ethSrc:6}
(prio:0,{ethDst:4, ethSrc:6},action:[port 30])
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Andreas Voellmy, Yale
41
Optimization 2: Annotate nodes with
priority dependencies
tcpDst==2
2
True
{tcpDst:22}
{}
False
1
ethDst
drop
2
{ethDst:2}
drop
(prio:1,{tcpDst:22},action:drop)
{}
4
ethSrc
{ethDst:4}
6
port 30
(prio:0,{ethDst:2},action:drop)
{ethDst:4,
ethSrc:6}
(prio:0,{ethDst:4, ethSrc:6},action:[port 30])
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Andreas Voellmy, Yale
42
Improved compilation result
(prio:1,{tcpDst:22},action:drop)
(prio:0,{ethDst:2},action:drop)
(prio:0,{ethDst:4, ethSrc:6},action:[port 30])
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Andreas Voellmy, Yale
43
Maple Status
• Maple has been implemented in Haskell using the McNettle
Openflow controller, which implements Openflow 1.0.
• The implementation includes several other features:
– Incremental TT compilation, to avoid full recompilation on
every update.
– Trace reduction, to ensure traces and trace trees do not
contain redundant nodes.
– Automatic and user-specified invalidation, to support
removing and updating TT and FT when network state
changes.
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Andreas Voellmy, Yale
44
Summary: Contributions
• Algorithmic policies provide a simple, expressive programming
model for SDN, eliminating a key source of errors and
performance problems.
• Maple provides a scalable implementation of algorithmic
policies through several novel techniques, including:
– runtime tracing of algorithmic policies,
– maintaining a trace tree and compiling TT to flow tables to
distribute processing to switches;
– using TT annotations to implement compiler optimizations
such as rule and priority reductions.
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Andreas Voellmy, Yale
45
Outline
• Announcements
– Homework 2 posted due in 18 days
– Next lecture: first half by Josh Reich from
Princeton on Pyretic
• Review of previous lecture
• SDN programming language
– Maple: generic programming language syntax
such as Java, Python
– Frenetic: domain specific programming language
9/29/14
Software Defined Networking (COMS 6998-10)
46
Key questions:
•What are the right abstractions for
programming software-defined networks?
•How can we engineer trustworthy
implementations that provide assurance?
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
47
Modular Abstractions
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
48
Combining Functionality
One monolithic
application
Monitor + Route + Load Balance + Firewall
Controller Platform
Challenges:
•Writing, testing, and debugging programs
•Reusing code across applications
•Porting applications to new platforms
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
49
Pattern
Route
+
Monitor
Actions
dstip=10.0.0.1
Fwd 1
dstip=10.0.0.2
Fwd 2
Pattern
Actions
srcip=1.2.3.4
Count
Pattern
Route
+ Monitor
9/29/14
Actions
srcip=1.2.3.4, dstip=10.0.0.1
Fwd 1, Count
srcip=1.2.3.4, dstip=10.0.0.2
Fwd 2, Count
srcip=1.2.3.4
Count
dstip=10.0.0.1
Fwd 1
dstip=10.0.0.2
Fwd 2
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
50
Pattern
Route
+ Monitor
Actions
srcip=1.2.3.4, dstip=10.0.0.1
Fwd 1, Count
srcip=1.2.3.4, dstip=10.0.0.2
Fwd 2, Count
srcip=1.2.3.4
Count
dstip=10.0.0.1
Fwd 1
dstip=10.0.0.2
Fwd 2
Pattern
+
Firewall
Actions
tcpdst = 22
Drop
*
Fwd ?
Pattern
Route
+ Monitor
+ Firewall
9/29/14
Actions
srcip=1.2.3.4, tcpdst = 22
Count, Drop
srcip=1.2.3.4, dstip=10.0.0.1
Fwd 1, Count
srcip=1.2.3.4, dstip=10.0.0.2
Fwd 2, Count
srcip=1.2.3.4
Count
tcpdst = 22
Drop
dstip=10.0.0.1
Fwd 1
dstip=10.0.0.2
Fwd 2
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
51
Modular Applications
One module
for each task
Monitor
Route
Load Balance
Firewall
Controller Platform
Benefits:
•Easier to write, test, and debug programs
•Can reuse modules across applications
•Possible to port applications to new platforms
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
52
Beyond Multi-Tenancy
Each module controls a
different portion of the traffic
Slice 1
Slice 2
Slice 3
...
Slice N
Controller Platform
Relatively straightforward to split rule, bandwidth,
and network events across these modules
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
53
Modules Affect the Same Traffic
Each module partially specifies
handling of all traffic
Monitor
Route
Load Balance
Firewall
Controller Platform
How should we combine a collection of such modules
into a single application?
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
54
Language-Based Approach
Monitor
Route
Load Balance
Firewall
Compiler + Run-Time System
Controller Platform
Design languages based on modular programming
abstractions, and engineer efficient implementations
using a compiler and run-time system
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
55
Language Constructs
[POPL ’12, NSDI ’13]
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
56
Parallel Composition
Pattern
srcip=1.2.3.4
Pattern
Actions
Count
Monitor
+
Actions
dstip=3.4.5.6
Fwd 1
dstip=6.7.8.9
Fwd 2
Route
Controller Platform
Pattern
srcip=1.2.3.4, dstip=3.4.5.6
Fwd 1, Count
srcip=1.2.3.4, dstip=6.7.8.9
Fwd 2, Count
srcip=1.2.3.4
Count
dstip=3.4.5.6
Fwd 1
dstip=6.7.8.9
9/29/14
Actions
Fwd 2
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
57
Sequential Composition
Pattern
Pattern
Actions
Actions
srcip=*0
dstip:=10.0.0.1
dstip=10.0.0.1
Fwd 1
srcip=*1
dstip:=10.0.0.2
dstip=10.0.0.2
Fwd 2
Load Balance
;
Route
Controller Platform
Pattern
9/29/14
Actions
srcip=*0
dstip:=10.0.0.1, Fwd 1
srcip=*1
dstip:=10.0.0.2, Fwd 2
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
58
Dividing Traffic Over Modules
Predicates specify which packets traverse which
modules, using ingress port and packet-header fields
if dstport=80
Load Balance
then
;
else if dstport=22
Monitor
+
Route
then
Route
else
Drop
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
59
The NetKAT Language
field ::= switch | inport | srcmac | dstmac | ...
val ::= 0 | 1 | 2 | 3 | ...
a,b,c ::= true
(* true constant *)
| false
(* false constant *)
| field = val
(* test value *)
| a 1 | a2
(* disjunction *)
| a1 & a2
(* conjunction *)
|!a
(* negation *)
p,q,r ::= filter a
(* filter by predicate *)
| field := val
(* modify value *)
| p1 + p2
(* parallel composition *)
| p 1 ; p2
(* sequential composition
*)
| p*
(* iteration *)
Syntactic sugar: if a then p1 else p2 = filter a; p1 + filter !a;
Software Defined Networking (COMS 6998-10)
9/29/14
60
Source:
Nate
Foster,
Cornell
p2
Example NetKAT Program
open NetKAT.Std
(* a simple repeater *)
let repeater : policy =
<:netkat<
if port = 1 then port := 2 + port := 3 + port := 4
else if port = 2 then port := 1 + port := 3 + port := 4
else if port = 3 then port := 1 + port := 2 + port := 4
else if port = 4 then port := 1 + port := 2 + port := 3
else drop
>>
let _ = run_static repeater
9/29/14
Software Defined Networking (COMS 6998-10)
61
Example NetKAT Program (Cont’d)
open NetKAT.Std
let forwarding : policy =
<:netkat<
if ip4Dst = 10.0.0.1 then port := 1
else if (* destination is 10.0.0.2, forward out port
2, etc. *)
...
else drop
>>
9/29/14
Software Defined Networking (COMS 6998-10)
62
Example NetKAT Program (Cont’d)
open NetKAT.Std
open Forwarding
let firewall : policy =
<:netkat<
if (ip4Src = 10.0.0.1 && ip4Dst = 10.0.0.2 &&
tcpSrcPort = 80 || ip4Src = 10.0.0.2 &&
ip4Dst = 10.0.0.1 && tcpDstPort = 80)
then $forwarding
else drop
9/29/14
Software Defined Networking (COMS 6998-10)
63
Example: Topology Abstraction
It is often useful to write programs in terms of a simplified
abstract network topology
Example: load balancer
Abstract topology
Physical topology
Benefits:
•Information hiding: limit what each module sees
•Protection: limit what each module does
•Reuse: write code for appropriate interface
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
64
Example: “One Big Switch”
Abstract Network
Physical Network
• Simplest example of topology abstraction
• Can be used in many applications, including access
control, load balancing, distributed middleboxes, etc.
Implementation:
(ingress; raise; application; lower; fabric; egress)
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
65
Formal Reasoning
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
66
Program Equivalence
Given a program and a topology:
A
B
Want to be able to answer questions like:
“Will my network behave the same if I put the firewall rules
on A, or on switch B (or both)?”
Formally, does the following equivalence hold?
(filter switch = A ; firewall; routing + filter switch = B; routing)
~
(filter switch = A ; routing + filter switch = B; firewall; routing)
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
67
NetKAT Equational Theory
Boolean Algebra
Packet Algebra
a | (b & c) ~ (a | b) & (a | c)
f := n; f’ := n’ ~ f’ := n’ ; f := n
if f ≠ f’
a | true ~ true
f := n; f’ = n’ ~ f’ = n’; f := n
if f ≠ f’
a | ! a ~ true
f := n; f = n ~ f := n
a&b~b&a
f = n; f := n ~ f = n
a & !a ~ false
f := n; f’ = n’ ~ f := n’
a&a~a
f = n; f = n’ ~ filter drop
if n ≠ n’
Kleene Algebra
p + (q + r) ~ (p + q) + r
p+q~q+p
p + filter false ~ p
p+p~p
p ; (q ; r) ~ (p ; q) ; r
p; (q + r) ~ p ; q + p ; r
(p + q) ; r ~ p ; r + q ; r
9/29/14
filter true ; p ~ p ~ p ; filter true
filter false ; p ~ filter false
p ; filter false ~ filter false
filter true + p ; p* ~ p*
filter true + p* ; p ~ p*
p + q ; r + r ~ r ⟹ p* ; q + r ~ r
p + q ; r + q ~ q ⟹ p ; r* + q ~q
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
68
NetKAT and Kleene Algebras
The design of NetKAT is not an accident!
Its foundations rest upon canonical mathematical structure:
• Regular operators (+, ;, and *) encode paths through topology
• Boolean operators (&, |, and !) encode switch tables
This is called a Kleene Algebra with Tests [Kozen ’96]
Theorems
• Soundness: programs related by the axioms are equivalent
• Completeness: equivalent programs are related by the axioms
• Decidabilty: program equivalence is decidable (PSPACE)
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
69
NetKAT Verification
• Model programs and topologies in the Z3 SMT solver
• Encode network-wide function as the transitive closure of
the sequential composition of the program and topology
• Verify reachability properties automatically
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
70
Machine-Verified Controllers
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
71
Certified Software Systems
Recent Successes
•seL4 [SOSP ’09]
•CompCert [CACM ’09]
•F* [ICFP ’11, POPL ’12, ’13]
Tools
Inductive pred : Type :=
| OnSwitch : Switch -> pred
| InPort : Port -> pred
| DlSrc : EthernetAddress -> pred
| DlDst : EthernetAddress -> pred
| DlVlan
: option
VLAN -> pred
Lemma
inter_wildcard_other
: forall x,
| ...
Wildcard_inter WildcardAll x = x.
| And : Proof.
pred -> pred -> pred
| Or : pred
-> pred
-> predx; auto.
intros;
destruct
| Not : Qed.
pred -> pred
| All : pred
| None :Lemma
pred inter_wildcard_other1 : forall x,
Wildcard_inter x WildcardAll = x.
(** :=
val handle_event :
Inductive Proof.
act : Type
event
->x;
unit
Monad.m
| ForwardMod
: Moddestruct
-> PseudoPort
-> act **)
intros;
auto.
let handle_event = function |
| ... Qed.
SwitchConnected swId ->
Inductive Lemma
pol : inter_exact_same
Typehandle_switch_connected
:=
: forall x,swId |
SwitchDisconnected
swId ->x)
| Policy :Wildcard_inter
pred
-> list act
-> pol
(WildcardExact
handle_switch_disconnected
swId |
| Union
: pol -> pol
-> =pol
(WildcardExact
x)
WildcardExact x.
SwitchMessage
(swId,
xid0, msg) ->
(match
| Restrict
: pol -> pred -> pol
Proof.
msg with
| PacketInMsg pktIn ->
| ...
intros.
handle_packet_in
swId
pktIn
| _ ->
unfold Wildcard_inter.
Monad.ret
())
(** val main : unit
destruct (eqdec
x x); intuition.
Monad.m
**)
let
main
=
Monad.forever
Qed.
(Monad.bind Monad.recv (fun evt ->
handle_event evt))
Write code
Prove correct
Extract code
Textbooks
Certified
binary
Certified
Programming with
Dependent Types
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
72
Certified NetKAT Controller
• Each level of abstraction
formalized in Coq
• Machine-checked proofs
that the transformations
between levels preserve
semantics
• Code extracted to OCaml
and deployed with real
switch hardware
9/29/14
NetKAT
Compiler
Optimizer
Flow tables
Run-time system
OpenFlow messages
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
73
NetKAT Compiler
Overview
•Compiler: maps NetKAT programs to flow tables
•Optimizer: eliminates “empty” and “shadowed” rules
Correctness Theorem
Theorem compile_correct :
forall opt pol sw pt pk bufId,
SemanticsPreserving opt ->
netcore_eval pol sw pt pk bufId =
flowtable_eval (compile pol sw) sw pt pk bufId.
Formalization Highlights
•Library of algebraic properties of flow tables
•New tactic for proving equalities on bags
•Key invariant: all packet patterns “natural”
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
74
OpenFlow 1.0 Specification
42 pages...
...of informal prose
...diagrams and flow charts
...and C struct definitions
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
75
Featherweight OpenFlow
Semantics
Syntax
Key Features:
•Models all features related to
packet forwarding and all
essential asynchrony
•Supports arbitrary controllers
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
76
Forwarding
/* Fields to match against flows */
struct ofp_match {
uint32_t wildcards;
/* Wildcard fields. */
uint16_t in_port;
/* Input switch port. */
uint8_t dl_src[OFP_ETH_ALEN]; /* Ethernet source address. */
uint8_t dl_dst[OFP_ETH_ALEN]; /* Ethernet destination address. */
uint16_t dl_vlan;
/* Input VLAN. */
uint8_t dl_vlan_pcp;
/* Input VLAN priority. */
uint8_t pad1[1];
/* Align to 64-bits. */
uint16_5 dl_type;
/* Ethernet frame type. */
uint8_t nw_tos;
/* IP ToS (DSCP field, 6 bits). */
uint8_t nw_proto;
/* IP protocol or lower 8 bits of
ARP opcode. */
uint8_t pad2[2];
/* Align to 64-bits. */
uint32_t nw_src;
/* IP source address. */
uint32_t nw_dst;
/* IP destination address. */
uint16_t tp_src;
/* TCP/UDP source port. */
uint16_t tp_dst;
/* TCP/UDP destination port. */
};
OFP_ASSERT(sizeof(struct ofp_match) == 40);
Record Pattern : Type := MkPattern {
dlSrc : Wildcard EthernetAddress;
dlDst : Wildcard EthernetAddress;
dlType : Wildcard EthernetType;
dlVlan : Wildcard VLAN;
dlVlanPcp : Wildcard VLANPriority;
nwSrc : Wildcard IPAddress;
nwDst : Wildcard IPAddress;
nwProto : Wildcard IPProtocol;
nwTos : Wildcard IPTypeOfService;
tpSrc : Wildcard TransportPort;
tpDst : Wildcard TransportPort;
inPort : Wildcard Port
}.
Detailed model of matching, forwarding, and flow table update
9/29/14
Definition Pattern_inter (p p':Pattern) :=
let dlSrc := Wildcard_inter EthernetAddress.eqdec (ptrnDlSrc p) (ptrnDlSrc p') in
let dlDst := Wildcard_inter EthernetAddress.eqdec (ptrnDlDst p) (ptrnDlDst p') in
let dlType := Wildcard_inter Word16.eqdec (ptrnDlType p) (ptrnDlType p') in
let dlVlan := Wildcard_inter Word16.eqdec (ptrnDlVlan p) (ptrnDlVlan p') in
let dlVlanPcp := Wildcard_inter Word8.eqdec (ptrnDlVlanPcp p) (ptrnDlVlanPcp p') in
let nwSrc := Wildcard_inter Word32.eqdec (ptrnNwSrc p) (ptrnNwSrc p') in
let nwDst := Wildcard_inter Word32.eqdec (ptrnNwDst p) (ptrnNwDst p') in
let nwProto := Wildcard_inter Word8.eqdec (ptrnNwProto p) (ptrnNwProto p') in
let nwTos := Wildcard_inter Word8.eqdec (ptrnNwTos p) (ptrnNwTos p') in
let tpSrc := Wildcard_inter Word16.eqdec (ptrnTpSrc p) (ptrnTpSrc p') in
let tpDst := Wildcard_inter Word16.eqdec (ptrnTpDst p) (ptrnTpDst p') in
let inPort := Wildcard_inter Word16.eqdec (ptrnInPort p) (ptrnInPort p') in
MkPattern dlSrc dlDst dlType dlVlan dlVlanPcp
nwSrc nwDst nwProto nwTos
tpSrc tpDst
inPort.
Definition exact_pattern (pk : Packet) (pt : Word16.T) : Pattern :=
MkPattern
(WildcardExact (pktDlSrc pk)) (WildcardExact (pktDlDst pk))
(WildcardExact (pktDlTyp pk))
(WildcardExact (pktDlVlan pk)) (WildcardExact (pktDlVlanPcp pk))
(WildcardExact (pktNwSrc pk)) (WildcardExact (pktNwDst pk))
(WildcardExact (pktNwProto pk)) (WildcardExact (pktNwTos pk))
(Wildcard_of_option (pktTpSrc pk)) (Wildcard_of_option (pktTpDst pk))
(WildcardExact pt).
Definition match_packet (pt : Word16.T) (pk : Packet) (pat : Pattern) : bool :=
negb (Pattern_is_empty (Pattern_inter (exact_pattern pk pt) pat)).
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
77
Asynchrony
“In the absence of barrier
messages, switches may arbitrarily
reorder messages to maximize
performance.”
“There is no packet output
ordering guaranteed
within a port.”
Essential asynchrony: packet buffers, message reordering, and barriers
Definition
Definition
Definition
Definition
9/29/14
InBuf := Bag Packet.
OutBuf := Bag Packet.
OFInBuf := Bag SwitchMsg.
OFOutBuf := Bag CtrlMsg.
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
78
Distributed Programming:
non-atomic table updates
Priority
Predicate
Asynchrony (Cont’d)
Action
⊆
Priority
Predicate
Action
10
SSH
Drop
⊆
Priority
Predicate
Action
5
dst_ip = H1
Fwd 1
Priority
Predicate
Action
10
SSH
Drop
5
dst_ip = H1
Fwd 1
update re-ordering
Priority
Predicate
Action
5
dst_ip = H1
Fwd 1
5
dst_ip = H2
Fwd 2
9/29/14
⊆
Priority
Predicate
Action
10
SSH
Drop
5
dst_ip = H1
Fwd 1
5
dst_ip = H2
Fwd 2
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
79
Controllers
Ultimately we want to prove theorems
about controllers that implement the
NetKAT run-time system...
...but we didn’t want to bake specific
controllers into Featherweight OpenFlow!
Controller model: fully abstract
Controller Parameters
: abstract type of controller state
fin :
fout :
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
80
Weak Bisimulation
(H1,
)
(S1,pt1,
)
(S2,pt1,
)
(H2,
)
≈
≈
≈
≈
≈
≈
≈
≈
Theorem fwof_abst_weak_bisim :
weak_bisimulation concreteStep abstractStep
bisim_relation.
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
81
The
System
predicates
predicates
predicates
policies
policies
policies
queries
queries
queries
Frenetic
implemented using
OX
Ox
stream of snapshots
over time
OCaml embedding
• predicates and policies
• queries
OCaml OpenFlow Platform
• similar to Nox, Pox, Floodlight, etc.
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
82
The
System
Domain-specific language
Frenetic DSL
• predicates and policies
• monitoring
• mac learning
• network address translation
implemented using
Frenetic
implemented using
OX
Ox
OCaml embedding
• predicates and policies
• queries
OCaml OpenFlow Platform
• similar to Nox, Pox, Floodlight, etc.
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
83
Conclusion
Modularity is a key concern in the design of any language
NetKAT provides rich abstractions for building modular
network programs, including parallel and sequential
composition operators
By leveraging recent advances in formal methods, can build
trustworthy compilers, run-time systems, and verification tools
Implementation status:
• Stand-alone controller platform implemented in OCaml
• Sophisticated, proactive compiler for OpenFlow rules
• Large parts of the system formally verified in Coq
• Experimental support for OpenFlow 1.3
9/29/14
Software Defined Networking (COMS 6998-10)
Source: Nate Foster, Cornell
84
Questions?
9/29/14
Software Defined Networking (COMS 6998-10)
85