F5 Friday: ADN = SDN at Layer 4-7

The benefits of #SDN have long been realized from #ADN architectures

There are, according to ONF, three core characteristics of SDN:

“In the SDN architecture, the control and data planes are decoupled, network intelligence and state are logically centralized, and the underlying network infrastructure is abstracted from the applications. As a result, enterprises and carriers gain unprecedented programmability, automation, and network control, enabling them to build highly scalable, flexible networks that readily adapt to changing business needs.”

-- Software-Defined Networking: The New Norm for Networks, ONF

Let’s enumerate them so we’re all on the same page:

1. Control and data planes are decoupled

2. Intelligence and state are logically centralized

3. Underlying network infrastructure abstracted from applications

Interestingly enough, these characteristics – and benefits - have existed for quite some time at layers 4-7 in something known as an application delivery network.

ADN versus SDN

First let’s recognize that the separation of the control and data planes is not a new concept. It’s been prevalent in application architecture for decades. It’s a core premise of SOA where implementation and interface are decoupled and abstracted, and it’s even in application delivery networking – has been for nearly a decade now.

When F5 redesigned the internal architecture of BIG-IP back in the day, the core premise was separation of the control plane from the data plane as a means to achieve a more programmable, flexible, and extensible solution. The data plane and control plane are completely separate, and it’s part of the reason F5 is able to “plug-in” modules and extend functionality of the core platform.

Now, one of the benefits of this architecture is programmability – the ability to redefine how flows, if you will, are handled as they traverse the system. iRules acts in a manner similar to the goals of OpenFlow, in that it allows the implementation of new functionality down to the packet level. You can, if you desire, implement new protocols using iRules. In many cases, this is how F5 engineers develop support for emerging protocols and technologies in between major releases. BIG-IP support for SIP, for example, was initially handled entirely by iRules. Eventually, demand and need resulted in that functionality being moved into the core control plane.

Which is part of the value proposition of SDN + OpenFlow – the ability to “tinker” and “test” experimental and new protocols before productizing them.

So the separation of control from data is not new, though BIG-IP certainly doesn’t topologically separate the two as is the case in SDN architectures. One could argue physical separation exists internal to the hardware, but that would be splitting hairs. Suffice to say that the separation of the two exists on BIG-IP platforms, but it is not the physical (topological) separation described by SDN descriptions.

Intelligence and control is logically centralized in the application delivery (wait for it… wait for it… ) controller. Agility is realized through the ability to dynamically adjust flows and policy on-demand. Adjustments in application routing are made based on policy defined in the control plane, and as an added bonus, context is shared across components focusing on specific application delivery domain policy.

Offering “unprecedented programmability, automation, and network control” that enables organizations “to build highly scalable, flexible [application] networks that readily adapt to changing business needs” is exactly what an application delivery network-based architecture does – at least for that sub-section of the network dedicated to delivering applications.

WOULD ADN BENEFIT FROM SDN?

There is not much SDN can provide to improve ADN. As mentioned before, there may be advantages to implementing SDN topologically downstream from an ADN, to manage the volatility and scale needed in the application infrastructure, and that might require support for protocols like OpenFlow to participate at layer 2-3, but at layer 4-7 there is really no significant play for SDN that has an advantage over existing ADN thus far. SDN focuses on core routing and switching, and while that’s certainly important for an ADN, which has to know where to forward flows to the appropriate resource after application layer routing decisions have been made, it’s not a core application delivery concern.

The argument could (and can and probably will) be made that SDN is not designed to perform the real-time updates required to implement layer 4-7 routing capabilities. SDN is designed to address network routing and forwarding, automatically, but such changes in the network topology are (or hopefully are, at least) minimal. Certainly such a change is massive in scale at the time it happens, but it does not happen for every request as is the case at layer 4-7. load balancing necessarily makes routing decisions for every session (flow) and in some cases, every request. That means thousands upon thousands of application routing decisions per second. In SDN terms, this would require similar scale of updating forwarding tables, a capability SDN has been judged unable at this time to accomplish. Making this more difficult, forwarding of application layer requests is accomplished on a per-session basis, not unilaterally across all sessions, whereas forwarding information in switches is generally more widely applicable to the entire network. In order for per-session or per-request routing to be scalable, it must be done dynamically, in real-time.

Certainly SDN could manage the underlying network for the ADN, but above layer 3 SDN will not suffice to support the scale and performance required to ensure fast and available applications.

When examining the reasons for implementing SDN, it becomes apparent that most of the challenges addressed by the concept have been addressed at layer 4-7 by a combination of ADN and integration with virtualization management platforms. The benefits afforded at layer 2-3 by SDN are duplicated at layer 4-7 with a unified ADN already.

In practice, if not definition, ADN is SDN at layer 4-7.