SDN is Network Control. ADN is Application Control.

#SDN is disruptive but it's not destructive, especially not at layer 4-7

In the wake of VMware's acquisition of SDN notable Nicira there was a whole lot of behind-the-scenes scrambling to understand the impact to the entire networking demesne – especially given speculation that after SDN focuses on L2/3 network virtualization it will move to encompass L4/7 services including ADCs and network security.

That sounds more than disruptive, it sounds downright destructive.

But the reality is that SDN is not designed for layers 4-7 and its focus on layer 2-3 – and specifically its packet-processing focus – has long been shown to be inadequate for managing application traffic at layer 4 and above.

SDN is about moving packets seamlessly and dynamically. It solves issues that have long been problematic for very large networks and service providers but in the wake of virtualization and cloud computing have begun to emerge as a challenge for unlarge networks and, in particular, cloud providers. These challenges revolve around limitations in Ethernet routing and switching standards as well as managing the high volumes of change inherent in cloud computing environments. To resolve this, SDN proposes a centrally controlled, programmable network model that overlays traditional physical networks. This overlay addresses limitations (such as those imposed by the VLAN standard) and the problem of physical wiring required to properly route traffic across networks in the face of failures and route changes.

SDN solves this by decoupling the control and data planes, leveraging programmable switching infrastructure and creating an overlay network without the limitations that hold back traditional networks.

But at the end of the day, SDN is about routing and switching and forwarding of packets.

ADN, on the other hand, is concerned with the routing and switching of applications and the forwarding of sessions. Its model is a mirror of that of SDN, but at the application layers (4-7 of the OSI model). ADN is not – and cannot be – primarily concerned with the forwarding of individual packets, as the application data upon which ADN works is an aggregation of multiple packets, i.e. application data which has been fragmented necessarily over multiple L3 packets by limitations imposed on it by Ethernet standards. Simply establishing a TCP connection, for example, requires the exchange of no less than 3 packets of data: SYN, SYN-ACK, and ACK. An ADC will not even begin to make a routing decision until all three packets have been exchanged and a session is established. This is the mechanism through which application security and routing are achieved – on a per session, per application request basis.

ADCs, therefore, are at least half (and the best are full) proxies. Packets are not forwarded until a decision has been made, and thus are required to maintain large stores of session data in their systems. SDN does not provide at this time for such functionality (though it certainly could in the future). Furthermore, SDN would need to solve a significant processing issue around the variability in making decisions at layer 4 and above. Simply load balancing based on source IP or other primitive methods would be possible for SDN and unlikely to overtax the system too much, but such basic functionality is decades old and been proven ineffective for adequately scaling applications while maintaining acceptable performance.

Improving beyond such rudimentary capabilities would be difficult for SDN, because it requires processing of each and every request. SDN is able to perform (right now) because only the first time a pattern is seen is the controller required to inform the switching fabric how to route matching packets. Each time thereafter the switching fabric uses its local FIB (Forwarding Information Base) and merrily forwards the packet. When attempting to add security to the mix, each and every request must be evaluated – often at a rate of thousands of requests per second.

SDN is simply not designed to handle the application layer processing needs of layer 4-7 and is unlikely able to scale to the levels needed to detect and prevent a large scale application-layer DDoS let alone a massive and sudden rise in layer 7 requests (such as a web application) because the number of DPS (Decisions per Second) that can be made by the controller is limiting in an SDN model.

The Intersection of SDN and ADN

ADN and SDN are not competing technologies. ADN and SDN are highly complementary and serve to solve to same problems, they each merely do so at different layers of the networking stack. As Mike Fratto recently pointed out, SDN will augment networking, not replace it:

In a perfect world--one invented 15 minutes ago--software-defined networking startups could build virtual network products that aren't encumbered by 30 years of tinkering with Ethernet. Ethernet has served us well, but as IT moves toward the software-defined data center , the network "is the barrier to cloud computing," according to Nicira (which was recently acquired by VMware). But, of course, the technology from Nicira will augment, not replace, traditional networking.

-- VMware's SDN Strategy Is No Threat to Cisco, Juniper or Anyone Else

Mike was focusing on traditional networking (layer 2 and 3) but the reality is that his words apply equally to layer 4-7. VMware's strategy is sound, but it is not a threat to its partners or others in the layer 4-7 space. SDN is disruptive to the space, but it's not destructive. SDN will force change as it is adopted, no doubt there. There will need to be adaption by layer 4-7 ADN vendors to adopt and support SDN programmability in its switching fabrics, as a means to integrate with a broader SDN initiative.

ADN and SDN intersect where core layer 2 and 3 routing and switching functionality is required as a means to forward data to the proper systems after the ADC has determined the target. ADN will necessarily need to support SDN in its underlying switch fabrics, most likely by tying into the SDN management plane through API exchange, interpretation, and action, while maintaining its existing capabilities at layer 4-7 as a means to address volatility throughout the upper realms of network stack.

As noted in other posts, ADN is architecturally SDN at layer 4-7, decoupling the data and control planes and enabling programmability through open APIs and scripting languages. The ADC provides the basis for expanding functionality of processing through plug-ins, much in the same way the SDN controller is designed to allow "applications" to extend processing functionality on a per-packet basis.

This intersection provides a model framework for future network architecture in which SDN is used to manage intra-networks in which a high volume of change or large scale number of nodes is present that requires the flexibility and dynamism inherent in SDN. ADN will still provide the core perimeter application traffic routing it has – including security – but its interface to the applications and systems for which it manages traffic will be an SDN-enabled interface, controlled by a packet delivery controller (or by whatever name the vendor in question decides to give it).

Referenced blogs & articles: