README

This repo contains the source code for the SDN system and emulation framework discussed in the SOSR2021 paper Helix: Traffic Engineering for Multi-Controller SDN. Helix is a hierarchical multi-controller (MCSDN) system that combines various techniques to address performance, robustness and consistency concerns of deploying TE on WANs. The emulation framework allows evaluating the control plane failure resilience, data-plane failure resilience and TE optimisation performance of SDN systems.

The raw results collected to evaluate Helix (presented in the paper) can be found in the SOSR2021_RESULTS/ folder of this repo. Please refer to the folder readme file for info on how results were collected.

To evaluate Helix’s TE optimisation performance, we extended YATES to add support for evaluating reactive TE algorithms. Our modifications to YATES and the Helix YATES modules are available here.

Repo Overview

This section contains an overview of the items contained in this repo as well as a description of all the modules used by Helix and the emulation framework.

Helix Implementation

Modules of the Helix MCSDN system. Helix is an OpenFlow controller that uses the Ryu framework. Helix defines two controller types, local and root controllers. A local controller connects to and interacts with data plane devices. The root controller connects to other local controllers and coordinates inter-domain/inter-area operations.

• TopoDiscoveryController.py
  • The base controller module contains code to detect the topology and defines shared methods for installing rules and interacting with switches. All controller types inherit this module.
• OFP_Helper.py
  • Static helper module that contains convenience methods to allow building and manipulating OpenFlow rules.
• ReactiveController.py (Extends: TopoDiscoveryController.py)
  • Alternative SDN controller that implements reactive (restoration) data plane recovery. The controller is involved in all failure recovery decisions (actively monitors links and recomputes paths when a failure is detected).
• ProactiveController.py (Extends: ProactiveController.py)
  • Helix Local controller that implements proactive (protection) data plane recovery. The controller computes multiple rules for each source-destination pair and installs using the fast-failover group type. Switches will recover from failures without controller intervention.
• ProactiveControllerAlt.py (Extends: ProactiveControllerAlt.py)
  • Helix local controller that computes loose path splices to improve protection coverage. Functionality, both proactive controller modules behave the same.
• TE.py
  • Helix’s TE optimization module. Defines three TE optimisation methods (FirstSol, BestSol, BestSolUsage, CSPFRecompute). Preferred default TE method for Helix is CSPFRecompute with a candidate_sort_rev = True (optimise heavy hitters first).
• ShortestPath/
  • Folder that contains modules to store topology information and perform path computation (using Dijkstra’s algorithm).
  • ShortestPath/dijkstra.te DEPRECATED
    • Old simple topology and path computation module which has no support for saving port statistics (used for TE).
  • ShortestPath/code_dijkstra_test.py
    • Unit tests for dijkstra.py module. See 'Testing' section.
  • ShortestPath/dijkstra_te.py
    • Similar to the dijkstra.py module, however, it extends topology graph to allow storing port/link stats (metrics) for TE.
  • ShortestPath/code_dijkstra_te_test.py
    • Unit test for dijkstra_te.py module. See 'Testing' section.
  • ShortestPath/protection_path_computation.py
    • Module that contains useful methods to allow computing protection paths rebuilding paths from group table entries (used by the standard proactive Helix local controller).
• topo_discovery/
  • Folder that contains topology discovery code used by the controller. Code is an extension of the standard RYU LLDP topology discovery code that adds host discovery, inter-domain link discovery, support for controller roles, and removes the need for the --observe-links flag. Do not use any of the standard RYU topology discovery modules as this will auto-start the RYU detection module which can cause problems.
  • topo_discovery/api.py
    • Contains convenience methods to send requests to the topology discovery instance to retrieve active links and pause/resume detection on controller role changes.
  • topo_discovery/event.py
    • Events that need to be generated and handlers registered for to receive topology discovery information.
  • topo_discovery/lldp_discovery.py
    • Actual topology discovery module that runs on a separate eventlet instance and performs active detection using LLDP packet flooding and retrieval. NOTE: a special flow rule that matches LLDP packets is installed onto the switches to send any packets back to the controller.
• RootCtrl.py
  • Helix root controller that performs inter-domain (inter-area) operations. Note: the root controller does not connect to switches so it does not implement any Ryu methods. Root controller relies on local controllers (i.e. ProactiveController.py) to install forwarding rules (interact with the data-plane).

YATES Wrapper

We evaluated Helix’s TE optimisation algorithm using YATES a TE simulation framework. This section describes the wrappers we call in YATES to simulate Helix's path computation and TE algorithm. The wrappers import and override the Helix controller modules to implement shallow controllers that load and prime data structures with state from files (generated during a YATES simulation) and execute controller code to perform specific operations (e.g. compute paths or perform TE), simulating Helix’s behaviour. The wrappers override handler methods and module constructors to disable connecting/interacting with switches (Ryu specific code and methods), spawning multiple threads or waiting (e.g. path or TE consolidation timeouts), and communicating with other switches (e.g. sending or listening for RabbitMQ messages).

The wrappers define several supported actions that require different state provided as serialized JSON files (generated by YATES) or arguments (run the wrappers with the --help to see list of supported arguments). When executed, the wrappers will load the provided state, perform the specified action, and return the action result by printing a list of path changes (or info) to standard out. YATES will read and process the output, which is used to modify the active paths of the current simulation run (apply the specified changes). All wrappers generate temporary files that contain state that needs to be saved between calls (e.g. computed path info). All temporary files are saved in the /tmp/ folder and use a naming convention of /tmp/<info>.<CID>.tmp, where <info> is the info that is stored (e.g. "paths" for paths information) and <CID> the controller identifier (specified as an argument). The temporary files are generated when calling the compute path ("topo") action and modified when performing other operations such as TE optimisation. The compute path action always needs to be called at the start of every YATES simulation.

• yates_wrapper.py DEPRECATED
  • Old wrapper that allows testing Helix in single controller mode. This wrapper is partially deprecated. To test performance of Helix using a single controller, define a map that contains a single device connected to all switches in the topology and use yates_mctrl_wrapper.py.
• yates_mctrl_wrapper.py (Extends: ProactiveController.py, TE.py)
  • Helix local controller wrapper that allows simulating local controller behaivour in YATES. Code defines several actions to simulate Helix's behaivour under specific conditions. Network state for each action (e.g. topology and link usage information) needs to be provided as a serialized JSON file (yates_mctrl_wrapper.py --help for list of arguments).
• yates_root_wrapper.py (Extends: RootCtrl.py)
  • Helix root controller wrapper.

Emulation Framework

The emulation framework allows evaluating the control-plane failure resilience (discussed in the paper), data-plane failure recovery, and TE optimisation performance of MCSDN/SDN systems. The emulation framework is built on top of Mininet, which is used to emulate a virtual topology. Mininet provides support for emulating network conditions such as link latency, loss or packet corruption (using netem). The emulation framework will consider a SDN system as a black-box, observing its modifications to the network rather than interacting with the framework via a specific interface. For more info see "Emulation Framework" section of this read me.

• emulator_base.py
  • Base module of the emulator that contains shared code and useful methods to allow easy loading of configuration files and management of controllers.
• EmulateLinkFailure.py
  • Emulation framework that evaluates data plane failure recovery performance of an SDN controller. The emulator generates a constant stream of packets using Pktgen, introduces failures in the topology (as defined by a scenario file), and computes the time it takes for traffic to be redirected to an alternative path (i.e. failure was detected and fixed).
• EmulateTE.py
  • Emulation framework that evaluates TE optimisation performance of a SDN s