main

Application DeliveryEventsSDN

Get Ready for “Network Apps”

April 23, 2012 — by Avi Chesla4

I just got back from the 2nd Open Networking Summit (ONS) that took place in Santa Clara. This event was three times bigger than the one held on October last year. Networking innovation was once again the focus of the discussions and demonstrations and it was interesting to see a few examples of production network environments that have fully adopted the SDN (Software Defined Networking) approach and implemented OpenFlow. For example, Google showed that most of its production network is OpenFlow enabled – there’s no better “Proof of Concept” than that.

Over the past 2 years, Google has designed and built its own switches that are OpenFlow supported and has developed a sophisticated Traffic Engineering (TE) controller application that is responsible for all of their advanced dynamic routing decisions, which are adapted automatically thanks to the nature of OpenFlow. You can read more about it at here.

Telcos such as NTT, DT and Verizon talked about the need for WAN SDN and discussed a few other strategies they are undertaking by leveraging OpenFlow. This includes ideas for overlay networks, smart traffic steering that better utilizes network resources, and improved quality of service for mobile devices through a new proposed mobile access point selection mechanism. It was really all about innovation in networking – something we haven’t see for quite a while.

However, the most interesting point for me was the fact that ADC and security vendors will play a very dominant role in this new networking era. The way I see it, this networking revolution is all about making the network an Application Aware Network. The OpenFlow centralistic controller approach allows it to collect application states, analyze them by a business application, make a decision and enforce it at the network level by injecting new or modified network flow rules into the OpenFlow enabled network fabrics.

The obvious question “Who will provide these application states?” and the answer is that ADC and security products, which have L4-L7 visibility and intelligence, are a perfect choice for this. ADC and security elements’ decisions and actions are mostly application aware and therefore are the perfect sources to “signal” to the OpenFlow controller about application aware network actions. And these actions should be taken based on the applications status and business needs, e.g., application’s health, load and response time, threats imposed on the application, application security policies, application resource utilization etc. There is also a value in doing the opposite, i.e., enforcing application level changes based on the network status (status that is visible through the OpenFlow controller).

We introduced and demonstrated some of these concepts in our booth at the ONS event. We showed how Radware’s ADC and security commercial products, together with the service delivery controller application we have developed, “shapes” (or “programs”) the OpenFlow enabled network. We showed the commercial value it brings, including network resource optimization (reduced cost), application aware highly available network, secured software defined network infrastructure and how added value services such as security and application delivery functions, can be automatically provisioned to customers in a cloud MSP environment.

Based on the discussions at the event, all indications are that the network will become more and more application aware and therefore will be led by the application vendors. We are not so far from having a marketplace for “network apps” that will be stacked into the network controller and will “shape” the network per business need.

I have included a diagram of how our demo works:

Avi Chesla

Avi manages Radware’s security business unit and the security roadmap for the company’s attack mitigation system. This includes defining all product management and product marketing operations, the theoretical basis for current and future security products, and research and design of core product algorithms. He also holds several patents related to network security. Avi writes on a variety of security topics including application security, behavioral analysis, data loss, and wireless/mobile security.

4 comments

  • MN

    September 13, 2012 at 12:18 am

    Very interesting. Will ADCs need to be rearchitected/recoded for this new paradigm? And will they work with any standards based OFController or OFSwitch – or will they be integrated to specific ones. I would imagine this would open up new areas for ADC/SDC vendors, at the expense of Layer 2-3 switching vendors

    Reply

  • Avi Chesla

    September 15, 2012 at 12:34 pm

    Time will tell, but I do not believe that ADC or any L4-L7 product need to be re-architected. In general L4-L7 SDN applications should be designed to be agnostic to control protocol itself and work with any network controller. In order to be effective with any network controller, there are a few basic principles these network Apps should follow such as the capability to read network topology, monitoring network stats, an API that can change the “routing rules” in the network, an interface to read and control the L4-L7 product. Some controllers would allow more granular operations and some less (depends of the L2-L3 switching vendor, openflow switch version etc). As a result of that we will see more and more basic L4-L7 operations that are offloaded to the network and much better utilization of the L4-L7 resources (which would allow ADC product to provide more advanced application services) – This is what I meant by a Network that is more application aware.

    Reply

  • mnarayan67

    October 19, 2012 at 2:36 pm

    Among the various solution providers in the market Citrix and Radware seem to be ahead with regards to a service delivery fabric, F5, Stingray do not seem to be there. A10 may have a view. I am curious as to how the larger vendors, IBM HP Dell Juniper EMC/VMWare etc. view this framework.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *