Skip to content
Snippets Groups Projects
  1. Jul 06, 2016
  2. Jul 05, 2016
  3. Jun 30, 2016
  4. Jun 14, 2016
  5. Apr 29, 2016
  6. Apr 28, 2016
  7. Apr 26, 2016
  8. Mar 25, 2016
  9. Jan 25, 2016
  10. Jan 21, 2016
  11. Dec 22, 2015
  12. Dec 18, 2015
  13. Dec 15, 2015
  14. Dec 07, 2015
  15. Dec 04, 2015
  16. Oct 08, 2015
  17. Oct 06, 2015
    • Ryan Izard's avatar
      Implemented a rolling link latency history for switch links. Each link will... · 5f511c16
      Ryan Izard authored
      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.
      5f511c16
  18. Oct 05, 2015
  19. Sep 21, 2015
  20. Aug 31, 2015
  21. Aug 20, 2015
  22. Aug 15, 2015
    • Ryan Izard's avatar
      Lots of goodies here. Apologies for the largish commit. Most files are just... · 774b1ff0
      Ryan Izard authored
      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 :-).
      774b1ff0
  23. Aug 13, 2015
  24. Jun 27, 2015
  25. Jun 26, 2015
  26. Jun 22, 2015
    • Ryan Izard's avatar
      First go at implementing OpenFlow version bitmaps. Also, made it a lot easier... · 10476046
      Ryan Izard authored
      First go at implementing OpenFlow version bitmaps. Also, made it a lot easier to change your default OpenFlow versions via floodlightdefault.properties's net.floodlightcontroller.OFSwitchManager.supportedOpenFlowVersions variable. The variable searches any string for 1.0, 1.1, 1.2, 1.3, and 1.4 and saves those versions as possible OpenFlow versions to use during a handshake and used in our controller's version bitmap. We don't presently account for future versions that might be e.g. 1.10 (which 1.1 would match). We need to use regexs to make the string parsing more robust. What I also noticed in working on this commit was that there are no utilies for parsing OpenFlow versions from wire (at least that are exposed by Loxi). TODO Create an OFVersion.ofWireValue(int wireVal) function in Loxi that efficiently tries to locate an OpenFlow version from the wire value. Right now, there are getters for each defined version, but not a utility to go the other way. Also, it might be useful to include an OFVersion.ofString(String laypersonString) that takes e.g. '1.1' and tries to get the OFVersion enum value. Last thing: NEED TO FIX CONNECT, DISCONNECT, and RECONNECT BUG that only occurs when OVS connects to Floodlight after Floodlight has been running first. I think it has to do with how OVS starts up and ***might*** be an OVS issue and not a Floodlight issue. Furthermore, need to allow OVS to send a PORT_STATUS message before we query for the PORT_CONFIG in the handshake. It's okay, we'll just get the port info again when we query for it shortly. This causes us to disconnect OVS even though the handshake is okay.
      10476046
  27. Jun 08, 2015
  28. Jun 03, 2015
  29. Jun 02, 2015
Loading