Implemented a rolling link latency history for switch links. Each link will contain a single latency value. When a link update occurs, the latency computed from the LLDP packet is added to the exisiting link's LinkInfo. LinkInfo maintains a latency history for link L. The 1-to-1 mapping between Link and LinkInfo still exists. LinkInfo will provide a new latency based on the rolling window size and update threshold -- configurable through floodlightdefault.properties but default to 5 latency data points and 30%, respectively. As an example, the 0th latency value is used as the intial latency for a particular (new) link. Each LLDP update for this link will contain a latency. This latency is added to the LinkInfo from updates 0 - 3. Update 4 will make 5 historical latency data points. This will cause an average to be computed of these 5 data points. If the average is +/-30% of the latency recorded in the 0th latency, the link latency will be updated. For exach, successive latency recorded, the same average will be computed. If the new average is not +/-30% of the old recorded value, an update will not occcur. Every latency 'replacement/update' will cause a new topology to be computed in the topology manager. Keeping a rolling average takes into account current network conditions, but also helps to average out outliers and keeps topology updates to a minimum.

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.

Patch load balancer to include source port in static flow pusher entry names. This will allow a single source host to have multiple connections load-balanced across multiple LB hosts.

Link latency estimation

We now take into account the one-way latency between each switch (src, dst) and the controller when determining data plane link latencies.

First round of support for primitive link latency detection. We do not presently account for the latency between the switches and the controller.

Fixed srcPort bug in compareTo()

TCP checksum error. New code, based on JSocket Wrench code.

Better to rely on the compareTo() method of DatapathId and OFPort.

IPv6 support, new device manager

VLAN wildcard is null, unlike others. REST API now returns correct devices across all VLANS when VLAN is unspecified.

Fixed port stats reply serialization where not all ports would be shown if sent in different messages.

Forwarding unit tests updated to test for IPv6 forwarding. Updated IPv6 and Ethernet to print known packets correctly and account for forgetting to set the IpProtocol, respectively.

Added some IPv6 tests and added the IPv6 secondary index to the device manager's init function (ooops).

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).

Forwarding and handshake optimizations and bug fixes

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 :-).

Allow switches that don't support table-features message to still receive table-miss flows

Change error message for IllegalArgumentException. It's not just an SSL issue. Also, didn't realize this at the time, but a switch that does not support table features will not have the table-miss flows inserted at present. As a workaround, we don't check for table existance before adding the flows. This might result in a flow-add error, but it's better than not having the flow when you would expect it. TODO: Have a flag in the switch that denotes whether or not table features were supported.

Improve handshake reliability with user modules that implement IOFSwitchListener and modify flow table on switchAdded event

Patched the handshake so that on transition to master, we guarantee the order of flow table operations (e.g. clear, adding table-miss flows, and IOFSwitchListener module switchAdded/switchActivated listener operations). Barriers are used inbetween all such operations.

Quick bug fix in OFHello composition for OF versions 1.0, 1.1, and 1.2. 

Fix bug in controller OF protocol version when we set below 1.3. We now honor OF1.2 and under's lack of version bitmaps in the hello.

OF-DPA updates and ignore PI on wait features

Added the next round of OF-DPA features. None of this has been tested yet, but we are closer to a learning-switch capable OF-DPA switch as programmed from Floodlight. There are a few utility functions in OFDPAUtils that allow for the installation of the required OF-DPA groups and flows so that the switch can be treated as an (almost) normal switch from the perspective of Forwarding/LearningSwitch. There is a utility function that will need to be used to make sure the instructions, matches, and table ID are correct though. This has been done, and hopefully works well. Included with this commit are OFPortMode and OFPortModeTuple, which help to keep track of OFPorts that are in either trunk or access modes. This impacts the groups to be used by OF-DPA.

Adding OFDPAUtils.java

Features request via REST API bug fix and start on OF-DPA support

Patched features request/reply via REST API. Wrote a stub for OF-DPA default flow insertion -- still a work in progress. It's an uncalled function right now, so it will not hurt anything.