During refactoring of traffic_controllers, it has been found, that implementation of send_traffic_async() method is obsoleted. Following issues should be solved:

1) stop() method of traffic controller doesn't have any real implementation; So it doesn't make sense to call it from _exit_() method now. If it should really stop traffic, then we would have to call a stop method related to the type of traffic being executed. We can store this method inside the private member during send_traffic_async processing. So it can be easily called from traffic_controller.stop().

2) Once (1) will be fixed, then we should assure, that stop() won't be called twice. We can either keep current traffic_started logic or just simply check content of _traffic_stop_func (None or real func to be called). So stop() will be called from __exit_ only in case that send_traffic_async failed to stop traffic already.

3) Methods send_traffic_async are obsoleted and they support only one type of traffic pattern per traffic controller, i.e. rfc2554_throughput respectively rfc2899_forwarding. These methods should be updated to support all supported traffic types by particular controller.

4) I have doubts about current handling of 'function' dictionary by sent_traffic_async methods. It is assumed, that "pointer" to the "background" function is passed within 'function' key, that's ok. However I don't think, that args handling is correct. It seems, that args are expected as a list of arguments. In that case, I would assume, that correct call of the function with params should be with '*', i.e.:

 function['function'](*function['args'])

During implementation, following use cases should be considered, i.e. implementation should allow to execute additional TestSteps. This can be achieved also by explicit call of start and stop method of particular TrafficGen, which would simplify the matter.

TC #1: integration TC to check the latest ‘reconnect’ feature in OVS. This feature should be that - in case OVS crashes - after it is restarted it should reconnect and restore any VM connection seamlessly with no external intervention.

TC #2: integration TC to setup some VMs in parallel e/o serial, then while this is going on, remove some flows, remove some VM, add some new flow and launch some new VM.