Commit 651dd38f authored by Christopher Alfeld's avatar Christopher Alfeld
Browse files

The DB to IR plan.

parent 3f9b4cdf
Prerun Outline:
Step 1 - parse.tcl
Here we convert the NS file into a temporary IR file. We
assign port numbers and generate a virtual topology in terms
of these virtual node:port's.
We also do as many checks on the tb-* commands as possible at
this point.
By the end of this step all tb-* commands should have resulted in
data in the IR file. The topology we have is very close to the
final emulation. All that is missing is the delay nodes and
extra links that go along with them.
Step 2 - Traffic Generation
We set up any traffic sources and syncs that may have been requested.
Step 3 - IP address allocation
We now fill out all unassigned IP addresses. Whenever a link or
LAN has already had some of its nodes assigned IP addresses we
preserve the subnet. In cases were no IP addresses have been
assigned we generate a unique subnet and unique IP addresses
within that subnet.
Step 4 - Update DB
If no errors have occurred then we upload our representation into
the DB (virt_nodes and virt_lans) tables.
Swap In Outline:
Step 1 - Snapshot current testbed state
We generate a ptop file from the current testbed state.
Step 2 - DB to top
We take the topology from the database and convert it into a top
file. This involves generating delay nodes.
Step 3 - Assign
We check that resources exist and run assign. If successful we
convert the output into a virtual node <-> physical node mapping
and a virtual node:port <-> physical node:port mapping.
Step 4 - Port Shuffling
We now shuffle ports as much as possible to match the portmap
table. The portmap table holds the last mapping (or none if this
is the first swapin). We can swap two ports if physically they
have the same bandwidth and go to the same destination. In terms
of the Utah testbed this means we can always swap ports of the
same type (ethernet, gigabit, etc.) and so should always be able
to match the previous mapping.
Step 5 - Reserve Resources
At this point we call nalloc and grab the resources we need. If
the resources are no longer available we go back to step 1 (or
Step 6 - DB
We need to calculate and setup vlans and delays. We also update
portmap, nodes, and interfaces.
Step 7 - tbrun
We do all the old tbrun tasks. Should be identical except for
snmpit taking from vlans instead of IR file.
Step 8 - Final DB
At the very end we set the state column of the experiments table
to 'active'.
Swap Out Outline:
Step 1 - Teardown
We reset VLANs, clear up the named maps, and clean up any other
node state.
Step 2 - DB Teardown
We do any DB changes to show that the experiment is no longer
active. This involves changing vlans, delays, interfaces, and
nodes and changing the expt_state flag in experiments.
End Experiment Outline:
Step 1 - Swap Out
If the experiment is currently running we swap it out.
Step 2 - Clean up DB
We remove the experimental data from the DB. This involves
virt_nodes, virt_lans.
Crash Recovery:
If a crash occurs during tbprerun then we should run tbend which will
clean up all partial state.
If a crash occurs during swapin we should do any necessary tasks to
reset node state and run tbswapout to cleanup DB state. There is one
potential problem if the crash occurred at exactly the right moment so
that portmap was only partially updated. In this case we would need
to clear the portmap table for that experiment and would loose our
port consistency. I foresee this as being extremely unlikely and not
worth worrying about. On the Utah testbed, as the portmap should
never change after it is setup on the first swapin, this is even more
unlikely. If we decide we really care about this we can add
generation numbers to the portmap table, add the new generation before
removing the old, and add checks for crash recovery.
If a crash occurs during tbend we should be able to rerun tbend
without adverse effect.
DB tables:
The existing tables: delays, vlans, nodes stick around to represent
current DB state.
We'll need tables to store experiments:
virtual name
ips This is a list of <port>:<ip>
The following table is both lans and links. Links are just lans with
only two nodes.
virtual name
members (node:ports)
We need a table that stores the previous host:port virtual<->physical
mapping. This table is used in the port shuffling step of tbswapin to
try to maximize port consistency across swaps. While an experiment is
swapped in the this table is redundant with the vname columns of the
nodes and interfaces table. However, as soon as an experiment is
swapped out this becomes a useful record of the previous mapping.
Add expt_state to experiments with values 'active'|'dormant'.
Add vname to interfaces table which holds virtual name of each
How it connects:
Virtual Physical
virt_nodes nodes
virt_lans delays, vlans
NS File:
source tb_compat.tcl
set ns [new Simulator]
set n1 [$ns node]
set n2 [$ns node]
set n3 [$ns node]
set lan1 [$ns make-lan "$n1 $n2" 100Mb 0ms]
set link1 [$ns duplex-link $n3 $n2 100Mb 0ms DropTail]
tb-set-node-ip $n1
This will generate a virt_nodes table of something like:
pid eid vname ips ...
testbed chris n1 0:
testbed chris n2 0: 1:
testbed chris n3 0:
and a virt_lans table of:
pid eid vname members ...
testbed chris lan1 n1:0 n2:0
testbed chris link1 n2:1 n3:0
Now let's assign runs and comes up with the following assignment:
vnode pnode
n1 pc33
n2 pc19
n3 pc2
vport pport
n1:0 pc33:eth0
n2:0 pc19:eth1
n2:1 pc19:eth3
n3:0 pc2:eth2
As this is the first run we do now port shuffling. We do update the
portmap table:
pid eid vnode vport pport
testbed chris n1 0 eth0
testbed chris n2 0 eth1
testbed chris n2 1 eth3
testbed chris n3 0 eth2
We now generate the vlans table:
id pid eid virtual type members
0 testbed chris lan1 lan pc33:eth0 pc19:eth1
1 testbed chris link1 link pc19:eth3 pc2:eth0
Finally we fill in the reserved and interfaces table:
node_id pid eid vname ...
pc33 testbed chris n1
pc19 testbed chris n2
pc2 testbed chris n3
node_id port IP ...
pc33 eth0
pc19 eth1
pc19 eth3
pc2 eth2
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment