Skip to content
Snippets Groups Projects
  1. Jun 23, 2016
  2. Jun 21, 2016
  3. May 31, 2016
  4. May 18, 2016
  5. May 16, 2016
    • Ryan Izard's avatar
      This is a huge commit. Lots of (good) stuff has been added and updated. First... · b9458ee4
      Ryan Izard authored
      This is a huge commit. Lots of (good) stuff has been added and updated. First and foremost, OpenFlow 1.5 is now supported (yay) via a major update to OpenFlowJ-Loxi. This update necessitated the update of the Static Flow Pusher module and MatchUtils, ActionUtils, and InstructionUtils to support the newly-added features. This prompted me to explore the SFP to see if there was anything that could be improved. First thing that came to mind was adding support to push OpenFlow groups in addition to flows, thus group support has been added to the SFP via JSON, which is the format that should have been used in the first place. Action lists will be updated in the near future to be JSON instead of one massive ',', '=', and '->' delimited string. Thus, the Static Flow Pusher has been renamed the StaticEntryPusher, since it now encompasses groups. While groups were being added to the SFP (ahem...SEP), a number of optimizations were made to the SEP code, greatly reducing its complexity (IMHO). The support for OpenFlow meters can now be added rather trivially in the future, if desired. Last thing to note about the SEP is the work-in-progress addition of a 'schema' API to allow northbound applications to get information about SEP syntax. This is not complete yet, but the skeleton code is in place. Next thing in this pull request is miscellaneous changes throughout the controller, primarily in (de)serializers and REST APIs to support OpenFlow 1.5. Next item of business is the removal of the DebugEventService. This is an artifact of days past and need not clutter the controller anymore. Same goes for the TestModule; now that we have better tutorials and documentation on the wiki, an example isn't necessary. And, last but not least, some old libraries that weren't being used have now been removed.
      b9458ee4
  6. Apr 29, 2016
  7. Apr 28, 2016
  8. Apr 26, 2016
  9. Mar 28, 2016
    • Tulio Ribeiro's avatar
      Now it is totally event driven. · 0fe87738
      Tulio Ribeiro authored
      Hello guys, I have changed the logic of simple.FT (Fault Tolerant) module.
      
      The basic idea is, the FT module register on SyncManager to receive RPC events
      (connect and disconect nodes).
      
      In connect events, the controller send its switch list to storage and
      the other controllers can sync this info.
      In disconnect events, the controller is informed about which controller crashed and
      get switch list from storage and send a role request message to swicthes.
      
      Regards.
      0fe87738
  10. Mar 26, 2016
  11. Mar 25, 2016
  12. Jan 25, 2016
  13. Jan 21, 2016
  14. Dec 22, 2015
  15. Dec 18, 2015
  16. Dec 15, 2015
  17. Dec 07, 2015
  18. Dec 04, 2015
  19. Oct 08, 2015
  20. 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
  21. Oct 05, 2015
  22. Sep 21, 2015
  23. Aug 31, 2015
  24. Aug 20, 2015
  25. 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
  26. Aug 13, 2015
  27. Jun 27, 2015
Loading