Trace File Format in NS2

In the previous post, I showed you how to create a “trace file” in NS2. In this post, I will show you the interpretation of an NS2 trace file.

Example of trace files :-

When using trace-all in NS2, a trace string is created in a trace file. The trace file would look like this.

Trace file format :-

The format of a trace string is shown below:

where 12 fields of the trace string are as follows.

1. Type Identifier:

 • “+”: a packet enque event
 • “-”: a packet deque event
 • “r”: a packet reception event
 • “d”: a packet drop (e.g., sent to dropHead_) event
 • “c”: a packet collision at the MAC level

2. Time: at which the packet tracing string is created .

3-4. Source Node and Destination Node: denote the IDs of the source and the destination nodes of the tracing object.

5. Packet Name: Name of the packet type

6. Packet Size: Size of the packet in bytes.

7. Flags: A 7-digit flag string

 • “-”: disable
 • 1st = “E”: ECN (Explicit Congestion Notification) echo is enabled.
 • 2nd = “P”: the priority in the IP header is enabled.
 • 3rd : Not in use
 • 4th = “A”: Congestion action
 • 5th = “E”: Congestion has occurred.
 • 6th = “F”: The TCP fast start is used.
 • 7th = “N”: Explicit Congestion Notification (ECN) is on.

8. Flow ID

9-10. Source Address and Destination Address: the format of these two fields is “a.b”, where “a” is the address and “b” is the port.

11. Sequence Number

12. Packet Unique ID

Post processing NS2 Result using NS2 Trace

In this post, I will show you a simple (and perhaps the most common way) to create an NS2 trace file. This trace file contains a lot of information. In fact, it contains too much information, which intimidates NS2 users. Don’t worry about it. We will try to interpret NS2 trace files later. For now, let’s focus on how an NS2 trace file can be created.

To create a trace file, you need to do the following two steps:

1. Create a file to record tracing information.
2. Record the tracing information to the created file.

Create a File for Writing :-

Tcl uses a command “open” to open a file. The syntax of the command “open” is as follows:

open <filename> <purpose>

where <filename> is the name of the file to be opened, and <purpose> can be

“w” for writing,

“r” for reading, or

“a” for appending

This statement returns a file handle, which can be used to refer to the opened file.

An example of a Tcl statement which opens a file whose name is “tracefile.tr” for writing and stores to the file handle in the variable $var is shown below:

set var [ open tracefile.tr w ]

Record tracing information in the opened trace file :-

The next step is to record trace information in the opened file. This can be achieved using the following Tcl statement:

$ns trace-all $var

where $ns is the Simulator instance, and $var is the file handle. This statement tells all the tracing objects (e.g., enqT_, deqT_, rcvT_, and drpT_ in the SimpleLink object below) to record information of traversing packets in the trace file whose variable is $var.

There is only one requirement for tracing: The above statement must be located prior to “$ns run”.

After the simulation complete, a trace file would be created. Here is an example of trace files.

The statement “$ns trace-all” inserts tracing object into various places in network topology. The most common place is in a SimpleLink usually used to connect two nodes. The statement “$ns trace-all” inserts few tracing objects into the SimpleLink object as shown above.

A tracing object sits between two NsObject intercepting objects. Once receiving a packet, it prints related tracing information as a line into the trace file. In the above figure, we have four tracing objects:

• enqT_: Print a line beginning with “+”, indicating an enqueuing event
• deqT_: Print a line beginning with “-”, indicating a dequeuing event
• rcvT_: Print a line beginning with “r”, indicating a packet reception event
• drpT_: Print a line beginning with “d”, indicating a packet dropping event

Tracing Statements in the Trace File:

These tracing objects print information of all traversing packets. Information of packets which do not pass through any of these objects would not appear on the trace file.

The only object responsible for dropping packets in the above figure is queue_. It does so by invoking function drop(p). The function drop(p) in turn sends the packet p to the forwarding NsObject, which in this case is drpT_. It is drpT_, who is responsible for printing dropping information statements (i.e., those begin with ‘d’) in the trace file.

This means that if you drop the packet explicitly (e.g., using drop(p)) without passing the packet through drpT_, no information about dropping packet would appear on the trace file.

IP Routing in NS2

I know. I know. IP is “the most” widely used routing in the computer industry. But, we as people in academic need to be a bit more precise when using buzz words.

IP: refers to IP address. It is different from routing mechanism. IP address is just a hierarchical way of defining an endpoint.
Routing mechanism: is a way of determining the route to get to a given destination. It works according to an underlying routing table.
Routing algorithm: computes a routing table.
Routing protocol: is a set of communication rules, which shall be followed under a certain condition such as a route failure.

Here is a example set of parameters in practice:

Addressing = IP Address
Routing mechanism = Routing table; Route Summary
Routing algorithm = Dijkstra
Routing protocol = OSPF

What about NS2?

By default, NS2 uses the following setting

Addressing = Flat address (1,2,3,…)
Routing mechanism = Address classifiers
Routing algorithm = Dijkstra
Routing protocol = Static (The condition of all the nodes does not change throughout the simulation)

Do You Really Need IP?

I have received quite a few questions like “How do I implement IP in NS2?” My first response would be “this is too vague”. You really have to break down your questions. At least, you have to identify which of the above 4 topics you would like to study.

For example, if you would like to study routing protocols, you’d probably refer to OSPF or BGP routing protocols. If your focus is on the communiation protocols of the routing, you can use the following setting

Addressing: Flat
Routing Mechansism: Classifier
Routing Algrithm: Dijkstra (used by default as a part of OSPF)

which are the default setting of NS2.

Routing in NS2

The default routing protocol of NS2 is static routing. This means that there would be no change in topology throughout the simulation. In this case, NS2 configures the routing information once when the simulation start with the OTcl statement “$ns run”. The process proceeds as follows:

Step 1: [OTcl] Simulator::run
Step 2: [OTcl] Routelogic::configure
Step 3: [OTcl] Agent/rtProto/Static::init-all
Step 4: [OTcl] Simulator::compute-routes
Step 5: [OTcl] Simulator::computer-flat-route
Step 6: [OTcl] RouteLogic::compute
Step 7: [OTcl] Simulator::populate-flat-classifier

Step 6: The OTcl class RouteLogic is bound to the C++ class with the same name (see file ns-2.35/routing/route.cc,h). The OTcl command compute simply executes the funciton compute_routes(…) in the C++ domain. From this point, you have look closely of what NS2 does and apply necessary changes to fit your needs.

Step 7: See how NS2 populate the routing information to all the Nodes. You will need to look into this step to see how routing information are delivered to all related Nodes.

Network Simulator 2 Tutorials

1.  For Learning about Network Simulator 2 basics you can use Marc Greis Tutorials here.

2. You can use following materials

• Wireless Sensor Network Simulator
• An Introduction to NS2
• NS2 Tutorial by Kameswari Chebrolu
• Marc Greis Tutorial