1. Programming Languages for Programmable Networks
Jennifer Rexford
Princeton University
During the past few years, the computer networking field has moved toward greater programmability inside the network. This is a tremendous opportunity to get network software right, and put the field on a stronger foundation. In this talk, I want to tell you about this trend, and discus some of our work on raising the level of abstraction for programming the network.

2. The Internet: A Remarkable Story
Tremendous success
From research experiment to global infrastructure
Brilliance of under-specifying
Network: best-effort packet delivery
Hosts: arbitrary applications
Enables innovation in applications
Web, P2P, VoIP, social networks, virtual worlds
But, change is easy only at the edge… 

3. Inside the ‘Net: A Different Story…
Closed equipment
Software bundled with hardware
Vendor-specific interfaces
Over specified
Slow protocol standardization
Few people can innovate
Equipment vendors write the code
Long delays to introduce new features
Impacts performance, security, reliability, cost…

4. Do We Need Innovation Inside?
Many boxes (routers, switches, firewalls, …), with different interfaces.
Enterprise network.

5. How Hard are Networks to Manage?
Operating a network is expensive
More than half the cost of a network
Yet, operator error causes most outages
Buggy software in the equipment
Routers with 20+ million lines of code
Cascading failures, vulnerabilities, etc.
The network is “in the way”
Especially a problem in data centers
… and home networks

6. Creating Foundation for Networking
A domain, not a discipline
Alphabet soup of protocols
Header formats, bit twiddling
Preoccupation with artifacts
From practice, to principles
Intellectual foundation for networking
Identify the key abstractions
… and support them efficiently
To build networks worthy of society’s trust

7. Rethinking the “Division of Labor”

8. Traditional Computer Networks
Data plane:
Packet streaming
Maybe this is a better picture… though need some details of what happens in each plane… like in next slides… or, have both?
Forward, filter, buffer, mark,
rate-limit, and measure packets

9. Traditional Computer Networks
Control plane:
Distributed algorithms
Maybe this is a better picture… though need some details of what happens in each plane… like in next slides… or, have both?
Track topology changes, compute routes, install forwarding rules

10. Traditional Computer Networks
Management plane:
Human time scale
Maybe this is a better picture… though need some details of what happens in each plane… like in next slides… or, have both?
Collect measurements and configure the equipment

11. Shortest-Path Routing
Management: set the link weights
Control: compute shortest paths
Data: forward packets to next hop 1 1 1 1 3

12. Shortest-Path Routing
Management: set the link weights
Control: compute shortest paths
Data: forward packets to next hop 1 1 1 1 3

13. Inverting the Control Plane
Traffic engineering
Change link weights
… to induce the paths
… that alleviate congestion 5 1 1 1 3

14. Avoiding Transient Anomalies
Distributed protocol
Temporary disagreement among the nodes
… leaves packets stuck in loops
Even though the change was planned!
1  5 1 1 1 3

15. Death to the Control Plane!
Simpler management
No need to “invert” control-plane operations
Faster pace of innovation
Less dependence on vendors and standards
Easier interoperability
Compatibility only in “wire” protocols
Simpler, cheaper equipment
Minimal software

16. Software Defined Networking (SDN)
Logically-centralized control
Smart,
slow
API to the data plane
(e.g., OpenFlow)
Dumb,
fast
Switches

17. OpenFlow Networks

18. 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
src=1.2.*.*, dest=3.4.5.*  drop
src = *.*.*.*, dest=3.4.*.*  forward(2)
3. src= , dest=*.*.*.*  send to controller

19. Controller: Programmability
App #1
App #2
App #3
Network OS
Events from switches
Topology changes,
Traffic statistics,
Arriving packets
Commands to switches
(Un)install rules,
Query statistics,
Send packets

20. OpenFlow in the Wild Open Networking Foundation
Creating Software Defined Networking standards
Google, Facebook, Microsoft, Yahoo, Verizon, Deutsche Telekom, and many other companies
Commercial OpenFlow switches
HP, NEC, Quanta, Dell, IBM, Juniper, …
Network operating systems
NOX, Beacon, Floodlight, Nettle, ONIX, POX, Frenetic
Network deployments
Eight campuses, and two research backbone networks
Commercial deployments

21. Dynamic Access Control
Inspect first packet of each connection
Consult the access control policy
Install rules to block or route traffic

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

23. See http://www.openflow.org/videos/
Example Applications
Dynamic access control
Seamless mobility/migration
Server load balancing
Using multiple wireless access points
Energy-efficient networking
Adaptive traffic monitoring
Denial-of-Service attack detection
Network virtualization
See

24. Challenges of Programming Software Defined Networks

25. Programming OpenFlow Networks
OpenFlow makes programming possible
Network-wide view at controller
Direct control over data plane
The APIs do not make it easy
Low level of abstraction
Challenges
Composition
Concurrency …
Controller
Switches

26. Modularity: Simple Repeater
def repeater(switch):
# Repeat Port 1 to Port 2
pat1 = {in_port:1}
act1 = [forward(2)]
install(switch, pat1, DEFAULT, act1)
# Repeat Port 2 to Port 1
pat2 = {in_port:2}
act2 = [forward(1)]
install(switch, pat2, DEFAULT, act2)
Controller 1 2
When a switch joins the network, install two forwarding rules.

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

28. 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.

29. Concurrency: Switch-Controller Delays
Common programming idiom
First packet goes to the controller
Controller installs rules
packets

30. Concurrency: Switch-Controller Delays
More packets arrive before rules installed?
Multiple packets reach the controller
packets

31. Concurrency: Switch-Controller Delays
Rules along a path installed out of order?
Packets reach a switch before the rules do
packets
Must think about all possible packet and event orderings.

32. Frenetic Language and Run-Time System
Joint work with Nate Foster, Dave Walker, Chris Monsanto, Mark Reitblatt, Rob Harrison, Mike Freedman, Alec Story, Josh Reich

33. Functional Reactive Programming
Streams of events
Packets
Switch join/leave
Port status change
Traffic statistics
Commands to switches
Seconds
Operations on streams
Filter
Merge
Transform
Split
Accumulate
Lift
Single Value or Event
Event Stream
Declarative programming of OpenFlow networks [Nettle, Frenetic]

34. Database Query Language [ICFP’11]
Controller applications read network state
Traffic counters in the switches
Packets sent to the controller
Minimize controller overhead
Filter using high-level patterns
Limit the # of values returned
Aggregate by #/size of packets
Return an event stream
Time-indexed stream of values
Run-time system
Installs rules, reads counters, handles packets, …
Learning Host Location
Select(packets) *
GroupBy([srcmac]) *
SplitWhen([inport]) *
Limit(1)
Traffic Monitoring
Select(bytes) *
Where(inport:2) *
GroupBy([dstmac]) *
Every(60)

35. Composition of Modules [ICFP’11]
# 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

36. Compiler/Run-Time System [POPL’12]
Two-tiered programming model
Smart controller and dumb switches
Automatically partition a program
Network policies change over time
Controller (un)installs rules in switches
Reactive specialization of a policy
Rules with wildcard patterns
Wildcards lead to overlapping patterns
Automatic synthesis the low-level rules
Customized to the switch’s capabilities
Controller
Switches

37. Consistent Writes [HotNets’11]
Transition from policy P1 to P2
Security: new access control lists
Routing: new shortest paths without a link
Load balancer: new split over server replicas
Transient policy violations
Packets in flight experience a mix of policies
Modifying switch rules is not instantaneous
Consistent update semantics
Packets experience either P1 or P2
… but never a mixture of the two
Enables verification of just P1 and P2
CHANGE
We Can Believe In

38. Many Hard Questions Remain
Higher-level abstractions
Network-wide policy
Domain-specific languages
Heterogeneous components
Mix of end hosts and switches
FPGAs and network processors
Distributed controllers
Replication, distribution, and aggregation
Consistency and durability of state
Multiple administrative domains
Trust, scalability

39. Related Work Programming languages OpenFlow OpenFlow standardization
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

40. Conclusion SDN is exciting SDN is happening Great research opportunity
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

41. Thanks to My Frenetic Collaborators
Nate Foster
Dave Walker
Chris Monsanto
Mark Reitblatt
Rob Harrison
Mike Freedman
Alec Story
Josh Reich