Necessity of Analytics and Monitoring in the SDN Era

A recent SDNCentral article about the Five Habits of Highly Effective SDN Startups asserts that achieving success in the SDN landscape will require creating focused products that solve real-world problems. In addition, the article emphasizes the need to build a sales channel with great partners, market strategically but be lean and mean, and adopt a slow and steady route into the SDN world. 

The article quoted the new landscape of SDN as we know it. Take a look at the diagram below. The building blocks range from controllers to network operating systems to monitoring and analytics.

As the above diagram illustrates, monitoring and analytics are key. With SDN, the network self-adapts to the new demands of the application, and without visibility into these changes it’s very hard to say if an SDN application is doing the right things to your network. Understanding the programmable events that happen in real time requires mature analytics technology that can correlate service delivery to physical and virtual resource states. 

At Packet Design, we have been working on a solution for SDN analytics that maps well to the SDN building blocks quoted in the article. Packet Design’s Network Access Broker (NAB) uses topology models, traffic profiles (both current and predictive profiles), and business policies to determine in real time whether or not application requests for network resources can be satisfied (see diagram below). 

This is possible by computing baselines for traffic flows across the network. The NAB receives traffic flows via NetFlow records from the routers. Applications like bandwidth calendaring and demand placement can interact with the NAB through RESTful APIs. 

Additionally, the NAB can calculate the impact that requested changes will have on other services by determining the resulting network topology and traffic behavior. 

The NAB can be integrated with the OpenDaylight (ODL) controller for provisioning. This will be done in two ways: (1) Initially, as a third party application that uses the ODL RESTConf interface. In this case, the NAB doesn’t share the process address space of ODL and hence, it need not co-locate with the ODL controller. (2) In a later version, it will reside within the ODL controller as a pluggable OSGI module. The OSGI module could be started and stopped without interrupting the controller. In this way, the NAB will be able to interact much more closely with the ODL controller and utilize features that are not accessible through RESTConf. 

Packet Design is the leading provider of route analytics for traditional networks, and we believe these analytics will be the foundation for critical analytics in the SDN era. For more information, see our white paper on SDN Management and Orchestration.