Software-defined networking (SDN) has the potential to bring major news to networking. Some of this potential has already been realized, but some of the main advantages of software-defined networking (SDN) still need to be implemented. For example, SDN has the potential to create a network which is smarter than what we have today. For me, a smarter network means that all the networking elements become application-aware. In other words, 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 concepts 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 application-awareness into these network elements. 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.
I don’t think there is a way today to measure how aware our network application is (how smart a network it is), at least not a standard one. SDN concepts enable not only greater application awareness, but also measure the level of this awareness. If we have an SDN-enabled network that is managed through a centralized SDN network controller, then the number of control applications that interact with it and the frequency with which these application functions program the network elements can be a very good measure for application awareness. The figure below illustrates this concept:
Another effective way to measure application awareness is to take a "snapshot" of the data-plane flow tables. A good SDN control application that interacts with the network controller would allow seeing into each data plane and considering the SDN-enabled element a piece of application intelligence. Let's take a look at the figure below and try to think which security application is interacting with the SDN-enabled network, or rather, what type of security application is "programmed" into this network.
The lower part of the figure shows a logical view of the OpenFlow flow-table rules in each SDN-enabled networking element, which I call a “snapshot.” This snapshot shows the SDN security application program’s fine-grained flow counters on the Open vSwitch flow tables that are close to the business applications (VMs), and also deploys much coarser-grained flow counters on the edge physical router/switches of the network.
The fine-grained counters enable the SDN security application to collect network statistics or copy/redirect specific application flows to a DPI device. Through that, it can detect deviations in network traffic patterns that might indicate an attack on an individual application or service and block them, while the coarser-grained flow on the edge allows the SDN application to detect, for example, a large-scale DDoS attack that imposes a threat on the entire network infrastructure. In other words, we can say that this snapshot reflects a “layers of defense” strategy, implemented natively as part of the network.
In conclusion, 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. It’s time to take another look at SDN and benefit from it to the fullest extent.