Software Defined Networking (SDN) Will Change the WAN

Software Defined Networking (SDN) is increasing in popularity. SDN will fundamentally change how networks work, and adoption in small pockets will become commonplace in the next 3-5 years, writes Haseeb Budhani of Infineta.

Haseeb Budhani is the Chief Product Officer at Infineta where he is responsible for overseeing all aspects of Infineta Systems' product marketing, marketing communications, and partner management activities.

Haseeb Budhani Infineta SystemsHASEEB BUDHANI

Software Defined Networking (SDN) is clearly this year’s "Big Data." Particularly since the recent Nicira acquisition by VMware, everybody has been clamoring to get a word in about how a) Software Defined Networks (SDNs) will change the face of networking, and b) How their respective solutions are perfectly (magically) poised to win big in this brave new world. I completely agree that sooner or later, SDN will fundamentally change how networks work, and adoption in small pockets will become commonplace in the next 3-5 years. To be clear, Infineta has no plans to rebrand itself in an SDN light. We sell networking equipment that is a foundational component of all inter-data center networking, be it traffic between a physical set of storage arrays or servers, or traffic between virtual application topologies that were created via a programmatic interface.

Recently, I have been asked (a variation of) the following question by a number of industry analyst types:

“In a data center utilizing some permutation of a software-defined network, how do you see a hardware-based WAN optimization solution being deployed?”

A Typical WAN Optimization Solution

Before we get into how SDN and inter-data center WAN optimization play together, let’s agree on the core values that a typical WAN optimization solution offers for inter-data center traffic:

  • WAN data footprint reduction
  • Transport-level optimization

These are real features that are helping customers solve critical problems today, be it to reduce RPOs/RTOs for replication/backup workflows, move large data sets across thousands of miles or longer distances, move VMDKs over the WAN in near-real time for disaster recovery purposes, etc.

To increase the reduction efficacy of data traversing the WAN, it is best for the WAN optimization device to “see” as much of the data traversing the WAN as possible. In most networks, the optimal location for doing this is in the vicinity of the WAN router(s).

To increase the value of transport-level optimization, it is best for the WAN optimization device to manage congestion windows for all TCP flows crossing the WAN, so that bandwidth allocation across flows is carried out based on IT groups’ desired policies and relative application priorities.

So, really, if you want the biggest bang for your inter-data center WAN optimization bucks, deploy the solution near your WAN router.

In a software defined data center (does someone already own this phrase?), applications may be arbitrarily stretched within, and across the data center (over the WAN), by utilizing some overlay tunneling technology such as VXLAN, NVGRE, STT, or whatever else.

How Will Networks Evolve?

I will leave the pros and cons of the plethora of overlay tunneling protocols to the experts, but if you agree that SDNs are going to play some role in the data center in 3-5 years, you have to ask: If the network service element in question needs to look at the payload or deliver acceleration at the transport layer, how will it work if the actual packet is encapsulated within some alphabet-soup of a tunnel?

The easy answer: Build a virtual appliance that sits on top of an Open Virtual Switch (OVS) or similar technology, and basically abstract the overlay tunnels out of the equation as far as the network service is concerned.

The challenge with this answer is: You have to deploy a network service VM close to the data generating application, i.e. potentially everywhere in the data center. Ignoring the fact that this may be expensive (software may be cheap, but it ain’t free), the overall value delivered by this service may be minimal. In particular, if the service is inter-data center WAN optimization, data reduction efficacy will be reduced and the TCP optimization benefits will be totally marginalized.

So the easy answer isn’t going to fly. . .

The more complex answer is: Build a high-speed WAN optimization device that can be deployed near the WAN router, but is able to look inside the tunnels and do all it needs to do without any performance degradation.

This is a complex answer because such a system requires a unique architecture. Of course, it needs to scale to 10s of Gbps of capacity. But more importantly, it needs a way for policies to be applied to the tunnel payload, i.e. the actual application packet. Said another way, customers will need to take advantage of systems that can transparently terminate these tunnels at line rate.

Industry Perspectives is a content channel at Data Center Knowledge highlighting thought leadership in the data center arena. See our guidelines and submission process for information on participating. View previously published Industry Perspectives in our Knowledge Library.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.