There is alternatively a 32bit VM, but we don't recommend it (2.7 GB):
netsynth32.ova.
There is a binaries+source ZIP equivalent of the tarball (41.5 MB):
netsynth.zip.
Backup mirrors:
paper.pdf,
paper.pdf,
netsynth64.ova,
netsynth32.ova,
netsynth.tgz,
netsynth.zip.
We recommend using a 64bit host machine with at least 2+ processors and 8+ GB RAM.
netsynth
, password: netsynth
).~/tools/netsynth
directory.PLATFORM=`uname -i` tar -xvf netsynth.tgz cd netsynth tar -xvf yices-1.0.39-$PLATFORM-pc-linux-gnu.tar.gz cd yices-1.0.39 chmod +rx bin/yices chmod +rx lib/libyices.so sudo cp -rv * /usr cd .. sudo apt-get install -y liblog4cxx10-dev libcppunit-dev graphviz python-networkx mininet cp $PLATFORM/netsynth . sudo cp $PLATFORM/net_plumber $PLATFORM/NuSMV /usr/bin
./netsynth help
and see a usage message.cd experiments make cd ..
tar -xvf netsynth.tgz cd netsynth ./install_ubuntu.sh
install_ubuntu.sh
is fairly well-documented to assist with this../netsynth
and see a usage message, and typing
which net_plumber NuSMV yicesshould show all three of these tools as being installed.
./netsynth help
./netsynth <command> [options]Note that commands can be abbreviated:
./netsynth help ./netsynth he ./netsynth hTo get a list of options for a certain command:
./netsynth help <command>
solve
, which
solves a pre-defined network update problem instance. These are stored as .ltl
files,
and encode the topology, initial/final configuration, and linear temporal logic (LTL) property in a
human-readable format:
./netsynth solve code/examples/diamond.ltl
The output is an SDN program, represented as a sequence of controller commands, each of which is either update (represented as (s,r) where s is a switch ID, and r is a rule index) or wait (represented as #). A negative rule index is used to denote an atomic update of all rules on that switch (i.e. a switch-granularity update).
To view only the synthesized SDN program, grep for a left-parenthesis:
./netsynth solve code/examples/diamond.ltl | grep "^("
experiment
, which
builds a randomized problem instance from a given topology:
./netsynth exper experiments/models/zoo/Napnet.gmlYou can see the generated LTL specification by typing:
./netsynth exper experiments/models/zoo/Napnet.gml | grep FORMYou can also generate the
.ltl
file and then solve it separately (dumped as model.ltl
).
Additionally, you can visualize the generated experiment via the dumped files model.pdf
(port-level topology, and initial/final switch
configurations with initial rules as solid lines and final rules dotted), and switches.pdf
(switch-level network topology):
./netsynth exper experiments/models/zoo/Napnet.gml -dump ./netsynth solve model.ltl
./run_experiments.py
script.
Arbitrarily-many names can be specified (separated by spaces). If no name is specified, all experiments are run in alphabetical order:
./run_experiments.py <experiment_name>
Name | Paper Description | Paper Figure(s) |
result_reach_topozoo_nusmv_all | Incremental vs. Monolithic (p. 10) | Figure 6(a) |
result_reach_fattree_nusmv | Figure 6(b) | |
result_reach_smallworld_nusmv | Figure 6(c) | |
result_reach_topozoo_netplumber_all | Incremental Performance * (p. 10) | Figure 6(d) |
result_reach_fattree_netplumber | Figure 6(e) | |
result_reach_smallworld_netplumber | Figure 6(f) | |
result_reach_smallworld_netplumbermc | Incremental Performance, last sentence (p. 10) | N/A |
result_way_topozoo_batch_big | Incremental vs. Monolithic * (p. 10) | Figure 6(g) |
result_way_fattree_batch | Figure 6(h) | |
result_way_smallworld_batch | Figure 6(i) | |
result_way3_smallworld_incr | Scalability (p. 10) | Figure 6(j); Table 1-3 |
result_way_smallworld_incr | ||
result_reach_smallworld_incr | ||
result_way3_smallworld_incr_imp | Infeasible Updates, switch-impossible (p. 10) | Figure 6(k); Table 4-6 |
result_way_smallworld_incr_imp | ||
result_reach_smallworld_incr_imp | ||
result_way3_smallworld_incr_rule | Infeasible Updates, rule granularity (p. 10) | Figure 6(l); Table 7-9 † |
result_way_smallworld_incr_rule | ||
result_reach_smallworld_incr_rule |
netsynth/experiments/data/<experiment_name>.csvThe CSV columns are defined as follows:
Column | Description |
filename | experiment filename |
suc_one | Solver #1 - success code: 1=success, 0=failure (timeout or out-of-memory), 2=impossible |
tim_grph | graph generation time (in seconds) |
time_one | Solver #1 - total runtime (in seconds) |
labl_one | Solver #1 - number of Kripke structure nodes re-labeled by model-checker |
call_one | Solver #1 - number of switch/rule changes during synthesis |
chk_time | Solver #1 - total model-checking time (in seconds) |
diff | whether generated update sequence is non-trivial, i.e. not simply lexicographic order (1=yes, 0=no) |
rules | number of flow-table rules (same as switches for switch-granularity) |
nt_rules | number of non-trivial (i.e. updating) flow-table rules (same as nontriv for switch-granularity) |
switches | number of switches |
nontriv | number of non-trivial (i.e. updating) switches |
num_pair | number of source/destination pairs (diamonds) in experiment |
suc_two | Solver #2 - success code: 1=success, 0=failure (timeout or out-of-memory), 2=impossible |
time_two | Solver #2 - total runtime (in seconds) |
labl_two | Solver #2 - number of Kripke structure nodes re-labeled by model-checker |
call_two | Solver #2 - number of switch/rule changes during synthesis |
chk_tm2 | Solver #2 - total model-checking time (in seconds) |
waypts | number of waypoints used in experiment |
seed | random seed used in experiment |
speedup | speedup of Solver #1, i.e. (time_two / time_one ) |
num_wts | number of waits in generated update sequence |
wrm_time | wait-removal heuristic runtime |
./netsynth solve code/examples/diamond.ltl -verboseTo use the wait-removal heuristic:
./netsynth solve code/examples/diamond.ltl -waitremTo use rule-granularity (instead of switch-granularity):
./netsynth solve code/examples/diamond.ltl -rule
./netsynth exper experiments/models/zoo/Napnet.gmlYou can use NetPlumber instead of our incremental model checker. Note that rule-granularity must be enabled, and the property must be "reachability":
./netsynth exp experiments/models/zoo/Karen.gml -prop reach -rule -netplumberTo use NuSMV instead of our incremental model checker:
./netsynth exper experiments/models/zoo/Bellcanada.gml -nusmvYou can alter parameters of the "diamonds" discussed in Section 6 of the paper. For example, the
-pairs
parameter specifies number of source/destination pairs
(i.e. number of diamonds), -prop
specifies LTL property type
(either reach
for reachability or way
for waypointing),
and -waypoints
specifies number of waypoints. The -seed
option
specifies a random seed.
./netsynth exper experiments/models/zoo/TataNld.gml -pairs 2 -prop way -waypoints 3 -seed 19Most numeric options allow you to specify a fraction of the maximum value, and this is specified as a negated floating point between 0 and 1. For example, the following lines
./netsynth exper experiments/models/zoo/TataNld.gml -len -0.5 -waypoints -0.1 ./netsynth exper experiments/models/zoo/TataNld.gml -len -0.5 -waypoints -0.9
set the -len
option to 0.5 times its maximum. Since this option controls the size
of selected diamonds, this setting chooses diamonds that are half the size of the largest ones
found in the topology. Similarly, the first and second commands set -waypoints
to 10% and 90% of the total possible waypoints available on these diamonds.
./netsynth exper experiments/models/zoo/Napnet.gml -impossible ./netsynth exper experiments/models/zoo/TataNld.gml -impossible -cex -heuristic cexSwitch-impossible updates can often be solved by using rule-granularity:
./netsynth exper experiments/models/zoo/TataNld.gml -impossible -rule
./netsynth exp experiments/models/zoo/Napnet.gml -controller -mininetUpon pressing "Enter" to start the controller when prompted, if there is a failure due to "port 6633 in use", try first starting Mininet:
sudo mnIf that fails, try again and you should get a Mininet prompt. Just type "exit" and hit enter. The following Mininet command cleans up the virtualized network state, so try it if something strange is happening:
sudo mn -cThe
experiments/data/mininet_fattree*.txt
files describe in detail how to perform the
experiments related to Figure 1 described in Section 2 of the paper. To summarize briefly, running the
following command
./netsynth solve code/examples/fattree1.ltl -controller -pair a5:a5in1,a7:a7out1 -rule -mininetwill solve the problem instance in
fattree1.ltl
using rule-granularity, and dump a Mininet
script mininet_test.py
. Once you press "Enter" to start the controller when prompted, you can open another terminal
and type:
chmod +x mininet_test.py sudo ./mininet_test.pyThis will initialize Mininet with the proper topology, and our running controller will be used to perform the update. At the Mininet prompt, you can type
h1 ping h2 -i 0.1once our controller says to start the Ping Test, and you should see zero traffic loss throughout the update (type CTRL-C to terminate the
ping
command).
You can add the -bad
option to perform a wrong-order update
./netsynth solve code/examples/fattree1.ltl -controller -pair a5:a5in1,a7:a7out1 -rule -mininet -badand you should see some traffic loss during a Ping Test. You can also use two-phase update instead of our ordering update, and see the rule overhead once the controller finishes:
./netsynth solve code/examples/fattree1.ltl -controller -pair a5:a5in1,a7:a7out1 -rule -mininet -twophase
./netsynth listen 8080See the file
code/examples/diamond.json
for the sequence of JSON commands
which builds the same problem instance as code/examples/diamond.ltl
. You can
send this to a running Netsynth server by typing:
nc localhost 8080 < code/examples/diamond.json