J-Sim INET Tutorial

December 10, 2003

This tutorial is intended to provide users with an overview of network simulation  in the J-Sim environment.  Before delving into the details of network simulation, we introduce several terms below.

Components: J-Sim is built upon a component-based software architecture, called the autonomous component architecture (ACA).  Every network entity, e.g., a network, an end host, a router, a link, and a protocol, is a component. Components are connected through their ports in the same manner as IC chips are connected through their pins in IC circuit design.  The behavior of a component is specified by the contract (which describes, when data arrives at each of its ports, how a component process data and possibly generates outputs at certain ports) in the same manner an IC chip is specified by its specification in the cookbook.  Figure 1 depicts the analogy between the autonomous component architecture and the IC design.

FIgure 1: The analogy between components in the autonomous component architecture and an IC chip in the IC design process.

A component may be a composite component.  That is, it may be composed of several inner components. In the context of network simulation, a network is a composite component and is composed (at run time) of nodes, links, protocols, and appropriate modules.  Figure 2 depicts the notion of composite components.

Figure 2: Composite components.

Scripts: J-Sim is a dual-language environment: Java(TM) is used to implement all the classes and Tcl is used as a "glue" script language to construct, configure, and/or control  network simulation at run time. In addition to a few of standard Tcl commands, J-Sim also uses two set of extended Tcl commands: 

  (1) Tcl/Java: defines the Java extension in Tcl and is the "bridge" between Tcl and Java. Tcl/Java commands make it possible to create and access any Java objects in the Tcl environment. The online manual page of Tcl/Java is available here. 

  (2) RUV system commands:  The notion of composite components in J-Sim makes it possible to organize components in a component hierarchy. The hierarchy is very similar to a file system in a modern operating system. To ease configuration of network simulation, we have developed a set of Runtime Virtual (RUV) system commands to manipulate the component hierarchy in the same fashion as several UNIX commands do to the file system.

First, central to the RUV system commands is the concept of path. Every component and every port in a component hierarchy can be uniquely identified by a path. For example, consider the composite component in Figure 3. The root component has four immediate child components, aaa, b, cc, and d. The component cc, in turn, is a composite component and contains two child components, ee and ff. The path of component cc is expressed as "/cc," and that of component ee is expressed as "/cc/ee." Also,  component cc owns a port labeled as x@y, where x@y is a full port ID with x being the port ID, and y being the port group ID.  The path of this port is expressed as "/cc/x@y".  Similarly, the path of port x@y of component ee is expressed as "/cc/ee/x@y".  (The port ID or the port group ID may be an empty string, and hence x@ or @y are valid full port IDs.) As a side effect, the character "@" is used to tell whether the object represented by a path is a component or a port.

RUV supports the wildcard expression in the same way most UNIX shells do. In addition to "*" and "?" which are commonly used in a shell, RUV supports "..." in a path expression. The expression matches all the components under the current path. For example, "/cc/.../x@y" represents both "/cc/x@y" and "/cc/ee/x@y".

Figure 3: An example the illustrates the concept of path in RUV.

As we proceed in the tutorial, we will illustrate how the Tcl, Tcl/Java, and RUV system commands are used and outline those most-commonly used ones.

Now the glorious detail on network simulation

INET is a network simulation framework built upon the autonomous component architecture and specific to network simulation. Essentially we factor out features common to each network component (such as an IP layer, a network interface card, a link, etc.) and define and implement in INET all the network components (and their contracts).  We also define the internal structure of a node (either an end host of a router). Users may then compose a network scenario in a plug-and-play fashion, by connecting components in their desired manner.  Users may also subclass an appropriate component and redefines new attributes and methods to incorporate their own protocols/algorithms.  We first cover the issue of creating  a network simulation scenario, and then discuss how users can subclass components to incorporate their new components. 

To create a network simulation scenario, one performs the following steps:

1. Create the topology.
2. Build the internal structure of nodes.
3. Configure the network scenario.

Figure 4 gives an example network that can be composed and the internal structure of nodes.

Figure 4: An example network scenario that can be simulated.

As the example shows, a network is a composite component which consists of nodes, links and smaller networks. A node is also a composite component which consists of applications, protocol modules, and a core service layer (CSL).

The core service layer is an abstract component which encapsulates the functions of the network layer and the layers beneath the network layer. It provides network services and events to protocols, in the form of inter-component contracts. The CSL service/event ports are illustrated in Figure 5. Each service port is in charge of one or more CSL services. The CSL services/events are listed and briefly described in Table 1.

Figure 5: The CSL service/event ports

Table 1: CSL services and events.

For extensibility, we decompose CSL into several sub-components The decomposition is illustrated in Figure 6. Basically, it consists (optionally) of a packet dispatching component (pd), an identity component (id), a routing table component (rt), a hello component, a composable set of packet filter banks, each of which corresponds to an "interface" of the node, and a packet filter switch component. 

NOTE: Since J-Sim v1.2, the default CSL composition combines the queue and network interface into one QueueNI component.

Figure 6: The composable core service layer

The sub-components in CSL are described below:

Interested users are referred to the INET document for a detailed account of the structure of, and the network services provided by, the composable core service layer.

With all the components available in INET, one may readily compose a network scenario of his/her like. Moreover, we provide several utility classes to help with scenario construction. In particular, since configuring the internal structure of nodes usually follows similar patterns and  repetitively cycles through several tedious steps, we provide utility classes to automate the process.  In what follows, we first use a simple two-node example to illustrate the network scenario construction process, and then use the other three examples to demonstrate how utility classes ease the process.

Examples

1. A simple two-node, raw IP example.
   Illustrates how to create the network scenario for simulation.
2. A simple two-host, one-router and one-TCP-connection example.
   Incorporates a transport protocol into a node.
   Sets up bulk TCP source and sink.
   Sets up static routes between two hosts.
   Sets up a bottleneck link.
3. A simple multiple-host, two-router and multiple-TCP-connection example.
   Illustrates how to create multiple TCP connections and how to execute scripts at specific simulation times.
4. A simple four-host, four-router, UDP and FSP example.
   Illustrates how to create a simple file transfer protocol on top of UDP and a cross-traffic TCP connection.

Advanced Examples

1. DVMRP examples.
   Demonstrates some advanced settings, e.g., configure interfaces, enable/disable a component, set debug flags/watchers, construct virtual networks and hierarchical networks, through examining DVMRP operations on different network topologies.

* JAVA and all JAVA-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.

~ END ~