Data center network fabrics vs. software – defined fabrics

Are data center fabrics and software defined networks competitive or complementary technologies?

This article can also be found in the Premium Editorial Download: Network Evolution: Data center fabric wars:

Just last year, data center network fabrics were the hot topic in networking. Flat, low-latency networks with any-to-any bandwidth promised to solve the networking problems of highly virtualized data centers. These fabrics would enable increased east-west traffic in—and free up bandwidth constraints created by—spanning tree protocol (STP), making networks responsive to server virtualization and resulting in easier-to-operate data center infrastructure.

Then something else happened—a tsunami of hype hit the networking industry in the form of OpenFlow and software defined networking (SDN). Startups emerged with claims that SDN could enable programmable networks in multi-vendor environments, solving many of the problems that expensive data center fabrics promised to fix, but for a whole lot less money.

Now network engineers and architects must sort through two separate hype machines. And they must ask whether data center fabrics and SDN are an either-or proposition, or two architectures that complement each other.

The answer to this question is hard to find, particularly because fabrics and SDNs are still very new to the market. Few enterprises have moved beyond the proof-of-concept stage with fabrics, and the availability of robust, commercial SDN products remains scarce. In fact, SDN is still evolving, and the use cases for it are still developing. What’s more, every vendor has its own self-defined data center fabric offering, but most are also cooking up SDN plans.

Proponents from either camp will tell you that their side can solve most data center networking needs. However, they’ll also concede that there is room for both.

“The goals [of SDN and fabrics] sound the same, but abstracting the network to extract complexity is one thing, and then fundamentally simplifying the infrastructure is another thing. The two working together can be extremely powerful,” said Mike Marcellin, vice president of product marketing and strategy at Juniper. “If you simply abstract the complexity like an SDN is trying to do, that can help. But if the fundamental architecture is still complex, if it’s still brittle, if you have to keep throwing more devices at the problem to scale the network, then the root of the problem is still not addressed.”
Dan Pitt, executive director of the Open Networking Foundation, which governs the development of OpenFlow, concedes Marcellin’s point to a point.

“You could choose one or the other, or you could choose a combination,” said Pitt. “But I think if a customer has a brand-new choice, a true SDN solution with its inherent benefits and with its many choices in how they procure and deploy it [that will be their choice].”

SDN is not quite ready to replace innovative hardware

When SDN and OpenFlow hype first started taking off, some industry observers predicted that OpenFlow’s ability to centralize the control plane of a network would commoditize network hardware. Switches and routers would become dumb boxes pushing packets back and forth, and the brains of a network would live on a server. However, reality has since started setting in.

“The less reasonable part of the [SDN] discussion is whether network companies are dead because young entrepreneurs can come along and buy a few parts from the silicon vendors and build stuff that is equivalent to what switch vendors do,” said Peter Christy, principal analyst with Internet Research Group. “I think that part is unrealistic because high performance, highly reliable fabric that operates on 40 Gbps links is pretty interesting engineering.”

Also, SDN remains more of a curiosity for enterprises, rather than a commercialized solution that can solve problems today. Google famously implemented OpenFlow on its WAN, thanks to a small army of internal engineers who have the expertise to build home-brewed Google gear. Similarly, SDN startups have helped some other Web-scale companies and cloud providers deploy software defined networks, but enterprises are a different animal.

“We’re still very early in figuring out the use case definitions for software defined networks,” said Michael Spanbauer, principal analyst with Current Analysis.

One of those use cases is certainly the enterprise data center, where virtualization has changed traffic patterns and added complexity. However, fabric solutions are aimed squarely at enterprise data centers with these problems, and they are shipping today.

“If I wanted to make a decision on an enterprise-class data center today at scale, I would have to go with one of the shipping fabric solutions,” Spanbauer said. “But that doesn’t mean you lock out OpenFlow as a solution down the path because all of [the fabric vendors] are active members of the [OpenFlow] working groups.”

A first step: Integrating SDN with fabric with legacy networks

Many SDN proponents point to the ability of their technology to make multivendor networks programmable from a centralized control point using OpenFlow solutions that require OpenFlow-friendly switches and routers. However, companies like Nicira Networks, Big Switch Networks and VMware will use network tunneling protocols like VXLAN, STT and NVGRE to create a software overlay network that abstracts and virtualizes the physical network from the virtual servers at the access layer of the data center LAN. This capability could be helpful to enterprises that are incrementally adding modern data center fabrics to their infrastructure. SDN can abstract that pocket of modern fabric and the rest of the data center LAN.

“If you’re using QFabric and other vendors in your data center, software defined networking could give you an overlay to that, which would allow you to manage your QFabric but then manage other infrastructure as well,” said Juniper’s Marcellin.

Are data center fabrics and software defined networks complementary?

Using SDN as an overlay to abstract management of multiple vendor footprints in your network is one thing, but SDNs and fabrics have much deeper complementary potential. Even in a data center where one vendor’s network fabric serves the entire data center, SDN can deliver added value.

“The most intelligent and pragmatic solutions tend to look at the problem of [data center] networking and break it into two pieces—the physical network piece and the dynamic network piece on top of that,” said Internet Research Group’s Christy.

The first piece—the physical network—is not trivial. “Software people don’t understand how hard it is to build a physical network that is reliable and manageable. And one of the hardest problems is [how] to use all the connecting wires on demand for whatever needs to be done at that moment. That is a difficult problem, and it is the kind of thing that network vendors like Cisco, Juniper and Arista do very well,” Christy said.

“Then there is the communication between the virtual machines, which increasingly you need to deal with in the realm of software. The problem you run into with traditional networking is when things become more dynamic and when more of the operation moves into the software at a higher level.”

Big Switch Networks, an SDN and OpenFlow startup, has at least one joint customer with Juniper QFabric, according to Kyle Forster, co-founder and vice president of marketing at Big Switch. And he anticipates having many more, not just with QFabric but with data center fabrics from Cisco, Brocade and others.

“Software defined networking gives you the functionality, and a fabric gives you the bandwidth,” Forster said. “If you want to place any virtual machine anywhere and you need to get subnets and VLANs fundamentally out of the way, you need a whole lot of management functionality. Most of that, and in my opinion, all of it is in the software defined networking camp.” A data center fabric can guarantee an enterprise equal bandwidth no matter where it chooses to place a virtual machine within a data center. As those VMs move around, the functionality of an SDN comes into play.

The joint QFabric customer, a cloud provider that caters to the healthcare industry, offers a multi-tenant environment for its customers. In that environment, it replicates a hospital’s existing data center. Over time, the cloud provider dynamically evolves those environments, moving VMs and other resources around to reduce its own internal costs. However, as it alters its internal network to support the migration of those resources throughout its data center, the cloud provider wants that network to remain transparent to its customers, Forster said.

“That means that the bandwidth guarantees had to be there [from QFabric] as [the provider] moved physical servers or virtual machines around. And he really needed to be able to place any physical server or virtual machine anywhere in the data center as he cost-reduced,” Forster said. “He wanted to be able to do that without saying to the customer, ’Oh, hey, due to funky reasons that are more my problem than yours, I want to change your IP addresses.’ That would be very distasteful to a customer relationship.”

“This is an extreme case of [a customer] wanting to get the network complexity out of the way and the VLANs and subnets out of the way,” Forster said. “We’re giving him all the Layer 2/Layer 3 functionality, and QFabric is giving him all the bandwidth.”

Every network fabric vendor is building an SDN strategy

If you have any doubts on whether fabrics and SDNs are reconcilable, look at the fabric vendors. Cisco, Juniper, Brocade, Extreme Networks, Dell Force10 and Arista Networks are all articulating and evolving SDN visions. They are working to find points of intersections between the two categories of products.

“I can’t speak for any vendor, but I suspect that every vendor is thinking about their migration strategy [to SDN and OpenFlow],” said Pitt of the Open Networking Foundation. “The general notion of fabrics is a really good idea. They are proprietary solutions that seek to solve some of the same problems that we are addressing with OpenFlow and software-defined networking in general. I think some of these original [fabrics] were by necessity proprietary, but I don’t think there’s much of a need to stay proprietary for much longer since we have a standardized approach that’s now in the market.”
 

This was first published in August 2012

Dig deeper on Network Virtualization Implementation

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

1 comment

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchSDN

SearchEnterpriseWAN

SearchUnifiedCommunications

SearchMobileComputing

SearchDataCenter

SearchITChannel

Close