Overview

x-Sim is a network simulator based on the x-kernel . It provides a framework for developing, analyzing, and testing network protocols; for evaluating congestion control mechanisms; and for studying network dynamics. This document is intended to be used as a reference to x-sim by those already familiar with the x-kernel .

x-Sim includes all of the modules necessary to simulate a large and arbitrarily complex internetwork. An internet composed of Ethernets and point-to-point links, FCFS and RED routers, and hosts with arbitrary protocol graphs can be specified. In addition, the user may write code to implement other types of networks and routers for inclusion in a simulation.

x-Sim is tightly integrated with the x-kernel architecture; it runs x-kernel protocols and protocols can be moved between the simulator and the x-kernel without any changes. x-Sim Version 1.0 adheres to Version 3.3 of the x-kernel interface [NSR96]. Despite the close relationship between x-sim and the x-kernel , there are two important differences between the standard x-kernel and the simulator of which the user should be aware. We discuss these differences here.

First, the x-kernel allows the hosts on which it runs to communicate with each other, either through direct network access (i.e., directly accessing the network device), or by emulating a low-level network connection via sockets. In contrast, the simulator does not use the network at all. Instead, it simulates communications between potentially thousands of hosts over an internetwork specified by the user. A special protocol called SIM is included at the bottom of all host protocol stacks; host driver protocols pass messages to SIM, and SIM implements the networks and routers that make up this internet.

Figures 1 and 2 show the protocol graphs of a user-level x-kernel and an instance of x-sim , respectively. Figure 1 shows two hosts, each running a user-level x-kernel with its own protocol stack, connected by an Ethernet. Protocol SIMETH on each host uses the Unix socket interface to send messages across the network. In contrast, Figure 2 shows a protocol graph representing four simulated hosts connected by an internetwork. Protocol SIM contains code that implements the entire internetwork to which the hosts are attached. Note that in x-sim , each simulated host is implemented by its own protocol stack; this leads to multiple instantiations of protocol objects, and a large protocol graph.

Second, in a user-level x-kernel , the protocol graph is static and it is specified at compile time in the graph.comp file. In contrast, the simulator has been enhanced so that the protocol graph is created at runtime, allowing different simulations to be run without recompiling. The graph.comp file is still used by x-sim , but only as a means of specifying which protocol modules to include in the executable. In other words, if any simulated host is going to be running protocol P, then protocol P must appear somewhere in

graph.comp. The relationships between protocols specified in

graph.comp are ignored by the simulator.

At runtime, x-sim reads a configuration file, called xsim.data, or any other file that can be specified by the -simfile option, which specifies the network topology: the number and types of networks; the number of hosts and routers; how the networks, hosts and routers are connected; the protocol graph for each host; and various other parameters such as the addresses of each host and network, the speed and delay of each point-to-point link and network, whether Ethernet networks should simulate collisions, and so on.

  
Figure 1: A user-level x-kernel protocol graph

  
Figure 2: An x-sim protocol graph

In summary, building the protocol graph for a simulation involves two stages: including the necessary protocol modules in the simulator executable (via graph.comp), and specifying at runtime the protocol graphs for the individual simulated hosts (via

xsim.data). To illustrate this point, here is the graph.comp file for the simulator instance shown in Figure 2:

    @;

    name=sim;
    name=ethd;
    name=eth;
    name=arp;
    name=vnet;
    name=ip;
    name=ttcp;
    name=rtcp;
    name=btcp;
    name=vtcp;
    name=megtest;
    name=traffic;

    @;

    prottbl=prottbl.default;
    prottbl=prottbl.xsim;

Notice that nowhere are multiple hosts mentioned in this

graph.comp file, and no explicit protocol relationships are given. (You can give them if you want, but they have no effect.) Also note that we included multiple TCP protocols (i.e., TTCP, BTCP, VTCP), not all of which are involved in the simulation illustrated in Figure 2. If later we want to replace RTCP in our simulation with another TCP, or have different TCP protocols running on different hosts, we can do so without recompiling because we've already included these protocols in the simulator.

Following the standard x-kernel build procedures defined in the x-kernel Programmer's Manual [NSR96], the above graph.comp file produces an x-sim executable in the build directory. Section 2 shows the xsim.data file that is read at runtime by this executable, resulting in the protocol graph shown in Figure 2.

Finally, we reiterate that only minimal modifications to the x-kernel were necessary so it could be used as the x-sim infrastructure. No modifications were made to the x-kernel interface, thereby making it possible to move protocols between the simulator and the standard x-kernel without modification.

The next section provides an example configuration file for a simple internetwork and explains its components; Figure 2 shows the protocol graph produced by this file. Section 3 then documents all aspects of the xsim.data file in detail. Section 4 includes a more complex example

xsim.data file. Finally, running a complex simulation is only half the battle. Often, analyzing the results takes much longer than running the simulation itself. A set of graphical display tools are included with x-sim to aid in analyzing the behavior of different parts of the simulator. These tools display graphs based on traces saved by protocols and routers, and have proven invaluable in helping to understand complex protocols. The final section of this documents briefly describes these display tools.