Newsletters




Software-Defined Networking (SDN) is the New Black but Application-Delivery Networking Provides Key Services


Bookmark and Share

Software-defined networking (SDN) is the new black for IT, displacing cloud as the technology darling du jour. The SDN market is already fragmenting to try to address specific needs, with network virtualization, tunneling, and separation of control and data planes. Despite this dispersal into tighter focused segments, all three maintain a common theme: a focus on layers 2-3 of the network stack.

And while all this focus on the network layers is ultimately good for applications—after all, an optimized network is critical for applications today—it does not address challenges in the application layers (layers 4-7) that are just as key to ensuring performance, security, and availability of applications in the data center and into the cloud.

Making the situation more difficult are emerging application architectures that decompose applications into tightly focused services. In conjunction with this emergence is the ascendency of the API across all types and sizes of organizations. This shift in application architecture puts the importance of services in the application layers in the forefront. Security, optimization, and availability at the service level become as important, if not more important, because any one of them can be disruptive to multiple applications.

Application-delivery networking (ADN) has always focused on the application layers of the network stack, providing services specifically designed to enhance and improve application security, reliability, and performance. SDN, with its focus on the network, does not.

3 Reasons Software-Defined Networking (SDN) is Distinct from Application-Delivery Networking (ADN)

SDN and ADN maintain very different foci because the network stack (layers 1-7) is naturally bifurcated; there has been and still remains a clear delineation between layers 2-3 and layers 4-7. This is primarily due to three distinct conflicts in the resources and processing models required to handle each segment of the networking stack. Let’s take a closer look at each one.

Packets Versus Messages  

Networking is, at its core, about passing packets from point A to point B. The goal of a layer 2-3 device is to pass a packet from an ingress port to an egress port as fast as possible. With SDN, the way in which such decisions are made has changed from static, pre-defined routing and switching tables to more dynamic and fluid methods, but the core premise remains the same: pass the packet.

ADN, focused on the application layers, is about messages. Messages are composed of one or more packets, of course, but the value in a message is in its data. By itself, a single packet cannot necessarily tell you what application protocol is being used, what client device the packet came from, or which user made the request. ADN is able to do so because it reconstructs messages that carry the data—data that is vital to the security, availability, and even performance of the application.

For example, an SDN cannot determine which version of an API a request may be destined for because it lacks visibility into the message. ADN, on the other hand, can easily extract API version information because its focus is on the messages being exchanged.

I/O Function Versus Processing Messages

A second challenge for SDN is its focus on input and output (I/O). The primary metric of I/O is based on packets per second, which measures how fast packets can be processed through the system. This means that the underlying hardware and software that supports layer 2-3 devices is designed to focus on pushing packets through the data path as fast as possible. As such, layer 2-3 devices are almost always stateless; their forwarding decisions are based on individual packets only to facilitate this focus on speed.

ADN, however, is focused on processing messages and maintaining the state of connections between endpoints. This requires much more computing power and memory than layer 2-3 devices. Processing a message requires reconstruction from multiple packets, which necessitates storing them in memory until the entire message has been received. Additionally, ADN must store information about the connection itself—usually the established TCP session over which messages are exchanged. Maintaining session tables require significant amounts of memory to ensure enough capacity is available to manage millions of connections simultaneously.

Fixed Versus Variable Structure

Finally, the way in which L2-3 and L4-7 devices parse and process packets and messages is distinctly different. In the network layers (2-3), packets are clearly defined; they are fixed in structure. In the application network layers (4-7), messages are not always clearly defined; they are almost always variable.

For example, a layer 2-3 device knows exactly where to find the source and destination IP fields within a packet. RFC 791 (Internet Protocol: IP) designates that each field within an IP datagram carry specific information. Parsing such a packet is as simple as finding the appropriate index in an array and extracting a set number of bits or bytes. The time it takes to extract these values is well defined using algorithms that can determine how many parsing cycles are required for any given field.

Parsing a message, however, is not so clear cut because messages are generally carried at layer 7 and are less structured. HTTP, for example, carries critical information in its header fields, all of which may be variable in length. This means parsing an application message requires much more processing power and takes varying numbers of CPU cycles. This is where ADN proves more capable than SDN—in its ability to parse and evaluate messages that enable services critical to ensuring performance, security, and availability of applications.

The Need for a More Agile Application Network

Ultimately, the reason we want a more agile network—and application network—is to support the rapid delivery of secure, reliable, and fast applications. SDN is an important piece of that puzzle. It promises to enable a more agile network and improve the responsiveness of network operations—both important goals in evolving the data center to support modern application architectures and a software-defined data center.

SDN, with its focus on the network, remains tailored to solving specific challenges occurring at layers 2-3. ADN, on the other hand, is focused on and designed to address those challenges occurring in the application domain with a capacious set of services. Its architecture and APIs, like that of SDN, enables the continuous delivery environment necessary to complement agile development methodologies.

An ADN addresses those challenges SDN simply cannot by enabling services that are both application-aware and application-specific; services that can enable the kinds of infrastructure architectures necessary to support emerging application models.  Where SDN solves challenges in the network layers, ADN solves challenges in the application layers. They are complementary, but very distinct, solutions.


Abstract of high tech data center courtesy of Shutterstock.


About the author

Lori Mac Vittie, is senior product manager of Emerging Technologies at F5 Networks, which provides solutions for an application world. F5 helps organizations seamlessly scale cloud, data center, and software defined networking (SDN) deployments to successfully deliver applications.


Sponsors