Vendors take alternatives to OpenFlow SDN
A comprehensive collection of articles, videos and more, hand-picked by our editors
Now considered a software-defined networking pioneer, Nick Feamster began his research journey at the Massachusetts Institute of Technology in 2001, when frustration with network troubleshooting led him to work on a pre-OpenFlow controller that would set the stage for the future of programmable networks.
Today, Feamster is an associate professor at the Georgia Institute of Technology, where his development of the first SDN-focused college course took place. As a Ph.D. student at MIT, Feamster and his advisor Hari Balakrishnan attempted to make networks easier for operators to manage, troubleshoot and secure, but they found trouble with the very way that networks were configured.
It will be interesting to see how we tackle these problems in network operations and management, and which of those SDN [makes] easier.
associate professor, Georgia Institute of Technology
Through his Ph.D. work, Feamster developed a tool called the Router Configuration Checker, which was used to find issues with Border Gateway Protocol (BGP) configurations using statistical analysis. The goal of the Router Configuration Checker was to enable network operators to test and debug configurations before deploying them in an operational network.
"As we were doing that work, it became clear it would be difficult to maneuver the behavior of the network by looking at low-level configurations," Feamster said. "You're looking at device-level configurations and router switches, and trying to fix your server across the entire network. No single router and switch knew what was going on."
Feamster had an epiphany -- troubleshooting based on behaviors from distributed low-level configurations across routers "is just a bad idea," he said. "I became interested in approaches and technology that could basically affect the behavior of the network based on some high-level program or configuration. ... We had the idea to work on high-level languages and control framework that dates back as far as 2004."
Routing gives way to a basic SDN controller
It was around that time that Feamster told Balakrishnan that high-level languages were hard to analyze in terms of the fabric configuration. "I said, 'Maybe we should develop a new language for helping operators.'"
The problem, he realized, was that asking network operators to learn a programming language was a tall order, since most are never trained to program and aren't willing to learn additional languages, he said.
"Furthermore, it wasn't clear how to decouple the network device and configure from whatever that language was, because there wasn't OpenFlow, and we were talking about high-level languages," he explained.
So Feamster set out to develop what he called a very basic SDN controller that would solve these issues. Prior to 2005, Feamster had met fellow researcher Jennifer Rexford during an internship at AT&T in 2001. He and Rexford came back together to work on this platform. "We called it the Routing Control Platform, which was motivated by my earlier work on configuration," he said. "We said, 'OK, configuring the network and changing behavior is hard. Why not have a controller where we do all the configuration in one place and use routing protocols to push out rules to routers in the network?'"
Needless to say, Feamster and his team didn't have OpenFlow but did have other routing protocols available to them. The idea, he said, was to hijack routing protocols and put a "super router" in the network. "That router would configure in a central way and talk to other routers in the network. … And then, it would exert its will on other routers in the network by pushing the right routing protocols. So in that sense, it was kind of like an SDN controller, except the control plane wasn't OpenFlow; it was the Border Gateway Protocol."
Hitting the SDN wall -- until the introduction of OpenFlow
By tricking routers into doing what a single controller wanted them to do, Feamster began his journey into the world of software-defined networking. However, he admittedly "hit a wall" after doing that work in 2005. "We implemented a prototype of that controller in late 2005," he said. "Because our work was very specific to routing, no one else had thought at that point, 'Could we use this kind of controller to control other parts of the network besides routing?'"
Flash-forward about four years, though, and Feamster found himself embracing SDN once again -- and the new OpenFlow protocol -- at Georgia Tech.
Stanford University had embarked on the Global Environment for Network Innovations (GENI) project, which deployed OpenFlow switches on a number of campuses around the country. Georgia Tech was one of the first deployment sites, and as a result of the effort, Georgia Tech became the first campus network to deploy a multibuilding OpenFlow network, Feamster said.
"At that point, the question was what to do with it," he said. It was shortly after the GENI project that Feamster and the CIO of Georgia Tech looked to OpenFlow in hopes it could help with a number of network management problems the college was experiencing. "That reinvigorated my 10-year passion," Feamster said. "We had hit that wall in 2005, but slowly, we had a campus deployment and a supportive campus IT department who wanted to see [whether] OpenFlow could solve various problems."
Using OpenFlow for event-based network access control
In an effort to see what OpenFlow could really do, Feamster and his team went on to build an access control system on Georgia Tech's OpenFlow network.
"So stringencies can occur, as well as traffic flows, people visiting the campus and registering devices," Feamster said. "And these devices could become compromised. Basically, what happens is … network operators are changing the configuration in response to these events." Hundreds of these events could occur in a single day, Feamster continued, forcing the change of many low-level configurations.
"We were back in the nest we found ourselves in in 2003, 2004, when we were working on routing and configuration checking," Feamster said. "We had operators touching low-level configurations all the time. … The insight there was, if we're going to use OpenFlow to solve network management, we need to do something with access control, and we need to do something with event-based control."
Feamster began designing a controller that would respond to all these various events that could occur within a network. He pointed out how important it was to have the controller respond to an event accordingly, depending on what device the event was occurring on or who it was effecting. "For example, when a host is infected, it depends on if it's a visitor, who you could block completely. But if it's the president or provost, you want to do something different," he explained. "So depending on the event that occurs, you may want a variety of different actions."
Keeping that in mind, Feamster created what he calls his flagship SDN project: a control plane called Resonance. "It's basically a controller that allows network operators to manage and secure their networks better because they can write policies in high-level languages, like Pyretic," Feamster said. The Resonance system uses programmable switches to manipulate traffic at lower layers. Switches then take actions to enforce high-level security policies and distributed monitoring and inference systems.
"The last part of the story is, there are all these different types of events. … There's all different things that could happen, so we built on top of the work [of] The Frenetic Project that allows modules and policies," Feamster said. The Frenetic Project, which Feamster's former colleague Jennifer Rexford works on, is aimed at developing network programming languages in the context of OpenFlow networks. Frenetic offers a domain-specific language -- like Pyretic -- which allows network operators to program the network as a whole, instead of manually configuring each connected network device. In addition, the project supports an application developer looking to write a controller application and code in a modular way.
"We can write an event-based program [that says], 'Here's what we want to have happen for security and traffic control'; the operator can write individual modules … and use Frenetic to compose them," Feamster said.
SDN as the tool
Looking ahead, Feamster stands behind this idea that SDN is simply a tool. "It's a new way of configuring the network," he said. "So just like when we started tackling access control problems, we had a different set of problems than we did with configuration 10 years ago," he said.
SDN isn't a panacea, he continued. The tool doesn't specify a solution, and it doesn't specify an application. "It's just a way of allowing network operators and programmers to control the network in a different way." Feamster predicts that in the coming years, engineers will spend time figuring out the best use cases and applications for SDN.
"Google's use of SDN to do traffic engineering in its backbone network, for example, was a specific use case. And now, on a campus, we have access control … but [SDN is] just a tool. We can revisit all the network management problems, like security, data leakage, traffic control, access control, etc., and I think it will be interesting to see how we tackle these problems in network operations and management," he said.
SDN is essentially a lens, Feamster concluded -- one that gives the industry a different perspective on an old set of problems. "SDN is a tool and a simpler way of looking at things," he said. "But it creates a new set of problems." These problems include challenges such as designing control applications and security, he said. "Whether or not those problems are easier to solve than the ones we have now, I'm optimistic. SDN makes solving certain problems easier … but we have a lot of work ahead of us."