Using NS2 to Monitor SCTP Traffic

SCTP is a transmission protocol that was introduced by the IETF workgroup SIGTRAN in October 2000 (RFC 2960) to allow SS7 traffic over IP. However, since then it has adopted many more uses because of its versatility as it also supports multihoming, network congestion control, error-free sequenced delivery and many other options.

After applying the SCTP patch to NS2 package, a README file is created: /usr/src/ns-allinone-2.1b8/ns-2.1b8/sctp.README. At the end of the sctp.README file, there is an example script for an SCTP interaction. In the simulation generated by this Tcl script, you will observe SCTP's four-way handshake as described in RFC 2960, as well as congestion control. This scenario examines FTP traffic over SCTP between two nodes: node 0 is FTP client and node 1 is FTP server.

The original script is hard coded for version 2.1b7a. You need to update few lines to reflect your own setup. Listing 1 has been updated assuming that NS2 version 2.1b8 was installed.

Listing 1. SCTP Simulation Script

The changes that were applied to the original script are basically setting the paths depending on the specific environment. Once you update the paths of all used tools, you are ready to start NS2 for a network simulation of SCTP. To start the simulation, follow these steps:

cd /usr/src/ns-allinone-2.1b8

ns ./sctp.tcl

Figure 1. SCTP Data Profile

Figure 2. Simulation Window

On execution, three windows will appear. The first window is represented by Figure 1 showing a graph with packet traffic. The second window shows the simulation window as seen in Figure 2. The third window is the control window of the network animator (NAM).

It is interesting to see the graph generated by NS2 (Figure 1). The yellow x represents a dropped packet and horizontally to the right is the retransmission. This dropped packet occurred because of an error loss model that was introduced into the script that simply drops the specified packets between nodes given. SCTP manages retransmission similarly to TCP, supporting fast retransmit.

set err [new ErrorModel/List]
$err droplist {15}
$ns lossmodel $err $n0 $n1

In the simulation window (Figure 2), right click on the link between both nodes and select graph --> graph bandwidth, and then click on Link 0-->1; you will obtain a bar graph representing bandwidth going from node 0 to node 1. You can repeat this process for reverse traffic bandwidth to monitor traffic going from node 1 to node 0. Now, you should see traffic bandwidth graphs below node display (Figure 3).

Figure 3. Traffic Bandwidth Utility Graphs

Before we start the scenario, we will take a brief look at some important lines in the script and explain what they do:

[...]                                                                          // After initializing trace
                                                                               // files and simulation windows
set n0 [$ns node]                                                      // two nodes are created
set n1 [$ns node]                                                      // (n0 and n1)
$ns duplex-link $n0 $n1 .5Mb 300ms DropTail
                                                                               // then they are linked
                                                                               // together
$ns duplex-link-op $n0 $n1 orient right
[...]
set sctp0 [new Agent/SCTP]
$ns attach-agent $n0 $sctp0
[...]
set sctp1 [new Agent/SCTP]
$ns attach-agent $n1 $sctp1

Then we define the protocol (SCTP) that will be used for destination and return traffic. An agent, defining what protocol to use, is similar to a carrier for packets. Each agent must be attached to a specific node:

$ns connect $sctp0 $sctp1                                       // connect both agents
                                                                           // together to set up
                                                                           // a communications
                                                                           // channel, or a stream
[...]
set ftp0 [new Application/FTP] // define the type of
                                                                           // application that
                                                                           // will use the
                                                                           // stream, FTP
$ftp0 attach-agent $sctp0

To start real-time simulation, press the play forward button. The first event to notice is the four packets that initiate the FTP connection. This corresponds to the stream initiation behavior specified in RFC 2960. The other event to observe is congestion control. SCTP will send few packets at a time and steadily increase until it reaches a maximum throughput but will not flood the network. Although we do not alter our network's bandwidth, the FTP connection between nodes 0 and 1 shows some basic congestion control. The beginning and end of the FTP connection are defined on these lines:

$ns at 0.5 "$ftp0 start"
$ns at 4.5 "$ftp0 stop"

Notice how the packets are being sent in an increasing fashion, or visually, in longer formats. Actually, the packets are always the same length; however, the number of packets received by the server is increased as can be seen by the number of SACKS received by client (Figure 4). SACKS are sent to acknowledge each packet received to ensure packet validation and reliability.

Figure 4. SACKS for Every SCTP Packet Sent

The University of Delaware did not implement multihoming in their SCTP patch to NS2. This means that SCTP behaves similarly to TCP when it comes to streams. Otherwise, packets could be seen traveling both along the primary path and along another routing path to the server's second, third or other IP address. A similar behavior is dynamic rerouting, which is a secondary function of SCTP's primary path monitoring.

source : here