Jennifer Rexford's path to the world of SDN research began out of frustration with the most traditional of physical networks.
Prior to coming to Princeton University in 2005, where she now is the Gordon Y.S. Wu Professor of Engineering, Rexford worked in the research labs at AT&T and fully experienced the pains of designing and operating a network. "I saw how difficult it was for carriers to innovate," she said. "They would depend on long standardization processes and complicated relationships with equipment vendors. Seemingly simple things were complicated."
The problem was that traditional physical networks tended to be inflexible, requiring users to stand by their proprietary operating systems that failed to have the ability to make the network bend.
Rexford and her co-workers began tinkering with underlying routers in the AT&T labs, in hopes of modeling what could be possible when using equipment in different ways. "We looked at whatever was available to [the company]…," she said. "Everything was working backwards. We knew what we wanted to do, but we needed the tools to coax the network into doing what we wanted it to do in the first place."
Rexford's frustration with AT&T networks sparked her interest in software-defined networking, she said. A colleague at AT&T mentioned to Rexford that during the 1970s, there was a move to separate the control of the network from the network itself. Rexford ended up finding research papers documenting the movement. "I said, 'Wow, that's interesting,'" she said. The papers were geared toward telephony networks, but Rexford immediately thought of what the concept could mean for the IP network at AT&T. As a result, she began working with a rough version of an SDN controller within the AT&T network in the early 2000s.
"It would be considered now a poor man's SDN controller," she said. "We used it to control the ways they did interdomain routing." The controller was also compatible with existing routers in their network. "It wasn't as flexible as OpenFlow, but it was still this idea of a programmable, general purpose computer that had logically central control over a distributed network," she said.
From makeshift SDN to OpenFlow at Princeton
Cue OpenFlow's introduction to the world of networking. The buzz around the new protocol began in 2006, after Martin Casado, Nick McKeown and teams at Stanford and Berkeley helped research and evolve the idea of Ethane -- which used a flow-based network and controller with a focus on network security -- into the better-known OpenFlow protocol.
Rexford had been involved in a number of routing control platform projects at AT&T, which eventually lead to the idea of a 4D approach to network and control management. The idea was similar to Casado and McKeown's Ethane, which was essentially a 4D-like architecture for enterprise access control, said Rexford. It was around this time that Rexford realized that the new version of Ethane was what she and her colleagues were attempting to do at AT&T; however, OpenFlow was more "general" and had a broader audience.
After Rexford made the move to Princeton, she became more involved in various SDN projects, including some that looked at backbone networks, reminiscent of her work at AT&T. When the OpenFlow API became available, she started pursuing more research on OpenFlow. Her main focus these days, though, is SDN programming languages. This "kicked-in" around the same time as the OpenFlow API introduction in early 2009, said Rexford, "and in earnest later that year, when Nate Foster, now a professor at Cornell, came to Princeton to start a post-doc with my colleague David Walker and myself. Our first paper on Frenetic appeared in December 2010. "
Nowadays, Rexford is collaborating with colleagues at Princeton and Cornell on The Frenetic Project, which is aimed at developing network programming languages in the context of OpenFlow networks. According to the project website, current languages used in programming networks tend to be error prone and lack modern features. The goal of the project, however, is to offer a domain-specific language, specifically for software-defined networks, that allows network operators to program the network as a whole instead of manually configuring each connected network device. It specifically addresses OpenFlow programming problems by introducing a set of functional abstractions, which help with modular program development and the difficulties associated with the two-tier programming model, among other things.
"It's a nice opportunity to bring community in and raise the level of abstraction for programming the network," Rexford said. "It was born out of that same frustration at AT&T…. SDN was making it possible to program the network, but it wasn't easy. We had the opportunity to think from scratch, ‘How can we do this?'"
Rexford admitted this wasn't an area of expertise for her, or one in which she had a background. "Frankly, networking has been an impenetrable area for people outside of networking," she said. "It's riddled with three- or four-letter acronyms. But the nice thing about SDN and OpenFlow is that it's a clear model of how the data plane and control plane work; it's possible to explain to people who don't revel in the minutiae of networking." In an academic setting, Rexford added, "this is a great vehicle to get computer science people interested in networking, and that's what happened here."
Creating top-notch programming languages
The Frenetic Project was developed to more tightly link controller application to the state of the network and ease programming across distributed resources.
"Once you decide on how you want to change the network, you're often taking a distributed collection of switches and updating the rules in many of them to affect that change," Rexford said. "What we've been doing is looking at that control loop, measuring the network and deciding what to do, depending on that measurement, to change the way the network behaves."
Rexford and her team find abstractions in each of those three steps to make it easier for a programmer to write network control logic, while not worrying about the details around patterns, rules and events coming into the controller -- things that tend to be "tedious and error-prone," she said. The abstractions, she explained, help update the network. "Say there are a bunch of things I want to say to a bunch of switches," she said. "[The abstractions] update switches and make sure none of the packets flying around in the network have weird things happen to them while these updates are happening."
However, possibly the most important part of the project, said Rexford, is supporting an application developer who is writing a controller application. "We want [the developer] to be able to write that application in a modular way, so they can combine multiple pieces of code, either written by themselves or others, without worrying that those pieces of code will step all over each other when working with the rules of the switches," she said.
"In the end, it's still one network, one set of rules and one set of events and switches. We want to make sure the right things happen when the programmer says how they want those modules to be put together."
Frenetic plus Python equals Pyretic
As part of the Frenetic Project, Rexford has worked on developing Pyretic, a domain-specific language that's embedded in Python. Although SDN has helped applications realize tasks like routing and traffic monitoring directly, today's SDN platforms don't provide full support for creating modular applications. In turn, Pyretic, which is open source, enables modular programming in a number of ways, such as defining composition operators and a library of policies for forwarding and querying traffic, as well as enabling each policy to operate on an abstract topology.
Rexford said Pyretic in particular is picking up speed within the industry. The language was featured in an assignment within Nick Feamster's online SDN course this past summer, where 1,000 students completed a Pyretic-based project. In addition, companies are "kicking the tire and trying it out," she said. "It's not a production system in a real sense -- it's still a research prototype, but the platform is interesting and we've been getting high-level ideas of what could be done with it. Our hope is some of those ideas may get in other control platforms and [in] other work, extending it and supporting open source platforms in hopes it will develop more of a following."
Driving home the potential of SDN
The relationship between SDN and the academic world is a new and refreshing one, said Rexford. In networking (as in other areas of technology) there has always been a gap between what's happening in academia and the impact research can have on actual operations. "What's exciting about SDN is, there's a great synergy between what the industry is trying to do and what academia finds interesting," she said. For Rexford and other researchers focusing on the SDN space, it's a great opportunity to directly see the impact of the research in real time.
"It's a great time and a rare opportunity to get things right as the technology takes off," she said. "And also because it's trying to bring some conceptual foundations to the parts of networking that have always been a mess, which is the design and operational sides of the network."
SDN projects from the channel perspective