A Network Topology Mapper
This page aims to serve as documentation for the on-going work to produce a topology mapping tool/service for the ORBIT testbeds.
Currently ORBIT does not have a framework with which users can easily set up network topologies for their experiments. Users may choose to build test topologies using methods such as:
- node-side packet filtering, e.g.
- switch partitions, e.g. VLANs
- SDN, e.g. OpenFlow
among others, but this entails impromptu scripting or manual configuration. In the ideal scenario a user should be able to set up an experiment by providing a topology description file to a framework that would build the topology on their behalf.
The framework/service is expected to have at least the following components:
- interpretation of user-provided graphs into a topology description file usable by topology setup components
- visualization of a topology setup from file
topology description file format
For now, GraphML has been chosen as the basis for describing topologies.
both on the nodes and network:
- nodes : via OMF (sorry, not familiar with it)
- network : via OpenFlow e.g. a Floodlight module that takes a topology description and pushes static flows, or even CLI.
This section contains some initial design considerations for the various components listed above. The overall architecture will possibly work as follows:
The file parser will produce two outputs, the node:edge information needed by the topology setup component, and a set of hints provided to a component that would initialize the base topology, which the final topology will be enforced upon using dpctl. Initialization would include actions such as starting up VMs and virtual switches, and checking that they are up and are in a configurable state.
OpenFlow topology setup
It was assumed that Floodlight will be used for development. Several methods to enforce topology using SDN methods come to mind:
- re-writing switch capabilities : expose just the switch ports included in the desired topology to the modules involved in the experiment. This may be done by over-writing the FEATURE_REPLY messages that the controller receives from the switches during the initial handshake. Forging FEATURE_REPLY messages may be needed if topologies need to be dynamic.
- static flow entries, via Static Flow Pusher : very high-priority flows may be proactively pushed to the controller via its RESTFul API. This would not require a module within Floodlight, but rather an external script that communicates with it.
- modified forwarding module : A Floodlight module that behaves like the forwarding module, but alters its forwarding behavior based on the topology file. This module would replace any other routing/forwarding module.
- dpctl : A controller/switch independent tool for pushing static flows.
In any case, high-priority static entries would work for the best. As
dpctl is the most device/controller independent, it will be used for configuration.