network cables

What’s the Role of the Application Delivery Controller in a Software-Defined Network?

network cablesThe topic of software-defined networks (SDNs) has been one of the hottest on this site, or really any site dedicated to networking. Much of the focus of the SDN-centric reports and articles I have seen has been on the disruption of the layer 2/3 network by abstracting control functions up from the physical infrastructure to some sort of software layer that sits above the network. This enables better, more granular control over things that like QoS, network utilization, the efficiency of a network, ACLs and other things.

As I mentioned, SDNs have focused on layer 2/3 which primarily involves packet processing functions. This does nothing for managing layers 4-7 where application traffic resides. Optimizing application traffic typically falls under the realm of application delivery controllers (ADCs). So we have ADCs managing application traffic and SDNs handing the processing of network traffic. If one of the purposes of an SDN is to make applications perform better it seems we have a bit of a problem in that there’s no overlap between SDNs and ADCs. This is why I believe ADCs will play a big role in the evolution of SDNs.

Traditional SDNs should handle the routing and switching of packets and interoperate with ADCs to route and switch application traffic. While the two play a similar role, they operate differently. I mentioned before that SDNs operate by processing network packets. ADCs operate by managing application sessions. Think of a session as being an aggregation of multiple packets. This prevents any kind of erratic performance caused by the fragmentation of traffic. This is how ADCs currently optimize and secure application traffic today — on a per-session, per-request basis.

Now, there are two possible ways ADCs and SDNs can interoperate. The first is with the ADC as a slave to the SDN controller. In this scenario, the SDN controller would communicate with an ADC and, based on the analytics of network information, the ADC would then make appropriate changes to how it manages the application sessions. The communication could be through something like OpenFlow, but it could also be via a script — such as F5’s iRules — to handle custom applications. This might work but it’s hard to see how the needs of an application could be interpreted correctly by the network.

The other, and what I think is the more likely, scenario is for the ADC to be the “master” controller and pass along instructions to the SDN controller. In this configuration the ADC would do what it normally does — optimize and secure the application — but would also send instructions to the SDN controller to dynamically create a virtual network, change QoS settings or other layer 2/3 functions. This should provide network change control that’s specific to application needs instead of network changes based on network criteria.

In fact, I believe there’s a chance that in the future the ADC could subsume most of the SDN controller functionality and talk directly to the network, depending on how much of that functionality the ADC vendors want to take on. In many ways, an ADC has been doing at layer 4-7 what SDN controllers are proposing to do now, so this co-existence model in a software-defined data center certainly isn’t a stretch.

Over the next year or so, I’m expecting to see greater messaging and vision from the ADC vendors as they carve out their role in this “software-defined” world, so stay tuned as this market continues to evolve.