Software-defined Networking (SDN) could radically change how networks are designed and operated, according to panelists at the Internet Architecture Board’s Technical Plenary discussion in Vancouver, Canada, which considered whether the IETF should develop protocols to support the emerging network architecture.
SDN separates the control plane from the data plane in network devices such as switches and routers. The leading SDN architecture is OpenFlow, which is a Layer 2 protocol that allows software running on routers to determine the path of packets through the network switches as a way of enabling more sophisticated traffic management.
Dave Ward, a Cisco Fellow, defined SDN as enabling applications not resident in embedded operating systems to extract and program state into networking nodes. He listed the following ways that SDN challenges basic assumptions about network design that have been popular for the last 20 years.
- Using a logically centralized data-base to keep all the information about the state of network devices, rather than having the devices store that information.
- Adopting new ways for network management systems to interact with network devices, rather than relying on transactions where state is written into configuration files.
- Taking a centralized view of network topology, rather than a distributed view.
The main goal of SDN is to make it easier for network operators to configure networks for specific applications and services, Ward said. The SDN architecture does this by moving the network away from command line interfaces and providing a standard interface that allows intelligent applications to customize network policies in real time.
Other potential advantages of SDN include faster deployment of computer, storage, and network services, as well as enabling new services. SDN could enable better usage of network capa-city, plus faster restoration when outages occur, Ward said.
However, he also pointed out that “it’s not all rosy in the arena of SDN.”
The current SDN architecture is missing information to understand topology, utilization, delay, loss, or jitter, he said. Other features that are not available include loop detection, the ability to remove duplicates, or fix errors in state. SDN doesn’t support horizontal communications between network nodes or controllers to enable collaboration between devices.
Nonetheless, Ward favors SDN. “SDN will augment and add functionality and make the Internet easier to operate, but as it’s currently constructed it’s missing a bunch of features that are necessary,” he says.
Ward says SDN requires standard interfaces to the Internet that could be created by the IETF. “Many of the critical features of networking nodes are not standardized,” Ward says. He recommends that new working groups be formed to address the architecture work that will be required by SDN.
Nick Feamster, associate professor at the University of Maryland’s computer science department, said the promise of SDN is the ability to change the network as easily as changing applications. Instead of having closed, proprietary network devices, SDN provides a single software program such as OpenFlow that can control the behavior of entire networks.
Feamster says the benefits of SDN include centralized control of the network, more sophisticated control of network flows, and the ability for operators to more easily evolve network capabilities.
“What we’re trying to do is enable operators to specify much more sophisticated policies and actions than they otherwise would be able to do,” Feamster explained.
He described the results of two SDN deployments using so-called Lithium controllers that extend the OpenFlow control model to allow network operators to take actions based on time, history, and user. Possible applications of Lithium event-based controllers include parental controls and usage caps for home networks, as well as access control on campus networks.
In home network deployments, ISPs are placing Lithium controllers outside the home so that residential customers needn’t operate their own home networks. “Those people who are unskilled and uninterested in running a home network—which is most of us—won’t have to,” Feamster said.
Feamster reported that 225 routers are deployed in home networks as part of an ongoing SDN trial involving several ISPs. The trial will be extended to try denser deployments in apartment buildings and integration with other in-home devices such as phones.
“We’re looking at how software-defined networking can simplify network monitoring and management. In our deployments and case studies, we’ve found that we need new control models to solve some of the problems,” Feamster said.
Ted Hardie, a network engineer with Google, is a fan of SDN, which he predicts will change the way networks evolve by allowing devices to change in terms of their function—from being routers to switches to load balancers to firewalls, for example. “SDNs allow a network element to be any of these, or a bit of each, and to change over time,” he explained.
Hardie said SDNs would allow networks to be routed differently. So instead of always routing for shortest path with added traffic engineering, networks might be routed to boost utilization, reduce latency, or accomplish some other goal of the network operator. Hardie referenced a data center-to-data center network that Google has built using OpenFlow that improves link utilization and drives down cost.
“What you can do in SDN is create entirely different optimalities,” Hardie said. “The network can behave differently for different flows and different optimalities.”
SDN is not without its challenges. Audience members identified several of these, including security risks from a centralized network control and state information, and reduced resiliency as network elements lose the ability to route around outages.
Bob Hinden, a Check Point Fellow, called SDN’s security implications “terrifying.” He said that the reason network devices are specialized is because they are customized for each function. He warned that a reprogrammable network device that does all functions well is “very optimistic.”
But presenters argued that the benefits of SDN outweigh the risks.
“The charter of the IETF is obviously Layer 3 routing protocols, and right now I suggest that some of the work we would want to do is to augment the current routing systems with these programmable interfaces… so we will not add routing loops and so they will work with our routing and signaling protocols,” Ward said. “If this work doesn’t get taken up because of lack of interest by this community, then it’s guaranteed to be done somewhere else. I strongly suggest it be taken up here.”