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.

Motivation

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. ebtables
• 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.

Components

The framework/service is expected to have at least the following components:

graph visualization

Two components:

1. interpretation of user-provided graphs into a topology description file usable by topology setup components
2. visualization of a topology setup from file

topology description file format

For now, ​GraphML has been chosen as the basis for describing topologies.

topology setup

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.

Components Overviews

This section contains some initial design considerations for the various components listed above.

OpenFlow topology setup

It is assumed that ​Floodlight will be used for development. Several methods to enforce topology using SDN methods come to mind:

1. 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.

2. 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.

3. 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.