Handling flow consistency after a new TCP/OpenFlow connection

[ajoaoff]

Original issue opened by @jab1982 at kytos#88.

In production, three situations might lead to a TCP/OpenFlow session disconnection: (1) switch reloads, (2) issues in the control plane communication (TCP reset), or the SDN controller reloads (3). When the switch reloads (1), its forwarding table will be empty, and the Kytos/FlowManager/MEF E-Line will need to install all flows in that switch (and that switch only). When there is a control plane communication issue (2), it is very plausible that the forwarding table wasn’t changed and flow entries are still operational. When the SDN controller reloads, switches' forwarding tables aren't affected, and the SDN controller just needs to confirm that forwarding tables weren't changed for any reason.

To find out the “new switch” forwarding status, after a Hello/FeatureReply, the Kytos/TopologyManager/other should collect the switch’s existing flow entries (via MultipartRequest/Flow) and compare with the FlowManager’s Storehouse data. If the switch reports no flows, all flows must be pushed down to the switch. If the switch reports some flows, ONLY the missing/misconfigured flows should be pushed down to the switch. This approach would prevent the OpenFlow counters of being reset.

[viniarck]

flow_manager is responsible for ensuring flows consistency, mef_eline as a client just have to send them and parametrize if they should be forced or not.