= 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 
   1. visualization of a topology setup from file
==== topology description file format ====
For now, [http://graphml.graphdrawing.org/primer/graphml-primer.html 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.  

The overall architecture will possibly work as follows:

[[Image(topologizer.png)]]

== Components Overviews ==
This section contains some initial design considerations for the various components listed above. 
==== !OpenFlow topology setup ==== 
It was assumed that [http://floodlight.openflowhub.org 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.         

 4. '''''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.