- The following figure shows the
most commonly used NS classes
in writing a
network simulation:
- Notes:
- Nodes:
nodes in NS is
not implemented as
a OTcl class
Rather, the user creates a node using the node method in the Simulator object
A node simulates a router .
- A node object
implements the
complete IP protocol layer in
NS.
- The node object
contains program code
that compute
minimum cost routes
from any node to any other node
(You don't need to worry about routing or re-routing)
- A node object
implements the
complete IP protocol layer in
NS.
- Links:
links in NS is not implemented
as a class
Rather, the user connects two Node objects using the simplex-link or duplex-link methods in the Simulator simulation object .
- Links provide
a fixed (constant)
delay
between 2 Node object
- A link also has
a given bandwidth
- Links also acts as
output buffers
to hold packets sent towards the destination end node
The output buffer has a specific size
- Links provide
a fixed (constant)
delay
between 2 Node object
- Agent/TCP
and Agent/TCP/Reno:
are OTcl classes that simulate the
Sending TCP Tahoe
and
TCP Reno
protocols.
- A Agent/TCP object
or Agent/TCP/Reno object
must be
attached to a
Node object
to operate.
A TCP object is attached to a Node object using the attach-agent method in a Simulator object
- Also, a Agent/TCP object
or Agent/TCP/Reno
must have a
corresponding
receiver TCP end point
The OTcl class that implements the receiver TCP protocol is called Agent/TCP/Sink
- A Agent/TCP object
or Agent/TCP/Reno object
must be
attached to a
Node object
to operate.
- Agent/TCP/Sink:
is an OTcl class
that simulates a
Receiving TCP
protocol.
- An Agent/TCP/Sink object
sends ACK packets back
to the TCP sender
- You must create one
Agent/TCP/Sink object for
each TCP sender
- Furthermore, you must associate ("connect") the TCP sender object and the TCP sink object using the connect method in a Simulator object (see below for details)
- An Agent/TCP/Sink object
sends ACK packets back
to the TCP sender
- Application/FTP:
is an OTcl class that
simulates an
continuously transmitting
packet source
that uses a
TCP protocol
(e.g., Tahoe, Reno, or some other
version of TCP)
Although the traffic source is transmitting continuously, due to TCP's sliding window mechanism, the FTP source will not transmit non-stop
- An Application/FTP object
needs to be attached to some
TCP agent
(see figure)
- This attachment is done using the attach-agent method in the Application/FTP object
Interestingly, the Application/FTP does not need to be asscoiated with a receiver:
- The FTP agent
triggers the
TCP agent
to transmit packets
- The TCP packets
will be acknowledged
by the
asscociated TCP-Sink object
- When the TCP source
receives the ACK,
it reports to
the associated FTP agent
that it can transmit more.
Bottom line: FTP agent does not need an "FTP sink".....
- An Application/FTP object
needs to be attached to some
TCP agent
(see figure)
- Nodes:
nodes in NS is
not implemented as
a OTcl class
- Recipe for writing a network simulation program in NS:
- Create a Simulator object
Example:
set ns [ new Simulator ]
- Create the network:
- Create nodes (routers):
click here
Example:
set n1 [ $ns node ] set n2 [ $ns node ]
- Connect the
nodes with (duplex)
links:
click here
Example:
$ns duplex-link $n0 $n1 10Mb 10ms DropTail
- Create nodes (routers):
click here
- Create TCP source modules
and TCP sinks
set tcp1 [new Agent/TCP/Reno] set sink1 [new Agent/TCPSink]
- Attach TCP agents to
some node (IP layer)
$ns attach-agent $n0 $tcp1 $ns attach-agent $n1 $sink1
- Connect a
TCP source to
a TCP sink
$ns connect $tcp1 $sink1
- Put a
traffic load generator
(Application/FTP)
on a
TCP source
set ftp1 [new Application/FTP] $ftp1 attach-agent $tcp1
And we are ready to rip !!!
I have more detailed notes below that clarifies each step
- Create a Simulator object
- In order to use the NS simulator, you need to create a
Simulator
object
The Simulator object is the network simulation system and provides many methods needed to construct the network simulation.
- How to create a Simulator object:
new Simulator
- Example:
set ns [new Simulator]
You only need one Simulator object
If you look in the source of a NS script, you will always see this statement at the top of the program !
- The Node class
in NS is used to simulate
routers
- The node must be created through the special method
node
defined in the
Simulator
class.
The following expression will return a Node object in NS that you use to simulate ONE router:
set ns [new Simulator] set n0 [$ns node]
- If you need to create a lot of routers, use a
for loop.
Example: create Nodes n(0), n(1), ..., n(9):
for {set i 0} {$i < 10} {incr i} { set n($i) [$ns node] }
- Links in
NS are used for:
- to provide connectivity between
Nodes (routers)
- Output buffering
- Because a link is in fact a buffer, you must pick (select) a buffer management algorithm to manage the buffer (e.g., what to do when the buffer overflows)
- to provide connectivity between
Nodes (routers)
- Properties of links:
- Duplex (bi-directional) or
Simplex (uni-directional)
BTW, a duplex link is actually 2 simplex links..
- Bandwidth (data transmission rate)
Units: b (#bits/sec), or Mb (#Megabits/sec)
- Propagation delay
Units: s (seconds), or ms (milliseconds)
- Queue management:
specifies how
packets in the queue
are managed
Some commonly used buffer management:
- DropTail:
FIFO queue where the node will
drop the last
arriving packet
when queue is full
- RED:
Random Early Drop
method (this method tries to break the
TCP Synchronization Syndrome)
- DDR:
Deficit Round Robin
method (research material)
- FQ:
Fair Queuing
method (very advanced research material)
- SFQ: Stochastic Fair Queuing method (another advanced research material)
We will only use DropTail
- DropTail:
FIFO queue where the node will
drop the last
arriving packet
when queue is full
- Duplex (bi-directional) or
Simplex (uni-directional)
- Example: duplex (bi-directional) link, 10 Mbps, 10 msec delay
set n0 [$ns node] set n1 [$ns node] $ns duplex-link $n0 $n1 10Mb 10ms DropTail
- Often, you want to experiment with the same network configuration
but using different bottleneck link capacities.
For example, the bottleneck link is f times the normal bandwidth in other network links
- Trick:
set bw 10 set f 0.5 $ns duplex-link $n0 $n1 [expr $bw]Mb 10ms DropTail $ns duplex-link $n0 $n1 [expr $f*$bw]Mb 10ms DropTail
- You can change the buffer size of
one particular
link using the
$ns queue-limit
method
- Example:
set the queue length to 10 packets
$ns duplex-link $n0 $n1 10Mb 10ms DropTail $ns queue-limit $n0 $n1 10
- Links in NS are created with a certain default queue size
- Each
class (DropTail, RED, FQ, etc)
of queue has its own default queue size
- You can change the buffer size of
a class of queue
using the
set queue-limit
command in the class
Queue/QUEUE-CLASS
- Example:
set the default queue length of
DropTail queues
to 10 packets
Queue/DropTail set queue-limit $n0 $n1 10
- After you created the nodes and connected them through links,
NS will provide Internet routing
automatically
- So, after created the nodes and connected them through links,
you have an Internet.
- All you need to do now is:
- Add
transport protocol to the
end point nodes (no need to do so to
intermediate nodes)
- Add traffic (load)
- Add
transport protocol to the
end point nodes (no need to do so to
intermediate nodes)
- For one reason or another, the transport protocol modules in
NS are called
agents
- There are an ever increasing number of
sending transport agents
(because people are developing new TCP transmission protocols
to improve network performance.
- There are 2
receiving transport agents
that sends back ACKs to the sending agent.
- The most commonly used
sending transport protocol modules
are:
- Agent/TCP: TCP Tahoe
- Agent/TCP/Reno: TCP Reno
- Agent/TCP/Newreno: Improved TCP Reno
that paces the transmission interval
- Agent/TCP/Vegas: TCP Vegas
Example:
set tcp1 [new Agent/TCP/Reno]
- Agent/TCP: TCP Tahoe
- The most commonly used
receiving
transport protocol modules
are:
- Agent/TCPSink: sends ACK packet
immediately after receiving a packet
- Agent/TCPSink/DelAck: ACK is delayed. Receiver sends ACK packet after receiving 2 packets or after a certain delay (tries to reduce number of ACK packets)
Example:
set sink1 [new Agent/TCPSink]
- Agent/TCPSink: sends ACK packet
immediately after receiving a packet
- Transport agents are
end points
of communication
They can be attached to any Node object
- You can attach
multiple
Transport agents to one
Node
object
- The
attach-agent
command in a
Simulator
object is used to associate
a Transport agents to a Node:
$ns attach-agent NODE TCP-Agent
- Example:
set ns [new Simulator] set node1 [$ns node] set tcp1 [new Agent/TCP/Reno] $ns attach-agent $node1 $tcp1
- Transport agents are
end points
of communication
We need to tell NS the destination of each sending Transport Agent.
The destination must be a receiving Transport Agent.
- In order to tell NS where to transmit the packets,
we need to
connect
a
sending communication end points
to a
receiving communication end points
- This is done through the
NS method:
connect SOURCE DESTINATION
- Example:
set ns [new Simulator] set tcp1 [new Agent/TCP/Reno] set sink1 [new Agent/TCPSink] (tcp1 and sink1 must also be attached to nodes, this step is omitted) $ns connect $tcp1 $sink1
This will make NS route all packets from the source tcp1 towards the destination sink1
- After a TCP agent has been created, you can set some
of its parameters
(using the set command of the
TCP agent)
- The most useful parameters are:
- packetSize_:
the packet size used by TCP
(default packet size is 1000 bytes)
- maxcwnd_:
the maximum of CWND (0 means infinite)
- window_: the Advertised Window size
- packetSize_:
the packet size used by TCP
(default packet size is 1000 bytes)
- Example:
set tcp1 [new Agent/TCP/Reno] $tcp1 set packetSize_ 552
- NOTE:
recall that the set method without arguments will
return the value of the variable !
Example:
set tcp1 [new Agent/TCP/Reno] set pksize [$tcp1 set packetSize_] // get packetzise used
- The standard traffic generator for TCP protocol
is the FTP
application.
- The
FTP
application transmits continuously - as long as the
TCP protocol permits.
- FTP
application are created using:
new Application/FTP
- Example:
set ftp1 [new Application/FTP]
- You need to associate a FTP traffic generator with a
sending TCP module
- The association is made using the
attach-agent
method defined in the
Application/FTP
class.
- Example:
set tcp1 [new Agent/TCP/Reno] set ftp1 [new Application/FTP] $ftp1 attach-agent $tcp1
- The FTP traffic generator is run (started) using the
start
method defined in the
Application/FTP
class.
- Example:
set ftp1 [new Application/FTP] $ftp1 start // Start the FTP application
- The FTP traffic generator canbe stopped using the
stap
method defined in the
Application/FTP
class.
- Example:
set ftp1 [new Application/FTP] $ftp1 stop // Stop the FTP application
- NOTE:
the TCP module does not need to be stopped and in fact, cannot be
stopped.
When the FTP traffic generator stops generating traffic, TCP will have no data to send and will "go quiet".
You can start the FTP again after stopping it.