Tutorial NS3

NS3 Instalación y Análisis de Ejemplos David Farfán, Facultad de Ingeniería Escuela de Ingeniería Electrónica y Telecomunicaciones Universidad de Cuenca Cuenca, Ecuador Reporte desteban.farfang @ucuenca.ec

I NTRODUCCIÓN NS3 es un simulador de redes que permite simular diferentes topologias y analizar el rendimiento de las mismas de esta forma se puede poner a prueba diferentes sistemas con el objetivo de conocer cual se ajusta más a un problema en la vida real, en el siguiente informe se detalla la instalación del software así como el análisis/modificación de ejemplos con el fin de poder tener un conocimiento previo de NS3 y de sus prestaciones.

I.

A NÁLISIS TUTORIALES FIRST, SECOND Y THIRD EN CARPETA / EXAMPLES / TUTORIAL

Para este punto de procederá a ejecutar los tutoriales first, second y third en /examples/tutorial, y se verificara la información que se puede obtener de estos además se modificara los tutoriales para observar los resultados. Los ejemplos a ser analizados están en la carpeta de ns3 y dentro de “Examples”, todo esto una vez que entremos a Eclipse.

I-A. Ejemplo 1: “first.cc”

Figura 1. Análisis ejemplo first.cc

Se observa además que se utiliza un enlace punto a punto, es decir de extremo a extremo conectado un servidor con un cliente. Se crea el cliente, para que el cliente pueda establecer conexión con el servidor, primero tiene que pedir una identificación con la cual pueda entablar la comunicación, para eso se le asigna una dirección que es de tipo IPv4, esta se configura según la red designada y la máscara de subred, también se crea una aplicación (servidor), la cual espera paquetes tipo UDP y se configura un echo (retransmitir) de dicho paquete por el puerto establecido. Además se configura CSMA que permite sensar si el medio esta disponible para transmitir, esta no es una red conmutada al estar conectados todos con todos se puede producir colisiones, así como el Internet Stack para enrutamiento.

En el primer ejemplo se detallan dos nodos, un nodo representa al cliente y el otro representa a un servidor, la simulación busca analizar el comportamiento de los datos que se están transmitiendo desde el cliente al servidor y desde el servidor al cliente, los datos que se trasmiten son de tipo UDP. Dentro de este análisis se configuran parámetros importantes como son: Figura 2. Análisis ejemplo first.cc

- DataRate. - Delay. Por defecto estos están dados con valores: DataRate—5Mbps y Delay—-2 ms.

Por último se configura el tiempo de inicio y fin de la ejecución de la aplicación servidor, las cuales son de 1 y 10 segundos respectivamente. También se configura parámetros del paquete que son dados por el cliente, tales como:

-Máximo de paquetes (valor defecto:1). -Intervalo (valor defecto:1). -Tamaño de paquete (valor defecto:1). Al final se establece el tiempo de inicio (2 seg, por defecto) y fin de ejecución (10 seg, por defecto) de la aplicación cliente y se procede a ejecutar la simulación.

Figura 4. Análisis ejemplo first.cc

I-B. Ejemplo 2: “second.cc” En el segundo ejemplo se agrega a la topología desarrollada en el primer ejemplo más un enlace p2p, es decir mantiene un enlace PPP como en el punto anterior, pero ahora se configura en el lado que analizamos como servidor el protocolo p2p que es una red entre iguales es decir no diferencia cliente de servidor todos los host relacionados pueden enviar y recibir información entre si. Se observa que la configuración de PointToPoint es la misma que en el ejemplo anterior, además configura los valores del DataRate a 5Mbps y el Delay a 2ms que son los mismos valores que en el first.cc. Figura 3. Análisis ejemplo first.cc

Procedemos a correr el programa, para esto en consola nos dirigimos a la carpeta del ns3 y ejecutamos el comando para compilar con el nombre del programa.

Aquí se agrega la configuración del p2p, se agrega el nodo con p2p, además se hace la relación entre los dos protocolos el uno que maneja el enlace cliente-servidor PPP y el otro que maneja el stack en el servidor p2p. Además se configura los valores de p2p para un DataRate de 100 Mbps y un Delay de 6560 ns, por los requerimientos tiene una mayor tasa y un retardo menor.

Observamos los resultados que se obtienen, se observa que el cliente comienza enviando una petición al puerto del servidor al que se va a conectar este pide salir enviando la dirección a la cuál va a llegar que es la IP 10.1.1.2, y el puerto es el 9, se observa el tiempo en el que se pide esta petición. El servidor recibe la petición que es un paquete de 1024 bytes, además indica de donde proviene la petición IP 10.1.1.1 con puerto 49153. El servidor envía la confirmación que es un paquete de 1024 bytes, a la IP 10.1.1.1 con puerto 49153, por último se muestra que el cliente recibe desde la IP 10.1.1.2 con puerto 9 un paquete, con esto se termina la comunicación punto a punto de forma correcta, siempre en cada envió/recepción se muestra el tiempo que se demora. Se observa que esta comunicación se da en una misma red que es la 10.1.1.*.

Figura 5. Análisis ejemplo second.cc

También se configura tanto la red que se esta creando como el enrutamiento estático, esto mediante los comandos NetDeviceContainer y el InternetstackHelper. en este caso se maneja la red de PPP y la del p2p, el servidor se conecta al grupo de host que forman la red, para la configuración de los protocolos cada uno debe estar en una red diferente, se comunican entre si mediante el enrutamiento. Además se configura CSMA que permite

sensar si el medio esta disponible para transmitir,esta no es una red conmutada al estar conectados todos con todos se puede producir colisiones,. Este ejemplo como se menciono es una continuación del anterior adecuando un escenario con mayor complejidad.

Figura 8. Análisis ejemplo second.cc Figura 6. Análisis ejemplo second.cc

Se configuran las redes tanto la 10.1.1.0 con máscara 255.255.255.0 para el enlace que es punto a punto, esto es parecido a la configuración en el ejemplo anterior, además se configura la segunda red p2p con la dirección 10.1.2.0 y máscara 255.255.255.0. También el servidor configura el puerto por el cuál va a recibir peticiones.

Procedemos a correr el programa, para esto en consola nos dirigimos a la carpeta del ns3 y ejecutamos el comando para compilar con el nombre del programa. Observamos los resultados que se obtienen, se observa que el cliente comienza enviando una petición al puerto del servidor al que se va a conectar esta pide salir enviando la dirección que de llegada que es la IP 10.1.2.4 como se observa el cliente pertenece ya a otra red, el puerto del servidor es el 9, se observa el tiempo en el que se pide esta petición. El servidor recibe la petición que es un paquete de 1024 bytes, además indica de donde proviene la petición IP 10.1.1.1 con puerto 49153.

Figura 7. Análisis ejemplo second.cc

Se configura el tiempo de inicio y fin de la ejecución de la aplicación servidor, las cuales son de 1 y 10 segundos respectivamente. También se configura parámetros del paquete que son dados por el cliente, tales como:

El servidor envía la confirmación que es un paquete de 1024 bytes, a la IP 10.1.1.1 con puerto 49153, por último se muestra que el cliente recibe desde la IP 10.1.2.4 con puerto 9 un paquete, con esto se termina la comunicación punto a punto de forma correcta, siempre en cada envió/recepción se muestra el tiempo que se demora. La comunicación p2p permite a cualquier host en la red 10.1.2.0 actuar como servidor, mediante CSMA.

-Máximo de paquetes (valor defecto:1). -Intervalo (valor defecto:1). -Tamaño de paquete (valor defecto:1024). Al final se establece el tiempo de inicio (2 seg, por defecto) y fin de ejecución (10 seg, por defecto) de la aplicación servidor esto se muestra que corre con el protocolo p2p, con estos parámetros se procede a ejecutar la simulación, mediante el comando Simulator.Run. El tiempo de la comunicación en la topología tendría que revestir una mayor duración dado que la comunicación es ahora entre dos subredes diferentes, esto diferencia debería ser baja en el orden de us.

Figura 9. Análisis ejemplo second.cc

I-C. Ejemplo 3: “third.cc” En el tercer ejemplo se agrega a la topología desarrollada en el primer ejemplo,segundo ejemplo más un enlace inalámbrico WIFI, es decir mantiene un enlace PPP, p2p como en el punto anterior, se configura en el lado que

analizamos como servidor el protocolo p2p que es una red entre iguales es decir no diferencia cliente de servidor todos los host relacionados pueden enviar y recibir información entre si, mientras que de el lado del cliente se comunica vía WIFI que es un protocolo de comunicación inalámbrica.

Se configura la interfaz móvil, para los clientes se configura mediante un AP (access point), el usuario tiene movilidad y debe la red darle una dirección si este pide una petición por eso se configura el área de cobertura, y se la define como WIFI AP, el área se configura como un rectángulo.

Se observa que la configuración de PointToPoint y p2p es la misma que en el ejemplo anterior, PPP configura los valores del DataRate a 5Mbps y el Delay a 2ms que son los mismos valores que en el first.cc. La configuración del p2p, agrega el nodo con p2p, además se hace la relación entre los dos protocolos el uno que maneja el enlace cliente-servidor PPP y el otro que maneja el stack en el servidor p2p. Además se configura los valores de p2p para un DataRate de 100 Mbps y un Delay de 6560 ns, por los requerimientos tiene una mayor tasa y un retardo menor, así como también se asigna el CSMA que es para analizar cuando el canal esta vació para poder transmitir. Figura 12. Análisis ejemplo third.cc

Se configuran las redes tanto la 10.1.1.0 con máscara 255.255.255.0 para el enlace que es punto a punto, además se configura la segunda red p2p con la dirección 10.1.2.0 y máscara 255.255.255.0 y por último se configura la tercera red que es para la red móvil con dirección 10.1.3.0 y máscara 255.255.255.0. También el servidor configura el puerto por el cuál va a recibir peticiones.

Figura 10. Análisis ejemplo third.cc

Ahora se configura el nuevo protocolo que es WIFI, este se crea y se relaciona con p2p, además configura términos de calidad de servicio QoS, las capas. Figura 13. Análisis ejemplo third.cc

Se configura el tiempo de inicio y fin de la ejecución de la aplicación servidor, las cuales son de 1 y 10 segundos respectivamente. También se configura parámetros del paquete que son dados por el cliente, tales como: -Máximo de paquetes (valor defecto:1). -Intervalo (valor defecto:1). -Tamaño de paquete (valor defecto:1024).

Figura 11. Análisis ejemplo third.cc

Al final se establece el tiempo de inicio (2 seg, por defecto) y fin de ejecución (10 seg, por defecto) de la

aplicación servidor esto se muestra que corre con la rd WIFI con estos parámetros se procede a ejecutar la simulación, mediante el comando Simulator.Run y se da el tiempo de simulación que es de 10 seg. El tiempo de la comunicación en la topología tendría que revestir una mayor duración dado que la comunicación es ahora entre dos subredes diferentes, esto diferencia debería ser baja en el orden de us. Figura 15. Análisis ejemplo third.cc

II.

M ODIFICACIÓN DE EJEMPLOS FIRST, SECOND Y THIRD EN CARPETA / EXAMPLES / SCRATH

II-A. Ejemplo first.cc Para poder modificar el ejemplo first.cc tenemos que copiarlo en la carpeta scratch, se le ha nombrado como ejemplo1.cc.

Figura 14. Análisis ejemplo third.cc

Procedemos a correr el programa, para esto en consola nos dirigimos a la carpeta del ns3 y ejecutamos el comando para compilar con el nombre del programa.

Se mantiene la topología de una red punto a punto, con dos nodos uno que representa al servidor y otro que representa al cliente. La información que se envía serán paquetes UDP. Las variables a cambiar para ver como el comportamiento cambia son: - DataRate. - Delay.

Observamos los resultados que se obtienen, se observa que el cliente comienza enviando una petición que es un paquete de tamaño 1024 bytes, manda a la dirección 10.1.2.4 como se observa el cliente pertenece a otra red, el puerto del servidor es el 9, se observa el tiempo en el que se pide esta petición. El servidor recibe la petición que es un paquete de 1024 bytes, además indica de donde proviene la petición IP 10.1.3.3 por el puerto 49153, esta dirección es de la red móvil que el AP otorga al cliente.

Los valores modificados son: DataRate—-2Mbps y Delay—-1 ms. Se busca analizar con una menor tasa de bits y un retardo menor que comportamiento cumple la red. La red como tal y el puerto del servidor se mantienen porque ambos nodos están en la misma red, y la dirección que se otorga a cada uno no alterará los resultados. También se cambia los valores del: -Máximo de paquetes (valor:10).

El servidor envía la confirmación que es un paquete de 1024 bytes, a la IP 10.1.3.3 con puerto 49153, por último se muestra que el cliente recibe desde la IP 10.1.2.4 con puerto 9 un paquete, con esto se termina la comunicación punto a punto de forma correcta, siempre en cada envió/recepción se muestra el tiempo que se demora. La comunicación p2p permite a cualquier host en la red 10.1.2.0 actuar como servidor, mediante CSMA.

-Intervalo (valor:3 seg). -Tamaño de paquete (valor defecto:1024). Se configura una red en donde se busque que la red trabaje a la máxima capacidad.En la siguiente imagen se muestra que resultados se obtienen:

Figura 16. Análisis ejemplo1.cc

Observamos los resultados que se obtienen, se observa que el cliente comienza enviando una petición al puerto del servidor al que se va a conectar este pide salir enviando la dirección a la cuál va a llegar que es la IP 10.1.1.2, y el puerto es el 9, se observa el tiempo en el que se pide esta petición. El servidor recibe la petición que es un paquete de 1024 bytes, además indica de donde proviene la petición IP 10.1.1.1 con puerto 49153.

Figura 17. Análisis ejemplo1.cc

Se analiza que al aumentar la tasa de bits y el retardo, los paquetes completan la comunicación, cada petición toma 2 seg más o menos que es según el intervalo configurado y hasta los 11 seg ya se completa. Otro ejemplo cambia el tiempo del sistema, y se configura los otros datos: DataRate—-4Mbps y Delay—-2 ms. Además se configura: -Máximo de paquetes (valor:5). -Intervalo (valor:2 seg). -Tamaño de paquete (valor defecto:2048).

El servidor envía la confirmación que es un paquete de 1024 bytes, a la IP 10.1.1.1 con puerto 49153, por último se muestra que el cliente recibe desde la IP 10.1.1.2 con puerto 9 un paquete, con esto se termina la comunicación punto a punto de forma correcta, siempre en cada envió/recepción se muestra el tiempo que se demora. Lo importante es observar que el tiempo que le toma a cada solicitud cumplir la petición es mayor, además que el numero de paquetes que se configuro en el tiempo que se tiene no puede completar. El tiempo promedio de completar la comunicación es de 3 seg, y se completa 5 paquetes de los 10 que se configuro, se observa que la red esta saturada. En otro escenario se configura valores de: DataRate—4Mbps y Delay—-4 ms. Además se configura: -Máximo de paquetes (valor:5). -Intervalo (valor:2 seg). -Tamaño de paquete (valor defecto:1024).

Figura 18. Análisis ejemplo1.cc

Se observa que los valores corresponden a la configuración, en donde el tiempo de respuesta es de 1 seg, y el intervalo de 2 seg, el tiempo de cumplir la petición es bajo. Entonces podemos definir que la comunicación puede fallar si es que el tiempo total de ejecución del sistema es menor al total que le tomarían enviar los paquetes, o si se tiene una demanda mayor a la que podría soportar el

canal, también depende del intervalo entre cada petición, el tamaño de cada paquete y de los valores del datarate y del retraso que se configure. Con todos estos escenarios se debe poder lograr un sistema optimo para un enlace PPP.

II-B. Ejemplo second.cc Para poder modificar el ejemplo second.cc tenemos que copiarlo en la carpeta scratch, se le ha nombrado como ejemplo2.cc. Figura 20. Análisis ejemplo2.cc

Se mantiene la topología de una red punto a punto y el protocolo p2p, la información que se envía serán paquetes UDP. Las variables a cambiar para ver como el comportamiento cambia son: - DataRate. - Delay. Se cambiara la tasa de bits a diferentes valores y el delay también tanto para el PPP como para p2p que tiene CSMA, los valores analizados son los siguientes datos: -Máximo de paquetes (valor:5). -Intervalo (valor:2 seg). -Tamaño de paquete (valor defecto:2048).

Como se observa en un enlace con mayor datarate las peticiones se realizan en menor tiempo como se observa en la imagen 32 el tiempo total de completar la solicitud en uno de los paquetes enviados desde el cliente va desde 8.00416seg hasta 8.00838seg, en cambio para el caso de la figura 33 ese mismo paquete va desde 8.01046seg hasta 8.2098seg, vemos que la diferencia es del orden de centésimas de segundo, lo cual garantiza que la tasa de bits de transferencia es una característica importante para garantizar una correcta transmisión.

La siguiente figura muestra un delay de 8ms para la configuración PPP que es un valor mayor al dado por defecto:

La siguiente figura muestra un datarate de 8Mbps para la configuración PPP que es un valor mayor al dado por defecto:

Figura 21. Análisis ejemplo2.cc Figura 19. Análisis ejemplo2.cc

La siguiente figura muestra un datarate de 2Mbps para la configuración PPP que es un valor menor al dado por defecto:

La siguiente figura muestra un delay de 2ms para la configuración PPP que es un valor menor al dado por defecto:

Figura 22. Análisis ejemplo2.cc

Como se observa para el caso de un delay de 8ms la respuesta del paquete es de 8 a 8.0229seg a diferencia de cuando el delay es de 2ms donde la respuesta total se da desde 8 a 8.0109seg, lo que demuestra que un paquete con menor retardo tiene una mejor respuesta, esto depende también del tipo de información que se este transmitiendo, en el caso del retardo se observa que tiene una respuesta más cambiante que en el caso de un datarate, manejar el retardo puede ser más importante cuando se tiene paquetes UDP como en este caso, en donde se observa que el retardo es un obstáculo mayor que la tasa de bits en el rendimiento de la red. En la red p2p que se analiza como una red CSMA se observa de igual manera para los siguientes valores:

Figura 24. Análisis ejemplo2.cc

Se observa que de igual manera cuando el datarate es de 50Mbps una petición se completa desde 8 hasta 8.01107seg, mientras que en el caso de 150Mbps va desde a 8 hasta 8.01085seg, se observa que la diferencia en cuanto a datarate no es significativa a pesar de la gran diferencia del enlace, el datarate en los paquetes UDP en CSMA no afecta de manera considerable, aunque se mantiene que a un mayor velocidad menor tiempo de transmisión.

La siguiente figura muestra un delay 3730ns para la configuración p2p que es un valor mayor al dado por defecto:

La siguiente figura muestra un datarate de 50Mbps para la configuración p2p que es un valor mayor al dado por defecto:

Figura 25. Análisis ejemplo2.cc

Figura 23. Análisis ejemplo2.cc

La siguiente figura muestra un datarate de 150Mbps para la configuración p2p que es un valor mayor al dado por defecto:

La siguiente figura muestra un delay 17000ns para la configuración p2p que es un valor mayor al dado por defecto:

según sea el protocolo utilizado. En el ejemplo3.cc se tiene además de los casos mencionados una red WIFI, que es un protocolo inalámbrico esto implica que es una red móvil en el cual el usuario pide un a identificación en este caso un IP para conectarse a la red, pero el usuario a parte de conectarse vía inalámbrica tiene posibilidad de moverse por el área configurada para la red WIFI, en este caso se puede modificar el comportamiento de la red móvil, modificando los parámetros del área de cobertura. Figura 26. Análisis ejemplo2.cc

Como se observa el retardo es en el orden de los ns por lo que no cambia mucho los valores que demoran en realizar un envío y recepción del paquete desde el cliente al servidor, esto se necesita para evitar colisiones en el sistema CSMA ya que al estar conectados todos con todos no es un sistema conmutado y puede causar colisiones si es que más de uno envía un mensaje a la vez.

-Máximo de paquetes (valor:5). -Intervalo (valor:2 seg). -Tamaño de paquete (valor defecto:2048). Con los datos configurados se obtiene los siguientes resultados:

Entonces podemos definir que la comunicación puede fallar si es que el tiempo total de ejecución del sistema es menor al total que le tomarían enviar los paquetes, o si se tiene una demanda mayor a la que podría soportar el canal, también depende del intervalo entre cada petición, el tamaño de cada paquete y de los valores del datarate y del retraso que se configure, de las colisiones que exista en el sistema al no ser una red conmutada. Con todos estos escenarios se debe poder lograr un sistema optimo para un enlace PPP y para el p2p.

II-C. Ejemplo third.cc Para poder modificar el ejemplo second.cc tenemos que copiarlo en la carpeta scratch, se le ha nombrado como ejemplo3.cc. Se mantiene la topología de una red punto a punto y el protocolo p2p, además en este se agrega la red WIFI, la información que se envía serán paquetes UDP. Las variables a cambiar para ver como el comportamiento cambia son:

Figura 27. Análisis ejemplo3.cc

A partir de esto la señal puede verse potenciada según se este más cerca de la fuente AP, o según el número máximo de usuarios que puede soportar el AP, todo esto determina el tiempo que se demorara en cumplir con una petición.

- DataRate. - Delay. Se puede cambiar la tasa de bits a diferentes valores y el delay también tanto para el PPP como para p2p que tiene CSMA, para estos casos se ha analizado tanto en el ejemplo1.cc y en el ejemplo2.cc en donde se ha visto que el cambio que revise mayor importancia para paquetes UDP es el delay, el datarate en cambio permite que a mayor enlace menor tiempo de completar la transmisión

Figura 28. Análisis ejemplo40.cc

En la imagen anterior se analiza una topología en donde hay 6 usuarios en el AP, inicialmente solo había 3, se observa un pequeño cambio en cuanto al tiempo de completar la solicitud, si una red móvil tiene ocupado todos sus canales el BW disponible disminuye y por lo tanto la tasa también disminuiría, tomando en cuenta que WIFI con su AP, tiene características de conmutación. En una configuración con 9 nodos WIFI se obtiene el siguiente resultado, que se relaciona con todo lo mencionado hasta el momento:

BIBLIOGRAFÍA Fuentes Bibliográficas: 1. How to Install JAVA 8 (JDK 8u45) on UbuntuLinuxMint via PPA», TecAdmin.net. 2. How to Install The Latest Eclipse Release in Ubuntu 14.04 | UbuntuHandbook» 3. Instalando Eclipse IDE sobre Ubuntu 14.04 | Isma’s Blog». [En línea]. Disponible en: https://pajarokillo.wordpress.com/2014/07/08/instalandoeclipse-ide-sobre-ubuntu-14-04/. 4. Software NS3. 5. O. Mohammad,B Noureddine, FUNDAMENTALS OF PERFORMANCE EVALUATION OF COMPUTER AND TELECOMMUNICATION SYSTEMS, Wiley, 2010.

Figura 29. Análisis ejemplo39.cc

Entonces podemos definir que la comunicación puede fallar si es que el tiempo total de ejecución del sistema es menor al total que le tomarían enviar los paquetes, o si se tiene una demanda mayor a la que podría soportar el canal, también depende del intervalo entre cada petición, el tamaño de cada paquete y de los valores del datarate y del retraso que se configure; del área de cobertura esto depende del AP de la potencia que radie del lugar en el cual radie,. Con todos estos escenarios se debe poder lograr un sistema optimo para un enlace PPP, para el p2p y para WIFI.

CONCLUSIONES Se aprendió a instalar NS-3, en eclipse, esto facilita el desarrollo de los diferentes proyectos que se pueden realizar para simulación de sistemas de redes, este programa es de mucha utilidad pues permite ejemplificar los diferentes casos que existen en el mundo de los sistemas de redes, a más que permiten una mejor comprensión de la parte teórica. Se pudo analizar los ejemplos del comportamiento de diferentes redes, se comprendido como funcionan diferentes protocolos como PPP, p2p, WIFI, además de que se observo como al cambiar los parámetros los sistemas cambian su rendimiento, encontrando factores importantes para mantener una red de forma estable como el datarate, el delay.