Home
| Copyright: | 2016 WAND. All Rights Reserved. |
|---|
RheaFlow enables a Linux router to perform routing with any number of OpenFlow switches controlled by the application. The OpenFlow switches controlled by RheaFlow behave like a single hardware router to the rest of the network. Additionally, RheaFlow centralises the control plane of the OpenFlow switches and their configuration by multiplexing their interfaces into a single logical device on the Linux router. This provides the network operator with a single point of access for performing debugging and configuration tasks with regular Linux tools.
RheaFlow proactively converts the Forwarding Information Base (FIB) table of the Linux router into OpenFlow rules and installs the rules on the OpenFlow switches to enable them perform routing. The FIB table is computed from the routing table maintained by an IP routing software (in this case a modified BIRD routing daemon) running on the Linux router.
The RheaFlow architecture consists of three applications running on Ryu, a virtul switch running on the Linux router hosting RheaFlow as well as the BIRD routing daemon. RheaFlow makes use of Ryu because it provides Application Programming Interface (API), libraries and an asynchronous event-driven platform for writing network control applications. Additionally RheaFlow also uses Netlink to collect network information from the kernel of the Linux router.
The virtual switch multiplexes the interfaces of the OpenFlow switches controlled by RheaFlow into a single logical device on the Linux router hosting the application. The virtual switch is an Open vSwitch instance that is created and configured by RheaFlow. The virtual switch has a virtual Ethernet interface for each physical OpenFlow switch interface included in the RheaFlow configuration file. These virtual interfaces are created and configured by RheaFlow with consistent naming schemes (based on the vs_port_prefix value provided in the configuration file) that allow the network operator to easily identify the OpenFlow switch interfaces multiplexed on the virtual switch. IP addresses can also be assigned to these interfaces. The virtual switch allows the Linux router to see all control traffic received by the OpenFlow switch interfaces controlled by RheaFlow. The virtual switch provides the network operator with a single point of access for performing troubleshooting tasks in the network. Additionally, RheaFlow updates the virtual switch and its interfaces based on interface status events received from the connected OpenFlow switches, this allows RheaFlow to propagate link failure events on the OpenFlow switches to the IP routing software Linux machine and force route updates.
RheaController reacts to changes in the state of the network by adding or removing OpenFlow rules on the switches and updating the virtual switch configuration as necessary.
RheaRouteReceiver receives route updates from the BIRD routing daemon via TCP socket on port 55650 in JSON format. This choice of JSON input allows RheaFlow to receive routing information from multiple routing daemons and makes it trivial to extend other IP routing engines to provide routing information.
RheaNLSocket communicates with the Linux kernel using netlink messages and maintains a database of interface configuration and neighbour configuration from the Linux network stack. These interface and neighbour databases are used by RheaFlow to maintain a view of the hosts and subnets that are directly connected to the Linux router on all its interfaces (including the virtual ones).
RheaFlowProcessor is used to interact with the OpenFlow switches. It contains methods which create and send OpenFlow flow modification messages to the switches and process packet-in messages from these switches.
NetlinkProcessor is an auxiliary application that uses the Pyroute2 netlink library to receive and process netlink messages asynchronously. NetlinkProcessor receives netlink messages relevant to RheaFlow such as, RTM_NEWNEIGH, RTM_DELNEIGH, RTM_NEWLINK, RTM_DELLINK, RTM_NEWADDR and RTM_DELADDR, these messages are sent to RheaNLSocket via TCP connection on port 55651. RheaNLSocket raises an event to RheaController as necessary for these messages.
- The RheaFlow design was motivated by a desire to reduce the barriers to entry that discourage network operators from using SDN applications (which are still considered new technologies) in production networks. Some of these entry barriers are:
-
- Overly complex configurations
- Difficulty debugging process
- Lack of resilience to certain types of failure.
RheaFlow addresses these concerns by minimising the configuration tasks that should be performed by the network operator, removing opportunities for misconfiguration. RheaFlow achieves these by providing a simple YAML based configuration file to the user and automatically configuring the virtual switch and interfaces with consistent naming schemes for easy debugging and troubleshooting. The automatic configuration of the virtual switch also allows RheaFlow to propagate interface failure events on the OpenFlow switches to the routing daemon without manual intervention, this reduces convergence time and improves the resilience of the network.
Additionally, RheaFlow centralises the control plane of the OpenFlow switches performing routing on the Linux router.
- Delivery mode for Control Traffic; The Linux machine running RheaFlow should receive all control traffic (such as BGP updates, ARP, OSPF LSAs, ICMP, NDP) received on the interfaces of the OpenFlow switches. This traffic could be via the OpenFlow control channel between the switches and RheaFlow as OpenFlow packet-in messages. However, this is inefficient and it is not recommended. RheaFlow provides line rate delivery of control traffic to Linux machine via an Ethernet link between Linux machine and one of the OpenFlow switches. This is known as direct-control path mode and it requires that values are provided for the
fastpath_port,fastpath_vsandfastpath_interfaceoptions in the configuration file.- Multiple OpenFlow Switches: RheaFlow allows any number of OpenFlow switches to behave like a single hardware router. RheaFlow proactively installs OpenFlow rules each switch that ensure traffic bound for interfaces on other switches are forwarded over the inter-switch links between them. RheaFlow requires a full mesh of the inter-switch links between all the OpenFlow switches in the topology. This feature requires adding the inter-switch interfaces with the
interswitch_linksoption for every OpenFlow switch included in the configuration file.
- Single Flow Table Application: RheaFlow was designed as a single flow table application to ensure comptability with a wide range of OpenFlow switches. However, this increases the number of OpenFlow rules in proportion to the number of interfaces used on each OpenFlow switch.
- Realtime Configuration: RheaFlow requires a manual update of the configuration file and a restart of the application before it can control a newly discovered OpenFlow switch.
- Single FastPath Link: RheaFlow only allows a single fastpath link between the Linux machine and the OpenFlow switch for direct control path operations. This lacks redundancy as a failure of the fastpath link will disrupt direct-control path operations.
- Inter-Switch Links: RheaFlow requires n number of interfaces on each OpenFlow switch for n number of OpenFlow switches in the configuration for a full mesh topology. This does not scale and is limited by the maximum number of interfaces available on the smallest OpenFlow switch controlled by RheaFlow.
- Unit tests code for RheaFlow.
- Add multiple flow table support.
- Add policy based routing support.
- Provide realtime configuration features.