Yale Ph.D. candidate Andreas Voellmy would like to take the programming out of programmable networks. It's not...
that he wants to eliminate network programmability. In fact, with his team's OpenFlow-based Maple controller, he'd like to automate SDN programming, simplify the process and make it accessible to even the non-programmer.
Voellmy's draw to SDN was born from a stint at a software development company, where he witnessed firsthand the frustrations associated with creating network commands. Each device had to be configured individually, and the commands were cumbersome at best. He figured he could couple his programming experience and the basic skills he gained as a math and physics undergrad to solve the problem.
[OpenFlow] is entering into a critical time right now, where people are forming impressions; at the moment, it seems terrific, but it's still not mature.
Ph.D. candidate, Department of Computer Science at Yale University
"[Prior to Yale], I worked with clients in different fields to solve problems and build their systems -- it was fun and satisfying," Voellmy said. "In the end, though, there were frustrating things about it as well."
The barriers to programming may not have been mathematical in nature, but they sparked two specific interests in Voellmy. The first was functional programming, or the concept of using ordinary math -- high school algebra, even -- to write programs. "It makes programming more accessible," he said. The second was domain-specific languages that could empower users to employ their own technology and systems, instead of relying on "middlemen," to make their ideas real, Voellmy said.
"That's what I wanted to do in grad school -- I wanted to make programming more accessible and empower people who are not trained as programmers or computer scientists to use this technology," he said.
BGP and functional programming at Yale
At Yale, Voellmy began to work with Paul Hudak, professor of computer science, who is an expert in both of these areas. These were the days before OpenFlow, so the two applied other programming languages and network policy languages to the problem of network configuration. In particular, Voellmy and his team tackled interdomain routing policies, which he said were "notorious for being hard and very funky."
"We were trying to define a new policy language that was easier to work with," he said. Voellmy and his team would compile and examine the Border Gateway Protocol (BGP) configurations for all of the BGP routers in a network. "Ultimately, we felt it was frustrating because the BGP protocol was so limiting," he said. "And it was hard to define any kind of higher-level abstraction off of it."
Soon Voellmy heard of the OpenFlow protocol. "Immediately, I saw [that] it gives all this flexibility to the hands of users. At that time, I hadn't spent years reading stacks of protocols and RFCs, so it made this whole area accessible to me as a person who knows programming languages and math. That was really appealing," he said.
SDN research changes networking
Jennifer Rexford discusses network programming language Pyretic
Rob Cannistra works on OpenFlow development
Nick Feamster uses OpenFlow SDN for access based control
No need for a network overhaul with Marco Canini’s hybrid SDN approach
Voellmy convinced his peers to shift the focus of the project away from BGP and onto OpenFlow. They started network management configuration on OpenFlow, which led to Voellmy implementing the OpenFlow protocol in Haskell, a functional programming language.
"I did things like apply the idea of functional reactive programming, that had been used for interactive animation, to program OpenFlow controllers," he said. "We could directly translate ideas from a mathematical control theory to the problem of traffic engineering in OpenFlow networks; we could directly translate the control theory equations into this language."
Building with McNettle and Nettle-Openflow
Early on in his OpenFlow project, Voellmy wrote Nettle-OpenFlow, a library that implements the OpenFlow protocol in Haskell. "We were using that to send messages to switches. The library handles the details of translating that into the right formats. … That's the basic layer."
Next, Voellmy began work on McNettle, an OpenFlow controller framework that's designed specifically for large, multicore servers. The framework was made to allow high-performance and multicore scaling, while also allowing users to write control logic in Haskell.
"You can see from my work, I explored a few different problems," Voellmy said. "With McNettle, I was interested in the problem of scaling the performance of the centralized controller." There's concern that one centralized controller can't scale as a network grows and will result in a bottleneck, he continued. "So we looked at how could we preserve this simple programming module that you get when you're writing a program for a single computer, and still get it scaling and performing."
Voellmy attempted to level multicore CPUs, which, in modern servers, he called little distributed systems -- multiple nodes that have a lot of memory and multiple interfaces. "It's highly distributed with caching protocols. … It's an amazing system," he said. With that in mind, he and his team scaled the controller processing by having the work execute over a number of CPUs. After looking at papers that described the kinds of loads people expect in larger data centers, Voellmy saw numbers like 20 million controller events per second. "We wanted to get a controller that could handle that kind of load," he said.
Switching up network rules with Maple
Voellmy's Maple controller builds on both McNettle and Nettle-OpenFlow. "I'm having a lot of fun working on Maple," he said. After building some real-world controllers, Voellmy realized how hard it is to build a "reasonable, production-quality controller."
"Even though OpenFlow is exciting, there [is] a tremendous amount of problems you have to solve to build a controller on top of OpenFlow." Specifically, you have to specify what rules should be included, while laying out flow tables for every switch in the network, he said.
"And with these rules … there are a lot of details in there," he said. For example, many switches have a limited capacity for the number of rules they can hold and execute at a point in time. "So if you want to write a controller that has reasonable performance acceptable in a real network."
This is a process that's susceptible to mistakes. "This stuff is switch-specific," he explained. "The optimizations you apply for one switch are going to be different for another."
In addition, the rules aren't "really enough, and the controller will always need to see some packets," he said. "For example, the controller will need to respond to some packets by sending another packet in a way that can't be mimicked by an OpenFlow rule; some packets are processed at the switch, some are at the controller, and you have to make sure they work together."
The last problem Voellmy recognized is the idea that when a controller installs a rule in the network, that rule can depend on multiple different states of the network. For example, the rule could be there because the sender of the packet is in a certain location or topology of the network, which results in the packet being sent on a specific route. As soon as the state of the network changes -- a host moves to a different location, for example -- rules need to be updated. "The problem is not just about compiling the rules, but also about maintaining them as the state of the system changes, and that's challenging to keep track of," he said.
So the Maple controller created by Voellmy and his team automates all these complicated details. "It takes a different approach to how a software-defined network is programmed. We call the user's program an algorithmic policy," he said.
In this system, a programmer writes a function, referred to as F, in a familiar programming language, such as Java or Python. The function will then take as input a packet and the network state, as well as a user-defined configuration in some cases, and return with the route of how the packet should be treated in the network.
"And this function F doesn't have to say anything about rules," Voellmy explained. "It's focused on saying, 'Here's the packet, and here's what should happen to it.'"
Then, the Maple system manages the network to keep the rules in sync. "The semantics of Maple is that the function F is applied to every packet in the network, and that's the high-level idea," he said. "The network will operate as if every packet is going through ‘F,' but of course, we want to implement this in a scalable way, so we compile F into rules for all the switches in the network."
Math makes the Maple controller
To make all this happen, Maple doesn't rely on the programming language; it allows people to program ordinary Java functions. After this happens, Voellmy and his team run the program on packets and observe how it executes over time. "By just looking at how the program executes when we give it a few packets, we can see how that function depends on packets in general," he said.
Voellmy and his team have a prototype of Maple, which they demoed earlier this year at the Open Networking Summit, and later at Open Networking User Group. They currently have the controller running at Yale on HP switches, and Voellmy is working on organizing real deployments of the Maple controller. "We're still in the process," he said. "We haven't finalized them; we have described the algorithms in our academic papers and fill out the prototype so it does more features for real use cases." He's hoping this will include firewalls, monitoring and routing, Voellmy said. "But each new feature or use case brings a new obstacle, so we're flushing out the functionality with real use cases."
Looking to the future of SDN and OpenFlow specifically, Voellmy said it's unclear to him where it will go. "On one hand, it's clear from a research perspective that it's a really appealing model," he said. "Used in an educational setting, it will probably be a major area of impact as a way of teaching about networks and experimenting." However, as OpenFlow continues to be implemented more and more, Voellmy said the industry is reaching a crucial point with the protocol. "[OpenFlow] is entering into a critical time right now, where people are forming impressions; at the moment, it seems terrific, but it's still not mature." If OpenFlow doesn't mature quickly, Voellmy continued, it could have a negative impression that lasts for a while. "That may make it hard for OpenFlow to take off," he said.