We Want You...

...To Add Cool Features to Floodlight!

Want to help contribute to Floodlight? You've come to the right place! Here is a list of features we would like to add to Floodlight, but do not have the manpower to implement ourselves. Feel free to add a feature or add your contact information to existing projects if you would like to help contribute. Multiple people interested in implementing the same feature should collaborate using the floodlight@groups.io email list to get community feedback.

Key

	I'm getting some attention, but the more help the merrier! Contact team members and floodlight@groups.io if you'd like to help finish me!
	I need some love, please help! Add yourself to me if you're interested and let the team know at floodlight@groups.io!
	I am complete! Thanks to all who helped make me become an official Floodlight feature/module!

Feature Name	Feature Description	Volunteers
Multipath Routing	Add the ability for modules to choose between multiple routes in multipath topologies. The idea is to have the TopologyInstance precompute all possible paths and expose them as a list of routes using the existing IRoutingService API. Might want to order by shortest path defined by latency or hop count.	Tomek Osiński, osinstom@gmail.com Rafał Sosnowski, r.sosnowski93@gmail.com Paweł Szumański, pawel.szumanski@gmail.com Ryan Izard, rizard@g.clemson.edu Geddings Barrineau, cbarrin@g.clemson.edu Junaid Zulfiqar, jzulfiq@g.clemson.edu Scott Groel, Casey McCurley, Caleb Linduff
Quality of Service	Add a module to expose queue and meter configuration from the REST API. This should hook into Forwarding so that Forwarding will include configured meters/queues in its flows for hosts/devices or classes of traffic that should go through meters or use queues instead of simply being sent out a switch port directly.
Switch Roles	Properly handle OpenFlow 1.4 roles. OpenFlow 1.4 switches notify the controller of changed roles. Make sure we process these roles and transition accordingly. Update LinkDiscovery module to not send LLDP packets out switches that are in the SLAVE state. This likely involves getting active switches and not all switches when sending LLDP packets. Either that or explicitly checking the role before sending them. Should be a simple fix regardless.
OpenFlow 1.5	OpenFlow 1.5 support has been integrated into Floodlight, including the static flow/entry pusher. Handshake tests have been done with OVS 2.5.0. Unfortunately, OVS does not implement other necessary OpenFlow 1.5 features such as packet-out, so other testing has been limited.	Ryan Izard, ryan.izard@bigswitch.com
VLAN access/trunk handling	Allow Forwarding to insert flows to push/pop VLAN tags for hosts configured on switch ports with/without VLAN tags. We can detect whether a host should be sent tagged or untagged packets based on its "true" attachment point and whether or not this attachment point has a VLAN.
L3 Routing	Floodlight's Forwarding module is able to forward between hosts on a single subnet. There needs to be a way to route between hosts on different subnets. There are two implementations that should be supported: (1) using physical gateways, (2) using virtual gateways. Option (1) would require few changes to get working. A host on the same subnet would be configured as the router and each host on the subnet would be configured to use that IP as the gateway. Forwarding would need to detect this and be able to handle routing to a host by MAC address and ignore the destination IP in the lookup process. Option (2) would work in a similar manner to the Virtual Network Filter module, however Floodlight should be able to be configured with virtual gateways for implementation via flows. Hosts will be configured with these gateway IPs in their routing tables, but Floodlight would be responsible for responding to gateway ARP requests and rewriting destination MAC addresses from the gateway MAC to the next hop MAC (and source to current hop). This implementation should be able to work with multiple hops, across multiple logical networks, and in conjunction with option (1) above. The DHCP server module should be able to work in conjunction with L3 routing.	Qing Wang, qw@g.clemson.edu
NAT	Network Address Translation. Specify certain virtual gateways (see L3 routing above) as NAT boxes. Traffic through these virtual gateways should rewrite the source MAC, source IP, and source transport port to the those of the gateway, where the source transport port is some available port (i.e. Floodlight would need to keep a pool for each virtual gateway). The destination MAC address will be rewritten to the next hop MAC, as described in L3 Routing above. Packets a part of the same connection being routed back through one of these gateways should rewrite the original source transport port, IP address, and next hop MAC, just as a NAT router does.	Qing Wang, qw@g.clemson.edu
HA Support	Floodlight includes a Sync module designed to allow multiple Floodlight controllers to work collaboratively and provide a safe failover in the event of a catastrophic failure on one of the controllers. Unfortunately, this module needs to be integrated within the rest of the controller and needs to be tested. It's not a hard task but will require some effort and Java skills. The integration with the rest of the controller is required in order to synchronize information between Floodlight controllers (how the "sync" module got its name). Several interfaces are exposed by the Sync module to allow user and controller modules to register to have their information shared with other controllers. The difficulty here is in correctly pushing updates and receiving updates from other controllers in e.g. the Device, Link Discovery, Switch, and Topology modules.	Bhargav Srinivasan, sbhargav3@gatech.edu Om Kale, omkale@gatech.edu
Add groups to static flow pusher	Static flow/entry pusher now supports groups. The addition of support for meters is the next logical step, but what's the demand for the feature?	Ryan Izard, ryan.izard@bigswitch.com
Clean Shutdown	Create a service exposed to modules that allows them to register as listeners. For example, the service might be called the IShutdownService, and the listener might implement IShutdownListener with the function shuttingDown(). When an event occurs that prompts a shutdown, such as a particular REST API invocation or some other event, the IShutdownService will call all listeners' shuttingDown() functions, where they can perform necessary cleanup and get into a stable state.
Expose Floodlight version via REST API	Need a good way for users to know the version of Floodlight they're using.	Ryan Izard, ryan.izard@bigswitch.com
Switch Pipeline Plugin	Create plugins for different types of switches that do not have OVS-like tables. This would allow Forwarding and other modules to leverage the plugin to install a flow intention (expressed as an OFFlowMod). The black box plugin would convert this flow mod to any sequence of flow mods as required by the pipeline to achieve the expressed intent.
Any suggestions?	Send mail to floodlight@groups.io and add a row here!	Could be you!