Sie sind auf Seite 1von 17

NS2 - Network Simulator

Jos´e Miguel Herrera M. Estudiante de Ing.Civil Inform´atica

Valpara´ıso, 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, tr´afico de colas como DropTail, RED, algoritmo de Dijkstra, y mucho m´as.

1.

Introducci´on

A trav´es de los anos˜ se ha hecho importante el modelamiento de diversos eventos antes de tomar decisiones. Tal es el caso de la programaci´on lineal, donde se plant´ea un problema de la vida cotidiana y mediante un modelamien- to matem´atico es factible encontrar una o m´as soluciones. Sin embargo, en la realidad hay que considerar miles de factores importantes que lamentablemente un modelo matem´atico no considera en el mayor de los casos, pero aproxima bastante a una soluci´on 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´a una descripci´on a lo que es este simulador de redes. Esta investigaci´on est´a orientada a conocer el tema de la simulaci´on de redes mediante esta aplicaci´on denominada Network Simulator. Se realizar´an pruebas de algunos algoritmos ya realizados y se har´a una descripci´on interna de c´omo 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´en fun- ciona bajo plataforma windows, sin embargo, la investigaci´on no se llev´o 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´a referencia a las consolas de Linux. En el caso de Linux, el unico´ requisito (suponiendo un PC normal con interfaz gr´afica X y paquetes t´ıpicos) fue la instalaci´on del paquete xfree-devel.

1

2.

Descripci´on 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´on se toma en cuenta lo que es la estructura (topol´ogia) de la red y el tr´afico de paquetes que posee la misma, con el fin de crear una especie de diagn´ostico 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´afico 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´on (por ejemplo, una interfaz gr´afica). La versi´on con que fue probado (en este informe) es la NS versi´on 2 escrita en los lenguajes de programaci´on C++ y OTcl 1 .

El funcionamiento de Network Simulator se explicar´a poco a poco mostrando

las partes m´as generales a las m´as particulares. Para comenzar se mostrar´a una

vista bastante simplificada de lo que es NS.

mostrar´a una vista bastante simplificada de lo que es NS. Figura 1: Vista simplificada del funcionamiento

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 d´a el usuario al programa. El resto es el procesamiento interno de NS. La simulaci´on queda en un archivo que puede ser bastante inc´omodo de leer o analizar para el usuario, sin embargo, usando una aplicaci´on especial se puede mostrar mediante una interfaz gr´afica.

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´on, planifica cuando iniciar o terminar el tr´afico de un determinado paquete, entre otras cosas.

A continuaci´on se entrar´a a especificar un poco m´as como funciona cada

componente. Tampoco es la idea de entrar en detalle, sin embargo, una referencia

r´apida a cada punto ser´a justa y necesaria.

1 Lenguaje Scripting orientado a objetos, desarrollado por MIT

2

2.1.

Event Scheduler Object

con una calendarizaci´on o programa

dado por el programador en la codificaci´on. Internamente se identificar´a con un puntero al objeto que maneja este evento. En la figura 2 se muestra la forma de calendarizar los eventos.

Este evento en NS, es un paquete unico´

los eventos. Este evento en NS, es un paquete unico´ Figura 2: Planificador de eventos Los

Figura 2: Planificador de eventos

Los usuarios principales del planificador de eventos es el Network Component que se ver´a a continuaci´on. Esto porque la transmisi´on de paquetes requiere de ciertos tiempos o retardos necesarios para la simulaci´on. Por ejemplo, al declarar un link con un ancho de banda muy bajo, el planificador de eventos deber´a realizar retardos m´as prolongados en ese enlace para simular que la transmisi´on 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´on que hay entre distintos componentes de red, por donde pasar´an 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´en 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 deber´a quedar en la cola. Ac´a se realizar´an 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 est´a

Figura 3: Componente de red - Link

la cola, o si la cola simplemente est´a llena, etc. Considerando esto, se tomar´a la desici´on si el paquete es descartado, en cuyo caso pasar´a a Drop y a un agente NULO. De lo contrario, se realizar´a un retardo simulado (Delay) del que se hablaba anteriormente. Finalmente se recalcular´a y actualizar´a 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.

4 que representa el flujo de paquetes entre los nodos. Figura 4: Ejemplo de un flujo

Figura 4: Ejemplo de un flujo de paquetes entre nodos

Ac´a se quiere representar una comunicaci´on entre 2 nodos mediante el pro-

tocolo TCP. Este protocolo requiere de una respuesta de confimaci´on 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 informaci´on 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´on. Luego de esto se genera otro paquete y as´ı se repite para cada transmisi´on.

4

2.3.

Network Setup Helping Module

Por ultimo,´ el network Setup Helping Modules indicar´a las bibliotecas nece- sarias para realizar la simulaci´on. Esto es necesario ya que los 2 primeros com- ponentes, descritos en los sub´ıtemes 2.1 y 2.2, est´an escritos y compilados en C++ y est´an disponibles para el int´erprete OTcl a trav´es de un linkage 2 . La raz´on no es muy clara, pero tiene que ver con el tiempo de procesamiento (no de simulaci´on). 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´as bien, es OTcl que llama a estas bibliotecas.

OTcl . M´as bien, es OTcl que llama a estas bibliotecas. Figura 5: linkage entre bibliotecas

Figura 5: linkage entre bibliotecas C++ y OTcl

3. Ejecutar un script

Para ejecutar la aplicaci´on, Network Simulator toma como INPUT a un script en OTcl. En este script se define f´ısicamente la configuraci´on de la red (nodos, conexiones entre nodos), los protocolos que ser´an 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´a un archivo que contendr´a el OUTPUT del an´alisis, un archivo de extensi´on .nam (o el similar .tr que m´as adelante se analizar´a la pequena˜ diferencia). Este archivo es una completa descripci´on de la simulaci´on, donde cada l´ınea describe los paquetes recibidos, enviados, encolados, sacados de la cola, etc. M´as adelante se realizar´a un estudio m´as acabado de este tipo de archivo. Sin embargo, por mucho que se mire este archivo, ser´a muy dificil obtener una gran fotograf´ıa de lo que sucede en la simulaci´on. Es por ello que la visualizaci´on 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´en explicado:

Aparte de generar el archivo .nam, tambi´en puede generar otro archivo .q (si se especifica) que contiene informaci´on acerca de una cola de un nodo en particular durante la simulaci´on. 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´afica para ver la simulaci´on.

5

kd jasdlkasj diaj kjdkasjdsak asd ns ejemplo1.tcl dasod jaspdj pijdwpqij qw qw qroqw oqrjf qwifjwqpifjq
kd
jasdlkasj diaj kjdkasjdsak asd
ns ejemplo1.tcl
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
ejemplo1.tcl
.nam .tr
.nam
.tr

nam ejemplo1.nam

fiwjfpisjdfpiasjdf ejemplo1.tcl .nam .tr nam ejemplo1.nam Dificil de analizar Simulación Gráfica Figura 6: Pasos
fiwjfpisjdfpiasjdf ejemplo1.tcl .nam .tr nam ejemplo1.nam Dificil de analizar Simulación Gráfica Figura 6: Pasos

Dificil de

analizar

Simulación

Gráfica

Figura 6: Pasos para realizar la simulaci´on

4. An´alisis Mediante Ejemplos

A continuaci´on se presentar´an 2 ejemplos bastantes comentados de c´omo

realizar un script en OTcl. El primero es bastante simple y se representa en la

figura 7:

ftp::TCP

n0 n2 2 mbps, 10ms n1 CBR::UDP
n0
n2
2 mbps, 10ms
n1
CBR::UDP

2.5 mbps, 10ms

Sink n3 NULL
Sink
n3
NULL

1 mbps, 20ms

Figura 7: Ejemplo 1, una red simple con tr´afico TCP y UDP

La red consiste en 4 nodos (n0, n1, n2, n3). Todos los links ser´an 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´axima

capacidad de la cola, se descartar´an los siguiente paquetes entrantes. Para este caso, la capacidad m´axima ser´a de 10 paquetes. Los nodos n0 con n3 realizar´an una conexi´on de tipo FTP (Bajo TCP), es decir, se requerir´a de un ACK (SINK ) para confirmar recepci´on del paquete. Los nodos n1 con n3, tendr´an una comunicaci´on CBR (bajo UDP), es decir, este no requerir´a de un paquete ACK de confirmaci´on. Simplemente se enviar´a. Esto se ve en el nodo n3, NULL. La simulaci´on comenzar´a el tr´afico CBR a los 0.1 segundos y finalizar´a a los 5 segundos. El tr´afico FTP comenzar´a a los 0.5 segundo y finalizara a los 4.5 segundos.

6

A continuaci´on se muestra el c´odigo comentado:

#Creacion

del

objeto

simulador

set

ns

[new

Simulator]

 

#Definicion

de

distintos

colores

para

la

simulaci´on,

 

#

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´on.

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´on.

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´an

un

link

bidireccional

de

2mbps,

con

un

retardo

de

10ms

y

#el

tipo

de

 

cola

ser´a

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´a

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

muestran

$ns

de

los

la

cola

paquetes

del

$n2

link

(n2-n3).Si

no

la

0.5

descartados,

$n3

queuePos

duplex-link-op

se

descomenta,

cola.

#Configuracion

del

agente

TCP

al

nodo

$n0

solo

se

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´on

(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

#

que

pantalla

salen

imprimira

el

tama~no

del

paquete

CBR

y

el

intervalo

en

puts

"CBR

packet

size

=

[$cbr

set

packet_size_]"

puts

"CBR

interval

=

[$cbr

set

interval_]"

#Iniciar

$ns

run

la

simulaci´on

4.1. An´alisis de trazado

Como se explic´o en el ´ıtem 3, al ejecutar el comando ns ejemplo1.tcl, se generar´a un archivo .nam y/o .tr (tienen la misma informaci´on pero en distinto formato). Al ver este archivo, se distinguen todos los eventos realizados durante la simulaci´on 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´afica 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´as amigable para nosotros si se requiere un an´alisis. Por lo tanto, del punto de vista de contenido son exactamente iguales, pero difieren s´olo en el formato. Por lo tanto, el an´alisis 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

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´alisis de cada campo.

r: recivido, + : encola, - : salecola, d : descartado. : recivido, +: encola, -: salecola, d: descartado.

Tiempo. Fijarse en que a los 5 segundos comienza el tr´afico TCP, tal como se hab´ıa propuesto en el ejemplo.r : recivido, + : encola, - : salecola, d : descartado. Nodo fuente Nodo Destino

Nodo fuenteTCP, tal como se hab´ıa propuesto en el ejemplo. Nodo Destino Tipo de paquete Tamano˜ del

Nodo Destinotal como se hab´ıa propuesto en el ejemplo. Nodo fuente Tipo de paquete Tamano˜ del paquete

Tipo de paquetehab´ıa propuesto en el ejemplo. Nodo fuente Nodo Destino Tamano˜ del paquete Flags varios El resto

Tamano˜ del paqueteen el ejemplo. Nodo fuente Nodo Destino Tipo de paquete Flags varios El resto no es

Flags variosfuente Nodo Destino Tipo de paquete Tamano˜ del paquete El resto no es necesario nombrar En

El resto no es necesario nombrarDestino Tipo de paquete Tamano˜ del paquete Flags varios En la figura 4 se ilustr´o la

En la figura 4 se ilustr´o 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´o por puerta 0 y cuando llegue al nodo n3 debe entrar por puerta 1. Como se hab´ıa visto anteriormente, esto es l´ogico, 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´ogica de entrada y salida de cada paquete a una cola o llegada a un nodo.

10

5.

Simulaci´on RED

Otro ejemplo bastante interesante es el de la simulaci´on 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 disenado˜ para operar con cualquier protocolo. Su mejor funcionamiento se logra a trav´es 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´aximo 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 decisi´on de descartarlo o aceptarlo. El usuario debe definir 4 par´ametros: fijar el l´ımite QL que es el tamano˜ de la cola, definir max th y min th que es la denominada regi´on RED, la probabilidad m´axima a aceptar mediante max p y w q que es un factor de peso (tamano˜ instant´aneo de la cola). El promedio se obtiene mediante el siguiente c´alculo:

avg i

=

(1 w q ) × avg i1 + w q × q

El algoritmo que se sigue se muestra a continuaci´on

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´on es bastante especial ya que genera un gr´afico de la simulaci´on, es decir, no muestra la simulaci´on. 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´as en este ejemplo intervienen ventanas para el tr´afico TCP, en este caso es de 25 en los nodos s1 y s2. El script red.tcl consiste en una simulaci´on que generar´a diversos archivos, siendo los m´as importantes queue y temp.queue, donde se guardar´an los valores para graficar la cola RED entre r1 r2. Se generan dos archivos porque el gr´afico 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,4ms 10Mb,2ms sink2 r1 r2 1.5MB,20ms 10Mb,3ms 10Mb,5ms
ftp::TCP
sink1
{Ventana = 15}
s1
s3
10Mb,4ms
10Mb,2ms
sink2
r1
r2
1.5MB,20ms
10Mb,3ms
10Mb,5ms
s2
s4
{Ventana = 15}
FTP2::TCP2
Figura 9: Estructura del ejemplo 2

Como observaci´on, es importante hacer notar que la generaci´on del gr´afico no es parte de la implementaci´on de NS. Para ello en el mismo script tcl mediante programaci´on se generaron los archivos con los valores para gr´aficar. Estos se entregan como par´ametro a una aplicaci´on 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´on

de

los

agentes

con

ventana

de

m´aximo

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´an

estos

tres

valores

que

representan

el

tipo,

# tiempo

promedio

y

tiempo

en

cola,

respectivamente

 

$redq

trace

curq_

 

$redq

trace

ave_

$redq

attach

$tchan_

 

#

Programaci´on

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´a

se

ejecuta

xgraph

y

lleva

como

par´ametro

los

archivos

# creados

mediante

el

procesamiento

anterior.

 

exec

xgraph

-bb

-tk

-x

time

-y

queue

temp.queue

&

exit

0

}

$ns

run

Este procesamiento generar´a el gr´afico que se muestra a continuaci´on:

generar´a el gr´afico que se muestra a continuaci´on: Figura 10: Gr´afico resultante en ejemplo 2 El

Figura 10: Gr´afico resultante en ejemplo 2

El gr´afico muestra la cantidad de paquetes dentro de la cola en relaci´on 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´aximo 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´asico lo explicado recientemente, pero la idea es que medi- ante la simulaci´on 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´on.

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

#Close

close

#Execute

exec

exit

nam

flush-trace

0

the

$nf

NAM

NAM

out.nam

on

trace

the

&

file

trace

file

$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´asicamente es lo mismo que el ejemplo 1, pero se le eliminaron todos los c´alculos que se realizan para generar el gr´afico y se anadi´˜ o la funci´on ’finish’ para terminar el programa. Si se realizara una simulaci´on a nivel de una organizaci´on se podr´ıan detectar los horarios de mayor congesti´on y variar los enlaces de tal manera de dejar lo m´as optimo´ posible la estructura de red. Por lo tanto, este ejemplo pienso que es uno de los m´as importantes para darse cuenta realmente el uso e importancia que tiene este simulador.

6.

Conclusi´on

Finalmente, este trabajo a pesar de ser bastante extenso en lo te´orico, cosa que no cre´ı nunca, fue necesario hacer una descripci´on general del funcionamien-

to de este sistema. Al principio la investigaci´on del tema fue siempre hacia el lado pr´actico y no tom´o m´as de dos d´ıas en entender el lenguaje y el funcionamiento

fueron

partes claves que dieron un gusto m´as interesante a la investigaci´on. Como opini´on personal, pienso que el sistema esta bastante avanzado y si su desarrollo continua,´ puede llegar a ser un gran simulador. Al parecer los desarrolladores est´an constantemente haciendo cambios a NS. Por lo menos en los archivos fuente con que se prob´o este programa, segun´ en control de versiones, sal´ıa que la ultima´ modificaci´on fue en Enero del 2003. Se est´an agregando m´odulos para transmisi´on Wireless que lamentablemente no se pudieron probar por falta de documentaci´on respecto al tema.

del sistema. Sin embargo, la forma de simular, de procesar los datos, etc

16

El lenguaje es bastante c´omodo de trabajar y no se debe tener un conocimien-

to muy acabado de programaci´on, ya que no se emplean sentencias cl´asicas como while, for, etc. Los OUTPUT en los archivos de trazado con los resultados de la simulaci´on 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´agina principal. Por otro lado, el simulador .nam est´a muy bien realizado, pero aun´ 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 ultimo´ ejemplo empleado demuestra la efectividad que tiene este instrumento de simulaci´on. El gr´afico es bastante explicativo ya que da una referencia del tr´afico de esa cola con respecto al tiempo. Esto puede ser de mucha utilidad porque pueden estudiarse los tiempos de mayor o menor congesti´on y realizar ciertas tareas cuando se entren a esos horarios. Por ejemplo, en el gr´afico 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´on puede ser la hora almuerzo donde los empleados dejan sus computadores sin actividad por lo tanto la red tiene poca congesti´on. 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´as pareja posible. Para finalizar, estoy conciente que NS no es un producto terminado, pero es el resultado de mucha investigaci´on y desarrollo de los programadores. En particular, se han descubierto muchos bugs en el c´odigo y han sido corregidos a cabalidad. Sin embargo, gran parte del c´odigo no est´a 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´on y gran aporte para mis conocimien-

tos.

Referencias

[1] The Network Simulator NS 2, Home page. P´agina 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´apida para Tcl. http://www.slac.stanford.edu/~raines/tkref.html

JoTa/L A T E X2 ε

17