Flowlog
April 18, 2018

Today we'll explore the power and pitfalls of Software Defined Networks, or SDNs. An SDN is a network that has a centralized protocol carried out by an all-seeing controller device. Switches in the network rely on the central device to confer instructions regarding how to treat incoming packets.

The central controller of an SDN runs a program P that is fairly simple to specify. P takes in a network state (the current status of whatever data structures the controller is keeping track of), and a single recieved packet. It then outputs an updated state, and a set of packets that should be send onwards. This output set of packets may be empty (if the network wanted to block the incoming packet, for example), may contain an altered or unchanged version of the input packet (if it needs to be sent on) or maybe even additional packets. In short, the controller has lots of freedom in how it manages the network.

Unfortunately, this kind of freedom has some drawbacks. For example, it is REALLY SLOW: if the central controller has to handle every packet on every router in the network it can easily get backed up.

Fortunately, there are some optimizations we can make to prevent controller overload. One possibility is to process the first of a series of related packets (for example, a Netflix stream) in the central controller, which then tells the appropriate switch to forward additional packets from the same source to the same place without sending them up to the controller. In practice, there are lots of these kinds of directives that the controller can hand down to the routers to lighten its load a little.

However, adding directions to routers on the fly is tough to do correctly, because it involves tossing aside our original simple abstraction of the controller program--in addition to providing directions to switches on how to handle their current packets, it must develop instructions for the future and send those back down to switches as well. That is, the controller program has to consider multiple tiers of operational complexity.

Failing to correctly write the controller program introduces many potential bugs! A particular switch might fail to send an important packet that the controller needs to see up to to the controller, or the controller might fail to handle dead switches.

Some of the research Tim does is in developing solutions to SDN issues. Along with research partners, he developed Flowlog, a tierless SDN. A programmer using Flowlog can program as if our original controller abstraction is correct. They can write a program that deals with every packet, and Flowlog handles compiling that program into one which handles some packets directly, and passes down directions to the various switches without the programmer having to explicitly choose when this happens.

In addition, every Flowlog program can be automatically converted into an Alloy specification for the purposes of verification; we can confirm that as written, our configuration ensures many of the properties we desire in a well-behaved network.

The Flowlog paper can be found here, if you want to learn more about it!