SDN Analytics and Orchestration from the 17th Annual SDN/MPLS Conference

In the presentation, Cengiz discussed three types of SDNs: Data center, network edge, and WAN. All three must work in concert, as data center and edge orchestrators will need to request services from the WAN orchestrator. He explained the required elements of SDN analytics, which include historical, current and predictive awareness of the following: 

• Topology (IGP, BGP, RSVP-TE, L2/3 VPNs, OpenFlow tables)
• Traffic (real-time and historical traffic matrices, and projected demands)
• Performance (jitter, packet delay/loss, MOS scores, etc.)
• Application requirements 

Cengiz went on to discuss provisioning, and how the Packet Design Network Access Broker prototype, our first foray into SDN analytics and orchestration, is currently integrated with the OpenDaylight (ODL) controller to configure tunnels using the above inputs. As an aside, he provided a commentary on the improvements in the ODL’s Helium release as well as some of the areas where it is still lacking (for more, see our recent blog post). However, he quickly returned to analytics, the focus of his presentation and the key to successful orchestration.

Using a bandwidth calendaring use case, Cengiz explained why merely using current and historical link utilization metrics to determine available bandwidth is insufficient to make go/no-go provisioning decisions. This approach does not take into account the possibility of failures in the network and their impact on traffic routing: What would be the link utilizations after a link/router failure? Where does the traffic enter and exit the network, and how much is there? How would the network reroute the traffic after the failure? 

This is where traffic matrices are valuable. By computing for each router pair (r1, r2) how much traffic enters r1 and exits r2, and layering this information on the real-time layer 3 topology from route analytics, it is possible to calculate the path for each flow. For example:

• Source AS—upstream transit ASs—neighbor AS
• Ingress router—core routers—egress router
• Downstream neighbor AS—transit ASs—destination AS 

From this data, traffic demand matrices can be created for:

• Ingress routers—egress routers
• POP—POP or core—core 
• AS—AS

The impact of failures on bandwidth availability can be modeled beforehand by analyzing each flow on the failed link using route analytics: 

Identify the ingress router and find the new path for the flow
Subtract the flow’s bandwidth from the failed link(s)
Add the flow’s bandwidth to the new link(s) 

As we have asserted before in this blog, SDN demands real-time analytics. Offline extract, transform and load (ETL) approaches are not suitable for SDN predictive analytics. The end game should be online monitoring, diagnosis, analysis, and orchestration in each SDN, and between and across SDNs.

To read Cengiz Alaettinoglu’s take on the best presentations at the conference, click here: http://www.packetdesign.com/blog/best-presentations-sdn-mpls-2014

—–

[1] As an indication of the growing SDN interest and conference content, Isocore, the event organizers, switched the conference name this year from “MPLS/SDN.” Packet Design was a Platinum sponsor of the event.