Software-Defined Networking – Sit On The Fence Or Take Action
As the industry and the media keep feeding the Software-Defined Networking (SDN) hype and vendors introduce SDN products into the market – it is becoming increasingly important to understand the difference between various offerings as well as the ways in which they can help end users.
The majority of the discussion has centered on changes in forwarding functionality – the functionality of forwarding packets between interconnection ports of networking devices. With OpenFlow (which is not SDN, but is what triggered a lot of the SDN discussion) the intelligence making the forwarding decisions, which lies in the control plane, has moved out of the forwarding platforms that connect the external systems into the network and into the controllers. Here we have decoupled OpenFlow switches and controllers.
SDN, riding atop of the OpenFlow hype, is a broader term that represents the ability to re-program the network forwarding behavior in real-time. It essentially amounts to the ability of the rest of the infrastructure to communicate with the network and request what it needs in order to program the network. While there are obviously various approaches in terms of implementing OpenFlow, some directly controlling the physical hardware and some leveraging OpenFlow to dynamically control forwarding on top of overlay networks, I’ll save that for another blog post.
For now, I want to focus on the following questions – if you are not an L2/L3 network equipment manufacturer, what does it mean to support SDN or OpenFlow? What does it mean to be an SDN product?
It seems like most of the industry has taken a minimal effort approach in which any product that either supports one of the common overlay network encapsulation formats or has any kind of API is an SDN product. Is that what the overlords of SDN had in mind? Possibly… For a very technology savvy segment of the market, however, this approach really amounts to sitting on the fence. Most IT consumers and professionals want products that work better together and save them time. Products that help them spend their valuable knowledge and experience on new initiatives rather than just getting stuff to work.
Having said that, there is another side of the SDN products spectrum. An approach that takes SDN to the point where it makes things happen automatically, ultimately allowing the network to better serve the applications.
At Radware we are thinking of SDN proactively. Application Delivery Controllers (ADCs) and Attack Mitigation Systems hold very strategic application information. ADCs sit right in front of the applications and are constantly exposed to application transactions including user requests and application responses. Additionally, Attack Mitigation systems reside in front of the network, acting as a sort of network scout and can identify a number of things using only limited information. By leveraging the unique intelligence and data flow, these devices have an opportunity to dynamically configure the network in order to adapt to ever-changing demands from the applications. Networks can divert malicious traffic to areas with less impact and can direct traffic to applications and services that are less occupied. In addition, networks can provide real-time statistics and information that have previously been very costly to collect.
The opportunity is in building SDN capabilities that communicate from the applications to the network, constantly monitoring their configuration and state at both ends. These capabilities should then be able to analyze the information and take decisive action, optimizing the network to best deliver application traffic given the changes throughout the application lifecycle and operations. Radware’s approach, initially available through our publicly announced cooperation with NEC’s OpenFlow products, does exactly that – it proactively makes things better.
