NS2 - Network Simulator

Transcripción

1 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 simulador/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 modelamiento 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 funciona 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 2. Descripción Interna NS Network Simulator es un simulador discreto de eventos creado por la Universidad 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 herramientas 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 OTcl 1. 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

3 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 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 estructura 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

4 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 protocolo 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

5 2.3. Network Setup Helping Module Por último, el network Setup Helping Modules indicará las bibliotecas necesarias para realizar la simulación. Esto es necesario ya que los 2 primeros componentes, 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 conexiones 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 nam 3 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

6 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 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 fidsaj foiasjf 9iuwer'f 9wuef oskfas iaf sjdfiasuf098u fiwjfpisjdfpiasjdf ns ejemplo1.tcl.nam.tr nam ejemplo1.nam ejemplo1.tcl Dificil de analizar Simulación 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 1 mbps, 20ms n3 n1 2 mbps, 10ms NULL 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

7 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

8 $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

9 $cbr set packet_size_ 1000 $cbr set rate_ 1mb $cbr set random_ false # Maximo tama~no de paquetes #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

10 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 cbr r cbr cbr cbr tcp tcp cbr cbr r cbr r cbr 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 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

11 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 max th y min th que es la denominada región RED, la probabilidad máxima a aceptar mediante max p y w q que es un factor de peso (tamaño instantáneo de la cola). El promedio se obtiene mediante el siguiente cálculo: avg i = (1 w q ) avg i 1 + w q 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

12 ftp::tcp {Ventana = 15 s1 10Mb,2ms r1 10Mb,3ms s2 {Ventana = 15 FTP2::TCP2 1.5MB,20ms r2 10Mb,4ms 10Mb,5ms sink1 s3 sink2 s4 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 xgraph 4. 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

13 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

14 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 segundos comienza a tener mucha actividad nuevamente pero no como la anterior. 14

15 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 mediante 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

16 #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 funcionamiento 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 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

17 El lenguaje es bastante cómodo de trabajar y no se debe tener un conocimiento 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 verificado 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 conocimientos. Referencias [1] The Network Simulator NS 2, Home page. Página principal. [2] Jae Chung, Mark Claypool. NS by Example, [3] Sally Floyd. Validation Experiences with the NS Simulator. Abril 19, [4] Tcl/Tk Quick Reference Guide. Referencia Rápida para Tcl. JoTa/L A TEX 2ε 17