IMO: Selection Criteria for SDN Controllers


As the Software Defined Networking (SDN) hype dust settles, more vendors are offering SDN products that represent their take on the “how the world will be a better place with SDN” strategy. I figured that we should really get a better sense of what matters and what doesn’t when it comes to SDN controllers, as well as recognize the best ways to determine which controllers are a good choice.

In order to start addressing this question, I’ll first lay out the two main approaches in this space: the pure SDN controller approach, and the network equipment manufacturer (NEM) specific approach. The former is when the SDN controller supports (can control) multiple SDN switching and routing devices from different vendors. The latter refers to the network, which is likely to work well with the network gear from that specific NEM.

Beyond the origin of the SDN controller, there is the open source vs. commercial controller perspective that should also be factored into the overall consideration. I will not address this question in this blog post, as it is no different with SDN controllers than in other technologies.

IMO, otherwise known as the premise of SDN, is the ability to have the network be more compliant with the applications that are running in it. This principal is what should be influencing your preference criteria for an SDN controller. Ask yourself what you want your network to do. As I see it, there are a few basic types of networks, of which there are numerous variants. The following are the main types of networks as I see it:

  1. Data center networks – networks that are designed to host servers and applications supporting high-speed communications from the data center out. Data center networks also require relatively high-speed horizontal communications of servers communicating with other servers (i.e., multi-tier applications, application clusters, virtualized workload migration, etc.).

  2. WAN networks – typically designed to enable any-to-any network connectivity between distant locations in a highly available fashion. The link types of a global wide area networks are different between the different connections. Some are leased lines, some are dedicated lines, some are shared lines and some may even be VPN connections.

  3. Campus/Employee networks – typically designed to connect users to data centers most efficiently, somewhat similar to data center networks, though less demanding on the front of horizontal traffic. One exception of horizontal traffic is VoIP, in which media traffic flows directly between clients.

  4. Wireless Public networks – typically designed to connect users out to the public Internet, often by means of backhauling traffic to a central location. Typically, they’re not horizontally traffic-supported and only traffic directly from user devices to the Internet.

  5. Backbone networks – intended to connect other networks – of any type – together, typically designed for high-speed and differentiated network service levels.

Since each of these networks function and operate differently, organizations that are trying to build a specific type of network should choose an SDN controller based on the best solution to their network requirements. The physical and speed characteristics of the network, the types of network devices that construct it, the applications that run in it, and the type of personnel that will be in charge of operating it are all very important factors. Consider these elements in terms of network specifications that will serve to qualify and disqualify different SDN controller types.

Below are a few questions (not a finite list by any means, just a list that is “network function” oriented) that can help define the network controller type preference:

  1. Is the network going to be constructed on a set of similar (or dissimilar) devices? Are they all from the same vendor? (e.g., multiple global worldwide locations running totally different routers)

  2. Is the network expected to host specific functionality that can best be achieved by using a specific controller? (i.e. Radware DefenseFlow on Cisco XNC and OpenDaylight)

  3. Is the network engineering/operations team that will be responsible for running the network familiar with certain vendor products? Or is the network planned to be used by a software development team for a new project?

  4. Is the network forwarding scheme predictable and steady, or are there expected to be many moving parts corresponding to changes in application behavior?

While there are more questions to ask that can help define requirements from the SDN controller, the main point to consider is valuing the SDN controller based on the proven functionality it offers in the realm of a specific network challenge. It’s not about buying a new network, it’s about solving a problem in a way that wasn’t previously possible.

Lior Cohen

Contact Radware Sales

Our experts will answer your questions, assess your needs, and help you understand which products are best for your business.

Already a Customer?

We’re ready to help, whether you need support, additional services, or answers to your questions about our products and solutions.

Locations
Get Answers Now from KnowledgeBase
Get Free Online Product Training
Engage with Radware Technical Support
Join the Radware Customer Program

CyberPedia

An Online Encyclopedia Of Cyberattack and Cybersecurity Terms

CyberPedia
What is WAF?
What is DDoS?
Bot Detection
ARP Spoofing

Get Social

Connect with experts and join the conversation about Radware technologies.

Blog
Security Research Center