NS2 - Network Simulator

José Miguel Herrera M.

Estudiante de Ing.Civil Informática
Valparaı́so, 12 de mayo de 2004

Resumen
He aquı́ una reseña 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, tráfico de colas
como DropTail, RED, algoritmo de Dijkstra, y mucho más.

1. Introducción
A través de los años se ha hecho importante el modelamiento de diversos
eventos antes de tomar decisiones. Tal es el caso de la programación lineal,
donde se plantéa un problema de la vida cotidiana y mediante un modelamien-
to matemático es factible encontrar una o más soluciones. Sin embargo, en la
realidad hay que considerar miles de factores importantes que lamentablemente
un modelo matemático no considera en el mayor de los casos, pero aproxima
bastante a una solución 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 dará una descripción a lo que es este simulador
de redes. Esta investigación está orientada a conocer el tema de la simulación
de redes mediante esta aplicación denominada Network Simulator. Se realizarán
pruebas de algunos algoritmos ya realizados y se hará una descripción interna
de cómo 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 también fun-
ciona bajo plataforma windows, sin embargo, la investigación no se llevó a cabo
en este sistema operativo, por lo tanto, requisitos, funcionamiento, u otros, no
fueron probados. Por lo tanto, al hablar de Lı́nea de comandos se hará referencia
a las consolas de Linux.
En el caso de Linux, el único requisito (suponiendo un PC normal con interfaz
gráfica X y paquetes tı́picos) fue la instalación del paquete xfree-devel.

1
2. Descripción 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 simulación se toma en
cuenta lo que es la estructura (topológia) de la red y el tráfico de paquetes que
posee la misma, con el fin de crear una especie de diagnóstico que nos muestre
el comportamiento que se obtiene al tener una red con ciertas caracterı́sticas.
Trae implementaciones de protocolos tales como TCP y UDP, que es posible
hacerlos comportar como un tráfico 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 simulación (por ejemplo, una
interfaz gráfica).
La versión con que fue probado (en este informe) es la NS versión 2 escrita
en los lenguajes de programación C++ y OTcl1 .
El funcionamiento de Network Simulator se explicará poco a poco mostrando
las partes más generales a las más particulares. Para comenzar se mostrará 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 único INPUT que dá el usuario al
programa. El resto es el procesamiento interno de NS. La simulación queda en
un archivo que puede ser bastante incómodo de leer o analizar para el usuario,
sin embargo, usando una aplicación especial se puede mostrar mediante una
interfaz gráfica.
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 topologı́a de la red, calendariza
los eventos, carga las funciones necesarias para la simulación, planifica cuando
iniciar o terminar el tráfico de un determinado paquete, entre otras cosas.
A continuación se entrará a especificar un poco más como funciona cada
componente. Tampoco es la idea de entrar en detalle, sin embargo, una referencia
rápida a cada punto será 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 único con una calendarización o programa
dado por el programador en la codificación. Internamente se identificará 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 verá a continuación. Esto porque la transmisión de paquetes requiere
de ciertos tiempos o retardos necesarios para la simulación. Por ejemplo, al
declarar un link con un ancho de banda muy bajo, el planificador de eventos
deberá realizar retardos más prolongados en ese enlace para simular que la
transmisión 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 comunicación que hay entre distintos
componentes de red, por donde pasarán 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 también actúa 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 deberá quedar
en la cola. Acá se realizarán una serie de procesamientos dependiendo del tipo de
cola que tenga ese link, tales como, si el tamaño del paquete supera el tamaño de

3
 Figura 3: Componente de red - Link

la cola, o si la cola simplemente está llena, etc. Considerando esto, se tomará la

desición si el paquete es descartado, en cuyo caso pasará a Drop y a un agente
NULO. De lo contrario, se realizará un retardo simulado (Delay) del que se
hablaba anteriormente. Finalmente se recalculará y actualizará 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

Acá se quiere representar una comunicación entre 2 nodos mediante el pro-

tocolo TCP. Este protocolo requiere de una respuesta de confimación 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 añadir al paquete la información 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 confirmación. Luego de esto se genera
otro paquete y ası́ se repite para cada transmisión.

4
2.3. Network Setup Helping Module
Por último, el network Setup Helping Modules indicará las bibliotecas nece-
sarias para realizar la simulación. Esto es necesario ya que los 2 primeros com-
ponentes, descritos en los subı́temes 2.1 y 2.2, están escritos y compilados en
C++ y están disponibles para el intérprete OTcl a través de un linkage 2 . La
razón no es muy clara, pero tiene que ver con el tiempo de procesamiento (no
de simulación). Se puede hacer la analogı́a 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. Más bien, es OTcl que llama a estas
bibliotecas.

Figura 5: linkage entre bibliotecas C++ y OTcl

3. Ejecutar un script
Para ejecutar la aplicación, Network Simulator toma como INPUT a un
script en OTcl. En este script se define fı́sicamente la configuración de la red
(nodos, conexiones entre nodos), los protocolos que serán 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 lı́nea de comandos y esto creará un archivo
que contendrá el OUTPUT del análisis, un archivo de extensión .nam (o el
similar .tr que más adelante se analizará la pequeña diferencia). Este archivo
es una completa descripción de la simulación, donde cada lı́nea describe los
paquetes recibidos, enviados, encolados, sacados de la cola, etc. Más adelante
se realizará un estudio más acabado de este tipo de archivo. Sin embargo, por
mucho que se mire este archivo, será muy dificil obtener una gran fotografı́a de lo
que sucede en la simulación. Es por ello que la visualización se realiza mediante el
programa nam3 y se ejecuta simplemente con el comando nam ejemplo1.nam.
En la figura 6 se muestra lo recién explicado:
Aparte de generar el archivo .nam, también puede generar otro archivo .q
(si se especifica) que contiene información acerca de una cola de un nodo en
particular durante la simulación. 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 gráfica para ver la simulación.

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 Simulación

analizar Gráfica

Figura 6: Pasos para realizar la simulación

4. Análisis Mediante Ejemplos

A continuación se presentarán 2 ejemplos bastantes comentados de cómo
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 tráfico TCP y UDP

La red consiste en 4 nodos (n0, n1, n2, n3). Todos los links serán 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 máxima
capacidad de la cola, se descartarán los siguiente paquetes entrantes. Para este
caso, la capacidad máxima será de 10 paquetes.
Los nodos n0 con n3 realizarán una conexión de tipo FTP (Bajo TCP), es
decir, se requerirá de un ACK (SINK ) para confirmar recepción del paquete.
Los nodos n1 con n3, tendrán una comunicación CBR (bajo UDP), es decir,
este no requerirá de un paquete ACK de confirmación. Simplemente se enviará.
Esto se ve en el nodo n3, NULL.
La simulación comenzará el tráfico CBR a los 0.1 segundos y finalizará a los
5 segundos. El tráfico FTP comenzará a los 0.5 segundo y finalizara a los 4.5
segundos.

6
 A continuación se muestra el código comentado:

#Creacion del objeto simulador

set ns [new Simulator]

#Definicion de distintos colores para la simulación,

# 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 simulación. 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 simulación. 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 tendrán un link bidireccional de 2mbps, con un retardo de 10ms y
#el tipo de cola será 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 será 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 simulación (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 simulación
$ns run

4.1. Análisis de trazado

Como se explicó en el ı́tem 3, al ejecutar el comando ns ejemplo1.tcl, se
generará un archivo .nam y/o .tr (tienen la misma información pero en distinto
formato).
Al ver este archivo, se distinguen todos los eventos realizados durante la
simulación lı́nea por lı́nea. 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 gráfica 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 más
amigable para nosotros si se requiere un análisis. Por lo tanto, del punto de
vista de contenido son exactamente iguales, pero difieren sólo en el formato.
Por lo tanto, el análisis lo concentraremos en el archivo .tr. Es importante
saber leer este archivo .tr ya que puede ser de muchı́sima utilidad a la hora de
requerir filtrar ciertos eventos. Eso se puede lograr con un buen manejo en la
lı́nea de comandos en Linux, especificamente con el comando egrep.
En la figura 8 se muestra el formato que tiene cada lı́nea.

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

Análisis de cada campo.

r: recivido, +: encola, -: salecola, d: descartado.
Tiempo. Fijarse en que a los 5 segundos comienza el tráfico TCP, tal como
se habı́a propuesto en el ejemplo.

Nodo fuente
Nodo Destino
Tipo de paquete
Tamaño del paquete
Flags varios
El resto no es necesario nombrar
En la figura 4 se ilustró 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 salió por puerta 0 y cuando llegue al nodo n3
debe entrar por puerta 1. Como se habı́a visto anteriormente, esto es lógico, 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 lógica de entrada y
salida de cada paquete a una cola o llegada a un nodo.

10
5. Simulación RED
Otro ejemplo bastante interesante es el de la simulación de una cola de tipo
RED - Random Early Detection. Esta cola consiste en un sistema que mediante
un resultado probabilı́stico indica si un paquetes es descartado o no de una cola.
No esta diseñado para operar con cualquier protocolo. Su mejor funcionamiento
se logra a través de TCP.
En los ejemplos anteriores, se disponı́a de las colas de tipo DropTail que
consistı́a en descartar los paquetes si estos exceden el máximo del tamaño 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 decisión de descartarlo o
aceptarlo. El usuario debe definir 4 parámetros: fijar el lı́mite QL que es el
tamaño de la cola, definir maxth y minth que es la denominada región RED, la
probabilidad máxima a aceptar mediante maxp y wq que es un factor de peso
(tamaño instantáneo de la cola).
El promedio se obtiene mediante el siguiente cálculo:
avgi = (1 − wq ) × avgi−1 + wq × q
El algoritmo que se sigue se muestra a continuación
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 simulación es bastante especial ya que genera un gráfico de la simulación,
es decir, no muestra la simulación.
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.
Además en este ejemplo intervienen ventanas para el tráfico TCP, en este caso
es de 25 en los nodos s1 y s2.
El script red.tcl consiste en una simulación que generará diversos archivos,
siendo los más importantes queue y temp.queue, donde se guardarán los valores
para graficar la cola RED entre r1 → r2. Se generan dos archivos porque el
gráfico 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 observación, es importante hacer notar que la generación del gráfico no

es parte de la implementación de NS. Para ello en el mismo script tcl mediante
programación se generaron los archivos con los valores para gráficar. Estos se
entregan como parámetro a una aplicación 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

# Configuración de los agentes con ventana de máximo 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 irán estos tres valores que representan el tipo,
# tiempo promedio y tiempo en cola, respectivamente
$redq trace curq_
$redq trace ave_
$redq attach $tchan_

# Programación 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 lı́nea 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
# Acá se ejecuta xgraph y lleva como parámetro los archivos
# creados mediante el procesamiento anterior.
exec xgraph -bb -tk -x time -y queue temp.queue &
exit 0
}
$ns run

Este procesamiento generará el gráfico que se muestra a continuación:

Figura 10: Gráfico resultante en ejemplo 2

El gráfico muestra la cantidad de paquetes dentro de la cola en relación al

tiempo. La otra curva indica el promedio que tiene de uso la cola. En sı́ntesis
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 máximo 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 básico lo explicado recientemente, pero la idea es que medi-
ante la simulación 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 continuación.

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

Básicamente es lo mismo que el ejemplo 1, pero se le eliminaron todos los

cálculos que se realizan para generar el gráfico y se añadió la función ’finish’
para terminar el programa.
Si se realizara una simulación a nivel de una organización se podrı́an detectar
los horarios de mayor congestión y variar los enlaces de tal manera de dejar lo
más óptimo posible la estructura de red. Por lo tanto, este ejemplo pienso que
es uno de los más importantes para darse cuenta realmente el uso e importancia
que tiene este simulador.

6. Conclusión
Finalmente, este trabajo a pesar de ser bastante extenso en lo teórico, cosa
que no creı́ nunca, fue necesario hacer una descripción general del funcionamien-
to de este sistema. Al principio la investigación del tema fue siempre hacia el lado
práctico y no tomó más de dos dı́as 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 más interesante a la investigación.
Como opinión personal, pienso que el sistema esta bastante avanzado y si
su desarrollo continúa, puede llegar a ser un gran simulador. Al parecer los
desarrolladores están constantemente haciendo cambios a NS. Por lo menos en
los archivos fuente con que se probó este programa, según en control de versiones,
salı́a que la última modificación fue en Enero del 2003.
Se están agregando módulos para transmisión Wireless que lamentablemente
no se pudieron probar por falta de documentación respecto al tema.

16
 El lenguaje es bastante cómodo de trabajar y no se debe tener un conocimien-
to muy acabado de programación, ya que no se emplean sentencias clásicas como
while, for, etc.
Los OUTPUT en los archivos de trazado con los resultados de la simulación
son de gran ayuda pero requiere de un manejo bastante avanzado en lı́nea 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 página
principal.
Por otro lado, el simulador .nam está muy bien realizado, pero aún esta
muy inestable. A veces se caı́a el programa de la nada, o bien, al momento de
hacer cambios en los tiempos, desde nam, se “volvı́a loco” el sistema y mandaba
cualquier cosa a cualquier nodo.
Creo que el último ejemplo empleado demuestra la efectividad que tiene
este instrumento de simulación. El gráfico es bastante explicativo ya que da una
referencia del tráfico de esa cola con respecto al tiempo. Esto puede ser de mucha
utilidad porque pueden estudiarse los tiempos de mayor o menor congestión y
realizar ciertas tareas cuando se entren a esos horarios. Por ejemplo, en el gráfico
se observaba que a los 5 segundos habı́a una baja muy considerable durante 1
segundo. Por lo tanto, se podrı́a suponer que ese horario en una organización
puede ser la hora almuerzo donde los empleados dejan sus computadores sin
actividad por lo tanto la red tiene poca congestión. Entonces podrı́a realizar en
ese horario los respaldos pertinentes a la hora que tengo disponible y ası́ intentar
dejar la curva de promedio lo más pareja posible.
Para finalizar, estoy conciente que NS no es un producto terminado, pero
es el resultado de mucha investigación y desarrollo de los programadores. En
particular, se han descubierto muchos bugs en el código y han sido corregidos
a cabalidad. Sin embargo, gran parte del código no está ejercitado o verifica-
do por ninguna entidad verificadora, por lo tanto, uno podrı́a esperar cierta
incertidumbre en los resultados que entrega.
A pesar de eso, interesante investigación y gran aporte para mis conocimien-
tos.

Referencias
[1] The Network Simulator NS 2, Home page. Página 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 Rápida para Tcl.
http://www.slac.stanford.edu/~raines/tkref.html
JoTa/LATEX 2ε

17