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.

Fixed some DeviceManager unit tests and (not quite a bug but) an issue converting an Entity to a SyncEntity, which requires primitives for serialization. I tried to supply the MacAddress, IPv4Address, etc JSON serializer classes via the @JsonSerialize annotation, but the serializer still didn't do it...

Quick fix for OF1.0. Should find a way so that all modules don't have to worry about how to get Match from PI. OF1.0-1.2 use pi.getInPort(); OF1.3 uses pi.getMatch(MatchField.IN_PORT). Workaroud is: (pi.getVersion().compareTo(OFVersion.OF_13) < 0 ? pi.getInPort() : pi.getMatch().get(MatchField.IN_PORT))

VLAN matches added conditionally to Forwarding flows. Started moving sync code to the OFSwitchManager; not sure if SyncService needs to live there too.

Ethernet's untagged VLAN notation updated. Match.Builders created from exising Matches will only remember parent Match's MatchFields if the new builder is not modified (not very useful IMHO). MatchUtils.java added to create a new builder from and existing Match and retain all the MatchFields unless explictly overwritten with the new builder.

Forwarding with port, L2, and, L3 matches. OFPBMC_BAD_VALUE sent back from switch for matching FL's no-VLAN notation; need to update all VLAN's = -1 to NO_VLAN instead.

Ethernet fixed; proto = byte, not short. Fixed DeviceManager; toString() of Entity corrected and misc bugs. Fixed Forwarding; forgot to initialize OFSwitchService reference. Basic Forwarding works! Known issue: Forwarding only matches switch port numbers...

Working on device manager. Currently devices aren't being saved, or cannot be located after they are stored...I'm searching incorrectly for devices and entities or am not saving them correctly or at all.

This reverts commit 4ae94669.

Refactored structure of core components to work with openflowj-loxi.
Presently refactoring Routing, Firewall, Forwarding, DeviceManager,
LinkDiscovery, Topology, and LearningSwitch.
Hub has been refactored.