1. Programming Abstractions & Languages for SDN: Frenetic & Pyretic

2. Network Programming is Hard
Programming network equipment is hard
Complex software by equipment vendors
Complex configuration by network administrators
Expensive and error prone
Network outages and security vulnerabilities
Slow introduction of new features
SDN gives us a chance to get this right!
Rethink abstractions for network programming

3. Programming Software Defined Networks
Controller
OpenFlow already helps a lot
Network-wide view at controller
Direct control over data plane
The APIs do not make it easy
Limited controller visibility
No support for composition
Asynchronous events
Switches

4. Example Network A B SDN Switch Servers Internet 2 1 3 w/ labeled ports
The API that has made this possible is OpenFlow
Which I’ll describe in the context of a simple network (which we will return to later)
Made of an SDN switch
connected on port 1 to the internet
And on ports 2 and 3 to servers A and B respectively A 2 1 3 B

5. A Simple OpenFlow Program
2:dstip=A -> fwd(2)
1:* > fwd(1)
2:dstip=B -> fwd(3)
OpenFlow
Program
Priority
Pattern
Action
Counters for each rule
- #bytes, #packets
Route: IP/fwd
Let’s consider a simple OpenFlow IP routing program shown in the green box
Each line or “rule” has a pattern – that determines which packets will be matched – here destination IPS
An associated action – here forward out a particular port
A priority used to disambiguate between overlapping patterns,
dstip=A A 2 1 3 B
dstip!=A
dstip!=B
dstip=B

6. One API, Many Uses Switch: MAC/fwd A B Priority Ordered Pattern Action
1:dstmac=A -> fwd(2)
1:dstmac=B -> fwd(3)
2:* > fwd(1)
Priority
Ordered
Pattern
Action
Switch: MAC/fwd
A different choice of pattern use MAC addresses instead of IPs, with the same relative priorities (we’ll assume our rules are listed in priority order from here on)
produces an ethernet switching program. A 2 1 3 B

7. One API, Many Uses Load Balancer: IP/mod A B Pattern Action 2 1 3
srcip=0*,dstip=P -> mod(dstip=A)
srcip=1*,dstip=P -> mod(dstip=B)
Pattern
Action
Load Balancer: IP/mod
Likewise, we can produce a load balancer by choosing a more complex pattern match and a different action – modify
In this way OpenFlow lets us manage all sorts of heterogenous hardware / functionality using same interface! A 2 1 3 B

8. Composition: Simple Repeater
def switch_join(switch):
# Repeat Port 1 to Port 2
p1 = {in_port:1}
a1 = [forward(2)]
install(switch, p1, DEFAULT, a1)
# Repeat Port 2 to Port 1
p2 = {in_port:2}
a2 = [forward(1)]
install(switch, p2, DEFAULT, a2)
Controller 1 2
When a switch joins the network, install two forwarding rules.

9. Composition: Web Traffic Monitor
Monitor “port 80” traffic
def switch_join(switch)):
# Web traffic from Internet
p = {inport:2,tp_src:80}
install(switch, p, DEFAULT, [])
query_stats(switch, p)
def stats_in(switch, p, bytes, …)
print bytes
sleep(30) 1 2
Web traffic
When a switch joins the network, install one monitoring rule.

10. Composition: Repeater + Monitor
def switch_join(switch):
pat1 = {inport:1}
pat2 = {inport:2}
pat2web = {in_port:2, tp_src:80}
install(switch, pat1, DEFAULT, None, [forward(2)])
install(switch, pat2web, HIGH, None, [forward(1)])
install(switch, pat2, DEFAULT, None, [forward(1)])
query_stats(switch, pat2web)
def stats_in(switch, xid, pattern, packets, bytes):
print bytes
sleep(30)
query_stats(switch, pattern)
Must think about both tasks at the same time.

11. OpenFlow Programming Stack
*First Order Approximation
Controller Platform
Switch API
(OpenFlow)
Monolithic Controller
Switches
App
Runtime
Control Flow, Data Structures, etc.

12. Limited Controller Visibility
Example: MAC-learning switch
Learn about new source MAC addresses
Forward to known destination MAC addresses
Controller program is more complex than it seems
Cannot install destination-based forwarding rules
… without keeping controller from learning new sources
Solution: rules on <inport, src MAC, dst MAC> 2
1 sends to 2  learn 1, install
3 sends to 1  never learn 3
1 sends to 3  always floods 1 3
Must think about reading and writing at the same time.

13. Asynchrony: Switch-Controller Delays
Common OpenFlow programming idiom
First packet of a flow goes to the controller
Controller installs rules to handle remaining packets
What if more packets arrive before rules installed?
Multiple packets of a flow reach the controller
What if rules along a path installed out of order?
Packets reach intermediate switch before rules do
Controller
packets
Must think about all possible event orderings.

14. Wouldn’t It Be Nice if You Could…
Separate reading from writing
Reading: specify queries on network state
Writing: specify forwarding policies
Compose multiple tasks
Write each task once, and combine with others
Prevent race conditions
Automatically apply forwarding policy to extra packets
This is what Frenetic does!

15. Programming SDN w/ OpenFlow
The Good
Network-wide visibility
Direct control over the switches
Simple data-plane abstraction
The Bad
Low-level programming interface
Functionality tied to hardware
Explicit resource control
The Ugly
Non-modular, non-compositional
Challenging distributed programming
Images by Billy Perkins

16. Today: OpenDaylight, POX, etc.
~ Assembly language
~ Registers, adders, etc.
Controller Platform
Switch API
(OpenFlow)
Monolithic Controller
Switches
App
Runtime
Data and Control Flow

17. Programming Software Defined Networks
Controller
OpenFlow already helps a lot
Network-wide view at controller
Direct control over data plane
The APIs do not make it easy
Limited controller visibility
No support for composition
Asynchronous events
Frenetic simplifies the programmer’s life
A language that raises the level of abstraction
A run-time system that handles the gory details
Switches

18. Frenetic Language http://www.frenetic-lang.org/
Reads: query network state
Queries can see any packets
Queries do not affect forwarding
Language designed to keep packets in data plane
Writes: specify a forwarding policy
Policy separate from mechanism for installing rules
Streams of packets, topology changes, statistics, etc.
Library to transform, split, merge, and filter streams
Current implementation
A collection of Python libraries on top of NOX

19. Example: Repeater + Monitor
# Static repeating between ports 1 and 2
def repeater():
rules=[Rule(inport:1, [forward(2)]),
Rule(inport:2, [forward(1)])]
register(rules)
Repeater
# Monitoring Web traffic
def web_monitor():
q = (Select(bytes) *
Where(inport:2 & tp_src:80) *
Every(30))
q >> Print()
Monitor
# Composition of two separate modules
def main():
repeater()
web_monitor()
Repeater + Monitor

20. Frenetic System Overview
High-level language
Query language
Composition of forwarding policies
Run-time system
Interprets queries and policies
Installs rules and tracks statistics
Handles asynchronous events

21. Frenetic Run-Time System
Rule granularity
Microflow: exact header match
Wildcard: allow “don’t care” fields
Rule installation
Reactive: first packet goes to controller
Proactive: rules pushed to the switches
Frenetic run-time system
Version 1.0: reactive microflow rules [ICFP’11]
Version 2.0: proactive wildcard rules [POPL’12]
Get it right once, and free the programmer!

22. Evaluation Example applications Performance metrics
Routing: spanning tree, shortest path
Discovery: DHCP and ARP servers
Load balancing: Web requests, memcached queries
Security: network scan detector, DDoS defenses
Performance metrics
Language: lines of code in applications
Much shorter programs, especially when composing
Run-time system: overhead on the controller
Frenetic 1.0: competitive with programs running on NOX
Frenetic 2.0: fewer packets to the controller

23. Conclusions Frenetic foundation Makes programming easier
Separating reading from writing
Explicit query subscription and policy registration
Operators that transform heterogeneous streams
Makes programming easier
Higher-level patterns
Policy decoupled from mechanism
Composition of modules
Prevention of race conditions
And makes new abstractions easier to build!

24. Modular SDN Programming w/ Pyretic
Today, I’m going to show you how to build sophisticated SDN apps
Out of independent modules
written in a novel domain specific language embedded in Python
Available for you to download at the URL behind me

25. Pyretic: Language & Platform
Pyretic Controller Platform
Switch API
Programmer API
(OpenFlow) LB
Route
Monitor FW
Switches
Apps
Runtime
(Pyretic)

26. {Frene,Pyre}tic? Frenetic is a SDN umbrella project focused on
Language design
Compiler implementation
Princeton/Cornell Team Produced:
Great (northbound) abstraction for programmers
Techniques for implementing these abstractions
Two current members of the family
Pyretic: embedded & implemented in Python
Frenetic Ocaml: embedded & implemented in OCaml

27. Pyretic or Frenetic Ocaml?
Target Community
Systems and Networking
Programming Languages
Primary Dev. Location
Princeton
Cornell
Host Language
Python
OCaml

28. Pyretic Philosophy Provide high-level programming abstractions
Based on state-of-the-art PL techniques
Implement w/ state-of-the-art systems tech
Package for the networking community
Focus on real world utility and cutting edge features

29. Open Source and Programmer-Friendly
Embedded and Implemented in Python
Rich support for dynamic policies
Familiar constructs and environment
Python library / module system
Default 3-clause BSD license
Active & growing developer community
GitHub repository & wiki
Video tutorials and documentation

30. Basic Programmer Wishlist
Encode policy concisely
Write portable code
Specify traffic of interest
Compose code from independent modules
Query network state
Modify policy dynamically

31. Pyretic =
* Our goal

32. Pyretic Provides Feature Example Concise policy encoding
flood()
Boolean predicates
~(match(dstip= ) |
match(srcip= ) )
Composition operators
(load_balance + monitor) >> route
Virtual header fields
match(switch)
modify(class=‘staff’)
Query Policies
count_packets()

33. Pyretic: Key Abstractions
Abstract Packet Model
packet flows as a dictionary mapping field names to values
(nested) virtual header fields
located packet and policy function: set  multi-sets
Network Object Model: virtual switches & ports
“big switch”: one-to-many
“virtual network”: many-to-one

34. Pyretic: Policy Language
Composition: parallel and sequential composition operators: “|” and “>>”
High-level Policy Functions
Static Policies:
primitive actions
Predicates
query
Dynamic Application
def main():
P.when(…)

35. Policy in OpenFlow Defining “policy” is complicated
All rules in all switches
Packet-in handlers
Polling of counters
Programming “policy” is error-prone
Duplication between rules and handlers
Frequent changes in policy (e.g., flowmods)
Policy changes affect packets in flight

36. From Rules to a Policy Function
Located packet
A packet and its location (switch and port)
Policy function
From located packet to set of located packets
Examples
Original packet: identity
Drop the packet: drop
Modified header: modify(f=v)
New location: fwd(a)

37. Why a set? Consider flood
To flood every packet: from pyretic.lib.corelib import * def main(): return flood()
hub.py

38. No worrying about: Writing a separate handler for controller
Constructing and sending OpenFlow rules
Keeping track of each switch
Whether all switches supports the OpenFlow “flood” action (portability!)

39. Programmer Wishlist Encode policy concisely
Specify traffic of interest
Write portable code
Compose code from independent modules
Query network state
Modify policy dynamically

40. From Bit Patterns to Predicates
OpenFlow: bit patterns
No direct way to specify dstip!=
Requires two prioritized bitmatches
Higher priority: dstip=
Lower priority: *
Pyretic: boolean predicates
Combined with &, |, and ~
E.g., ~match(dstip= )

41. Example: Access Control
Block host def access_control(): return ~(match(srcip=‘ ’) | match(dstip=‘ ’) )

42. Programmer Wishlist Encode policy concisely Write portable code
Specify traffic of interest
Compose code from independent modules
Query network state
Modify policy dynamically

43. Neither concise nor portable
OpenFlow Packets
Location specific code needs both
The packet
The OF packet_in message*
Tagging packets requires choosing
Header field (e.g., VLAN, MPLS, TOS bits)
Set of values
Neither concise nor portable *

44. Pyretic Virtual Header Fields
Unified abstraction
Real headers: dstip, srcport, …
Packet location: switch and port
User-defined: e.g., traffic_class
Simple operations, concise syntax
Match: match(f=v)
Modify: modify(f=v)
Example
match(switch=A) & match(dstip=‘ ’)

45. Runtime Handles Implementation
Compiler chooses
What set of header bits to use
What each value means
Conceptual – no tying to particular mech.
Portable – different hw, other modules
Efficient
Don’t need same vlan value network-wide
Sometimes tags will ‘factor out’

46. Programmer Wishlist Encode policy concisely Write portable code
Specify traffic of interest
Compose code from independent modules
Query network state
Modify policy dynamically

47. Recall OpenFlow

48. Balance then Route (in Sequence)
srcip=0*,dstip=P -> mod(dstip=A) srcip=1*,dstip=P -> mod(dstip=B)
dstip=A -> fwd(2)
dstip=B -> fwd(3)
* > fwd(1)
Combined Rules?
(only one match)
srcip=0*,dstip=P -> mod(dstip=A) srcip=1*,dstip=P -> mod(dstip=B)
dstip=A -> fwd(2)
dstip=B -> fwd(3)
* > fwd(1)
Balances w/o
Forwarding!
srcip=0*,dstip=P -> mod(dstip=A) srcip=1*,dstip=P -> mod(dstip=B)
dstip=A -> fwd(2)
dstip=B -> fwd(3)
* > fwd(1)
Forwards w/o
Balancing!

49. Route and Monitor (in Parallel)
dstip =  fwd(2)
dstip =  fwd(3)
*  fwd(1)
srcip =  count
IP = 2 1 3
IP =
From ICFP’11 and POPL’12
srcip =  count
dstip =  fwd(2)
dstip =  fwd(3)
*  fwd(1)
Forwards but doesn’t count
Counts but doesn’t forward
Combined rules installed on switch?
dstip =  fwd(2)
dstip =  fwd(3)
*  fwd(1)
srcip =  count

50. Requires a Cross Product [ICFP’11, POPL’12]
Route
Monitor
dstip =  fwd(2)
dstip =  fwd(3)
*  fwd(1)
srcip =  count
IP = 2 1 3
IP =
From ICFP’11 and POPL’12
srcip = , dstip =  fwd(2) , count
srcip = , dstip =  fwd(3) , count
srcip =  fwd(1) , count
dstip =  fwd(2)
dstip =  fwd(3)
*  fwd(1)

51. Policy Functions Enable Compositional Operators
Parallel ‘+’: Do both C1 and C2 simultaneously Sequential ‘>>’: First do C1 and then do C2

52. Example: Sequential Composition
To first apply access control and then flood
access_control() >> flood()
Two totally independent policies
Combined w/o any change to either
access_control.py

53. Easily Define New Policies
E.g., the ‘if_’ policy def if_(F,P1,P2): return (F >> P1) + (~F >> P2)

54. Or flood xfwd(a) = ~match(inport=a) >> fwd(a) flood =
parallel([match(switch=sw) >>
parallel(map(xfwd,ports))
for sw,ports in MST])
Portable: compiler chooses whether to implement using OpenFlow ‘flood’ or ‘forward’

55. Programmer Wishlist Encode policy concisely Write portable code
Specify traffic of interest
Compose code from independent modules
Query network state
Modify policy dynamically

56. Querying In OpenFlow
Pre-install rules at the needed granularity (so byte/packet counters are available)
Issue queries to poll these counters
Parse the responses when they arrive
Combine counter values from multiple rules
Keep track of any packets sent to controller

57. Queries in Pyretic Just a special type of policy
Forwarding to a “bucket”
q = packets(limit=1,group_by=['srcip'])
Used like any other (>>, +)
w/ Callback function registration
q.register_callback(printer)

58. Example: Monitor
q = count_bytes(interval=1) q.register_callback(printer) monitor = match(srcip=' ') >> q

59. Query Policy Library Syntax Side Effect packets( limit=n,
group_by=[f1,f2,…])
callback on every packet received for up to n packets identical on fields f1,f2,...
count_packets(
interval=t,
count every packet received callback every t seconds providing count for each group
count_bytes(
count bytes received callback every t seconds providing count for each group

60. Recall OpenFlow Toy Balance Route Monitor

61. In Pyretic A 0* 2 1 3 1* B
balance = (match(srcip=0*,dstip=P) >> modify(dstip=A)) + (match(srcip=1*,dstip=P) >> modify(dstip=B)) + (~match( dstip=P) >> identity) route = (match(dstip=A) >> fwd(2)) + (match(dstip=B) >> fwd(3)) + (~(match(dstip=A) | match(dstip=B)) >> fwd(1)) b = count_bytes(interval=1) b.register_callback(print) monitor = match(srcip=X) >> b mlb = (balance >> route) + monitor
Which let’s us finish our first example, the monitoring load balancer.
We’ve already written the route and monitor modules
The balance module is similar to the OpenFlow version we saw previously, but with a third case for packets not destined to P
To these we apply the identity policy, so such packets are passed through to the next module unchanged.
With these three modules, completing the monitoring load balancer takes one quick line
Balance then forward, and do monitoring in parallel
This is significantly more elegant, modifiable, and reusable than writing the corresponding app in any controller platform.

62. Compared to
install_flowmod(5,srcip=X & dstip=P,[mod(dstip=A), fwd(2)]) install_flowmod(4,srcip=0* & dstip=P,[mod(dstip=A), fwd(2)]) install_flowmod(4,srcip=1* & dstip=P,[mod(dstip=B), fwd(3)]) install_flowmod(4,srcip=X & dstip=A ,[ fwd(2)]) install_flowmod(4,srcip=X & dstip=B,[ fwd(3)]) install_flowmod(3, dstip=A,[ fwd(2)]) install_flowmod(3, dstip=B,[ fwd(3)]) install_flowmod(2,srcip=X ,[ fwd(1)]) install_flowmod(1,* ,[ fwd(3)])

63. Programmer Wishlist Encode policy concisely Write portable code
Specify traffic of interest
Compose code from independent modules
Query network state
Modify policy dynamically

64. Functions Support Dynamism
Dynamic policies are also functions of time
Value at current moment in self.policy
Reassigning updates dynamic policy
Can be driven by queries

65. Example: MAC-Learning
New Type of Dynamic Policy
class learn(DynamicPolicy): def init(self): q = packets(limit=1,[’srcmac’,’switch’]) q.register_callback(update) self.policy = flood() + q def update(self,pkt): self.policy = if_(match(dstmac=pkt[’srcmac’], switch=pkt[’switch’]), fwd(pkt[’inport’]), self.policy)
First packet with unique
srcmac, switch
Defined momentarily
and query
to flood
Initialize current
value of time series
I’ll demonstrate this in the context of a MAC-Learning module
For those of you who aren’t familiar MAC-Learning logic works by initially flooding all received packets.
as mappings between ports and MAC addresses are learnt by each switch, that switch switches from flooding to unicasting
We start by declaring a new standard Python class which will encapsulate our time series object
We then initialize the object by creating a bucket which for each switch will callback when a new srcmac is seen
We register an update function with that bucket
And initialize the current value of the time-series to flood all packets
The update function simply takes the previous value the time-series produces a new one that replaces a flood with a unicast.
All-in-all pretty compact, yet very flexible.
If newly learned MAC
Update current val
Forward directly to
learned port
Otherwise, policy unchanged

66. Can also be driven by external events!
Dynamic Policies
Can also be driven by external events!

67. Example: UI Firewall def update_policy (self):
def __init__(self): print "initializing firewall" self.firewall = {} ... self.ui = threading.Thread( target=self.ui_loop) self.ui.daemon = True self.ui.start()
def AddRule (self, mac1, mac2):
if (mac2,mac1) in self.firewall:
return
self.firewall[(mac1,mac2)]=True
self.update_policy()
def update_policy (self):
self.policy = ~union([(match(srcmac=mac1) &
match(dstmac=mac2)) |
(match(dstmac=mac1) &
match(srcmac=mac2))
for (mac1,mac2)
in self.firewall.keys()])

68. Programmer Wishlist Encode policy concisely Write portable code
Specify traffic of interest
Compose code from independent modules
Query network state
Modify policy dynamically

69. Pyretic Platform

70. Platform Architecture
Controller
OF Controller Platform
OF Controller Client
Pyretic Backend
Pyretic Runtime
Main
App 1
App 2
Process 1
Serialized Messages (TCP socket)
Process 2
OpenFlow Messages
Switches

71. Modes of Operation Interpreted (on controller) Reactive Proactive
Fallback when rules haven’t been installed
Good for debugging
Reactive
Rules installed in response to packets seen
Fallback when proactive isn’t feasible
Various flavors and optimizations
Proactive
Analyze policy and push rules
Computation can be an issue
Currently nuclear and simple incremental

72. Runtime Architecture (in Progress)
HA &
Scale Out
Query
Mgmt
Interpreter, QoS, ACL, Topo
Classifier Generation
Incrementalization
Consistent Update
Flow Table Cache Management

73. Also in Progress New features Applications Policy access controls
QoS operators
Enhanced querying library
Applications
Incorporation of RADIUS & DHCP services
Wide-area traffic-management solutions for ISPs at SDN-enabled Internet Exchange Points.

74. Test It Out Yourself

75. HW Middleware QA Ops Hard and soft-switches APIs and Languages
Network processors
Reconfigurable pipelines
Hardware accelerated features
Programmable x86 dataplane
APIs and Languages
Traffic Monitoring/Sampling/QoS
Testing, Debugging, Verification
Experimentation & Testbeds
Integration & Orchestration
End hosts
Legacy switches
Middleboxes
Network Services
WAN, Enterprise, DC, Home
Wireless & Optical
Systems Challenges
Scalability
Fault-tolerance
Consistency
Upgradability
Performance
Security
Virtualization
of network
of services
of address space

76. Where Pyretic Fits Hard and soft-switches APIs and Languages
Network processors
Reconfigurable pipelines
Hardware accelerated features
Programmable x86 dataplane
APIs and Languages
Traffic Monitoring/Sampling/QoS
Testing, Debugging, Verification
Experimentation & Testbeds
Integration & Orchestration
End hosts
Legacy switches
Middleboxes
Network Services
WAN, Enterprise, DC, Home
Wireless & Optical
Systems Challenges
Scalability
Fault-tolerance
Consistency
Upgradability
Performance
Security
Virtualization
of network
of services
of address space