ForwardingTest.testForwardDeleteFlowsByDescriptorMultiple() passed in Eclipse, but failed when run by "ant test".
Changed Forwarding.deleteFlowsByDescriptor() to use List<> instead of Set<> to simplify the unit test.
Tests now pass in every configuration I'm able to run them (eclipse single test, eclipse test class, eclipse all tests, ant all tests).

Also general code and comment cleanup.

This deletes/add flows from the switch out of forwarding when the firewall rule changes.

Added test cases for Forwarding if there is a decision packet.

Updated Firewall.java so that addRule and deleteRule and enableFirewall announce that a rule is being changed in the firewall. Then the IRoutingDecisionChangedListener shall alert Forwarding to update the flowtable accordingly.  None of this is tested and the TopologyManager needs to be fixed.  I might even want to move the change out of TopologyManager altogether since RoutingDecisionChange doesn't concern it.

Update Forwarding to support specifying a default table ID for flow insertion. It's flow table 0 by default, but it can be overridden using the net.floodlightcontroller.forwarding.Forwarding.table-id=X config parameter in floodlightdefault.properties. Set X to any table b/t 0 and the max.

Getting there w/OF1.5 support. Just need a switch that supports it (well) to do some more thorough testing.

TODO:
   * RoutingDecisionsChanged event
      * Define Listener class
      * Add Listener registration/messaging (probably going into IRoutingService)
      * Add code to fire event when firewall rules change.
      * Add code to fire event when firewall enable/disable happens.
      * Add code to handle RoutingDecisionsChanged in Forwarding
   * Unit tests
   * Functional tests

Handle link and port down events in Forwarding. Remove flows ingress and egress a failed port or link to eliminate stale entries. This is done in Forwarding instead of the Link Discovery Manager, since some user modules might not want their flows removed and wish for them to persist until the link comes back up.

Fired when receive a ROLE_STATUS message, at Master to Slave transitions, switch become deactivated.

Modified Forwarding and ForwardingBase to use setInstructions instead of setActions in OF 1.1 or later. New openflowj-2.0.0-SNAPSHOT.jar that duplicates the shortcut used for FlowMod setActions in version 1.3 to versions 1.1, 1.2 and 1.4

Patch Forwarding's pushPacket and pushRoute. We do not want to push a packet if the command is delete or delete-strict.

Added ability to disable ARP flows in Forwarding. Many hardware switches cannot handle ARP flows. ARP flows on by default; turn off/on via 'flood-arp' in floodlightdefault.properties. Also, finished integrating new topology service/routing into Forwarding. This required a few more null checks to handle cases where packet-ins are received while the controller is starting/still discovering the topology/links.

Integrated new topology code and updated unit tests to a passing state. I'd be more comfortable adding more unit tests to the topology. Also made some changes to the link discovery manager's latency subsystem. We start with a baseline latency based on the switch's features reply turnaround time. This should be relatively quick -- just like an echo. Next step for latency is to keep a rolling list of past latencies for more defined topology updates based on latency updates. We don't want to update latencies too frequently, since tiny changes (or outliers) shouldn't require a complete topology recomputation.

A new and improved device manager (woohoo). We support IPv6 now and have fixed some bugs. Other changes have been made to prefer 'empty/zero' objects instead of null, which made using the device manger less type safe and more error prone. Unit tests for IPv6 packets will come next, so IPv6 support should be considered experimental for this commit (although in theory it should be fine if IPv4 is).

Lots of goodies here. Apologies for the largish commit. Most files are just removing warnings that were introduced after updating JSON libraries a short time ago. IOFSwitch now can return specific list of tables supported. This is useful for the OFHandshakeHandler for one, which not inserts table miss flows up to the table ID indicated in floodlightdefault.properties, but only in the table IDs that actually exist. Up next, Forwarding has some preliminary, isolated support for IPv6. Still need to integrate support into the device service, which is more complex. Forwarding also supports routing through OF switches of multiple OFVersions. This was a very subtle bug that was fixed by modifying MatchUtils to create a Match clone to a specific OFVersion. This utility function is used to generate a Match compatible with the OpenFlow version of the switch. Believe it or not, Loxi actually allows you to insert a Match of OFVersion.OF_X into an OFFlowMod of OFVersion.OF_Y. The switch, of course, doesn't have a clue how to interpret it and either reports an error, or actually resets the OF channel, in the case of a couple hardware switches tested on. Good news is this is fixed now :-).

SEND_FLOW_REM in flow mod

Specify what to match on for Forwarding. This is a first step towards automatically adapting the match depending on what the switch requires for the flow to be in hardware.

Reapplied the LinkDiscoveryManager's patch from earlier (issue #471). Updated Ethernet.java to use EthType instead of short for EthTypes. In conjunction, bitmasked the LSBs of the ethertype as it is casted from short to int. This preserves the MSB (sign) as a data bit --> unsigned integer.

Forwarding's doDropFlow() changed to not base Match on OFPacketIn, which it shouldn't in the first place. We need to first deserialize the packet and use its header attributes. TODO: How much is too much to match on? Sometimes we want a very specific match by default. Other times, we don't. The former creates a larger flow table, while the latter might inadvertently match packets that we don't intend to. Perhaps this should be a user-configurable option? Such as net.floodlightcontroller.Forwarding.matchLayer=L2, L3, or L4?

Don't use the Match from the Firewall in Forwarding if a rule allowed the packet. If a packet has been allowed, that means the Forwarding module can send it where it needs to go matching on its header files (which have already been given the OK by the Firewall). If a Firewall rule is very general, e.g. allow all packets through switch 1, then the first packet that traverses the switch will cause Forwarding to insert a general from from port A to port B with no specific hheader field matches (since they weren't specified in the Firewall rule).

Updated circuitpusher with new SFP syntax. Updated Forwarding(Base) to use a default priority of 1, since in OF1.3 we have a priority=0 table-miss flow that will also match. Trying to update the Web UI to display flows correctly.

Mid-way through Forwarding unit tests. Added a sample equals to compare OFPacketIns when the XID does not matter (in net.floodlightcontroller.util.OFMessageComparisonUtils.java).

Some Firewall unit test fixes. Went through all code and corrected pi.getInPort() to (pi.getVersion().compareTo(OFVersion.OF_12) < 0 ? pi.getInPort() : pi.getMatch().get(MatchField.IN_PORT)). OF1.2 and greater specifies the ingress port as an OXM in the Match.