Industry Perspective is a regular Data Center Journal Q&A series that presents expert views on market trends, technologies and other issues relevant to data centers and IT.
This week, Industry Perspective asks Avi Chesla about application-aware software-defined networking (SDN) and its uses. As Chief Technology Officer at Radware, Avi is responsible for leading the company’s strategic technology roadmap and vision. This includes laying the theoretical basis for future products and solutions, research and design of core product algorithms, evaluating OEM opportunities, and representing the company’s technology and future plans to the industry. Avi also steers merger and acquisition research and manages intellectual-property ownership.
Industry Perspective: How would you characterize or define software-defined networking? How does it differ from what we might call traditional networking?
Avi Chesla: It’s clear that the networking industry is on the verge of a major transition. And leading that change is the SDN (software-defined networking) concept and the associated technologies that enable it.
First, a little background: Looking at the developments over the past 15 years in areas such as the Internet, mobile, applications and so on, we realize that these fields are virtually unrecognizable compared with how they were 15 years ago. Why, then, has the networking foundation, on which everything sits, hardly changed at all? The implications of SDN technologies for networking companies are tremendous. Currently, companies are occupied with trying to navigate the complexities of an archaic networking system instead of focusing on developing real innovations (as we see in the world of apps and the Internet).
OpenFlow/SDN challenges the basis of old-style networking, and it suggests a new approach—a centralized intelligent control entity, rather than a distributed one that is embedded in each network element. (Distributed algorithms are typically executed concurrently, with separate parts of the algorithm having limited information about what the other parts of the algorithm are doing.) This centralized approach leads to a democratization of networks, which means that anyone who wants to control the network could do so through programming, using an abstraction layer as the network operating system (Network OS).
Today’s networking industry specializes in mastering complexity; SDN allows the transition into creating simplicity. And network professionals, free from the burden of overcoming the challenges of complex networking, will be free to create true innovations.
IP: How would you relate the concept of “application aware” to SDN?
AC: SDN has the potential to bring major news to networking. Some of this potential has already been realized, but some of SDN’s main advantages still need to be implemented. For example, SDN has the potential to create a network that is smarter than what we have today. A smarter network means that all the networking elements become application aware, and the whole network is “shaped” to serve one purpose, which is the application that it was designed to host and serve in the first place.
SDN technologies and the concept allow us to program the network to become application aware. As SDN defines a centralized network control entity that programs the networking elements, it becomes pretty straightforward for application control functions to interact with the network controller and be responsible for inserting program application awareness into these network elements.
IP: What are the benefits of a network or network resources that are application aware?
AC: The benefit that these application control functions (which I call SDN applications) bring is an increased value of the existing network resources—simply because the network computation resources are all shaped to serve the applications properly, rather than just hosting and delivering the traffic to them. An application-aware network extracts more value from our network resources. More value means a lower-cost network in both operation and capital expenses and, at the same time, better service for the network’s customers. Customers in this case are the business applications on the one hand and the clients/users on the other. As long as we can use network resources to increase the level of service availability to customers, obviously the value of the network rises. More value also means that we can very quickly adapt network behavior and characteristics to suit the evolving needs of these customers, which as we know can change significantly over time.
IP: What are some of the challenges, particularly regarding security, of application-aware networks?
AC: To confront the threats of both today and tomorrow, traditional networks use single-point solutions for security. Each network entry point and all internal junctions need to be covered with security application (software or physical forms) that enforce access policies and perform attack detection, data leakage detection and protections, and more. There is a tremendous challenge, both in terms of operation complexity and budget, to deploy security applications to cover all these network junctions and security needs. An “application-aware network” solves many of these challenges.
IP: Could you describe a specific use case for SDN/application-aware networks?
AC: The example for a practical SDN application introduced below is taken from the network security area. The main purpose of this example is to show that it is possible to build network-wide (i.e., not just in a single-point security solution) application awareness and thus increase the value of the network.
The figure above shows a portion of Radware’s SDN security application called DefenseFlow. This application illustrates one way to intelligently deploy OpenFlow counters inside the SDN-enabled elements throughout the entire network, read traffic statistics accordingly and learn the normal traffic patterns in the network. This example includes an adaptive decision engine that identifies deviation from the normal patterns and, when it does, logs an alert with the associated anomaly or deviation information.
This kind of application can automatically detect a broad range of DoS and DDoS attacks on different levels. On detection, the application changes the flow-table rules in the switches to divert the suspicious portion of the traffic to the attack-mitigation resources—that is, the scrubbing-center resources. In this example, the scrubbing resources include an attack-mitigation solution that further analyzes the traffic going through it and blocks the attack flows while injecting the legitimate traffic back into the network. At the same time, it communicates with the DefenseFlow application to provide more-granular information about any suspicious flow it identifies, such as detected attack types, sources of the attack, attack footprint and so on. The figure below shows this diversion process.
It is important to emphasize the flow-counter deployment, as it is part of the process of injecting application awareness into the entire network. As the figure above shows, DefenseFlow deploys three types of flow counters across the SDN-enabled elements:
Edge flow counters—These flow counters are propagated and deployed in all edge routers or switches to collect broad traffic statistics at the entrance to the network. They can be collected from routers that are connected into the peer carrier links that provide the network services or routers/switches between core networks.
Network flow counters—These flow counters are propagated and deployed in all network elements between the aforementioned edge elements to the server application workloads. These counters collect wide network traffic statistics for each internal network. These internal networks can be either hosted customer networks (with large IP ranges), large hosted server-cluster networks (as in the case of cloud MSP) or any other network segment (physical or virtual network) defined by the network provider.
Local flow counters—These flow counters are propagated and deployed on the SDN-enabled virtual switches (such as Open vSwitch) of the compute fabric that hosts the server applications. As the figure shows, in some cases the local filters can be deployed on the host’s physical NIC in case it is an SDN-enabled one. These local flow counters collect traffic statistics in the scope of each individual service or application.
IP: How can one differentiate between a faux SDN solution and a real one?
AC: A true SDN control application that interacts with the network controller would allow seeing in each SDN-enabled data-plane element a piece of application intelligence. The case above shows the security application intelligence deployed in each network element. If you cannot take a snapshot of your network and see all the pieces of application intelligence, then you haven’t taken full advantage of SDN.