SDN Controller Message/Control Channel over L3 network?

[RGBD]

Can the VAN SDN Controller support a control channel over a Layer 3 routed network?  HP OpenFlow switches "point" at the controller-id via an IP address.  The design constraint would be that the SDN controller must be distributed away from the OpenFlow switch and it is impractical to provision a L2 path between the switch and controller.

[sdnindia]

Hello RGBD,

Yes the VAN SDN controller supports controller over Layer 3 routed network. One of the key feature that controller support is flexibility in packet processing.

Below are the excerpts from the datasheet

Flexible packet processing — enables both OpenFlow and normal packet processing with the HP SDN architecture; access control lists can be provisioned centrally, for example, while L2 or L3 forwarding decisions can be made using standard network protocols; this allows SDN concepts to be applied incrementally to the network, starting with the application of network policy and extending to exception-based forwarding, adding value without replacing traditional switching or routing

In addition you can also take a look at the below link which points to the L2 & L3 feature definition of HP switch

http://h17007.www1.hp.com/us/en/networking/products/switches/HP_3500_and_3500_yl_Switch_Series/index.aspx#tab=TAB2  

Please let us know if we have addressed your question. If not please feel free to reply to this trial.

Thanks

HP SDN Team

[sdnindia]

Hello RGBD,

Doing a follow up to check if you need any further assistance with respect to the query posted.
Please do let us know  if your problem is solved.

If you have more questions on the same topic please do reply on the same thread or open a new post if new topic.

Thanks
HP SDN Team

[RGBD]

One follow up question is that aside from obvious performance implications, are there additional considerations for the OpenFlow control and messaging channel characteristics such as maximum link latency, loss, etc. that should be taken into account for a centralized controller design?

Thanks,

Dale Smith

HPN SA

[Gerhard Roets]

Hi Dale

This is a bit of a tricky question.

The good news is the control channel is a TCP connection this implies that you are dealing with normal old fashioned TCP rules.

Most of the metrics you mention is really dependent on the application on the controller. If the application needs to make a lot of decisions based on packet_in or a lot frames get generated by packet_out you might have to deal with latency each time this is required. Now if the data traffic is sensitive to latency you might need a lower latency control channel.

With regard to loss, the fact that it is a TCP session we do have drop recovery built in. But if like above there is a large amount of packet_in and packet_out happening and you have a lot of loss this will induce extra delay and latency due to recovery.

One key item keep in mind is depending on the “failure” mode of the switch if the channel is lossy enough and the TCP session should break you might have to deal with flows needing reprogramming or other factors. This could especially be a factor where an application programs a lot of flows and we have flows depending on other flows. Here the application might need to check if the flows are in place when a new DPID is detected.

The key item to bear in mind is you are either extracting or extending the switch’s control plane using OpenFlow. The control plane in essence relies on the TCP session, hence the characteristics of your control plane rely on the control channel characteristics. If you data or OpenFlow application requires low latency and loss you need to implement that on your control channel characterisitcs. If it requires a lot of bandwidth the same logic applies.

There is no real one answer fits all.

HTH

Gerhard

HP SDN Team

[sdnindia]

Hello Dale,

Doing a follow up to check if you need any further assistance with respect to the query posted.
Please do let us know  if your problem is solved.

If you have more questions on the same topic please do reply on the same thread or open a new post if new topic.

Thanks
HP SDN Team

[RGBD]

All good.

I think we have explored this one well enough.

Thanks,

Dale Smith