How SDN Is Defined Within ADN Architectures

October 1, 2012 4 Comments »
How SDN Is Defined Within ADN Architectures

Software-defined network (SDN) architecture is the hottest trend in networking since the cloud moved its focus from infrastructure to end users. The similarities between SDN and ADN on the surface have given rise to many questions, not the least of which is “Are these two architectures complementary or competitive?” Where do they intersect and overlap? Does SDN supersede and obsolete ADN?

These questions rise naturally from the somewhat abstract definition of SDN as proposed by ONF (Open Networking Foundation), which presents as core to SDN the following three characteristics:

1. Control and data planes are decoupled

2. Intelligence and state are logically centralized

3. The underlying network infrastructure is abstracted from applications

Interestingly enough, these three core characteristics have been key foundations for ADN for quite some time. It is no surprise, then, that excitement over SDN and its architectural promises would be abstracted from its focus on the network layer up the rest of the stack, to where ADN has long been focused. In recent months we’ve even seen a redefinition of “ADN” from “application delivery” to “application defined” networking.

Such a change is likely coincidental but accidentally recognizes the similarity—and complementary nature—of the two architectures.

The Core Challenge for SDN

The core characteristics of SDN are designed to address three challenges:

  • Existing network protocol limitations
    • VLAN restrictions that inhibit growth
    • Inability of existing routing protocols to keep up with volatility in the IP network
  • Unmanageable infrastructure
    • Operational inconsistency
    • Inability to rapidly disseminate changes across network-layer devices
  • Inflexible infrastructure
    • Lack of programmability limits ability to adapt quickly to business and operational needs
    • Limited visibility

These challenges have always existed on some level, but they have been exacerbated by the adoption of virtualization and cloud computing in recent years, raising them to the level of severe impediments for a wider range of organizations rather than serious issues only for those experiencing rapid growth.

SDN proposes to resolve these issues by abstracting the control from the data plane in the network and instituting a central standards-based controller capable of managing very large-scale networks. It accelerates network virtualization by separating the logical network topology from the physical. Network virtualization can take the form of networking components running as software in a virtual form factor as well as the creation of a virtual overlay network using emerging standards such as VXLAN, STT, NVGRE and QinQ. SDN mitigates the complexity of large-scale networks using a centralized control plane, a policy engine that is implemented as a set of network services, and enforcement points in the network fabric.

ADN, on the other hand, resolves these same issues in the application layers, at Layer 4–7 of the traditional OSI stack, in much the same way as SDN: it decouples the control and data planes and uses a central standards-based controller capable of managing application traffic for even the largest and most dynamic network environments. ADN decouples end users from applications logically and physically, enabling a variety of processing and policy enforcement to occur at a naturally strategic point within the network: the application delivery controller. Much in the same way that SDN takes advantage of a central controller to manage and disseminate policy throughout the network fabric, ADN uses the same control model to manage and enforce policy throughout the application fabric.

Programmability is a significant value proposition for both SDN and ADN. The ability to programmatically alter the behavior of packet- or application-level routing is critical to ensuring availability and optimal performance, as well as security. Programmability ensures the flexibility necessary to adapt policies quickly in response to events and incidents such as zero-day exploits, hardware or software failure, and network oversubscription.

The Role of SDN and ADN in Data Center Architectures

It is understandable upon examination of the basic flow of packets through an SDN-enabled network why its architecture is immediately abstracted to higher levels of the stack. In SDN-enabled networks that make use of protocols like OpenFlow to programmatically update the switch fabric, packets are matched against a forwarding table. If no match is made, the switch queries the controller. The controller executes algorithms that determine—on the basis of the current state of the network—where that packet (and subsequent matching packets) should be directed. The controller updates the switch, and packets continue to flow. The controller can also push an update on the basis of its monitoring of the network. If a node moves, fails or becomes sluggish, the controller can update the affected switches so that packets are routed correctly to mitigate an outage or degrading performance.

In an ADN, the controller performs much the same role but does so at the application layers (Layer 4–7). When a connection request is received, the ADN controller determines whether a session exists between the user and the desired application or service. If a match is made, the request is forwarded using the existing session information. If a match is not made, the controller executes algorithms and determines, on the basis of configured logic and policies, where that request should be forwarded. Once the decision is made, the session table is updated and the connection established.

These two flows, though occurring at different layers of the network stack, are remarkably similar. It is easy to see how the SDN flow could be abstracted to apply to higher levels of the stack. But this ignores realities of the technological underpinnings of the architectures. SDN is designed purposefully to be stateless and packet based. Its routing and switching decisions are based on matching individual packets in a highly volatile environment. To address the high rate of change, its core network information caches are designed to flush entries on a tight time interval. This allows SDN to adjust to changing conditions very rapidly and ensure the paths through the network are always optimal. It also ensures that network element failures are transparent to the user. Packets will simply be routed along another path, without being noticed by the end user.

In an ADN, the decision on routing an application or service request is generally made on transport- (TCP/UDP) or application-layer (HTTP) data. This data requires the aggregation of multiple packets, and thus an ADN controller must necessarily buffer data until enough has been received to determine both its validity—enabling the implementation of network- and application-layer security functions—and its ultimate destination. The need to aggregate packets as well as maintain large session state tables was not a design consideration for SDN. The amount of memory and network processing required for an SDN to properly execute higher network-layer functions would necessarily obviate the benefits of commoditized switching hardware central to the SDN architecture.

Additionally, the performance of SDN is highly dependent on the ability to match large quantities of packets in the switch fabric, without requiring a query to the SDN controller. Higher network-layer sessions are unavoidably unique, being based not only on network (IP) layer data but on Layer 4 and Layer 7 data such as source- and destination-port combinations that are necessarily unique to each request. Applying an SDN approach to this traffic would require a query to the controller for every request, something for which the architecture is not designed.

The inherent differences in requirements for a network-focused and an application-focused dynamic system make it difficult if not impossible to interchange the two architectures. Both approach the same challenges in different layers of the network using similar core premises without compromising on the unique requirements of processing traffic with different focuses.

Where SDN and ADN Meet

Challenges occurring in the application layers (Layers 4–7)—availability, optimization and security—are currently not addressed by SDN solutions. ADN solutions are located at strategic points in the network where they control and manage how applications are delivered to end users over networking technologies such as SDN, which focuses on how network traffic (individual packets) are delivered to network infrastructure elements. Policies acting on packets are of limited scope by design. Application traffic is composed of multiple packets and must be aggregated to provide the value of higher network-layer functions such as load balancing, network and application security, and access control. This aggregation of packets at the device level runs contrary to SDN philosophy and design principles, which operate on a per-packet—not per-application flow—basis.

And yet ADN solutions necessarily interact with the network fabric as a means of communicating with the applications and services to which it connects end users. The ADN controller translates end-user, connection-oriented flows to targeted, node-specific communications across the switch fabric, which in highly virtualized and cloud-computing environments is ripe for SDN. The volume of change occurring in the network and application topology in such environments demands a solution, one which SDN readily provides. The ADN, then, must be able to move from traditional network to SDN seamlessly. The intersection of the two architectures occurs at this transition point, where requests at the application level are mapped to an element in a highly dynamic network domain that ultimately fulfills that request transparently.

In the simplest sense, ADN will continue to be responsible for connecting end users and applications. Certainly there will be integration between the two technologies—and such integration has already begun to show itself in interoperability demonstrations at various conferences. There is a clear delineation of duties between ADN and SDN. Where the former focuses on how to deliver applications, the latter is responsible for how to move packets. Together these two technologies will be able to work in tandem to address the complexity of managing network and application traffic across the entire network stack.

About the Author

Lori MacVittie is Senior Technical Marketing Manager for F5 Networks.

Photo courtesy of futureshape


Leave a Reply

Pin It on Pinterest

Share This