Application Delivery Controllers and Software-Defined Networking: SDN is a Layer 2–7 Industry Now
Software-defined networking (SDN) started out as an architecture for solving the inefficiencies of Layer 2/3 networks. SDN initially neglected the rest of the Open Systems Interconnection (OSI) stack, but that should change quickly as application delivery controllers (ADCs) and other network services expand their involvement in the SDN industry.
As SDN pioneer and UC Berkeley professor Scott Shenker mentioned in a 2013 seminar, SDN’s original focus on Layer 2/3 was a mistake because Layer 4–7 appliances (or “middleboxes,” as he calls them) are just as prevalent in networks as switches and routers. You can’t reinvent Layer 2 and Layer 3 networking without the rest of the stack.
Some of the early discussions that I had heard about SDN and Layer 4–7 services assumed that these network functions would evolve into applications that would reside on the SDN controller, implementing their services via the controller’s northbound API.
More recently, the SDN industry has recognized the need to orchestrate Layer 4–7 services in parallel with Layer 2/3 SDN to enable service insertion, policy migration, etc. Layer 4–7 middleboxes are destined to be implemented by SDN at the network edge, Shenker said. So far, this prediction has amounted to little more than a constellation of ADC and firewall vendors joining the technology partner ecosystems of leading SDN solutions and open source projects for rudimentary integration. However, ADCs, firewalls, and other Layer 4–7 services have a lot more to offer the SDN world.
We’ve seen ADCs and other Layer 4–7 services decomposed into virtual appliances that reside on hypervisors. This evolution has the potential to make networks much more agile and dynamic in how they apply network services. And it’s clear that SDN will play a major role in the orchestration and chaining of these virtualized services. These changes in the Layer 4-7 space amount to an enterprise version of network functions virtualization (NFV).
However, enterprise NFV is just an SDN use case. It doesn’t actually address the value that ADCs and other Layer 4–7 services can bring to SDN. For instance, ADCs have the opportunity to serve as SDN gateways to application-layer services like load balancing and web application firewalls. By adding support for SDN-related protocols like VXLAN and NVGRE, many ADC vendors have taken a step in that direction. This points to an evolving architecture where the SDN controller is the master system that pushes instructions to ADCs and other appliances, just as it does to switches and routers. The controller can service chain ADCs, firewalls, and other virtual appliances together, directing traffic to these boxes as needed.
Another route exists, however. Don’t forget that these Layer 4–7 systems are inspecting network traffic at the application layer. ADCs have a great deal of insight into the nature of traffic, far different from what switches and routers can glean by processing packet headers. What if they could push that information about applications and sessions to the SDN controller, giving the controller the ability to make decisions based on application-layer intelligence? And vice versa, what if the SDN controller could push telemetry about Layer 2/3 networking to the ADC, giving it more insight into how its application-layer traffic decisions will unfold on the network?
The exchange of network and application session information, if executed properly, could make SDN far more responsive to the needs of applications. To enable this intelligent exchange of information, developers may need to build new modeling and abstraction capabilities into SDN controllers and ADCs.
Although it’s been said many times before, we are still in the early days of SDN. An ADC’s role in SDN could take many forms, not just the ones discussed above. A network operator may end up having several options for leveraging value from an ADC in an SDN environment.
