Skip to content
Snippets Groups Projects
  1. Jul 15, 2016
  2. Jul 13, 2016
  3. Jul 11, 2016
  4. Jul 01, 2016
  5. Jun 30, 2016
  6. May 31, 2016
  7. May 18, 2016
  8. 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
  9. Apr 28, 2016
  10. Apr 26, 2016
  11. Apr 06, 2016
  12. Feb 22, 2016
  13. Jan 21, 2016
  14. Dec 18, 2015
  15. Oct 07, 2015
    • Ryan Izard's avatar
      Fixed (really this time) the last bug WRT link latencies. This actually wasn't... · 1aa05bbb
      Ryan Izard authored
      Fixed (really this time) the last bug WRT link latencies. This actually wasn't even a latency bug, but it existed beforehand. We only dispatch an update when checking for link timeouts if the link's unicast time just expired and we still have a valid multicast time. Otherwise, we remove the link if both unicast and multicast times are expired. Originally, we were dispatching updates when multicast times were expiring and unicast times were still valid. Such a case results in the link being in the unicast state before and after the multicast expiration; thus, no link update should be dispatched.
      1aa05bbb
    • Ryan Izard's avatar
      Topology manager now purges any existing link in its data structures before it... · 211b9774
      Ryan Izard authored
      Topology manager now purges any existing link in its data structures before it tries to add a new link (no-op if one exists). This needs to be done in order to update latencies. Also changed some log levels.
      211b9774
  16. Oct 06, 2015
    • Ryan Izard's avatar
      Hooray! Fixed (fingers crossed) the last couple bugs WRT LLDP vs BDDP timing.... · e977a1d8
      Ryan Izard authored
      Hooray! Fixed (fingers crossed) the last couple bugs WRT LLDP vs BDDP timing. Link discovery reaches a steady state now and latency updates do not impact the type of link (unicast/multicast) being reported to the topology manager.
      e977a1d8
    • Ryan Izard's avatar
    • Ryan Izard's avatar
      Fix potential divide by zero. Increased latency parameters to threshold=0.50,... · 516e88bb
      Ryan Izard authored
      Fix potential divide by zero. Increased latency parameters to threshold=0.50, history=10. Maybe it's just because my control plane is over a VPN and over the public internet, but the link latencies are fluctuating a bit. TODO evaluate whether or not we should completely clear the average/history each time we accept a new latency value. This would lessen the number of latency updates.
      516e88bb
    • Ryan Izard's avatar
      Change logging. Update default history size to 10. Base update decision on... · af750c25
      Ryan Izard authored
      Change logging. Update default history size to 10. Base update decision on previous link value, not current observed.
      af750c25
    • Ryan Izard's avatar
      Add latency to trace log in updates · 3ca1f648
      Ryan Izard authored
      3ca1f648
    • 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
  17. Oct 05, 2015
    • Ryan Izard's avatar
      Integrated new topology code and updated unit tests to a passing state. I'd be... · a3447938
      Ryan Izard authored
      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.
      a3447938
  18. Sep 21, 2015
  19. Jun 22, 2015
  20. Apr 16, 2015
    • Ryan Izard's avatar
      Added ability to switch OF roles per DPID or for all switches at once. This... · adb14342
      Ryan Izard authored
      Added ability to switch OF roles per DPID or for all switches at once. This includes a REST interface and integration with the handshake and channel handlers in order to keep the switch in the correct state. An IOFConnectionListener also has the ability to listen for messages that are written now instead of read from the wire. This allows modules to write role requests, have the underlying handshake/channel substrate tap in and listen to the request, and automatically update the role of the switch when the response comes back.
      adb14342
  21. Apr 13, 2015
  22. Apr 03, 2015
  23. Mar 20, 2015
  24. Mar 14, 2015
  25. Mar 09, 2015
  26. Dec 18, 2014
  27. Nov 21, 2014
  28. Nov 13, 2014
    • Ryan Izard's avatar
      This is a scattered commit, but it includes more unit test fixes, including... · 26ce6795
      Ryan Izard authored
      This is a scattered commit, but it includes more unit test fixes, including Forwarding and the NotificationManager's interdependency issue the unit tests were having when being run together as a group. It also includes some typo repairs. The last major change is a bug fix in the LinkDiscoveryManager that fixes the long-time issue of LINK_ADDED and PORT_STATUS messages being inconsistent when a link is brought up. The issue was a race condition between the PORT_STATUS update timer to process the queues and the propagation of LLDP packets from one switch to another that cause the LINK_ADDED updates.
      26ce6795
  29. Nov 07, 2014
Loading