Using the Emulab Frontend to ProtoGeni

Also known as ProtoGeni cooked mode, is the ability to use the Emulab front end, to create and interact with ProtoGeni resources. Cooked mode is currently under development in Utah, so you will need to have an Emulab account at Utah. See the Getting Ready section of the ProtoGeni tutorial for an explanation of how to get and prepare your Emulab account.

Once you have your Emulab account, you should read through the Emulab Tutorial so that the rest of this document makes sense.

Using The Emulab Java Client For Cooked Mode

To modified Java client for cooked mode is located here.

A Trivial Example

Here is a trivial NS file that allocates a single node. For brevity, only the relevant portions of the NS file are shown inline.

set nodeA [$ns node]

tb-set-hardware $nodeA pcfedphys
tb-fix-node $nodeA urn:publicid:IDN+emulab.net+node+*

In this example, we are asking for a pcfedphys node, which is a raw physical machine. We want that node to be allocated from the Utah cluster, but we do not care which node it is; the system will allocate a free node. If we had wanted to pick a specific node, we could change the URN to:

tb-fix-node $nodeA urn:publicid:IDN+emulab.net+node+pc333

although this node must obviously be free and available when you go to instantiate your experiment.

To instantiate this example, you should follow the same procedure for starting experiments as described in the Emulab Tutorial. Once your experiment is swapped in, you should refresh the Show Experiment page for the experiment. You will see the node that has been allocated to your experiment, is listed. This node is a "proxy" for the ProtoGeni resource; it does not actually exist except as a record in the Emulab database. Click on the name of the node, and you will be taken to another web page that displays a variety of information. Look for the line that says Hostname:; this is the actual name of the node, and the name you should use when logging in via SSH.

Virtual Machines

Instead of raw physical machines, you may also ask for virtual machines; these are sometimes easier to get and if your application allows you to multiplex a number of virtual machines on a single physical machine, you have a better chance of being able to get the resources you need. Consider this example:

set nodeA [$ns node]
set nodeB [$ns node]

tb-set-node-os $nodeA GENIVM
tb-set-hardware $nodeA pcfed
tb-fix-node $nodeA urn:publicid:IDN+emulab.net+node+*

tb-set-node-os $nodeB GENIVM
tb-set-hardware $nodeB pcfed
tb-fix-node $nodeA urn:publicid:IDN+emulab.net+node+*

After you instantiate this experiment, go to the Show Experiment page; you will see two nodes listed. Clicking on the node names, you can again find the Hostname info, as well as the SSHD port number you need in order to log into your node. For example, if the Hostname is pc76.emulab.net and the port number is 32333, then this command will log you in.

ssh -p 32333 pc76.emulab.net

Links

Links are also supported in cooked mode experiments, as described in the Emulab Tutorial. A critical difference though is that traffic shaping is not currently supported; only the native speeds can be used. In the following fragment, the speed of the link is specified as * to indicate that the resource mapper should use whatever the native speed of nodes it chooses.

set link0 [$ns duplex-link $nodeA $nodeB * 0.0ms DropTail]

Link tracing and monitoring is not currently supported on these links.

Tunnels

To support network topologies that span different sites, you may specify tunnels between nodes at different sites. Existing Emulab syntax can be used:

set mytun [$ns duplex-link $nodeA $nodeB 100Mb 0ms DropTail]
tb-set-link-encap $mytun gre

which will create a GRE tunnel between the two nodes. GRE is the only supported tunneling encapsulation.

Program Agents

Program agents (and more generally the event system) are supported, albeit with a few kinks:

set progA [$nodeA program-agent -command {/bin/ls -lt >& /tmp/foo}]
set progB [$nodeB program-agent -command {/bin/ls -lt >& /tmp/foo}]

$ns at 60  "$progA start"
$ns at 60  "$progB start"

Program agents and the event system are described in more detail in the Emulab Advanced Tutorial.

A critical issue at the moment is that the event system has interoperability with some testbeds. If the remote site is not running with ELVIN_COMPAT turned on, the events will not work. We are actively working to fix this.

Tar Files and RPMs

Tar file and RPM installation are also supported, and described in more detail in the Emulab Tutorial.

tb-set-node-tarfiles $nodeA /usr/local /proj/testbed/tarfiles/silly.tar.gz
tb-set-node-rpms $nodeB /proj/testbed/rpms/silly.rpm