this watermark does not appear in the registered version ...148.206.53.84/tesiuami/uami14513.pdf ·...

1

This watermark does not appear in the registered version - http://www.clicktoconvert.com

http://www.clicktoconvert.com

2

Contenido Pág. Objetivo-------------------------------------------------------------------------- 3 Introducción--------------------------------------------------------------------- 3 1 Fundamentos----------------------------------------------------------------- 4-6 1.1 Protocolo TCP----------------------------------------------------------- 6 1.1.1 Evitación de congestión en TCP-------------------------------- 7 1.1.2 Control de flujo--------------------------------------------------- 8-10 1.1.3 Control de errores ------------------------------------------------ 11 1.2 Fundamentos de NS-2------------------------------------------------- 12 1.2.1 Manejo de eventos con C++------------------------------------ 12 1.2.2 Lenguaje interprete TCL---------------------------------------- 12 1.3 Simulación con NS-2--------------------------------------------------- 13 1.3.1 Estructura del simulador---------------------------------------- 13 1.3.2 Metodología------------------------------------------------------ 14-17 2 Emulación con NS-2----------------------------------------------------- 18 2.1 Estructura del emulador------------------------------------------ 19 2.2 Comunicación entre UML y Host vía puente------------------ 20-21 2.3 Comunicación utilizando emulador ---------------------------- 22-24 2.4 Paso de tráfico real sobre el emulador Ns --------------------- 25 3 Escenarios de simulación----------------------------------------------- 26-27 4 Escenarios de emulación ----------------------------------------------- 28-38 5 Resultados---------------------------------------------------------------- 39-42 6 Conclusiones------------------------------------------------------------- 43-44 7 Referencias -------------------------------------------------------------- 45-46



3

Objetivo

- Estudio del protocolo TCP y de los fundamentos de NS-2 - Experimentaciones con NS-2 - Emulación de tráfico con NS_2

Introducción

La simulación en tiempo real, (o emulación), es una técnica de modelado donde los objetos simulador reproducen un comportamiento en el tiempo similar o igual al comportamiento en tiempo de las entidades simuladas. Esta técnica es empleada para diseñar el ambiente de aplicación deseado durante el proceso de desarrollo de la aplicación. Esto permite el probar diversos entornos simulados con relativamente poco esfuerzo. La meta principal es que una aplicación pueda trabajar con el entorno simulado durante la fase de desarrollo de la misma forma que lo efectuaría en un ambiente real y que la misma pueda ser implementada posteriormente sin modificaciones.

El simulador de redes NS-2, es un simulador de redes basado en eventos discretos, usado recurrentemente tanto para simulación de redes tanto alámbricas como inalámbricas. Posee un modo de emulación, i.e. la habilidad de simular una red arbitraria en tiempo real. La finalidad del presente proyecto se estructura como sigue; implementar el modo de emulación de Ns-2 en un entorno Ubuntu-Linux , probar su correcto funcionamiento en un ambiente de emulación compuesto de entidades virtuales(UML), haciendo pasar trafico real a través de ellas por medio del emulador, para posteriormente implementar el escenario de prueba y con la información obtenida de la emulación determinar el rendimiento del protocolo TCP ante perdidas aleatorias de paquetes en el enlace.

El contenido de este documento se estructura como sigue: En el capitulo 1 se habla acerca de los fundamentos del Protocolo TCP y de los métodos que maneja el mismo para evitar la congestión y controlar los errores en el trasporte de información. Además se describe que es NS-2, cual es su estructura y se finaliza este capitulo describiendo la metodología para implementar una simulación paso a paso. En el capitulo 2 se habla acerca de la capacidad que tiene NS-2 para emular trafico real, mediante la instalación de un paquete que tiene esta característica para el simulador. Se describe el desarrollo para obtener comunicación y transportar información entre UML y host vía un puente (br0 y br1) , posteriormente se habla de cómo implementar lo mismo pero ahora utilizando la característica de emulación de NS-2. En el capitulo 3 y 4 se muestran los scripts de escenarios de simulación y emulación. Finalmente concluimos este reporte con los capítulos 5 y 6 en los cuales se muestra la información obtenida mediante la emulación de tráfico real y se muestra los resultados del desempeño de TCP dado un escenario en el cual existen perdidas aleatorias en el enlace.



4

1 Fundamentos TCP es un protocolo estándar . Se describe en el RFC 793 - TCP("Transport Control

Protocol"). TCP proporciona una cantidad considerablemente mayor de servicios comparado con las de UDP, destacando la recuperación de errores, control de flujo y fiabilidad. Se trata de un protocolo orientado a conexión a diferencia de UDP. La mayoría de los protocolos de aplicación de usuario, como TELNET y FTP, usan TCP. [14]

La arquitectura de comunicaciones TCP/IP se fundamenta en una técnica de

estructuración de cinco niveles de comunicaciones. En la pila de protocolos TCP/IP, TCP es la capa intermedia entre el protocolo de internet (IP) y la aplicación.

Figura 1 Niveles y unidades de datos de protocolo TCP/IP

A continuación se describen las funciones de las capas del modelo de comunicación TCP/IP que están más directamente relacionadas con el segmento TCP y los datagramas UDP.[14]

Nivel de Aplicación: Es el nivel más alto de la arquitectura TCP/IP. En este nivel se

ubican las entidades de software , programas , protocolos o servicios con los que interactúa directamente el usuario. Las unidades de datos manejadas por cualquier entidad del nivel de aplicación se denominan mensajes , estos constan de una cabecera de información de control propia de la aplicación correspondiente y datos de usuario.

Nivel de Transporte: Es el nivel responsable del transporte de los mensajes entre entidades del nivel de aplicación. En este nivel se sitúan dos protocolos ,TCP (Transport Control Protocol) y UDP (User Datagram Protocol). En ellos la unidad de datos resultante se denomina segmento TCP para el caso del protocolo TCP y datagrama UDP en el caso del protocolo UDP.



5

En el caso del protocolo TCP el servicio ofrecido es orientado a conexión, es decir se establece una conexión extremo a extremo entre dos entidades TCP por la cual fluyen de manera ordenada los segmentos de información. TCP en el nivel de transporte se encarga de la fiabilidad de la comunicación extremo a extremo, independientemente de la tecnología, topología, número y tipo de redes que hayan intervenido.

En el caso del Protocolo UDP el servicio ofrecido por el nivel de transporte es no

orientado a conexión en este caso no se establece una conexión extremo a extremo entre las dos entidades UDP. Por consecuencia, cada datagrama UDP se trata como una unidad independiente y se envía aisladamente de las demás. Por tanto no se tiene control de errores ni de flujo. Esto quiere decir, que los datagramas UDP pueden no llegar y en el caso de que lleguen a su destino, seria de forma desordenada o duplicada.

Nivel de Internet o de Red: Es el nivel responsable del encaminamiento de los

segmentos TCP y datagramas UDP del nivel de transporte. Fundamentalmente, aquí se ejecuta una entidad o protocolo que se denomina IP (Internet Protocol). Este nivel acepta segmentos TCP o datagramas UDP del nivel de transporte y les añade una cabecera. A la unidad de datos resultante se la denomina datagrama IP.

La Figura2 muestra dos sistemas finales de usuario que se conectan a una misma

red. El principio de estructuración en niveles esta diseñado de tal manera que la entidad de software del nivel “n” en el destino reciba exactamente la misma unidad de datos enviada por la entidad de software del nivel “n” en el origen.

Figura 2 Comunicación entre niveles de comunicación contiguos



6

TCP utiliza el principio de puerto para realizar múltiplexión. Cada extremo de una conexión TCP tiene un conector que puede identificarse mediante los tres parámetros siguientes <TCP, dirección IP address, número de puerto>. Si dos procesos se están comunicando sobre TCP, tendrán una conexión lógica identificable por medio de los dos conectores implicados, es decir, con la combinación <TCP, dirección IP local, puerto local, dirección IP remota, puerto remoto>. En la figura3 se muestran los procesos X y Y,, los cuales se comunican sobre una conexión TCP que emplea datagramas IP.

Figura 3 Conexión TCP

1.1 Protocolo TCP

La importancia de simular y emular el comportamiento de TCP (Transport Control Protocol) es debido a que este protocolo es el responsable del manejo de más del 90% del tráfico que circula por el internet. TCP da soporte a muchas de las aplicaciones más populares de Internet, incluidas HTTP, SMTP y SSH.



7

1.1.1 Evitación de congestión en TCP

Las aplicaciones necesitan que la comunicación sea fiable y, dado que la capa IP aporta un servicio de datagramas no fiable (sin confirmación), TCP añade las funciones necesarias para prestar un servicio que permita que la comunicación entre dos sistemas se efectúe: libre de errores, sin pérdidas y con seguridad. Para poder implementar estas funciones, TCP cumple objetivos específicos como lo son;

· Adaptar la velocidad de transmisión de paquetes al ancho de banda disponible · Evitar la congestión de la red · Crear enlaces confiables para la retransmisión de los paquetes perdidos

El parámetro mas importante en el que TCP se basa para asegurar que la transmisión de paquetes se efectué exitosamente es el llamado ventana de congestión, esta es la responsable de regular la frecuencia con que se emiten los paquetes, pues obliga a la fuente a detener la transmisión hasta que lleguen los primeros paquetes a su destino, evitando así congestión en la red.

Un aspecto fundamental para lograr esto es el uso de acuses de recibo (AcK’s) cuyos objetivos son:

· Regular la velocidad de transmisión de TCP (Los paquetes se transmiten solo cuando otros han dejado la red)

· Solicitar a la fuente la transmisión de los paquetes que no alcanzaron su destino.

TCP usa una serie de mecanismos para conseguir un alto rendimiento y evitar la congestión de la red (la idea es enviar tan rápido como el receptor pueda recibir).

Actualmente se utiliza una ventana de congestión dinámica, el estado de esta varía dependiendo el estado de la red. Cuando la ventana es pequeña, puede crecer rápidamente y cuando llega a un valor grande solo crece lentamente. Si se detecta congestión, el tamaño de la ventana decrece rápidamente. Este tipo de mecanismo permite resolver la congestión rápidamente y permite emplear eficientemente el ancho de banda de la red.

Algunas variantes de TCP para el control de la ventana son:

· Tahoe; Cuando una perdida es registrada, la ventana se reduce al valor de 1 y comienza una fase de arranque lento. Implica una reducción drástica del tamaño de la ventana y por tanto de la velocidad de transmisión.[10]

· Reno o New Reno; La ventana decrece a 1 únicamente si la perdida es detectada cuando se ha excedido el tiempo de entrega de Ack’s. Cuando la pérdida es detectada por AcKs repetidos, la ventana de congestión decrece a la mitad, se permanece en fase de evitación de congestión. .[10]



8

1.1.2 Control de flujo

Utilizando control de flujo el receptor puede retrasar la respuesta a un paquete con un reconocimiento, conociendo los buffers libres de los que dispone y el tamaño de la ventana de comunicación.

La entidad TCP receptora, al enviar un ACK al emisor, indica también el número de

bytes que puede recibir, sin que se produzca sobrecarga y desbordamiento de sus buffers internos. Este valor se envía en el ACK en la forma del número de secuencia más elevado que se puede recibir sin problemas. Como TCP proporciona una conexión con un flujo de bytes, los números de secuencia se asignan a cada byte del canal. TCP divide el flujo de bytes en segmentos. [ ]

Figura 4 Buffers TCP de envió y recepción En la figura5 se muestra como se divide el flujo de bytes de un archivo en segmentos

TCP.

Figura 5 Segmento TCP El principio de la ventana se aplica a nivel de bytes; es decir, los segmentos enviados y

los ACKs recibidos llevarán números de secuencia de forma que el tamaño de la ventana se exprese con un número de bytes, en vez del de paquete.

El tamaño de la ventana lo determina el receptor, cuando se establece la conexión, y puede variar durante la transmisión de datos. Cada ACK incluirá el tamaño de la ventana que acepta el receptor en ese momento. [5 ]



9

El flujo de datos del emisor se puede ver en la figura 6 en la cual el tamaño de la ventana se expresa en bytes.

Figura 6 Control de flujo en TCP

Donde:

A; Bytes transmitidos que han sido reconocidos.

B; Bytes enviados pero no reconocidos. C; Bytes que se pueden enviar sin esperar ningún tipo de reconocimiento. D; Bytes que no se pueden enviar aún.

TCP agrupa los bytes en segmentos, y un segmento TCP sólo lleva el número de secuencia del primer byte.

Figura7 Formato de segmento en TCP



10

Donde: Source Port : El número de puerto de 16 bits del emisor, que el receptor usa para responder. Destination Port : El número de puerto de 16 bits del receptor. Sequence Number: El número de secuencia del primer byte de datos del segmento. Si el byte de control SYN está a 1, el número de secuencia es el inicial(n) y el primer byte de datos será el n+1. Acknowledgment Number :Si el bit de control ACK está a 1, este campo contiene el valor del siguiente número de secuencia que se espera recibir. Data Offset :El número de palabras de 32 bits de la cabecera TCP. Indica dónde empiezan los datos. Reserved :Seis bits reservados para su uso futuro; deben ser cero. URG : Indica que el campo "urgent pointer" es significativo en el segmento. ACK : Indica que el campo de reconocimiento es significativo en el segmento. PSH :Función "Push". RST :Resetea la conexión. SYN :Sincroniza los números de secuencia. FIN :No hay más datos del emisor. Window :Usado en segmentos ACK. Especifica el número de bytes de datos que comienzan con el byte indicado en el campo número de reconocimiento que el receptor esta dispuesto a aceptar. Checksum : El complemento a uno de 16 bits de la suma de los complementos a uno de todas las palabras de 16 bits de la pseudocabecera, la cabecera TCP y los datos TCP. Al computar el checksum, el mismo campo checksum se considera cero.

En la figura 8 se muestra la utilización de la ventana para el control de flujo en TCP , el

escenario mostrado es la retransmisión de un segmento debido a la perdida de un Ack , dado que el timeout para el Ack en el emisor espiro .

El primer segmento que envía el equipo A tiene un numero de secuencia 92 y 8bits de

datos el segundo segmento que debió haber mandado (indicado por el Ack) correspondía a un numero de secuencia 100 y 20 bits de datos , debido a la perdida del Ack , se reenvía el primer segmento.

Figura 8 Retransmisión debido a un Ack perdido



11

1.1.3 Control de errores

Durante la etapa de transferencia de datos, algunos mecanismos determinan la fiabilidad y robustez del protocolo. Destacan el número de secuencia para ordenar los segmentos TCP recibidos y detectar paquetes duplicados, checksums para detectar errores, asentimientos y temporizadores para detectar pérdidas y retrasos. Durante el establecimiento de conexión TCP, los números iniciales de secuencia son intercambiados entre las dos entidades TCP. Estos números de secuencia son usados para identificar los datos dentro del flujo de bytes y poder identificar los bytes de los datos de la aplicación. Todo segmento TCP incluye dos tipos de número de secuencia (número de secuencia y número de secuencia receptor).

Es determinante el uso de números de secuencia y asentimiento en TCP dado que con estos parámetros se puede pasar los segmentos recibidos en el orden correcto dentro del flujo de bytes a la aplicación receptora.

l Numero de secuencia: Utilizado cuando un emisor TCP se refiere a su propio número de secuencia.

l Numero de asentimiento: Se refiere al número de secuencia del receptor.

Los números de secuencia son de 32 bits (sin signo), que vuelve a cero tras el siguiente byte después del 232-1. Para asegurar la fiabilidad del protocolo, TCP hace uso del asentimiento selectivo (SACK, Selective Acknowledgement) el cual permite a un receptor TCP ratificar los datos que se han recibido de tal modo que el remitente solo retransmite los segmentos de datos que hacen faltan..

Para poder tener un control sobre los errores en TCP se hace uso de un checksum de 16 bits. El emisor calcula un checksum consistente en el complemento a uno de la suma en complemento a uno del contenido de la cabecera y datos del segmento TCP y se incluye en la transmisión del segmento. Se usa la suma en complemento a uno ya que el acarreo final puede ser calculado en cualquier múltiplo de su tamaño (16-bit, 32-bit, 64-bit...) obteniendo como salida el mismo resultado.

En el receptor TCP se guarda el valor del checksum recibido y se recalcula el

checksum sobre las cabeceras y datos recibidos. Se calcula la suma en complemento a uno con el checksum incluido, y el resultado debe ser igual a 0, Si se obtiene este resultado entonces se asume que el segmento ha llegado intacto y sin errores.


http://es.wikipedia.org/wiki/Complemento_a_uno

http://es.wikipedia.org/w/index.php?title=Suma_en_complemento_a_uno&action=edit&redlink=1




12

1. 2 Fundamentos de NS-2 NS fue desarrollado en UC Berkele y esta escrito en lenguaje C++ y Otcl. La versión

NS-2 es orientada a objetos, se basa en la simulación de eventos discretos. Con NS se

puede simular redes LAN , redes WAN y variedad de redes IP.

1.2.1 Manejo de eventos con C++

NS-2 es un simulador basado en eventos discretos donde el avance en la

ejecución de la simulación depende del tiempo asignado para cada evento, el manejo de

eventos en NS-2 se realiza mediante el lenguaje C++. En este lenguaje un evento es un

objeto dentro de una jerarquía de clase compilador. Con lo que tenemos una identificación y

comportamiento único, un tiempo de duración previsto y un apuntador al objeto (evento), que

permite el manejo del mismo. Esta caracterización de los eventos resulta particularmente útil

para una definición y operación detallada de protocolos, así como en la reducción en el

tiempo de procesamiento del evento. En cuanto a la definición de la topología propia de la

red, los protocolos y aplicaciones específicos que deseamos simular, (cuyo comportamiento

esta definido dentro de la clase compilador), y la forma en que deseamos obtener la salida

del simulador.

1.2.2 Lenguaje interprete TCL

NS-2 emplea la clase interprete OTcl, (una extensión orientada a objetos del lenguaje de

interprete Tcl), OTcl hace uso de los objetos compilados en C++ , a través de TclCL (un

lenguaje de interprete visual), creando el enlace para asignar al objeto en C++ su

correspondiente en OTcl.



13

1.3 Simulación con NS-2

Con NS se pueden implementar protocolos de red como TCP y UPD, el

comportamiento de fuente de tráfico como FTP, Telnet, Web, CBR y VBR . Mecanismos de

gestión de colas como Drop Tail, RED y CBQ.

1.3.1 Estructura del simulador

Para utilizar NS se requiere de un programa (script) en lenguaje Otcl en el cual el

usuario inicia un evento de programación, configura y gestiona la red a simular. La topología

de la red se establece utilizando la red de objetos. Un punto importante es indicar a las

fuentes de tráfico cuando deben iniciar y detener la transmisión de paquetes,

En la figura 9 se muestra la estructura de la que consta una simulación utilizando NS

partiendo desde la creación del escript en Otcl hasta la forma en que se pueden desplegar

los resultados, utilizando para este fin el NAM (análisis grafico) o el análisis de las trazas del

archivo de salida.

Figura 9 Estructura de simulador NS



14

1.3.2 Metodología

La metodología que siguen los modelos de simulación con NS es la siguiente: tratamos de crear objetos (nodos, enlaces, protocolos, fuentes de tráfico/aplicaciones) que modelan los elementos correspondientes del sistema real que se quiere estudiar. Al mismo tiempo también se planifican los eventos significativos en el tiempo simulado.

Con el fin de ilustrar este proceso, se empleara el modelo que se propone a continuación:

Figura 10 Escenario de simulación El sistema consta de 5 nodos y 2 agentes generadores de trafico: un agente UDP (con

un generador de trafico CBR) y un agente TCP (con un generador de trafico FTP). Asociados a los generadores de trafico, se tienen otros 2 agentes con la f unción de recibir ese trafico (sumideros). Los cuatro nodos están unidos entre si por enlaces duplex, (adicionalmente la figura# muestra el ancho de banda de los enlaces y el retardo de propagación asociado).

El script TCL que modela la red propuesta se enlista a continuación, (se realizan comentarios con la finalidad de comprender la estructura del script de simulación). El intervalo de ejecución de la simulación será de 20 segundos, obteniéndose como resultado de la misma 2 archivos, el out.tr y el out.nam.

####Inicio del script####

#Comando de inicialización: crea el objeto simulador,(programador de eventos). set ns [new Simulator] #Creación de los archivos de salida de la simulación, (archivos de traza).

set tf [open out.tr w] $ns trace-all $tf set nf [open out.nam w] $ns namtrace-all $nf

###Definición de la red### #Creación de los nodos



15

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

#Con cada línea se crea un nodo apuntado por la variable nX, i.e. cada vez que #en la simulación se haga referencia al nodo se indicara como $nX

#Creación de los enlaces #DropTail significa que las colas asociadas son FIFO. Politica de servicio FiFo(Primero en entrar primero en salir) $ns duplex-link $n0 $n2 5Mb 1ms DropTail $ns duplex-link $n1 $n2 5Mb 1ms DropTail $ns duplex-link $n2 $n3 2Mb 5ms DropTail $ns duplex-link $n3 $n4 2Mb 5ms DropTail

#Los nodos $nX y $nY son conectados mediante un enlace bidireccional, con una #capacidad de M Mbits/sec y un retardo de propagación de N ms. #Para definir un enlace unidireccional en lugar de uno bidireccional se remplaza #la sentencia "duplex-link" por "simplex-link".

#Creamos los agentes asociados a la fuente CBR

set udp [new Agent/UDP] ;# Nuevo agente UDP $udp set fid_ 2 ;# Para marcar el flujo UDP como "2" $ns color 2 Red ;# Presenta el flujo marcado como "2" en rojo $ns attach-agent $n0 $udp ;# Lo ubicamos en n0

set cbr [new Application/Traffic/CBR] ;# Nueva fuente CBR $cbr attach-agent $udp ;# La unimos a udp0 # Definimos los paquetes generados por la fuente como de 1000 octetos. $cbr set packetSize_ 1000 # Definimos que el intervalo entre paquetes de la fuente sea de 5 ms. $cbr set interval_ 0.005

set null [new Agent/Null] ;# Sumidero de tráfico $ns attach-agent $n4 $null ;# Lo ubicamos en n4 # Asociamos el agente UDP con el sumidero de tráfico. $ns connect $udp $null

#Planificamos el comienzo de la generación de tráfico CBR para t=1s. $ns at 1.0 "$cbr start"

#Ahora creamos un agente FTP sobre TCP

set tcp [new Agent/TCP] ;# Nuevo agente TCP $tcp set fid_ 1 ;# Marcamos el flujo TCP como "1" $ns color 1 Blue ;# Presenta el flujo marcado como "1" en azul # Definimos que el tamaño de los paquetes del flujo TCP sea de 600. $tcp set packetSize_ 600



16

$ns attach-agent $n1 $tcp ;#Lo ubicamos en n1. set sink [new Agent/TCPSink] ;# Creamos el "sumidero" TCP. $ns attach-agent $n4 $sink ;# Lo ubicamos en n4. $ns connect $tcp $sink ;#Conectamos los dos extremos TCP.

set ftp [new Application/FTP] ;# Nueva aplicación FTP # Definimos el número máximo de paquetes que generaría la fuente FTP $ftp set maxpkts_ 10000000 $ftp attach-agent $tcp ;# La asociamos al agente TCP. #Planificamos el comienzo de la generación de tráfico FTP para t= 1,5s. $ns at 1.5 "$ftp start" # Planificamos el final de la generación de tráfico FTP para t= 18 s. $ns at 18.0 "$ftp stop"

#Planificamos el final de la simulación para t=20s. #"finish" es un procedimiento que contiene todas las #instrucciones que se realizan al finalizar la simulacion. $ns at 20.0 "finish"

#Definimos aquí el procedimiento "finish" #que no tiene parámetros,(se indica con { }).

proc finish { } {

# si se usan variables externas a un # procedimiento, se indican de esta forma. global ns tf nf $ns flush-trace close $tf close $nf exec nam.out.nam & #ejecución del comando unix nam mediante la instrucción "exec", #para la visualización del resultado de la simulación exit 0 }

#Para acabar, iniciamos el programador de eventos

$ns run #Ejecución de la simulación

###Fin del archivo### Los archivos generados por las trazas tipo nam (network animator), se pasan a un programa

de animación que permite representar de forma gráfica lo que ha ocurrido en la simulación. Desde la simulación se activan con la instrucción $ns namtrace-all $fichero.

El programa de animación tiene controles muy intuitivos que permiten tratar la traza de animación como si fuera una "clip" de audio o vídeo, permitiendo avanzar, retroceder, o reproducir. La velocidad de reproducción también se puede modificar.

En cuanto a las trazas tipo trace (que aparecen en el fichero out.tr), se trata de representar los

eventos que han ocurrido en la simulación. Con la instrucción $ns trace-all $tf se activan las trazas



17

de todos los elementos del simulador. Es posible, con órdenes más específicas, indicar que solamente se trace parte de los eventos. Un ejemplo seria el ver que ocurren en el enlace entre los nodos 0 y 1. El formato del archivo de traza tiene el siguiente aspecto, (Otra forma de obtener información de lo simulado)

La primera columna contiene el tipo de evento: + significa que un paquete se mete en una cola, - significa que un paquete sale de una cola, y r significa que un paquete se recibe en un nodo. Otro posible evento (no mostrado) es d, que significa que un paquete se descarta.

La siguiente columna muestra el instante de tiempo simulado en el que el evento ocurre. Las

dos siguientes columnas muestran entre que par de nodos está sucediendo la traza. Por ejemplo, en la primera línea, la traza se refiere a un evento que ocurre entre los nodos 0 y 2. La siguiente columna contiene una descripción (cbr en este caso) para el tipo de paquete trazado. La siguiente es el tamaño,(en Bytes), del paquete trazado.

A continuación viene un campo dedicado a flags, que pueden indicar notificaciones relacionadas con la congestión, o bien con la prioridad de los paquetes, etc., (en el archivo mostrado no hay flags activados). A continuación viene el identificador de flujo, con el significado que se le da en IPv6,(Protocolo de Internet versión 6), aunque dichos identificadores de flujo se pueden definir en NS para flujos que no sean IPv6.

Los dos campos siguientes muestran los identificadores de los nodos fuente y destino (0.0 y 0.3 en el caso de la traza mostrada). El penúltimo campo es un número de secuencia, solamente usado para paquetes generados por fuentes que requieran que ese número de secuencia vaya incrementándose de paquete a paquete, y el último campo es un identificador de paquete, que es único para cada paquete creado en una simulación NS.



18

2 Emulación con NS-2

La simulación en tiempo real, (o emulación), es una técnica donde los objetos simulador reproducen un comportamiento en el tiempo similar o igual a el comportamiento en tiempo de las entidades simuladas. Esta técnica es empleada para diseñar el ambiente de aplicación deseado durante el proceso de desarrollo de la aplicación .La meta principal es que un aplicación pueda trabajar con el entorno simulado durante la fase de desarrollo de la misma forma que lo efectuaría en un ambien te rea l y que la misma pueda ser implementada posteriormente sin modificaciones.

La versión de NS-2 utilizada es la 2.33 , originalmente la opción de emulación con NS-2 estaba basada en free BSD .CCoonn ee ll oobb jjee ttii vvoo ddee eemmuullaarr ttrraa ffiiccoo uuttii llii zzaannddoo NNss--22 ssoobb rree ee ll ssiiss tteemmaa ooppee rraa ttii vvoo LLii nnuuxx ssee uuttii llii zzaa uunn ppaa rrcchhee ((nnss22eemmuullaa ttiioonn..ddii ff ff ))[16] ccoonn ee ll ccuuaa ll ssee aaddqquuii eerree llaa ccaa rraacc ttee rr ííss ttiiccaa ddee eemmuullaacciióónn uuttii llii zzaannddoo mmaaqquuii nnaass vvii rr tt uuaa lleess ((UUMMLL)) ..SSee ddeecciiddii óó hhaacceerr uussoo ddee llaa ddii ss ttrrii bbuuccii óónn ddee LLii nnuuxx UUBBUUNNTTUU ,, ddaaddoo qquuee eell tt rraabbaa jjoo ssoobb rree ee ll qquuee bbaassaammooss nnuueess ttrraa ii nnvveess ttiiggaacciióónn ssee ddeessaa rrrroo ll llaa eenn uunn ssiiss tteemmaa DDEEBB IIAA NN..

MM aaqquuiinnaa VVii rrttuuaa ll ((UUMMLL )):: SSooffttww aarree qquuee ccrreeaa uunnaa ccaappaa ddee aabbsstt rraaccccii óónn ,, oo ffrreecc iieennddoo uunn eeqquu ii ppoo

ddii ffee rreenntt ee aa llaa mm aaqquu ii nnaa oorr iigg iinnaa ll ((ddaannddoo aa ll ss iisstt eemm aa ooppee rraa ttii vvoo ddeell eeqquu iippoo aannff iitt rrii óónn llaa ppee rrcceeppccii óónn ddee uunnaa mm aaqquuii nnaa ff ííss iiccaa)) .. SSee ccoomm ppoorrtt aa ccoomm oo uunnaa eenn ttii ddaadd sseeppaarraaddaa ddeell hhoosstt .. LLaa mm aaqquuii nnaa vv iirrtt uuaa ll ppuueeddee iimm pp ll eemm eenn ttaarr ddii vveerrssooss dd iissppoossii ttii vvooss vvii rrtt uuaa lleess (( ii.. ee.. dd iissccoo,, mm eemm oorrii aa,, pp rroocc eessaaddoorr ,, dd iissppoossiitt ii vvooss ddee rr eedd ,, eett ’’cc)) dd iisstt iinn ttooss ee ii nnddeeppeenndd iieenntt eess aa ll ooss eexxiisstt eenntt eess eenn ll aa pp llaa ttaa ffoo rrmm aa rr eeaa ll,, yy ee jj eeccuutt aarr ccuuaa llqquuii eerr aappll iiccaacc iióónn ddiiss ppoonnii bb llee ppaa rraa uunn nnúúccll eeoo ll ii nnuuxx,, aadd iicc ii oonnaallmm eenn ttee ddaaddoo eell aa lltt oo ggrraaddoo ddee aaiiss llaamm ii eenntt oo ii nnhheerreenn ttee aa ll pp rrooyyeecc ttoo UUsseerr MMooddee LLii nnuuxx,, ssee oobbtt iieennee llaa vveenntt aajj aa ddee ppooddeerr ddeessccaarrtt aarr ttooddoo uunn ss iisstteemm aa,, ddeessaa rrrroo ll lloo ee iimm ppll eemm eennttaacc iióónn eenn llaa ccoonnff ii gguu rraaccii óónn ddee ccaaddaa UUMMLL ,, ss ii nn pprreesseenntt aarrssee llooss iinneevviitt aabb ll eess ccoonn ffll iicctt ooss oo rr eeqquuee rriimm iieenntt ooss ddee aa jjuusstt ee eenn llaa ccoonnff ii gguurraaccii óónn nneecceessaarr ii ooss ppaa rraa rreegg rreess aarr nnuueesstt rraa rreedd aa uunn eessttaaddoo ooppee rraa ttii vvoo eessttaannddoo eenn uunn eenntt oorrnnoo rr eeaa ll..

** GGuueesstt :: SS iisstt eemm aa OO ppee rraa ttii vvoo ddeenntt rroo ddee llaa mm aaqquu iinnaa vv iirr ttuuaall (( ppeerrmm ii ttee qquuee llaa

mm aaqquuii nnaa vvii rrtt uuaa ll pprreesseenntt ee uunn ccoomm ppoorrtt aamm ii eenn ttoo ss iimm iill aarr aa ll qquuee ss ee ttii eennee ss oobb rree hhaarrddwwaarree rreeaall )) ..

** HHooss tt:: SS iisstteemm aa OOppeerraatt ii vvoo ddeenn ttrr oo ddee uunnaa mm aaqquu iinnaa ff iiss iiccaa ,, ((rreeaa ll))..

FF iigguu rraa 1111 EEss ttrruucctt uurraa dd ee MMaaqq uuiinnaa vv iirr ttuuaa ll ee nn ee ll hhoo sstt

UUsseerr MMooddee LL iinnuuxx ((UUMMLL)) ;; EEss uunn nnúúcc lleeoo LL iinnuuxx ll ii ggee rraamm eenntt ee mm oodd iiff iiccaaddoo ppaarraa eejj eeccuutt aarrss ee ccoomm oo uunn

pprroocc eessoo ddee uussuuaa rrii oo ssoobb rree oottrr oo nnúúccll eeoo LL ii nnuuxx.. LLooss dd iissppoossiitt ii vvooss ddee ll gguueesstt nnoo eesstt aann vvii rrtt uuaa lliizz aaddooss.. PPoorr ttaanntt oo eenn eell gguueess tt ssee ppee rrccii bbee ee ll hhaarrddww aarree rreeaall ..

NNuueesstt rroo pprr iimm eerr oobb jj eett ii vvoo aann tteess ddee uutt ii ll iizz aarr eell eemm uu llaaddoo rr ppaarraa ttrr aannss ppoo rrttaa rr tt rraa ffiicc oo rr eeaa ll eess ccoomm pprroobbaa rr ll aa ccoomm uunn iiccaarroonn eenn ttrr ee ddooss UUMMLL mm eedd iiaanntt ee ll aa uu tt ii ll iizzaacc iióónn ddee uunn ppuueenn ttee (( bbrr00)) yyaa qquuee eessttaass ddeebbeenn eessttaarr ccoonnff iigguurraaddaass yy ttrr aabbaa jjaannddoo cc oorrrr eeccttaamm eenntt ee yyaa qquuee ppoossttee rrii oorrmm eenn ttee ss oonn uutt ii ll iizzaaddaass ppaarraa tt rraass ppoorr ttaarr tt rraa ffiicc oo ppee rroo yyaa nnoo uutt ii ll iizzaannddoo ee ll ppuueenn ttee (( bbrr00)) ss iinnoo ee ll eemm uu llaaddoorr ((NNss)) ..



19

22..11 EEsstt rruuccttuurraa ddeell eemmuullaaddoorr

FFiigguu rraa 1122 EEmmuullaaccii óónn eenn NNSS --22 uuttii llii zzaannddoo UUMMLL

Para la implementación de la emulacion en un equipo basado en la arquitectura AMD64 bajo el sistema operativo ubuntu 8.04, se realizaron los siguientes cambios en las instrucciones generales contenidos en la guia HOWTO : WIRELESS NETWORK EMULATION USING NS2 AND USER-MODE-LINUX (UML)[3].

l User_Mode_Linux kernel : linux-2.6.24-x86_64

l Filesystem : FedoraCore6-AMD64-root_fs

El mecanismo de transporte para UML empleado es el dispositivo virtual de Ethernet

(TAP), para dispositivos de red virtuales punto a punto (TUN). Se actualizo la configuracion del dispositivo mediante la herramienta tunctl[18] descargando el paquete uml-utilities, que contiene dicha herramienta para sistemas DEBIAN, a fin de configurar los dispositivos TUN/TAP mediante tunctl. La diferencia entre los dispositivos TUN y TAP es que TUN trabaja con tramas IP mientras que TAP trabaja con tramas ethernet.

El principal objetivo de los dispositivos TUN/TAP es trabajar mediante la tecnica

tunneling. Esta tecnica consiste en encapsular un protocolo de red sobre otro, creando un túnel dentro de una red de comunicaciones. El uso de esta técnica persigue diferentes objetivos, como por ejemplo la comunicación de islas en escenarios multicast y la redirección de tráfico.



20

2.2 Comunicación entre UML y Host vía puente

Para la puesta a punto de la red virtual se continuo con la creación de las UML remplazando las siguientes instrucciones dentro del documento: WIRELESS NETWORK

EMULATION USING NS2 AND USER-MODE-LINUX (UML) [3]

.

Para la terminal 1:

./linux ubd0=cow_uml0,root_fs_slack8.1 eth0=tuntap,tap0 por esta otra:

./linux ubd0=cow_uml0,FedoraCore6-AMD64-root_fs eth0=tuntap,tap0

Para la terminal 2:

./linux ubd0=cow_uml1,root_fs_slack8.1 eth0=tuntap,tap1 por esta otra:

./linux ubd0=cow_uml1,FedoraCore6-AMD64-root_fs eth0=tuntap,tap1

Dentro de ambas maquinas virtuales se define como login: root y se deja vació el campo de password: , se continua con la ejecución del script hasta el paso 3 dentro del documento WIRELESS

NETWORK EMULATION USING NS2 AND USER-MODE-LINUX (UML), para tener privilegios de usuario dentro de la maquina virtual, tecleamos su chmod 666 /dev/net/tun

LLooss ssiigguuiieenntteess ccoommaannddooss ii nniicciiaalliizzaann ddooss ddiissppoossii ttiivvooss ddee EEtthheerrnneett TTAAPP..

[root@host]# su [root@host]# ./ns2emulation/virtnet init 2 [root@host]# exit

Se crean dos UML utilizando terminales diferentes

En la terminal1 se teclean los siguientes comandos: [umluser@host]$ ./linux ubd0=cow_uml0,root_fs_slack8.1 eth0=tuntap,tap0 root@darkstar:~# hostname uml0 root@uml0:~# ifconfig eth0 10.0.0.2 up root@uml0:~# ping 10.0.0.2 PING 10.0.0.2 (10.0.0.2): 56 octets data 64 octets from 10.0.0.2: icmp_seq=0 ttl=64 time=10.9 ms 64 octets from 10.0.0.2: icmp_seq=1 ttl=64 time=4.8 ms 64 octets from 10.0.0.2: icmp_seq=2 ttl=64 time=4.9 ms 64 octets from 10.0.0.2: icmp_seq=3 tt=64 time=4.4 ms --- 10.0.0.2 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round -trip min/avg/max = 4.4/6.2/10.9 ms

Como puede verse lo ultimo que se hace es ejecutar un ping a la misma maquina para de esta forma comprobar que a sido creada y configurada correctamente.



21

Lo mismo se hace para la terminal 2

Se teclean los comandos:

[umluser@host]$ ./linux ubd0=cow_uml1,root_fs_slack8.1 eth0=tuntap,tap1 root@darkstar:~# hostname uml1 root@uml1:~# ifconfig eth0 10.0.0.3 up root@uml1:~# ping 10.0.0.PING 10.0.0.3 (10.0.0.3): 56 octets data 64 octets from 10.0.0.3: icmp_seq=0 ttl=64 time=10.9 ms 64 octets from 10.0.0.3: icmp_seq=1 ttl=64 time=4.8 ms 64 octets from 10.0.0.3: icmp_seq=2 ttl=64 time=4.9 ms 64 octets from 10.0.0.3: icmp_seq=3 tt=64 time=4.4 ms --- 10.0.0.3 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round -trip min/avg/max = 4.4/6.2/10.9 ms Mediante la utilidad ping se comprueba su correcto funcionamiento. Ahora lo que

hace falta es dar de alta el puente (br0) en el host para poder tener comunicacion

entre las dos UML y el host. Para comprobar la comunicación utilizando puente entre el Host y las UML; Se teclean los siguientes comandos desde la terminal en el host. [root@host:~]# brctl addbr br0 [root@host:~]# brctl stp br0 off PARA TERMINAL 1 [root@host:~]# brctl addif br0 TAP 0 PARA TERMINAL 2 [root@host:~]# brctl addif br0 TAP 1 [root@host:~]# groupadd tun [root@host:~]# useradd root -G tun [root@host:~]# chown :tun /dev/net/tun [root@host:~]# chmod g+rw /dev/net/tun [root@host:~]# ifconfig br0 10.0.0.1 netmask 255.0.0.0 \> broadcast 10.255.255.255 [root@host:~]# ifconfig

Están creados el puente br0 y los agentes TAP , por tanto la comunicación entre el host y

las UML existe . Para comprovar esto se hace un ping del host a la uml0 (ping 10.0.0.2) o

de la uml1 al host (ping 10.0.0.1) . Hasta este punto se a cumplido el primer objetivo de la

emulación.



22

22..33 CCoommuunniiccaacciióónn uuttiillii zzaannddoo eemmuullaaddoorr

AAhhoorraa ssee uuttii llii zzaa llaa ccaarraaccttee rr ííss ttiiccaa ddee eemmuullaacciióónn qquuee pprroovveeee NNss--22 ppaarraa ccoommuunniiccaarr llaass UUMMLL ccoonn eell hhoosstt ..

IInnssttaallaannddoo ppaarrcchhee ddee eemmuullaacciioonn

[umluser@host]$ cd ns-2_directory

[umluser@host]$ patch -p0 < ~/ns2uml/ns2emulation/ns2emulation.diff

[umluser@host]$ ./configure

[umluser@host]$ make clean

[umluser@host]$ make

[umluser@host]$ su

[root@host:~]# ln -s `pwd`/shmlog /usr/bin/shmlog

Con lo que fue posible realizar la compilación y obtener los ejecutables ns y nse

Ahora para comprobar la comunicación entre las UML y host utilizando el emulador se recurrió al escript de ejemplo (ns2emulation.tcl) , modificando parámetros en la creación de los agentes TAP , ya que se requieren 4 agentes TAP. Los siguientes son comandos utilizados en el host [root@host]#su [root@host]#./ns2emulation/virtnet init4 [root@host]# exit Entonces se ejecuta el emulador con el script de ejemplo (ns2emulation.tcl ) Los siguientes son comandos utilizados en el host [root@host]# cd ~umluser/ns2uml/ns2emulation [root@host]# /path_to_ns-2_directory/nse ns2emulation.tcl Al momento de la ejecucion se obtienen los siguientes resultados; Using gettimeofday() insdead of the CPU cycle counter to guarantee portability num_nodes is set 4 INITIALIZE THE LIST xListHead install nets into taps... okay El emulador se encuentra trabajando correctamente y se queda funcionando mientras dura el tiempo de emulación en este caso el parámetro es de 100hrs.



23

MMooddiiffiiccaannddoo eell ppaarráámmeettrroo ddee ttiieemmppoo ddee eemmuullaacciioonn aa 6600 sseegg ssee oobbtt iieennee lloo ss iigguuiieennttee;;

Desmarcando comentario en el script ns2emulation.tcl,(linea 29):

##sseett vvaall((ssttiimmee)) 6600..00 ;;## ssiimmuullaattiioonn ttiimmee ,,yy ddeejjaannddoo ccoommoo ccoommeennttaarriioo llaa ssiigguuiieennttee lliinneeaa:: sseett vvaall((ssttiimmee)) 336600000000..00 ;;## ssiimmuullaattiioonn ttiimmee == 110000 hhoouurrss

emir@emir-laptop:/root/ns2uml/ns2emulation$ sudo /home/emir/NS2/ns-2/nse ns2emulation.tcl [sudo] password for emir: Using gettimeofday() insdead of the CPU cycle counter to guarantee portability num_nodes is set 4 INITIALIZE THE LIST xListHead install nets into taps... Okey NS EXITING ...

Hasta este punto se comprueba que la instalación del emulador es correcta y además el ejemplo ns2emulation.tcl se ejecuta ya sin arrojar errores . Es necesario modificar parámetros dentro del script ya que a pesar de que se ejecuta sin errores, dentro de los archivos de salida no se muestran resultados.

Una vez analizada esta problemática se dedujo no se puede tener comunicacion entre las UML mediante el emulador puesto que hace falta mapear los nodos en NS utilizando las direcciones físicas (MAC) de cada UML.

La dirección MAC es un número que sirve como un identificador para un adaptador de red. De esta manera dos tarjetas de red en dos equipos diferentes tienen direcciones MAC diferentes al igual que un adaptador Ethernet y un adaptador inalámbrico en la misma computadora o varias tarjetas de red en un router.

De tal manera que se modifica el script ns2emulation.tcl cambiando el siguiente modulo:

#Tap Agent for each node

Agent/Tap set maxpkt_ 3100

set a1 [new Agent/Tap/Raw "FE:FD:C0:A8:2F:01"]






24

Se cambia por el siguiente;

#Tap Agent for each node

Agent/Tap set maxpkt_ 3100

set a1 [new Agent/Tap/Raw "A6:09:DC:9E:46:D6"]

set a2 [new Agent/Tap/Raw "EE:8A:93:8F:3E:62"]

set a3 [new Agent/Tap/Raw "E2:0F:6A:DD:2F:14"]

set a4 [new Agent/Tap/Raw "FE:27:FE:80:3B:34"]

Ahora ya se consideran las direcciones MAC reales correspondientes a los agentes TAP creados y sirven para identificar los nodos una vez dentro del script, para su posterior asignación en NS mediante direcciones IP.

Ejecutándose nuevamente el script ns2emulation;

root@emir-laptop:~/ns2uml/ns2emulation# /home/emir/NS2/ns-2/nse ns2emulation.tcl

en la terminal del host se obtiene la siguiente salida:

Using gettimeofday() insdead of the CPU cycle counter to guarantee portability

num_nodes is set 4 INITIALIZE THE LIST xListHead install nets into taps... okey channel.cc:sendUp - Calc highestAntennaZ_ and distCST_ highestAntennaZ_ = 1.5, distCST_ = 550.0 SORTING LISTS ...DONE!

De esta manera ahora ya no es necesario el puente (br0) puesto que el trafico de paquetes ahora es transportado mediante la utilización del emulador , de igual manera esto es comprobado aplicando ping's entre las UML y el Host.



25

2.4 Paso de tráfico real sobre el emulador Ns

El escenario utilizado para este fin consta de dos nodos (S-D) en este caso S y D son dos UML , el enlace entre ellas es de un ancho de banda de 1 Mb y con un retardo de propagación de 100ms. El enlace entre ellas es duplex teniendo como tamaño máximo en la fila de espera 10000 paquetes. La fuente generadora de trafico es un agente TCP /NewReno localizada en el nodo S (uml0) se utiliza una aplicación FTP donde el nodo sumidero de trafico es D(uml1) , el tiempo de simulación es de 1000 seg. El escript emutcp.tcl que describe el escenario de se puede consultar a el en la sección 4 escenarios de emulación.

Una de las aproximaciones existentes para determinar el rendimiento de TCP esta definida por la siguiente ecuación, llamada formula de la raíz cuadrada.

Se tiene una conexión TCP NewReno en la cual los paquetes se pierden con probabilidad p. El parámetro RTT lo tomaremos como el tiempo de conexión (tiempo de simulación) ,denotamos por S el tamaño de paquetes TCP en bytes este esta definido en el script. El objetivo de simular este escenario es estudiar el rendimiento de TCP , sobre todo cuando cambiamos la probabilidad de pérdida de paquetes p.

A través de las UML creadas se pasara trafico real utilizando la utilería ping , de este modo tenemos un flujo continuo sin perdidas pasando entre ellas . El escenario consiste en este paso de trafico real ,un modelo de error introducido sobre el enlace donde se implementan la perdida de paquetes a una tasa fija y finalmente un procedimiento de monitoreo del enlace donde estaremos recuperando en sus respectivos archivos de salida , el tiempo de muestreo contra una de cada una de las siguientes posibles variables;

l Tamaño de la fila en bytes

l El tamaño de la fila en paquetes

l El numero de paquetes que han arribado al nodo destino

l El numero de paquetes que han partido del enlace

l El numero de bytes que han llegado al nodo destino

l El numero de bytes que han partido del enlace

l El numero de bytes perdidos



26

3 Escenarios de simulación

ESCENARIO DE UNA SIMULACION EN NS

En este escenario de simulación se tienen 2 fuentes generadoras de trafico (n1,n2) , trafico CBR y FTP respectivamente. Se llevan acabo las tres etapas que debe cumplir una conexión TCP (Establecimiento, transmisión y liberación) , se tienen como sumideros de trafico los nodos (n2,n3) se tiene implementada la política de servicio FIFO (DropTail).

Se observa en la simulación que es importante el como definir la cantidad de paquetes

que puede formar un nodo Buffer) ya que la ventana utilizada es dinámica y esta tiende a crecer exponencialmente y si este parámetro (Buffer en n4) es pequeño es seguro que en pequeños intervalos de tiempo existirá congestión.

Las ventajas que conlleva el utilizar ventana dinámica y no de tamaño fijo es que si se

detecta congestión , el mismo sistema puede resolver esta degradación de servicio con tan solo modificarse el tamaño de la misma , de aquí la importancia de comprender el funcionamiento de la ventana, pues la red tendrá diferentes rendimientos dependiendo la implementación de la misma.



27

ESCENARIO DE SIMULACION NS

En este escenario, se implementa una política de servicio (FIFO) , al principio de la

simulación cualquiera de los nodos generadores de trafico (n0,n1,n2) mandan un paquete

sink de 40 bytes , el receptor (n4) acusa con un sink de 40 bytes (Etapa de establecimiento

de TCP) . El nodo (n3) tiene definido un buffer, 20 paquetes de tamaño. Cuando se excede

esta cantidad se desbordan los paquetes. Un aspecto importante que destaca en esta

simulación es que la congestión se da debido a que el buffer en (n3) es pequeño, en un

principio la ventana crece pues es dinámica y una vez que detecta la congestión decrece el

tamaño de la ventana evitando de esta manera una degradación del servicio y por tanto

manteniendo optimo el funcionamiento de la red.



28

4 Escenarios de emulación

Este escenario crea una red virtual donde a través de NS se hace pasar trafico real entre dos equipos en nuestro caso dos UML . #script ns2emulation.tcl #! /bin/nse # An example script for the usage of ns-2 in emulation mode: # Uses: # 1. Network/Raw agents to access to a network device at level II # 2. Tap/Raw agents to map between real MAC addresses and NS-2 IP addresses # 3. In-memory compression of the trace file to reduce disk write operations during simulation # (currently done via gzip) # Common variables # set scriptname routingdemo set val(chan) Channel/WirelessChannel ;# Channel Type set val(prop) Propagation/TwoRayGround ;# radio-propagation model set val(netif) Phy/WirelessPhy ;# network interface type set val(mac) Mac/802_11 ;# MAC type set val(ifq) Queue/DropTail/PriQueue ;# interface queue type set val(ll) LL ;# link layer type set val(ant) Antenna/OmniAntenna ;# antenna model set val(ifqlen) 50 ;# max packet in ifq set val(x) 800 ;#x range in meters set val(y) 600 ;# y range in meters #set val(rp) AODV ;# routing protocol set val(rp) DumbAgent ;# routing protocol set val(nn) 4 ;# number of mobile nodes #set val(stime) 60.0 ;# simulation time set val(stime) 360000.0 ;# simulation time = 100 hours



29

set ns [new Simulator] $ns use-scheduler RealTime set tracefd [open out.tr w] $ns trace-all $tracefd #set tr0 [new BaseTrace/ShmGZ test.tr.gz 16 400 104857600] set namtrace [open out.nam w] #set namtrace [open "|nam -r 0.1 -" w] $ns namtrace-all-wireless $namtrace $val(x) $val(y) #Procedure needed when running nam in real-time proc NamTime {} { #Send time to nam periodically global ns namtrace set now [$ns now] set next [expr $now + 0.05] puts $namtrace "T -t $now" flush $namtrace $ns at $next "NamTime" } #$ns at 1.0 "NamTime" proc UniformErr {} { set err [new ErrorModel] $err unit packet $err set rate_ 0.01 $err ranvar [new RandomVariable/Uniform] $err drop-target [new Agent/Null] return $err }



30

set topo [new Topography] $topo load_flatgrid $val(x) $val(y) # Create GOD create-god $val(nn) # Create channel set chan_1_ [new $val(chan)] # Configure node parameters $ns node-config -adhocRouting $val(rp) \ -llType $val(ll) \ -macType $val(mac) \ -ifqType $val(ifq) \ -ifqLen $val(ifqlen) \ -antType $val(ant) \ -propType $val(prop) \ -phyType $val(netif) \ -topoInstance $topo \ -agentTrace OFF \ -routerTrace OFF \ -macTrace ON \ -movementTrace OFF \ -channel $chan_1_ \ -IncomingErrProc UniformErr #Procedure to configure an ns-2 node initially proc setup_node {id x y z color} { global ns node_ set node_($id) [$ns node] $node_($id) set X_ $x $node_($id) set Y_ $y $node_($id) set Z_ $z



31

$node_($id) color $color $ns at 0 "$node_($id) setdest $x $y 0" $ns at 0 "$node_($id) color $color" $node_($id) random-motion 0 } setup_node 1 100 300 0 "black" setup_node 2 300 300 0 "green" setup_node 3 500 300 0 "blue" setup_node 4 700 300 0 "cyan" for {set i 1} {$i <= $val(nn)} {incr i} { $ns at 0 "$node_($i) start"; $ns at $val(stime) "$node_($i) reset"; } #Network objects to access the TAP devices at the link layer set raw1 [new Network/Raw] set raw2 [new Network/Raw] set raw3 [new Network/Raw] set raw4 [new Network/Raw] $raw1 open tap0 readwrite $raw2 open tap1 readwrite $raw3 open tap2 readwrite $raw4 open tap3 readwrite



32

#EL siguiente modulo debe ser actualizado en base a la

# dirección MAC asignada una vez que ha sido creada la uml #Tap Agent for each node Agent/Tap set maxpkt_ 3100 #set a1 [new Agent/Tap/Raw "FE:FD:C0:A8:2F:01"] set a1 [new Agent/Tap/Raw "A6:09:DC:9E:46:D6"] #set a2 [new Agent/Tap/Raw "FE:FD:C0:A8:2F:02"] set a2 [new Agent/Tap/Raw "EE:8A:93:8F:3E:62"] #set a3 [new Agent/Tap/Raw "FE:FD:C0:A8:2F:03"] set a3 [new Agent/Tap/Raw "E2:0F:6A:DD:2F:14"] #set a4 [new Agent/Tap/Raw "FE:FD:C0:A8:2F:04"] set a4 [new Agent/Tap/Raw "FE:27:FE:80:3B:34"]

# fin del modúlo . . . puts "install nets into taps..." #Assign network objects to TAP agents $a1 network $raw1 $a2 network $raw2 $a3 network $raw3 $a4 network $raw4 #Assign TAP agents to ns-2 nodes $ns attach-agent $node_(1) $a1 $ns attach-agent $node_(2) $a2 $ns attach-agent $node_(3) $a3 $ns attach-agent $node_(4) $a4 $ns at $val(stime) "stop" $ns at $val(stime) "puts \"NS EXITING ...\" ; $ns halt"



33

proc stop {} { global ns tracefd raw1 raw2 raw3 raw4 $ns flush-trace close $tracefd $raw1 close $raw2 close $raw3 close $raw4 close } puts "okey" $ns run



34

Paso de tráfico real sobre el emulador Ns Escenario de emulación (script emutcp.tcl) # Testing passing real world traffic # through the NS Emulator # Author : M_Diaz, E_Olvera # Date : 14/08/2008 - # Common variables set val(stime) 1000.0 ;# simulation time set ns [new Simulator] $ns use-scheduler RealTime set f [open out.tr w] $ns trace-all $f set nf [open out.nam w] $ns namtrace-all $nf # Create the nodes needed to emulation set node1 [$ns node] set node2 [$ns node]



35

# Setup connections between the nodes #$ns simplex-link $node1 $node2 10Mb 5ms DropTail $ns duplex-link $node1 $node2 1Mb 100ms DropTail #set lan [$ns newLan "$node1 $node2" 0.5Mb 40ms LL Queue/DropTail MAC/802_3 Channel] #Network objects to access the TAP devices at the link layer set raw1 [new Network/Raw] set raw2 [new Network/Raw] $raw1 open tap0 readwrite $raw2 open tap1 readwrite #Tap Agent for each node #Debe ser actualizado en base a la direccion MAC asignada cada vez que se invocan las uml's #Agent/Tap set maxpkt_ 3100 Agent/Tap set maxpkt_ 10000 set a1 [new Agent/Tap/Raw "E6:1C:2B:75:06:71"] set a2 [new Agent/Tap/Raw "52:03:1D:4C:99:6F"]



36

#puts "install nets into taps..." #Assign network objects to TAP agents $a1 network $raw1 $a2 network $raw2 #Assign TAP agents to ns-2 nodes $ns attach-agent $node1 $a1 $ns attach-agent $node2 $a2 # Configure the entry node set tap0 [new Agent/IPTap]; # Create the TCPTap Agent set bpf1 [new Network/Pcap/Live]; # Create the bpf set dev [$bpf1 open readonly br0] $bpf1 filter "src 10.0.0.2 and src port 8191 and dst 10.0.0.3 and dst port 16384" $tap0 network $bpf1; # Connect bpf to TCPTap Agent $ns attach-agent $node1 $tap0; # Attach TCPTap Agent to the node # Configure the exit node set tap1 [new Agent/IPTap]; # Create a TCPTap Agent set ipnet2 [new Network/IP]; # Create a Network agent $ipnet2 open writeonly $tap1 network $ipnet2; # Connect network agent to tap agent $ns attach-agent $node2 $tap1; # Attach agent to the node.



37

# Connect the agents. $ns simplex-connect $tap0 $tap1 # sample the targeted queue every 0.1 sec store the trace in qm.out set qmon [$ns monitor-queue $node1 $node2 [open qm.out w] 0.01] [$ns link $node1 $node2] queue-sample-timeout; # set error model on link n1 to n2. set loss_module [new ErrorModel] $loss_module set rate_ 0.01 $loss_module ranvar [new RandomVariable/Uniform] $loss_module drop-target [new Agent/Null] $ns lossmodel $loss_module $node1 $node2 $ns at $val(stime) "stop" $ns at $val(stime) "puts \"NS EXITING ...\" ; $ns halt"



38

proc stop {} { global ns f nf raw1 raw2 $ns flush-trace close $f close $nf $raw1 close $raw2 close } puts "okey" $ns run



39

5 Resultados

Los siguientes son los resultados de la emulación hecha a la red virtual, en la cual a través de NS se pasa tráfico real sobre nodos, (en esta caso cada nodo corresponde a una UML). Como resultado de la emulación se obtiene un archivo de salida, qm.out, debido a la introducción de un modelo de error, el cual contiene 10 columnas de datos que describen el comportamiento del tráfico en el enlace, estas se describen continuación.

Figura 13 Salidas que contiene el archivo qm.out:

En el modelo de error se establece un porcentaje de perdida de 0.01, p=0.01, y el tiempo de muestreo es de 0.01 seg. La emulación se hace para un tiempo de 1000 seg. En la siguiente figura se puede apreciar como es la traza de salida del archivo qm.out. Figura 14 Traza de archivo qm.out



40

Con el fin de observar el comportamiento tanto en la fila de espera en el nodo S (uml0) , como en el enlace y en el nodo destino (uml1) , se grafico en función del tiempo de muestreo los mencionados parámetros.

En las siguientes 2 figuras se observa como conforme transcurre el tiempo de emulación el tamaño de la fila aumenta debido a que se comienzan a acumular los paquetes puesto que el nodo fuente no puede saturar el enlace enviando demasiados paquetes al mismo tiempo .Este comportamiento se muestra tanto en Bytes y paquetes.

Figura 15 Comportamiento de la fila de espera Figura 16 Comportamiento de la fila de espera



41

Las siguiente dos figuras muestran la cantidad de bytes o paquetes que han arribado al nodo destino (uml1) , se nota que conforme aumenta el tiempo igualmente aumentan la cantidad de paquetes.

Figura 17 Tráfico de paquetes en nodo destino

Figura 18 Tráfico de bytes en nodo destino



42

Para medir el rendimiento que tiene TCP dado el escenario de emulación se utiliza la aproximación definida por la siguiente ecuación, llamada formula de la raíz cuadrada .

En el modelo de error introducido al escenario de emulación se definió la probabilidad de perdidas como p= 0.01 , El parámetro RTT se toma como el tiempo que dura la emulación es decir 1000seg. Por Ultimo para evaluar el desempeño necesitamos saber el tamaño de los paquetes este parámetro es S =98 bytes.

La emulación nos arroja un archivo de salida llamado out.tr en este el tamaño de los paquetes se observa en la columna 6.Además de este parámetro también podemos observar de izquierda a derecha el comportamiento de del paquete en la fila, el tiempo en que ocurre el evento, los nodos implicados, tipo de paquete y el tamaño. Figura 19 Comportamiento de trafico en escenario

Ingresando los parámetros RTT , S y p en la ecuación

X =0.098*Sqrt(3/(4*0.01)) se obtiene que el rendimiento de TCP para este escenario es de 0.8487 es decir del 84 % lo cual se considera aceptable dado que se establece en el modelo de error una probabilidad de perdidas de 1 %. Dadas las experimentaciones con este escenario se pudo deducir que este rendimiento depende de como se defina la probabilidad de perdidas en el modelo de error si esta probabilidad aumenta el rendimiento es bajo y si la P es pequeña por consecuencia el rendimiento será optimo.



43

6 Conclusiones A pesar de que hasta hace unos años el flujo de información sobre el desarrollo y el estado del arte sobre la característica de emulación en Ns-2, básicamente se encontraba enfocada a la implementación de esta sobre plataformas de cómputo operando bajo el sistema FreeBSD. Actualmente, no es posible obtener información sobre los proyectos realizados bajo este sistema, e incluso el no poder contactar a los autores de los mismos constituyeron obstáculos para obtener referencias sobre el estado funcional del proyecto o sobre análisis de resultados confiables que nos permitiesen llevar el desarrollo del presente proyecto bajo la misma línea de implementación. En base a lo anterior y al gran auge que tiene los sistemas Linux en la actualidad, (donde Linux y freeBSD parten del mismo origen, Unix). Se tomo la decisión de llevar el desarrollo del proyecto a un sistema Debian-Ubuntu, (que ofrece la ventaja de contar con una extensa documentación, ser de fácil configuración, así como contar con una extensa red de usuarios y ayuda en línea). La decisión anterior repercutió en proporcionarle al proyecto la flexibilidad y adaptabilidad a los nuevos entornos de desarrollo Unix-Linux, esto en gran parte posible gracias al proyecto User Mode Linux,(UML), que nos proporciono la tecnología de virtualizacion y el grado de encapsulamiento necesarios para que todo cambio en las entidades virtuales quedara confinada estrictamente a su ámbito, con lo que fácilmente podíamos descartar UML’s que no se ajustaran a nuestras necesidades o presentaran un comportamiento incorrecto, sin afectar la estabilidad e integridad del sistema anfitrión,(el kernel de Linux). Adicionalmente, adquirimos portabilidad en el proyecto ya que es posible implementarlo en sistemas AMD o Intel de 32 y 64 bits, así como adaptabilidad a las nuevas versiones, tanto del proyecto Ns-2 como de las nuevas versiones del proyecto UML y Ubuntu. Si bien, las propuestas de emulación sobre freeBSD ofrecían la característica de ejecutarse sobre redes de computadoras reales, nuestra propuesta de emulación fácilmente puede implementarse para redes reales, siempre y cuando se cuente con el hardware real necesario para establecer las conexiones entre equipo, (en este caso las direcciones MAC “Mandatory Access Control” mapeadas sobre los agentes tap no serán las que identifican a las UML sino que corresponderán a los equipos reales conectados en nuestra red). En nuestro caso el escenario fácilmente puede manipularse y expandirse creando el hardware necesario en las entidades virtuales conforme vaya siendo requerido. Donde realizar lo mismo en freeBSD, requeriría de una cantidad considerablemente mayor de tiempo, esfuerzos y recursos, (algo no deseable, sobre todo en entornos de desarrolló e investigación)



44

La implementación mediante entidades virtuales en freeBSD, no es una alternativa recomendable. Dado que la tecnología de virtualizacion empleada en BSD, (BSD jail), integra esta tecnología dentro del sistema operativo del host, teniendo como consecuencia una virtualizacion parcial y un aislamiento parcial de la entidad virtual. Esto da como resultado que el kernel del sistema físico este expuesto a alteraciones provenientes de cambios en las entidades virtuales, ( Bugs, configuración errónea, fallos en la seguridad del sistema, etc.), que afectan de manera negativa la estabilidad del equipo anfitrión. En resumen, la implementación de la característica de emulación de Ns-2 sobre entidades virtuales en un ambiente Ubuntu-Linux, ofrece flexibilidad, portabilidad y facilidades de implementación en escenarios de prueba y desarrollo. Y al mismo tiempo se evitan los problemas, y fallos en la configuración comunes en la interconexión de equipos en entornos reales.



45

7 Referencias bibliograficas [1] Exercises on ”ns-2” Chadi Barakat INRIA-PLANETE research group 2004, Sophia-Antipolis, France , November 21, 2003 [2] 0 i quinas Virtuales, Diseño y Administración de Sistemas y Redes Miguel Ortuno-Universidad Rey Juan Carlos, España 2006-2007 [3] HOWTO: WIRELESS NETWORK EMULATION USING NS 2 AND USER MODE L INUX (UML), VERSION 1.1. ,Daniel Mahrenholz, Svilen Ivanov - University of Magdeburg, Germany , February 4 2006 [4]User Mode Linux

Dike Jeff-Ed. Prentice Hall, April 12, 2006 [5]CONGESTION AVOIDANCE AND CONTROL Van Jacobson-Lawrence Berkeley Laboratory Michael J. Karels-University of California at Berkeley November, 1988 [6]Lifetime Packet Discard for Efficient Real-Time Transport over Cellular Links Andrei Gurtov-Dept. of Computer Science, University of Helsinki, Finland Reiner Ludwig-Ericsson Research, Germany November 26, 2003 [7]REAL-TIME NETWORK EMULATION WITH NS-2 Daniel Mahrenholz, Svilen Ivanov-University of Magdeburg, Germany September, 2004 [8]ADJUSTING THE NS-2 EMULATION MODE TO A LIVE NETWORK Daniel Mahrenholz, Svilen Ivanov-University of Magdeburg, Germany November, 2005 [9]The ns Manual, (formerly ns Notes and Documentation) A Collaboration between researchers at UC Berkeley, LBL, USC/ISI, and Xerox PARC. Kevin Fall & Kannan Varadhan, Editores August 26, 2008



46

7 Referencias bibliograficas [10]NS SIMULATOR FOR BEGINNERS LECTURE NOTES 2003-2004 Eitan Altman-ESSI, Sophia-Antipolis, Francia Tania Jiménez-Univ de los Andes, Mérida, Venezuela December 4, 2003

[11]TCP-X: An NS-2 environment for implementation and evaluation of TCP clones Michael Hallencreutz- Redmond, Sweden Master's Degree Project, Stockholm, 2005 [12]Manual de FreeBSD FreeBSD Documentation Project FEBRUARY 1999 [13]User Mode Linux (UML): An overview and experiences SLUG Tech Talk Matthew Grove-Red Hat Europe January 12, 2007 [14] http://ditec.um.es/laso/docs/tut-tcpip/3376c212.html “TCP,(Transport Control Protocol)” [15] http://edeca.net/articles/bridging/index.html "HOWTO: Networking UML's,(User Mode Linux Virtual Machines), using ethernet bridging" [16] http://www-ivs.cs.uni-magdeburg.de/EuK/index_eng.shtml "NS-2 Emulation Extensions Project" [17] http://vtun.sourceforge.net/tun/faq.html "TUN/TAP virtual network interfaces for IP/ETHERNET tunneling" [18] http://www.user-mode-linux.org/cvs/tools/tunctl/ "Tool to set up and maintain persistent TUN/TAP network interfaces between Linux Kernel and UML's"


http://ditec.um.es/laso/docs/tut-tcpip/3376c212.html



http://edeca.net/articles/bridging/index.html

http://edeca.net/articles/bridging/index.html

http://www-ivs.cs.uni-magdeburg.de/EuK/index_eng.shtml





http://vtun.sourceforge.net/tun/faq.html

http://www.user-mode-linux.org/cvs/tools/tunctl/






this watermark does not appear in the registered version ...148.206.53.84/tesiuami/uami14513.pdf ·...

Documents