Port Down Reconciliation (Dev)

Introduction

The PortDownReconciliation module has been implemented to reconcile flows across a network when a port or link goes down. Following a link discovery update of type "PORT_DOWN", this module will seek out and delete flows directing traffic towards the downed port. Once all invalid flows are removed Floodlight should re-evaluate the path the traffic should take according to the updated topology. Without this module, persistent traffic would continue to be routed to a downed port because the Idle Timeout of the flows would not have been exhausted.

How It Works

Suppose we have a simple topology with a base switch(sw1) connected to a host and also linking to two separate switches (sw2, sw3). Suppose traffic is flowing from sw2 and sw3 to the base switch with a destination address of the host. Suppose the link to the host goes down. A PORT_DOWN notification is then sent to the controller by the base switch. 

Upon receiving a PORT_DOWN link discovery update, the module will find which port has gone down. Once it has found which port has gone down it will query this base switch for all flows with an Output Action OutPort matching the one described in the LDU. It will analyze these flows and create an index of ingress ports and corresponding invalid OFMatch objects that all route flows to the downed port.

An example of the index would look like this.

Short ingressPort

List<OFMatch> (Invalid match objects of flows directing traffic to down port)

1

[ match1: dataLayerDestination: "7a:59:cd:34:a7:9b", dataLayerSource: "c6:cb:ad:80:49:70" ]

2

?[ match2: dataLayerDestination: "7a:59:cd:34:a7:9b", dataLayerSource: "c6:cb:ad:80:49:69"]

With the completed base switch index, the module begins to trace back the routes by asking the topology service for all the switch to switch links on the network. It loops through the links and finds those which have a destination switch corresponding to the base switch and a destination port that corresponds to one of the invalid ingress ports described in the index. If a match is found the source switch is added to a new "NeighborSwitch" index, this time pointing to the source port of the link (the output action outPort on the neighbor switch) and the invalid OFMatch.

NeighborSwitch index

IOFSwitch sw

Short outPort (outPort to link connected to the base switch)

List<OFMatch>  (Invalid match objects of flows directing traffic towards the base switch)

sw2

3

[ match1: dataLayerDestination: "7a:59:cd:34:a7:9b", dataLayerSource: "c6:cb:ad:80:49:70" ]

sw3

3

[ match2: dataLayerDestination: "7a:59:cd:34:a7:9b", dataLayerSource: "c6:cb:ad:80:49:69"]

Now that information is no longer needed from the base switch, all flows with an Output Action OutPort matching the downed port are deleted from the base switch. The module then loops through the index of NeighborSwitches and performs the same analysis that was performed on the base switch. This process continues recursively hop by hop until no more invalid flows exist in the network.

Issues and Limitations

  1.  In the event that multiple routes between a source and destination switch overlap, switches may be analyzed more than once for different flows. This may take extra time but it is necessary to maintain the integrity of flows across the network.
  2. This module depends on the forwarding module to be effective.