NS2 - Network Simulator

Jose Miguel Herrera M.

Estudiante de Ing.Civil Informatica
Valparaso, 12 de mayo de 2004

Resumen
He aqu una resena acerca de lo que es Network Simulator, un sim-
ulador/manejador de eventos en redes IP. Implementa protocolos tales
como TCP, UDP, aplicaciones como FTP, Telnet, WEB, trafico de colas
como DropTail, RED, algoritmo de Dijkstra, y mucho mas.

1. Introduccion
A traves de los anos se ha hecho importante el modelamiento de diversos
eventos antes de tomar decisiones. Tal es el caso de la programacion lineal,
donde se plantea un problema de la vida cotidiana y mediante un modelamien-
to matematico es factible encontrar una o mas soluciones. Sin embargo, en la
realidad hay que considerar miles de factores importantes que lamentablemente
un modelo matematico no considera en el mayor de los casos, pero aproxima
bastante a una solucion que nos puede llevar por un buen camino.
Es por ello que la idea de modelar y/o simular es bastante importante en la
toma de decisiones.
En el presente trabajo se dara una descripcion a lo que es este simulador
de redes. Esta investigacion esta orientada a conocer el tema de la simulacion
de redes mediante esta aplicacion denominada Network Simulator. Se realizaran
pruebas de algunos algoritmos ya realizados y se hara una descripcion interna
de como funciona este simulador.
Este simulador fue probado en un procesador Pentium II 700MHZ con 256MB
de memoria ram, bajo la plataforma Linux Debian. Este simulador tambien fun-
ciona bajo plataforma windows, sin embargo, la investigacion no se llevo a cabo
en este sistema operativo, por lo tanto, requisitos, funcionamiento, u otros, no
fueron probados. Por lo tanto, al hablar de Lnea de comandos se hara referencia
a las consolas de Linux.
En el caso de Linux, el unico requisito (suponiendo un PC normal con interfaz
grafica X y paquetes tpicos) fue la instalacion del paquete xfree-devel.

1
2. Descripcion Interna NS
Network Simulator es un simulador discreto de eventos creado por la Uni-
versidad de Berkeley para modelar redes de tipo IP. En la simulacion se toma en
cuenta lo que es la estructura (topologia) de la red y el trafico de paquetes que
posee la misma, con el fin de crear una especie de diagnostico que nos muestre
el comportamiento que se obtiene al tener una red con ciertas caractersticas.
Trae implementaciones de protocolos tales como TCP y UDP, que es posible
hacerlos comportar como un trafico FTP, Telnet, Web, CBR y VBR. Maneja
diversos mecanismos de colas que se generan en los routers, tales como DropTail,
RED, CQB, algoritmo de Dijkstra, etc.
Actualmente, el proyecto NS es parte de VINT proyect que desarrolla her-
ramientas para visualizar los resultados de una simulacion (por ejemplo, una
interfaz grafica).
La version con que fue probado (en este informe) es la NS version 2 escrita
en los lenguajes de programacion C++ y OTcl1 .
El funcionamiento de Network Simulator se explicara poco a poco mostrando
las partes mas generales a las mas particulares. Para comenzar se mostrara una
vista bastante simplificada de lo que es NS.

Figura 1: Vista simplificada del funcionamiento de NS

Como se puede observar, se comienza con un script en OTcl que viene a hacer
lo que el usuario codifica para simular. Es el unico INPUT que da el usuario al
programa. El resto es el procesamiento interno de NS. La simulacion queda en
un archivo que puede ser bastante incomodo de leer o analizar para el usuario,
sin embargo, usando una aplicacion especial se puede mostrar mediante una
interfaz grafica.
El script es un archivo escrito en Tcl orientado a objetos, es decir, OTcl, que
tiene diversos componentes internos que se muestran en el cuadro del medio de
la figura 1. En estos componentes se configura la topologa de la red, calendariza
los eventos, carga las funciones necesarias para la simulacion, planifica cuando
iniciar o terminar el trafico de un determinado paquete, entre otras cosas.
A continuacion se entrara a especificar un poco mas como funciona cada
componente. Tampoco es la idea de entrar en detalle, sin embargo, una referencia
rapida a cada punto sera justa y necesaria.
1 Lenguaje Scripting orientado a objetos, desarrollado por MIT

2
2.1. Event Scheduler Object
Este evento en NS, es un paquete unico con una calendarizacion o programa
dado por el programador en la codificacion. Internamente se identificara con un
puntero al objeto que maneja este evento. En la figura 2 se muestra la forma de
calendarizar los eventos.

Figura 2: Planificador de eventos

Los usuarios principales del planificador de eventos es el Network Component

que se vera a continuacion. Esto porque la transmision de paquetes requiere
de ciertos tiempos o retardos necesarios para la simulacion. Por ejemplo, al
declarar un link con un ancho de banda muy bajo, el planificador de eventos
debera realizar retardos mas prolongados en ese enlace para simular que la
transmision es lenta.
Por otro lado, cada objeto de red usa un planificador de eventos, que es quien
maneja el evento por el tiempo planificado. Importante es hacer notar que la
trayectoria de datos entre los objetos de la red es diferente de la trayectoria del
evento.

2.2. Network Component object

Se encarga de hacer consistente la comunicacion que hay entre distintos
componentes de red, por donde pasaran los paquetes. Los componentes de red
pueden ser; el ancho de banda de un link, un link unidireccional o bidireccional,
retardos de paquetes, etc. En el caso de los retardos tambien actua el event
scheduler.
A modo de ejemplo, en la figura 3 se muestra el componente de red que
permite unir dos nodos, es decir, un link.
En esta figura se representa un link simple unidireccional. En el caso de
requerir uno bidireccional, simplemente se crea otro objeto con la misma es-
tructura para el lado contrario. En la entrada al link el paquete debera quedar
en la cola. Aca se realizaran una serie de procesamientos dependiendo del tipo de
cola que tenga ese link, tales como, si el tamano del paquete supera el tamano de

3
 Figura 3: Componente de red - Link

la cola, o si la cola simplemente esta llena, etc. Considerando esto, se tomara la

desicion si el paquete es descartado, en cuyo caso pasara a Drop y a un agente
NULO. De lo contrario, se realizara un retardo simulado (Delay) del que se
hablaba anteriormente. Finalmente se recalculara y actualizara el TTL (time to
live, tiempo de vida) del paquete para llegar al nodo destino
Para finalizar, veamos la figura 4 que representa el flujo de paquetes entre
los nodos.

Figura 4: Ejemplo de un flujo de paquetes entre nodos

Aca se quiere representar una comunicacion entre 2 nodos mediante el pro-

tocolo TCP. Este protocolo requiere de una respuesta de confimacion cuando el
receptor reciba el paquete. La idea es la siguiente: la red consiste en 2 nodos (n0
y n1). En el nodo n0, cuando se genera el paquete, este sigue el camino por el
puerto 0 (port classifier ) para anadir al paquete la informacion que es de tipo
TCP. Luego, siguiendo el camino, vuelve a entrar al nodo n0 y ahora pasa por el
puerto 1 para salir por el link n0 n1 y llegar al nodo n1. De la misma manera
que en el nodo n0, en n1 pasa por el puerto 0 para generar el Sink de respuesta
y vuelve a entrar a n1 para salir por el link (puerto 0 de n1) n1 n0. Al llegar
a n0 entra por el puerto 0 y se genera la confirmacion. Luego de esto se genera
otro paquete y as se repite para cada transmision.

4
2.3. Network Setup Helping Module
Por ultimo, el network Setup Helping Modules indicara las bibliotecas nece-
sarias para realizar la simulacion. Esto es necesario ya que los 2 primeros com-
ponentes, descritos en los subtemes 2.1 y 2.2, estan escritos y compilados en
C++ y estan disponibles para el interprete OTcl a traves de un linkage 2 . La
razon no es muy clara, pero tiene que ver con el tiempo de procesamiento (no
de simulacion). Se puede hacer la analoga entre C con C++ y tcl con OTcl.
En la siguiente figura se logra mostrar la forma en que se comunican las
bibliotecas compiladas de C++ y OTcl. Mas bien, es OTcl que llama a estas
bibliotecas.

Figura 5: linkage entre bibliotecas C++ y OTcl

3. Ejecutar un script
Para ejecutar la aplicacion, Network Simulator toma como INPUT a un
script en OTcl. En este script se define fsicamente la configuracion de la red
(nodos, conexiones entre nodos), los protocolos que seran usados en las conex-
iones y definiciones especificas de aplicaciones usando tipos de conexiones.
El script es un archivo con extension .tcl. Para hacerlo correr se debe
ejecutar ns ejemplo1.tcl desde la lnea de comandos y esto creara un archivo
que contendra el OUTPUT del analisis, un archivo de extension .nam (o el
similar .tr que mas adelante se analizara la pequena diferencia). Este archivo
es una completa descripcion de la simulacion, donde cada lnea describe los
paquetes recibidos, enviados, encolados, sacados de la cola, etc. Mas adelante
se realizara un estudio mas acabado de este tipo de archivo. Sin embargo, por
mucho que se mire este archivo, sera muy dificil obtener una gran fotografa de lo
que sucede en la simulacion. Es por ello que la visualizacion se realiza mediante el
programa nam3 y se ejecuta simplemente con el comando nam ejemplo1.nam.
En la figura 6 se muestra lo recien explicado:
Aparte de generar el archivo .nam, tambien puede generar otro archivo .q
(si se especifica) que contiene informacion acerca de una cola de un nodo en
particular durante la simulacion. Esta puede ser graficada u otros fines.
2 Para enlazar a OTcl las bibliotecas de C++.
3 Nam es Network AniMator, que es una interfaz grafica para ver la simulacion.

5
 kd jasdlkasj diaj kjdkasjdsak asd
dasod jaspdj pijdwpqij qw qw
qroqw oqrjf qwifjwqpifjq wqwfq
oqwif hjqp'i3 rh3i8h fw eew
eiw hfiewhf'9u fiewhf iewhfw
e ijhewf0hw hfewifh wefewfuji wfwe
ns ejemplo1.tcl .nam nam ejemplo1.nam
fwie fjwief uew we we9f wef
wf iwe fwiehfiwefewufiw wfe fwe
fewf9 wuifehiowejfipwjef jwef jwe
f we+fi jwefew
tjt rjytwtykt yrothwqwwerij wewe
rewi jrweoir +we08ru0eur owehrwer
wre iw0iwer u3'0r9u irsr+pisjfklsdmf s
f dsifj isjaf'9je fwenfpijsd fas
dfasfsdiaj foasdfaisf iasdf
asfi sdajfosdaf'as fisjadf sdafjdsa
fasdfjaosfjias jdfiasj 'fd9as fda
.tr
fidsaj foiasjf 9iuwer'f 9wuef oskfas
iaf sjdfiasuf098u fiwjfpisjdfpiasjdf

ejemplo1.tcl Dificil de Simulacin

analizar Grfica

Figura 6: Pasos para realizar la simulacion

4. Analisis Mediante Ejemplos

A continuacion se presentaran 2 ejemplos bastantes comentados de como
realizar un script en OTcl. El primero es bastante simple y se representa en la
figura 7:

ftp::TCP

n0
2.5 mbps, 10ms
Sink

n2 n3
1 mbps, 20ms

NULL
2 mbps, 10ms
n1

CBR::UDP

Figura 7: Ejemplo 1, una red simple con trafico TCP y UDP

La red consiste en 4 nodos (n0, n1, n2, n3). Todos los links seran declarados
como bidireccionales, es decir, duplex links.
El link de n2 n3 tiene un ancho de banda de 1 mbps con un retardo de
20 ms.
El link n0 n2, tiene un ancho de banda de 2.5 mbps con 10 ms de retardo.
El link n1 n2, tiene un ancho de banda de 2 mbps con 10 ms de retardo.
El nodo n2 usa una cola de tipo DropTail, es decir, si supera la maxima
capacidad de la cola, se descartaran los siguiente paquetes entrantes. Para este
caso, la capacidad maxima sera de 10 paquetes.
Los nodos n0 con n3 realizaran una conexion de tipo FTP (Bajo TCP), es
decir, se requerira de un ACK (SINK ) para confirmar recepcion del paquete.
Los nodos n1 con n3, tendran una comunicacion CBR (bajo UDP), es decir,
este no requerira de un paquete ACK de confirmacion. Simplemente se enviara.
Esto se ve en el nodo n3, NULL.
La simulacion comenzara el trafico CBR a los 0.1 segundos y finalizara a los
5 segundos. El trafico FTP comenzara a los 0.5 segundo y finalizara a los 4.5
segundos.

6
 A continuacion se muestra el codigo comentado:

#Creacion del objeto simulador

set ns [new Simulator]

#Definicion de distintos colores para la simulacion,

# es opcional, pero recomendable. Ojo. Siempre con el objeto $ns
$ns color 1 Blue
$ns color 2 Red

#Abrir un archivo para escritura (w) out.nam. Esto para enviar el

#trazado de la simulacion. Se crea como objeto $nf.
set nf [open out.nam w]
# Todo el trazado que sea enviado al archivo
$ns namtrace-all $nf

#El trazado anterior es poco legible, pero debe ser creado para que el
#programa nam lo interprete. Sin embargo, hay otro tipo de trazado que
#es mas legible para nosotros. Para ello es necesario a~
nadir las
#siguientes lineas, muy parecidas a las de arriba
set tf [open out.tr w]
$ns trace-all $tf

#Definicion del procedimiento finish, es el que se llama cuando

# finaliza la simulacion. Se podria evitar este procedimiento,
#colocando el codigo mas abajo.
proc finish {} {
global ns nf tf
$ns flush-trace # Refrescar el trazado
close $nf # Cerrar el objeto $nf de trazado
close $tf # Cerrar $tf de trazado
exec nam out.nam & # Ejecutar .nam resultante
exit 0
}

#Crear los 4 nodos como n1, n2, n3, n4

set n0 [$ns node]
set n1 [$ns node]
set n2 [$ns node]
set n3 [$ns node]

#Definicion de los links entre cada nodo

#Por ejemplo, el primero dice que en el objeto $ns, los nodos $n0 y
#$n2 tendran un link bidireccional de 2mbps, con un retardo de 10ms y
#el tipo de cola sera DropTail
$ns duplex-link $n0 $n2 2.5Mb 10ms DropTail

7
$ns duplex-link $n1 $n2 2Mb 10ms DropTail
$ns duplex-link $n2 $n3 1Mb 20ms DropTail

#La cola maxima entre los nodos $n2 y $n3 sera de 10 paquetes, el
resto sera descartado
$ns queue-limit $n2 $n3 10

#Esto es opcional, es para dar la posicion de los nodos

$ns duplex-link-op $n0 $n2 orient right-down
$ns duplex-link-op $n1 $n2 orient right-up
$ns duplex-link-op $n2 $n3 orient right

#Monitor de la cola del link (n2-n3).Si se descomenta, solo se

muestran los paquetes descartados, no la cola.
$ns duplex-link-op $n2 $n3 queuePos 0.5

#Configuracion del agente TCP al nodo $n0

set tcp [new Agent/TCP]
$tcp set class_ 2
$ns attach-agent $n0 $tcp #Agregue el agente al nodo $n0

#Configuracion del agente SINK al nodo $n3

set sink [new Agent/TCPSink]
$ns attach-agent $n3 $sink #Agregue el agente a $n3
$ns connect $tcp $sink #Conexion para los agentes tcp y sink
$tcp set fid_ 1

#Configurar que agente TCP sea una aplicacion FTP

set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ftp set type_ FTP

#Configurar Agente UDP en nodo $n1

set udp [new Agent/UDP]
$ns attach-agent $n1 $udp # Agregando agente al nodo $n1

#configuracion de agente NULL para agente udp

set null [new Agent/Null]
$ns attach-agent $n3 $null
$ns connect $udp $null #Conexion agente udp y null
$udp set fid_ 2

#configurar para que UDP sea una aplicacion CBR

set cbr [new Application/Traffic/CBR]
$cbr attach-agent $udp
$cbr set type_ CBR

8
$cbr set packet_size_ 1000 # Maximo tama~
no de paquetes
$cbr set rate_ 1mb
$cbr set random_ false

#Programacion de eventos, por ejemplo, $cbr comienza a los 0.1

segundos y termina a los 5 segundos
$ns at 0.1 "$cbr start"
$ns at 0.5 "$ftp start"
$ns at 4.5 "$ftp stop"
$ns at 5.0 "$cbr stop"

#Detener los objetos cuando finalize la simulacion (esto no es tan

#necesario)
$ns at 4.5 "$ns detach-agent $n0 $tcp ; $ns detach-agent $n3 $sink"

#Al pasar los 5 segundos, para finalizar, llamar a la funcion finish

$ns at 5.0 "finish"

#Por pantalla imprimira el tama~

no del paquete CBR y el intervalo en
# que salen
puts "CBR packet size = [$cbr set packet_size_]"
puts "CBR interval = [$cbr set interval_]"

#Iniciar la simulacion
$ns run

4.1. Analisis de trazado

Como se explico en el tem 3, al ejecutar el comando ns ejemplo1.tcl, se
generara un archivo .nam y/o .tr (tienen la misma informacion pero en distinto
formato).
Al ver este archivo, se distinguen todos los eventos realizados durante la
simulacion lnea por lnea. Por lo tanto, es poco lo que uno puede concluir. Es
por ello que se usa el programa nam que tiene por objeto interpretar estos valores
y simularlos en una interfaz grafica bastante amigable.
Las diferencia entre el archivo .nam y .tr es muy simple: .nam es el formato
que debe tener para la lectura del programa nam y .tr es un formato mas
amigable para nosotros si se requiere un analisis. Por lo tanto, del punto de
vista de contenido son exactamente iguales, pero difieren solo en el formato.
Por lo tanto, el analisis lo concentraremos en el archivo .tr. Es importante
saber leer este archivo .tr ya que puede ser de muchsima utilidad a la hora de
requerir filtrar ciertos eventos. Eso se puede lograr con un buen manejo en la
lnea de comandos en Linux, especificamente con el comando egrep.
En la figura 8 se muestra el formato que tiene cada lnea.

9
 Figura 8: Formato de la estructura en archivo .nam

Extraeremos del ejemplo del tem 4 una parte del archivo .tr generado y lo
analizaremos:

r 0.494 2 3 cbr 1000 ------- 2 1.0 3.1 44 44

r 0.498 1 2 cbr 1000 ------- 2 1.0 3.1 48 48
+ 0.498 2 3 cbr 1000 ------- 2 1.0 3.1 48 48
- 0.498 2 3 cbr 1000 ------- 2 1.0 3.1 48 48
+ 0.5 0 2 tcp 40 ------- 1 0.0 3.0 0 50
- 0.5 0 2 tcp 40 ------- 1 0.0 3.0 0 50
+ 0.5 1 2 cbr 1000 ------- 2 1.0 3.1 50 51
- 0.5 1 2 cbr 1000 ------- 2 1.0 3.1 50 51
r 0.502 2 3 cbr 1000 ------- 2 1.0 3.1 45 45
r 0.506 1 2 cbr 1000 ------- 2 1.0 3.1 49 49

Analisis de cada campo.

r: recivido, +: encola, -: salecola, d: descartado.
Tiempo. Fijarse en que a los 5 segundos comienza el trafico TCP, tal como
se haba propuesto en el ejemplo.

Nodo fuente
Nodo Destino
Tipo de paquete
Tamano del paquete
Flags varios
El resto no es necesario nombrar
En la figura 4 se ilustro la forma como se movian los paquetes internamente
en cada nodo. Si se observa detenidamente, los campos 9 y 10, representan el
movimiento que debe tener el paquete dentro de cada nodo. Por ejemplo 1.0
3.1 quiere decir que en nodo n1 salio por puerta 0 y cuando llegue al nodo n3
debe entrar por puerta 1. Como se haba visto anteriormente, esto es logico, ya
que el puerto 1 era el port Clasiffier y era lo primero que debe hacer un paquete
al ingresar a un nodo para ver el tipo de paquete..
El resto del trazado es simple ya que es una secuencia logica de entrada y
salida de cada paquete a una cola o llegada a un nodo.

10
5. Simulacion RED
Otro ejemplo bastante interesante es el de la simulacion de una cola de tipo
RED - Random Early Detection. Esta cola consiste en un sistema que mediante
un resultado probabilstico indica si un paquetes es descartado o no de una cola.
No esta disenado para operar con cualquier protocolo. Su mejor funcionamiento
se logra a traves de TCP.
En los ejemplos anteriores, se dispona de las colas de tipo DropTail que
consista en descartar los paquetes si estos exceden el maximo del tamano de la
cola. En RED se verifica que el promedio de la cola se encuentre en distintos
rangos, y de acuerdo a su probabilidad se toma la decision de descartarlo o
aceptarlo. El usuario debe definir 4 parametros: fijar el lmite QL que es el
tamano de la cola, definir maxth y minth que es la denominada region RED, la
probabilidad maxima a aceptar mediante maxp y wq que es un factor de peso
(tamano instantaneo de la cola).
El promedio se obtiene mediante el siguiente calculo:
avgi = (1 wq ) avgi1 + wq q
El algoritmo que se sigue se muestra a continuacion
Para cada llegada del paquete {
Calcule avg
if (avg > max_th) {
Caiga el paquete
}
else if (avg > min_th) {

Calcule la probabilidad de descartarlo p_a

Descarte el paquete con probabilidad p_a, sino entreguelo
}
else {
entregar
}
}
La simulacion es bastante especial ya que genera un grafico de la simulacion,
es decir, no muestra la simulacion.
El script se denomina red.tcl y el esquema se presenta en la figura 9.
La idea es iniciar el evento a los 0 segundos con ftp1 y finalizarlo a los 10
segundo. El evento ftp2 comienza a los 3 segundos y finaliza a los 10 segundos.
Ademas en este ejemplo intervienen ventanas para el trafico TCP, en este caso
es de 25 en los nodos s1 y s2.
El script red.tcl consiste en una simulacion que generara diversos archivos,
siendo los mas importantes queue y temp.queue, donde se guardaran los valores
para graficar la cola RED entre r1 r2. Se generan dos archivos porque el
grafico despliega dos curvas, una para denotar el uso de la cola en el tiempo y
el otro el promedio del uso de la cola en el tiempo.

11
 ftp::TCP sink1
{Ventana = 15}

s1 s3
10Mb,2ms 10Mb,4ms

sink2

r1 r2
1.5MB,20ms

10Mb,3ms 10Mb,5ms
s2 s4
{Ventana = 15}

FTP2::TCP2

Figura 9: Estructura del ejemplo 2

Como observacion, es importante hacer notar que la generacion del grafico no

es parte de la implementacion de NS. Para ello en el mismo script tcl mediante
programacion se generaron los archivos con los valores para graficar. Estos se
entregan como parametro a una aplicacion llamada xgraph4.

set ns [new Simulator]

set node_(s1) [$ns node]
set node_(s2) [$ns node]
set node_(r1) [$ns node]
set node_(r2) [$ns node]
set node_(s3) [$ns node]
set node_(s4) [$ns node]

$ns duplex-link $node_(s1) $node_(r1) 10Mb 2ms DropTail

$ns duplex-link $node_(s2) $node_(r1) 10Mb 3ms DropTail
$ns duplex-link $node_(r1) $node_(r2) 1.5Mb 20ms RED
$ns queue-limit $node_(r1) $node_(r2) 25
$ns queue-limit $node_(r2) $node_(r1) 25
$ns duplex-link $node_(s3) $node_(r2) 10Mb 4ms DropTail
$ns duplex-link $node_(s4) $node_(r2) 10Mb 5ms DropTail

$ns duplex-link-op $node_(s1) $node_(r1) orient right-down

$ns duplex-link-op $node_(s2) $node_(r1) orient right-up
$ns duplex-link-op $node_(r1) $node_(r2) orient right
$ns duplex-link-op $node_(r1) $node_(r2) queuePos 0
$ns duplex-link-op $node_(r2) $node_(r1) queuePos 0
$ns duplex-link-op $node_(s3) $node_(r2) orient left-down
$ns duplex-link-op $node_(s4) $node_(r2) orient left-up

# Configuracion de los agentes con ventana de maximo 25

4 http://www.isi.edu/nsnam/xgraph/index.html

12
set tcp1 [$ns create-connection TCP/Reno $node_(s1) TCPSink $node_(s3) 0]
$tcp1 set window_ 25
set tcp2 [$ns create-connection TCP/Reno $node_(s2) TCPSink $node_(s3) 1]
$tcp2 set window_ 25
set ftp1 [$tcp1 attach-source FTP]
set ftp2 [$tcp2 attach-source FTP]

# Trazado de la cola r1->r2 ira en all.q

set redq [[$ns link $node_(r1) $node_(r2)] queue]
set tchan_ [open all.q w]
# En el archivo iran estos tres valores que representan el tipo,
# tiempo promedio y tiempo en cola, respectivamente
$redq trace curq_
$redq trace ave_
$redq attach $tchan_

# Programacion de los eventos

$ns at 0.0 "$ftp1 start"
$ns at 3.0 "$ftp2 start"
$ns at 10 "finish"

# Al finalizar se inicia el procesamiento para generar los archivos.

# Necesarios para graficar con Xgraph
proc finish {} {
global tchan_

# Esto se ejecuta para cada lnea del archivo all.q

set awkCode {
{
if ($1 == "Q" && NF>2) {
print $2, $3 >> "temp.q";
set end $2
}
else if ($1 == "a" && NF>2)
print $2, $3 >> "temp.a";
}
}
set f [open temp.queue w]
puts $f "TitleText: red"
puts $f "Device: Postscript"

if { [info exists tchan_] } {

close $tchan_
}
exec rm -f temp.q temp.a
exec touch temp.a temp.q

13
 exec awk $awkCode all.q

puts $f \"queue
exec cat temp.q >@ $f
puts $f \n\"ave_queue
exec cat temp.a >@ $f
close $f
# Aca se ejecuta xgraph y lleva como parametro los archivos
# creados mediante el procesamiento anterior.
exec xgraph -bb -tk -x time -y queue temp.queue &
exit 0
}
$ns run

Este procesamiento generara el grafico que se muestra a continuacion:

Figura 10: Grafico resultante en ejemplo 2

El grafico muestra la cantidad de paquetes dentro de la cola en relacion al

tiempo. La otra curva indica el promedio que tiene de uso la cola. En sntesis
se puede concluir mediante esta herramienta, que la cola comienza a llenarse
aproximadamente a los 2.5 segundos, sin embargo se mantiene bien dado que la
ventana tiene un maximo de 25 paquetes para el despacho. Luego a los 5.7 se-
gundos comienza a tener mucha actividad nuevamente pero no como la anterior.

14
El promedio de uso de la cola baja considerablemente a los 5 segundos.
Puede ser muy basico lo explicado recientemente, pero la idea es que medi-
ante la simulacion se pudo determinar los horarios en que se ven afectados con
mucha actividad la cola de una red.
El mismo script modificado para ser visto en el simulador .nam se presenta
a continuacion.

set ns [new Simulator]

$ns color 1 Blue

$ns color 2 Red
$ns color 3 Green
$ns color 4 Black

set nf [open out.nam w]

$ns namtrace-all $nf

set node_(s1) [$ns node]

set node_(s2) [$ns node]
set node_(r1) [$ns node]
set node_(r2) [$ns node]
set node_(s3) [$ns node]
set node_(s4) [$ns node]

$ns duplex-link $node_(s1) $node_(r1) 10Mb 2ms DropTail

$ns duplex-link $node_(s2) $node_(r1) 10Mb 3ms DropTail
$ns duplex-link $node_(r1) $node_(r2) 1.5Mb 20ms RED
$ns queue-limit $node_(r1) $node_(r2) 25
$ns queue-limit $node_(r2) $node_(r1) 25
$ns duplex-link $node_(s3) $node_(r2) 10Mb 4ms DropTail
$ns duplex-link $node_(s4) $node_(r2) 10Mb 5ms DropTail

$ns duplex-link-op $node_(s1) $node_(r1) orient right-down

$ns duplex-link-op $node_(s2) $node_(r1) orient right-up
$ns duplex-link-op $node_(r1) $node_(r2) orient right
$ns duplex-link-op $node_(r1) $node_(r2) queuePos 0
$ns duplex-link-op $node_(r2) $node_(r1) queuePos 0
$ns duplex-link-op $node_(s3) $node_(r2) orient left-down
$ns duplex-link-op $node_(s4) $node_(r2) orient left-up

set tcp1 [$ns create-connection TCP/Reno $node_(s1) TCPSink $node_(s3) 0]

$tcp1 set window_ 25
set tcp2 [$ns create-connection TCP/Reno $node_(s2) TCPSink $node_(s3) 1]
$tcp2 set window_ 25
set ftp1 [$tcp1 attach-source FTP]
set ftp2 [$tcp2 attach-source FTP]

15
#Define a finish procedure
proc finish {} {
global ns nf
$ns flush-trace
#Close the NAM trace file
close $nf
#Execute NAM on the trace file
exec nam out.nam &
exit 0
}

$ns at 0.0 "$ftp1 start"

$ns at 0.1 "$ftp2 start"
$ns at 1.0 "$ftp2 stop"
$ns at 1.0 "$ftp1 stop"
$ns at 1.1 "finish"

$ns run

Basicamente es lo mismo que el ejemplo 1, pero se le eliminaron todos los

calculos que se realizan para generar el grafico y se anadio la funcion finish
para terminar el programa.
Si se realizara una simulacion a nivel de una organizacion se podran detectar
los horarios de mayor congestion y variar los enlaces de tal manera de dejar lo
mas optimo posible la estructura de red. Por lo tanto, este ejemplo pienso que
es uno de los mas importantes para darse cuenta realmente el uso e importancia
que tiene este simulador.

6. Conclusion
Finalmente, este trabajo a pesar de ser bastante extenso en lo teorico, cosa
que no cre nunca, fue necesario hacer una descripcion general del funcionamien-
to de este sistema. Al principio la investigacion del tema fue siempre hacia el lado
practico y no tomo mas de dos das en entender el lenguaje y el funcionamiento
del sistema. Sin embargo, la forma de simular, de procesar los datos, etc.. fueron
partes claves que dieron un gusto mas interesante a la investigacion.
Como opinion personal, pienso que el sistema esta bastante avanzado y si
su desarrollo continua, puede llegar a ser un gran simulador. Al parecer los
desarrolladores estan constantemente haciendo cambios a NS. Por lo menos en
los archivos fuente con que se probo este programa, segun en control de versiones,
sala que la ultima modificacion fue en Enero del 2003.
Se estan agregando modulos para transmision Wireless que lamentablemente
no se pudieron probar por falta de documentacion respecto al tema.

16
 El lenguaje es bastante comodo de trabajar y no se debe tener un conocimien-
to muy acabado de programacion, ya que no se emplean sentencias clasicas como
while, for, etc.
Los OUTPUT en los archivos de trazado con los resultados de la simulacion
son de gran ayuda pero requiere de un manejo bastante avanzado en lnea de
comandos de Linux. Importante mencionar es que existen algunas herramientas
desarrolladas por los mismos programadores de NS que muestran varias opciones
teniendo el archivo de trazado en formato .tr. Estan disponibles en la pagina
principal.
Por otro lado, el simulador .nam esta muy bien realizado, pero aun esta
muy inestable. A veces se caa el programa de la nada, o bien, al momento de
hacer cambios en los tiempos, desde nam, se volva loco el sistema y mandaba
cualquier cosa a cualquier nodo.
Creo que el ultimo ejemplo empleado demuestra la efectividad que tiene
este instrumento de simulacion. El grafico es bastante explicativo ya que da una
referencia del trafico de esa cola con respecto al tiempo. Esto puede ser de mucha
utilidad porque pueden estudiarse los tiempos de mayor o menor congestion y
realizar ciertas tareas cuando se entren a esos horarios. Por ejemplo, en el grafico
se observaba que a los 5 segundos haba una baja muy considerable durante 1
segundo. Por lo tanto, se podra suponer que ese horario en una organizacion
puede ser la hora almuerzo donde los empleados dejan sus computadores sin
actividad por lo tanto la red tiene poca congestion. Entonces podra realizar en
ese horario los respaldos pertinentes a la hora que tengo disponible y as intentar
dejar la curva de promedio lo mas pareja posible.
Para finalizar, estoy conciente que NS no es un producto terminado, pero
es el resultado de mucha investigacion y desarrollo de los programadores. En
particular, se han descubierto muchos bugs en el codigo y han sido corregidos
a cabalidad. Sin embargo, gran parte del codigo no esta ejercitado o verifica-
do por ninguna entidad verificadora, por lo tanto, uno podra esperar cierta
incertidumbre en los resultados que entrega.
A pesar de eso, interesante investigacion y gran aporte para mis conocimien-
tos.

Referencias
[1] The Network Simulator NS 2, Home page. Pagina principal.
http://www.isi.edu/nsnam/ns/
[2] Jae Chung, Mark Claypool. NS by Example,
http://nile.wpi.edu/NS/
[3] Sally Floyd. Validation Experiences with the NS Simulator. Abril 19, 1999.
[4] Tcl/Tk Quick Reference Guide. Referencia Rapida para Tcl.
http://www.slac.stanford.edu/~raines/tkref.html
JoTa/LATEX 2

17