Traffic analytics and control

[netmon]

It there interest in extending the controller platform to include/support real-time traffic analytics and traffic engineering? Use cases include: DDoS mitigation, load balancing large flows, multi-tenant performance isolation, optimizing performance of overlay networks / network virtualization, and many others.

The key to addressing these use cases is to enable the standard sFlow instrumentation built into the data plane of the switches (I believe every OpenFlow capable HP switch also has hardware sFlow support). Does the HP controller / SDK provide a way to enable sFlow monitoring on the switches?

Northbound APIs for traffic engineering goes into more details about the controller requirements for integrating traffic analytics based on sFlow into the SDN stack. The requirements fall into two groups:

1. Linking the data model that SNMP, sFlow, etc. use ot identify ports and switches (agent and ifIndex) with the OpenFlow identifiers (OF switch ID, OF port ID).
2. Control actions that can be used to engineer traffic and that can be composed with competing requirements from other SDN applications (for example, the traffic shaping application might want to change the DSCP marking for a flow, but not interfere with decisions made be the access controller to admit / reject the flow, or the forwarding engines decision to create a path for the flow).

Are these architectural issues addressed / addressable in the current controller?

The article, RESTflow, describes a north bound API to make real-time, network-wide traffic analytics accessible to SDN application developers. Is there interest in incorporating analytics as a third party extension to the HP controller? What are the technical barriers? Any pointers to the API's that address the requirements described above would be appreciated.

Thanks.

[AndyBryant]

Hi netmon,

Apologies for the time taken to respond to this one.  It wasn't a straightforward question.

---

netmon wrote:

The key to addressing these use cases is to enable the standard sFlow instrumentation built into the data plane of the switches (I believe every OpenFlow capable HP switch also has hardware sFlow support). Does the HP controller / SDK provide a way to enable sFlow monitoring on the switches?

Northbound APIs for traffic engineering goes into more details about the controller requirements for integrating traffic analytics based on sFlow into the SDN stack. The requirements fall into two groups:

No, currently the controller does not provide the way to do this. However we are investigating the potential for a device driver framework for engaging with devices using protocols other than OpenFlow, e.g. SNMP, NETCONF, OFCONFIG. This is purposely to allow configuring the devices control & data planes, which could certainly include the ability to enable traffic data collection via sFlow.

---

netmon wrote:

• Control actions that can be used to engineer traffic and that can be composed with competing requirements from other SDN applications (for example, the traffic shaping application might want to change the DSCP marking for a flow, but not interfere with decisions made be the access controller to admit / reject the flow, or the forwarding engines decision to create a path for the flow).

Are these architectural issues addressed / addressable in the current controller?

---

As mentioned above, today’s controller does not have this capability and instead, for now relies on integration with a separate network management solution.

However, the use cases described above are precisely the reason why we want to embed a device driver framework to provide a more self-contained solution in the future.

If you'd like to re-apply to the HP Networking Alliance program, we can let you know as we make progress in these areas.

Andy.

[Sukar]

Hello Netmon,

Just following up to see if the previous post from Andy answers your query. Please feel free to reply incase you have more questions around the same topic or open a new thread if new  topic.

If you feel we have answered your question, please do let us know by marking Andy's response as an 'accepted solution’.

Thanks

Sukar

HP SDN Team

[netmon]

---

@AndyAtHP wrote:

---

@netmon wrote:

• Control actions that can be used to engineer traffic and that can be composed with competing requirements from other SDN applications (for example, the traffic shaping application might want to change the DSCP marking for a flow, but not interfere with decisions made be the access controller to admit / reject the flow, or the forwarding engines decision to create a path for the flow).

Are these architectural issues addressed / addressable in the current controller?

---

As mentioned above, today’s controller does not have this capability and instead, for now relies on integration with a separate network management solution.

However, the use cases described above are precisely the reason why we want to embed a device driver framework to provide a more self-contained solution in the future.

---

Thanks for the information on configuration management. However, the question about functional composition relates to the OpenFlow capabilities of the controller. Packets will only match one OpenFlow rule in the switch. If that rule is to realize policies set by different modules, then the controller must be able to functionally compose the policies into a unified set of rules (for example composing policies that set ToS with forwarding and access policies etc.). The importance of functional composition is described in the Frenetic project publications.

I would like to be able to implement traffic engineering SDN applications without having to take control of all forwarding, or risking interfering with other applications.

A pragmatic way to combine the scaleability of normal forwarding with OpenFlow control of selected flows is integrated hybrid mode OpenFlow (i.e. each switch port is handled by the switch's normal forwarding protocols, but any flow can be selectively overriden using an OpenFlow rule). This allows an SDN application to selectively block, mark, redirect, tap etc. specific flows without involving the controller in all flows. For example, would it be possible to implement the large flow re-marking functionality described in the article Large flow marking using hybrid OpenFlow using the HP VAN controller?

[sdnindia]

Hello Netmon,

Apologizes for the delay here.

As mentioned earlier in the thread sFlow is not currently exposed via the controller, but an app could directly get sFlow from devices.  Using that info with openflow traffic could be ID’d as large and an OF rule/policy applied.

In addition you can also refer to the whitepaper written by HP labs around this topic here http://www.cmlab.csie.ntu.edu.tw/~kenneth/qing2011/paper/6.pdf

Thanks,

HP SDN Team

[netmon · Accepted solution]

Thank you for the pointer to the HP Labs paper describing how to combine OpenFlow and sFlow to perform traffic engineering.  We have managed to implement an integrated hybrid OpenFlow solution with HP switches and combine it with our real-time sFlow analytics to dynamically mark large "elephant" flows.

The following article describes the solution:

Integrated hybrid OpenFlow control of HP switches