Programming Languages for Programmable Networks Jennifer Rexford Princeton University http://www.cs.princeton.edu/~jrex http://www.frenetic-lang.org/ 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.

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… 

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…

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

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

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

Rethinking the “Division of Labor”

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

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

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

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

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

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

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

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

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

OpenFlow Networks

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=10.1.2.3, dest=*.*.*.*  send to controller

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

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

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

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

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 http://www.openflow.org/videos/

Challenges of Programming Software Defined Networks

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

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.

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.

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.

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

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

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.

Frenetic Language and Run-Time System http://www.frenetic-lang.org/ Joint work with Nate Foster, Dave Walker, Chris Monsanto, Mark Reitblatt, Rob Harrison, Mike Freedman, Alec Story, Josh Reich

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]

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)

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

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

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

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

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 http://www.openflow.org/ https://www.opennetworking.org/

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

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