3.1 Accessing Netbed
To minimize administrative overhead, Netbed employs a
hierarchical structure for authorization: To begin a new
project, a “leader,” e.g., a faculty member or senior stu-
dent, submits a simple web form. Once the project has
been approved by Netbed staff, accountability and abil-
ity to authorize other project members are delegated to
the project leader. The web interface then serves as a
universally-accessible portal to Netbed, through which
an experimenter may create or terminate an experiment,
view the corresponding virtual topology, or configure
node properties.
After experiment creation, experimenters may log di-
rectly into their allocated nodes, or in to usershost,
depicted in Figure 1, which serves as a centralized point
of control. This node is also fileserver, which stores
operating system images, exports home and project di-
rectories to local nodes via NFS and to distributed nodes
via SFS, the Secure File System [20]. masterhost is a
secure server for many of our critical systems, including
the web server, database, and switch management.
3.2 Specification
Just as program text is the concrete specification of a
run-time process, an ns script written in Tcl configures a
Netbed experiment. This choice facilitates validation and
comparison since ns-specified topologies, traffic gener-
ation, and events can be reproduced in an emulated or
wide-area environment. For the large community of re-
searchers familiar with ns, it provides a graceful transi-
tion from simulation and an opportunity to leverage ex-
isting scripts. Since Tcl is a general-purpose program-
ming language, a researcher is empowered with looping
constructs, conditionals, and arbitrary functions to drive
experiment configuration and execution.
Emulated nodes and links enjoy full implementation
transparency. By default, links specified in the ns experi-
ment file are realized as interposed Dummynet nodes. To
instead incorporate distributed nodes, an experimenter
need only specify an appropriate node type. For ex-
ample, Figure 2 requests an Internet-connected node
by specifying a pc-inet hardware type. A simu-
lated topology can be embedded within an emulated
topology by wrapping standard ns syntax in a make-
simulated block, a Netbed-specific construct.
Any constant bit rate traffic flow identified via stan-
dard ns syntax automatically instantiates traffic sources
and sinks using the TG Tool Set [21]. Simulated FTP
and Telnet flows are rendered using ns’s emulation fa-
cility, nse. This mechanism injects traffic generated by
models, such as the tcplib telnet distribution, into a live
network. Such cross traffic is important for studying pro-
tocol behavior in the face of congestion.
Netbed defines a small set of ns extensions, including
set ns [new Simulator] # Create the simulator
source tb_compat.tcl # Add Netbed commands
$ns rtproto Static # Netbed computes routes
set source [$ns node] # define new nodes
set router [$ns node]
set dest [$ns node]
# Connect source to router and router to dest
$ns duplex-link $source $router 10Mb 0ms RED
$ns duplex-link $router $dest 1.5Mb 20ms DropTail
tb-set-node-os $source FBSD45-STD # Set OS on local node
tb-set-hardware $dest pc-inet # Request distributed node
$ns run # "run" on Netbed
Figure 2: An ns file showing a linear topology with routing and a dis-
tributed node
procedures to configure a node’s operating system and
to specify its hardware type. These procedures are not
required; Netbed supplies default behavior in their ab-
sence. A stub library defines null procedures so that the
same script may be executed on Netbed and within ns.
Program objects are a Netbed-specific ns extension
that provides a rudimentary remote execution facility. A
program object is associated with an ns node in the script
and attaches arbitrary applications to the corresponding
local node. It may be independently controlled during an
experiment’s execution. Program objects are currently
not available on distributed nodes, until we finish secur-
ing the distributed event system.
Experimenters unfamiliar with ns syntax may create
topologies graphically via a Java GUI, which generates
an ns configuration file. Alternatively, a standard topol-
ogy generator such as GT-ITM or BRITE may be used to
generate an ns script. This highlights one of the primary
benefits of integration: application of tools intended for
one experimental domain, in this case simulation, to an-
other.
3.3 Parsing
A traditional compiler is separated into front and back
ends whose interactions are mediated by an intermedi-
ate representation. This aids portability since the same
front end can be reused with back ends supporting dif-
ferent hardware architectures. Since Netbed targets mul-
tiple, heterogeneous physical resources simultaneously,
it uses an analogous split-phase style of compilation.
A database serves as the shared repository between the
front-end Tcl/ns parser and resource-specific back-end
mechanisms. Thus, a single experiment may incorporate
simulated, emulated, and wide-area links without requir-
ing excessive resource-specific knowledge in the specifi-
cation language or front-end parser.
Netbed’s parser recognizes the subset of ns relevant to
topology and traffic generation. Written in Tcl, it oper-
ates by overriding and interposing on standard ns pro-
cedures and Tcl primitives. Netbed executes the experi-