This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
1. - SDN in the data center: Read more in this section
- Will the software-defined data center go mainstream?
- Issues with a software-defined infrastructure
- Data center network fabrics and SDN intersect
Explore other sections in this guide:
Researchers at the University of Illinois at Urbana-Champaign's Ocean Cluster for Experimental Architectures in Networks are using SDN switches to test a new data center network architecture that incrementally scales bandwidth between servers without a significant hardware investment.
Ocean has installed 13 Pica8 SDN switches with a total of 670 ports that will be "sliced up" to emulate a much greater volume of smaller switches. These switches will act as a large data center network to form a test bed for a wide range of SDN applications, said Brighten Godfrey, an assistant professor of computer science at the university.
If you compare this to driving through a city, a traditional network would give you a couple of different choices [of roads on which to travel]. If you hit a lot of red lights [along that path], you're out of luck. But SDN lets us find different paths that may be longer but will be much faster.
assistant professor of computer science, University of Illinois
Ocean is testing an entirely new approach to designing and scaling data center networks, as well as a configuration management and monitoring tool that verifies instructions being sent from centralized OpenFlow controllers actually work.
OpenFlow switches support routing in a new network architecture
SDN interest has been largely driven by the need for a flexible network that can handle ever-growing demand for bandwidth between servers to support applications.
With this in mind, engineers at Ocean have developed a new network architecture called Jellyfish, which allows engineers to add switches to the network to incrementally increase bandwidth between servers. It's a significant departure from conventional networking topologies that have more rigid structures, and SDN is a critical enabler.
Currently, in conventional architectures, engineers must overprovision their networks to compensate for occasional bursts in bandwidth and to handle future growth. What's more, many data center networks depend on a fat-tree topology, which requires inter-linked switches to not vary in their number of ports. This fixed number of ports makes it difficult to add switches along the way in order to incrementally add bandwidth. When engineers do opt for an upgrade, they generally have to replace all of the switches.
The Jellyfish architecture does away with the structured fat-tree topology so top-of-rack switches can be added at random to the network. Randomly adding switches may seem chaotic, but the Ocean team is using what it calls "random topology graphs" to add switches, as well as SDN to help out with routing.
"If you compare this to driving through a city, a traditional network would give you a couple of different choices [of roads on which to travel]. If you hit a lot of red lights [along that path], you're out of luck. But SDN lets us find different paths that may be longer but will be must faster," Godfrey said.
The idea is that data would travel along more paths than it would with traditional protocols, therefore making better use of all available resources. Jellyfish can be applied to a traditional physical network, but SDN enables controlled routing in this complicated environment.
Using these random paths, Ocean engineers get 25% to 40% more bandwidth from their existing hardware, he said.
"With Jellyfish, you need less networking gear to support the same number of servers, and it gets you this operational flexibility so you can easily expand your network," Godfrey said. "This is because the physical structure of the network doesn't need to conform to these hard constraints as in past designs."
In OpenFlow network, configuration change and visibility take on a new meaning
Network configuration and change management have always been challenging, but in some ways, SDN and its random paths and virtual network provisioning make things even more complicated. Yet SDN also offers deeper visibility via centralized controllers.
More on SDN and the data center
Can SDN solve private cloud bottlenecks?
Software-defined storage: Parsing through the hype
Why we will still need fabrics with SDN in the data center
Do we need specialized SDN switches?
Ocean is testing an application called Veriflow that essentially verifies instructions from the OpenFlow controller are being carried out and ensures configuration changes. The Veriflow tool sits right beneath the controller and "watches all of the instructions streaming out to the switches from the controller," Godfrey said. Veriflow can work on a traditional network, but SDN's centralized control approach extends its capabilities.
"There are two things you get [with Veriflow]: one is an open interface that makes it easier to support a broad range of devices," Godfrey said, adding that engineers don't need to understand the "peculiar format of a new device" if every component speaks OpenFlow. "The second [benefit] is being able to see in real time this stream of rules for the network. As configuration of the network changes, or as it automatically adapts to new traffic or routes, we can check all changes to see whether they conform to the properties that operator wants."
Veriflow can use this information, for example, to check the isolation and security of network tenants or to ensure traffic coming into the network has not evaded firewalls.
Tackling challenges in centralized control
As SDN emerges, engineers are learning to solve problems on their feet. Ocean engineers are not finding problems specifically with SDN switches or controllers, but rather in the basic concept of centralized control.
Central to these challenges is that SDN "is trying to hide that you have a distributed system," but that approach doesn't always work, Godfrey said. "We can check all changes as they go out [of the controller], but we don't know when one of those forwarding rules is stalled in a device. There could be some difference in milliseconds that we can't predict."
There is currently research underway that is looking to solve issues with timing and rule implementation, but in the meantime, engineers must count on "some level of uncertainty," Godfrey explained.