SDxCentral DemoFriday ALERT: Join Plexxi and Real Status for DemoFriday on March 14, and see a demo on application abstractions using OpenDaylight and Real Status Visualization. Sign up today!

One of the central tenets of SDN is that the control plane can be separate from the underlying forwarding plane. The major advantage of a logically centralized control plane is that it can view the entire network as a resource, making intelligent decisions about how to use that resource in support of the applications and services running over it. But is that enough?

A good non-networking analog to central control is Google’s recently acquired traffic application Waze. For those who do not know what Waze is, think of it as a real-time traffic (think: cars on a road) monitoring system. Drivers turn the Waze application on, and it tracks their progress. By plotting out the individual drive times, Waze can determine what traffic flow looks like on major highways and surface streets. Waze relays this information down to users, who can then make route decisions to optimize for travel times.

The same possibilities exist on the network. If a centralized control plane can track the available paths in the network, it can form a global view of traffic patterns on the network. This global view can then serve as a basis for real-time traffic engineering. If a particular link is congested, the controller can route traffic across other available paths.

This capability requires the existence of a central controller that can track congestion, obviously, which suggests that the controller needs to have more than just flow-programming capability. There will need to be traffic analytics that provide a real-time view of conditions on the network. The emphasis here is on real-time (or near real-time). If traffic is modeled on stale or backward-looking information, it is akin to driving a car by looking in the rear-view mirror.

The short-term implication here is that controller efforts like OpenDaylight should be ripe for analytics integration. To date, the major initiatives have been around the platform itself, along with supporting functionality (OpenFlow, abstractions, and so on). But extending OpenDaylight’s capabilities to include analytics would open up a new class of application-handling functionality that could be quite interesting in securing best paths for particular applications, tenants, or flows.

Having a global view is useful for directing traffic, but if there is only a small number of paths to use, the capability is somewhat neutered. Underlying networks with a rich set of paths provide more optionality. Going back to the Waze example, it is useful to know what traffic looks like, but if there are no alternate routes, the information is not actionable. So if you pair controllers with underlying infrastructure with rich pathing, you essentially provide enough surface roads to make traffic avoidance possible. This puts some dependence on the pathing algorithms in the underlying network, but even leaf-spine architectures with a multiple spine routes are useful. Obviously, the more available paths, the more effective this type of solution.

Once you have a multipath environment, how do you operationally take advantage?

What we will see with SDN is that the initial deployments will unearth a set of operational requirements needed to actively manage the network. This includes things like monitoring, troubleshooting, capacity planning, and even billing. But one of the most useful tools in quickly understanding the conditions on the network and pinpointing issues is data visualization.

Operators can get great insights about how the network is functioning by having path visualization tools. Going again to the Waze example, any of the traffic applications (including sites like SigAlert) do more than just track conditions. They present those conditions atop maps. Information without context is not useful, so being able to visualize conditions anchored to a well-understood map is critical.

The same is true in networking. If SDN is to make possible the use of rich multipathing capabilities, there will be a need to visualize those paths. In the fullness of time, this will require including conditions along those paths. This would provide a straightforward way to identify hotspots in the network, a useful thing for examining how capacity is utilized and where changes might be required. The ability to snapshot traffic profiles at specific intervals (time of day might be interesting, for example) would allow operators to see how infrastructure is performing under certain load tied to end-user activity. This type of visualization could also allow operators to drill down on individual application flows, which would make things like troubleshooting dramatically interesting.

Anyone who has worked in data visualization will know that the task is conceptually simple but very difficult to execute well. There is a science behind rendering data in a way that is immediately relevant and easy to use. But this science will become increasingly important if SDN is going to take full advantage of its controller’s ability to generate a global view of the network and the traffic traversing it.

SDxCentral DemoFriday ALERT: Join Plexxi and Real Status for DemoFriday on March 14, and see a demo on application abstractions using OpenDaylight and Real Status Visualization. Sign up today!