Tarea 7: Simuación de movilidad

Para esta tarea se nos pide realizar un código documentado en donde implementemos una simulación de una MANET que cumpla con las siguientes características.

• Llegadas y salidas de nodos con una distribución exponencial, procesos poisson.
• Un modelo de movilidad
• Nodos con capacidad de batería inicial
• Envío de mensajes consume batería según el radio de transmisión
• El radio es ajustable en cada nodo
• Se utiliza una inundación con un TTL adaptable.

Por lo que realicé un código en python, utilizando pygame, y numeros random con la librería estandar de python y de numpy, para poder realizar esta simulación.

Primero que nada declaro variables generales, de esta manera, podemos tener el largo y ancho de la ventana, esto es importante para obtener los limites de la imagen, los cuales van a estar rebotando durante toda la pantalla, en las muestras de simulación declaro una población de 100 nodos que van entrado por procesos poisson, estoy verificando el tiempo cada corrida y estos en su vez tienen su propio tiempo que si entran dentro de los parámetros aparecen en la simulación.

El campo de visión de cada nodo es parametrizado de manera inicial, este puede ser modificado durante el transcurso de la simulación, al igual que el TTL, el cual crea conexiones con los nodos vecinos que se encuentran a su alrededor,

El TTL se puede cambiar según su propagación hacia atrás, pero esto afecta considerablemente su rendimiento ya que cada nodo tiene una batería y al momento de tener más TTL, estas conexiones pierden la batería y se quedan sin poder propagar la información por inundación.

El movimiento que desarrollé fue el agregar velocidad de manera exponencial y cambiar sus ángulos con un aleatorio con distribución uniforme, y luego de esta manera genera pequeños vectores y de esta manera hace buenos movimientos y creo que es apropiado para este tipo de simulación.

El TTL es una función recursiva que hace la propagación según cada distancia junto con todos los nodos y vamos comparando para obtener las que se encuentran en el rango de recepción, por lo que cambiamos sus estados y estos a su vez, van hacia atrás para obtener un mayor rango de información según su TTL.

En esta simulación podemos suponer que el enemigo es un helicóptero que esta en un campo tratando de mandar bombas en un campo de batalla, entonces, los soldados tienen radios que mandan información cuando uno de estos ve que en su campo de visión se encuentra el helicóptero, se quedan quietos y envían a los demás.

Código

Video de muestras

Referencias
Peter's Website, Project pygame physics simulation, Peter Colling, extraido de http://www.petercollingridge.co.uk/
Redes ad hoc, Redes de telecomunicaciones, Elisa Schaeffer, extraido de http://elisa.dyndns-web.com/~elisa/

Triangulación

Un receptor GPS utiliza la Triangulación para determinar su posición en la superficie de la Tierra por señales de temporización a partir de tres satélites del sistema de posicionamiento global. El sistema GPS es una red de satélites que orbitan la tierra que envían señales a los receptores GPS, proporcionando información sobre la posición, el tiempo y la velocidad de movimiento del dispositivo.

Cada satélite de la constelación GPS envía señales periódicas junto con una señal horaria. Estas señales son recibidas por los receptores GPS, el cual calcula la distancia entre el sensor y cada satélite como una función del retardo entre el tiempo de transmisión y el momento de la recepción. Aunque las señales (tipo de ondas de radio) viajan a la velocidad de la luz, siempre hay una demora debido a que los satélites están a decenas de miles de kilómetros sobre la Tierra.

Una vez que el GPS ha calculado las distancias a lo menos tres satélites, puede realizar los cálculos. Triangulación vuelve a afirmar su posición en un mapa con dos compases saber la distancia exacta desde tres lugares diferentes. El área de superposición de tres círculos centrados en cada lugar corresponde a su sitio ya que el radio de cada círculo corresponde a la distancia entre su lugar y cada lugar.

En la versión GPS de los cálculos se realizan en tres dimensiones con un conjunto imaginario de la brújula 3D, por lo que su posición corresponde a la superposición de los tres círculos cuyo radio viene dado por la distancia entre su posición y cada satélite. Si el receptor GPS puede recibir datos de un cuarto satélite, las mediciones se pueden verificar de nuevo.

El proceso de cálculo es extremadamente rápido, que permite que el receptor GPS para indicar su posición, altitud (aire), la velocidad y el destino.

Para hacer la Triangulación es necesario realizar un plano cartesiano de manera que el centro de nuestro plano sea 0,0, esto para poder asegurar que vamos a tener una intersección entre los circulos, es por eso que la creación de las antenas, cuyo radio es la intensidad de la señal, se crean uno, en el centro del plano catesiano, otro sobre el eje y y otro más, debajo de los dos circulos anteriores, esta manera es mucho más facil calcular lo que es la i y la j, por lo tanto tener una buena ubicación.

Para crear la interfaz para la observación del comportamiento de la trigonalización, utilicé la libreria tk de python en donde primero generé una ventana de 500 pixeles x 500 pixeles, programé un script en el cual pudiéramos obtener valores de -1:1 y tenerlos en sus planos correspondientes, por lo que dividí la ventana de manera que tuviéramos un plano de cuatro partes, en donde en la parte superior derecha tengamos los valores positivos de estos números, luego en la parte superior izquierda los valores negativos respecto al eje x y los valores positivos respecto al eje y, la parte inferior derecha los valores prositivos respecto al eje x y los valores negativos respecto al eje y, y en la parte inferior izquierda los valores negativos respecto a ambos ejes, por lo que por medio de la fórmula (1-x)*250, donde x es el número de que queremos graficar entre -1:1 y el menos uno para controlar la posición de pixeles, por lo que de esta manera podemos posicionar los elementos de manera correcta.

Luego de tener los valores de las fuerzas de los circulos, podemos calcular donde está posicionado según las matemáticas de la triangulación, en base a Wikipedia, se saca la derivación de los puntos a calcular y obtenemos.

X = (ar**2 - br**2 + d**2)/float((2*d))

Y = ((ar**2-br**2+i**2+j**2)/(2*j))-((float(i/j))*X)

En  donde:
ar = radio antena A
br = radio antena B
d = distancia entre antena A y antena B
i = distancia del origen a antena C
j = la distancia entre el punto de encuentro y la ubicación de la antena C

Tomada de wikipedia

Para entenderlo, primero hice un dibujo.

Ahora les muestro el código.



Este es un video que tomo sobre la animación del mismo ejercicio que dibuje.

Referencias.
NA, (2012). Qu'est-ce que la trilatération?. Mio web. Recuperado de http://eu.mio.com/fr_fr/systeme-positionnement-global_4991.htm

Infográfico: Puntos extra

Infográfico sobre los saltélites artificiales orbitando en el mundo

Referencias
The Ten Most Important Satellites Orbiting Earth Now, Stephanie Fox, iO9 web, liga

Tarea 5: Experimento de congestión

Se nos pide averiguar cómo se genera tráfico con distintas propiedades y cómo podemos monitorear las medidas de desempeño (mencionadas en la clase) en su simulador, para luego modificar un esquema de congestión

Hice un programa en el cual puedes generar los siguientes tipos de tráfico.

• Trafico CBR (Constant bit rate)
• Trafico exponencial
• Trafico Pareto

De manera que por medio de los argumentos dados al correr la simulación se puede especificar de la siguiente manera sus entradas.

ns simulacion.tcl [Topologia] [Tipo de trafico] [Tamaño de paquetes] [Rate] [Esquema]

Por ejemplo podemos correr el programa de la siguiente manera.

ns simulacion.tcl arbol CBR 1000 1mb Heap

Se nos pide realizar un experimento sobre nuestra simulación es por eso que hice un python que obtiene del archivo .nam los valores de kbps y el tiempo para graficar la medida de desempeño Throughput de manera que podamos saber como afecta el trafico a un nodo udp con CBR en diferentes tamaños de paquetes y rates.

Obtuvimos los siguientes resultados.

De manera que podemos observar que al agregar paquetes más pesados en un rate medianamente alto se transmite menos flujo por segundo, pero con mayor cantidad de información, este experimento fue realizado con una topología de árbol y generando trafico CBR dado el ns2.


Este es el código.

Validación de modelos de red inalámbricas móviles usando simuladores

Para la materia de telecomunicación se nos pide realizar una investigación en google scholar en donde tenemos que encontrar un paper en el cual usen un simulador de redes para hacer alguna prueba, es por eso que yo seleccioné Validation of Wireless and Mobile Network Models de David B. Johnson, en donde utiliza el simulador NS2 para hacer pruebas en redes inalámbricas.

Como introducción, nos dice que las redes inalámbricas tienen retos importantes a la hora de validar modelos de redes a gran escala, ya que si bien, la validación en redes convencionales conectadas por cable, existe problemas, a las redes inalámbricas se les agrega un extra lo cual es el movimiento físico y la propagación de la red, siendo una red variable y dependiente de factores que no podemos controlar como es el medio ambiente, paredes, árboles o cualquier obstrucción que tenga alguna red inalámbrica, es por eso que el departamento de informática de Carnegie Mellon University crean un experimento para hacer validación de modelos en redes inalámbricas.

Ellos utilizan el simulador NS2 para observar el comportamiento detallado de la capa física y de enlace de una red inalámbrica, para así permitir el movimiento arbitrario de los nodos en alguna red, en la capa física, se hacen modelos realistas con factores que habíamos descrito anteriormente, como el espacio libre, paredes y la reflexión del suelo, para obtener cierta potencia de transmisión, la ganancia de la antena y la sensibilidad de la recepción, por otra parte en la capa de enlace, utilizan el modelo DCF, Distributed Coordination Function, utilizando la MAC, Media Access Control del protocolo de la IEEE 802.11 inalámbrico LAN, junto con el estándar de Address Resolution Protocol.

Utilizan un baco de pruebas el cual consiste en aproximadamente 5 nodos móviles implementados en carros que viajan aproximadamente 25 millas por hora junto con dos nodos estacionarios separados por una distancia de 700 metros, en cada carro se tiene una computadora que tienen el protocolo de enroutamiento DSR ad hoc, permitiendo el registro local de los eventos de red en el disco duro de cada uno, cuando los carros se movían, utilizando un sistema de seguimiento de GPS, la ruta entre los dos nodos estacionarios iba cambiando constantemente, utilizando un área abierta a trafico de otros carros por lo que la velocidad de cada nodo, variaba con el tiempo, al igual que lo haría con cualquier red real, luego se mandaban datos para realizar el experimento entre el NS2 y con los carros, como flujos constantes de UDP, simulando voces, video, paquetes de información, etc.

Algunos de los resultados que obtuvieron en esta simulación fueron gráficas como la que muestro arriba, en donde muestran tres secuencias de tiempo para una misma simulación y la emulación del protocolo FTP entre los dos nodos estacionarios y una red de 16 nodos ad hoc. podemos ver en la curva superior que muestra una conexión simulada completamente utilizando el NS2 y las otras dos pruebas son haciendolo en forma de emulación, utilizando las técnicas que han desarrollado, podemos ver que son muy parecidas y que es posible su validación entre su simulación y la vida real.

Referencias.
Validation of Wireless and Mobile Network Models, David B. Johnson, Carnegie Mellon University. Liga.

Experimentos de QoS

Para la materia de redes de telecomunicaciones se nos pide realizar un experimento de manera que podamos comprobar que tan bueno es el servicio que se nos ofrece en diferentes aplicaciones en diferentes conexiones, es por eso que para esta entrada he seleccionado la calidad de servicio de QoS entre fibra óptica, conexión por cable y wireless en streaming de videos de youtube.

Valores a comprobar.

En este experimento estoy tomando en cuenta los kilobits por segundo que se está descargando en un streaming de video, comparado con el tiempo que se está tardando en hacer esa cantidad, en donde podemos observar que tan rápido está descargando los videos para que el usuario los pueda ver correctamente, el experimento es bueno cuando si el video es de una longitud mayor a la que tenemos de la descarga, podemos decir que el usuario pudo verlo sin problemas ni retardos, cuando no es así quiere decir que tuvo que soportar cierto retraso.

Es por eso que para este experimento, estamos realizando pruebas con los siguientes valores:

• Un video de aproximadamente 3 minutos (liga) en el cual tenga las siguientes resoluciones disponibles:
• 480p
• 720p
• 1080p
• 4k
• Utilizando los siguientes métodos de conexión
• Conexión por cable coaxial de 5 megas.
• Conexión inalámbrica de 5 megas.
• Conexión fibra óptica de 20 megas.
• Uso de comando ifstat para obtener los kbps en tiempo real
• Uso de gnuplot para realizar las gráficas.

Conexión inalámbrica.

En mi caso utilizo mi red de INTERCABLE de manera que utiliza conexión por cable coaxial a mi computadora inalambricamente, de una velocidad aproximada de 5 megas, en donde obtuvimos los siguientes resultados.

Podemos observar los siguientes puntos relevantes.

• El video en resolución 720p termina más rápido que las demás resoluciones (debería ser 480p).
• Los videos de resoluciones 1080p, 720p y 480p son vistos sin ningún retraso, aproximadamente demoran 120 segundos o menos en cargar.
• El video en resolución 4k demora más de 8 minutos para cargar, cuando su longitud es de 3 min, por lo que tenemos un retraso que hace que no podamos ver el video fluidamente.

Ahora expongo los resultados individuales.

Conexión alámbrica.

Ahora se utiliza la red de INTERCABLE de 5 megas alambricamente, en donde tenemos los siguientes resultados.

Vemos que de manera alámbrica es más estable que la inalámbrica al hacer streaming de video, al igual que la cantidad de tiempo es menor basada en la anterior, puntos destacables:

• La resolución de 480p carga en menos de 1 minuto
• Las resoluciones menores a 4k cargan sin retrasos y son menores que la longitud del video.
• 4k carga 100 segundos menos que inalambricamente, podemos ver una mejora al estar conectados directamente al router.

Ahora expongo los resultados individuales.

Conexión fibra óptica.

Para la conexión de fibra óptica se utiliza la red INFINITUM de 20 megas, el cual es considerablemente más rápida que la anterior experimentada, obtenemos los siguientes valores:

Vemos que al conectarnos en fibra óptica es más rápida, carga aproximadamente 40% más rápido que de las formas anteriores, aunque debería ser aún más el cambio, he observado que Telmex, tiene un cierto regulador de vídeos de manera que hace que no utilice todo el ancho de banda para descargar los videos, entre los puntos relevantes podemos decir que:

• La descarga de video en 480p fue menos rápido que los anteriores, tardando 120 segundos, cuando en la anterior tardó 60 segundos.
• La descarga de video en 1080p y 4k fueron considerablemente mejorados que los anteriores.
• Aún con fibra óptica, los videos de 4k no fueron vistos según el análisis, sin observar retraso, tardando aproximadamente más de 5 minutos en cargar, cuando la longitud del video es de 3 min.
• Vemos más picos y inestabilidad en esta señal.

Conclusión

Cómo conclusion podemos decir que de manera alámbrica en INTERCABLE tenemos una conexión mejor para observar videos, a pesar de que este proveedor ofrece 5 megas, es más estable, en lo que respecta a la fibra óptica de Telmex, vemos mucha inestabilidad al momento de ver videos, a menos que sean de resolución alta, se ve una mejora, pero igual se pueden observar retrasos, esto lo considero muy desagradable, los picos de Telmex, llegan hasta 18000 kbps pero solamente algunas veces, cuando en Intercable llega a picos 9000 y se mantiene en ellos, proporcionando una conexión más constante.

Tarea 3: Experimentos de monitoreo WiFi

Para la materia de redes de telecomunicaciones se nos pide realizar un experimento de como podemos monitorear una red WiFi e incluso poder tener de alguna manera una forma de realizar algún tipo de ataque sencillo.

Para esto, realicé una serie de pasos para poder disminuir el trafico de datos de mi iPod desde la computadora, de manera que no podamos abrir youtube para poder hacer streaming de video, por lo que las herramientas que utilicé fueron el comando tcpdump para hacer sniffing en mi red y el paquete scapy para hacer paquetes fake que simulen ser youtube en los puertos de HTTP y baje la velocidad de internet de manera que youtube no pueda abrirse.

Primero que nada para hacer el sniffing lo que utilicé fue el tcpdump, herramienta que es muy útil para poder analizar el trafico de mi red, viendo que es lo que se esta haciendo en vivo y poder realizar un ataque, por lo que tenemos los siguientes resultados.

Utilizando el comando sudo tcpdump -i en0, en donde en0 es mi interfaz de red por lo que podemos concluir que mi iPod tiene la IP .65, de manera que ahora vamos a realizar un ataque mandando múltiples paquetes creados por mi y mandados desde mi IP, para hacer que el iPod tenga muchos paquetes por recibir y colapsarlo, haciendo llamar como si fuera youtube y teniendo como resultado el no poder abrir dicha página.

Para poder ver el trafico solamente de mi iPod podemos especificar en el mismo comando a que host ver que es lo que esta haciendo, con la siguiente instrucción: sudo tcpdump -i en0 host IP

Obteniendo los siguientes resultados:

Como ahora pudimos verificar que en realidad el iPod esta conectado a la red, vamos a utilizar un programa que yo hice que por medio de una librería para python llamada scapy, podemos realizar paquetes y fingir datos que los estoy mandando al iPod, este es el script.

Para oponernos a que nos manden paquetes falsos podemos contraatacar de manera que si hacemos sniffing, hacer que el script mande a esa IP los paquetes falsos y evitar que nos controlen nuestro acceso.

Ahora probamos el script con la IP de mi iPod y empieza a mandar muchos paquetes al mismo tiempo.

Ahora, en el iPod tratamos de entrar a youtube y tarda mucho en cargar, de manera que nunca podemos  ver un video, ni siquiera la página web.

Para que vean como funciona en vivo, he realizado un video, en donde pueden ver que por ejemplo google si abre pero youtube no carga.

Referencias.

• Pueden descargar scapy desde macport o en esta liga.
• El comando tcpdump viene en mac, pueden ver su documentación en esta liga.

Tarea 2: protocolo

Se nos pide diseñar, implementar y comprobar experimentalmente y documentar un protocolo simple a nivel aplicación, utilizando sockets UDP en donde múltiples clientes hagan alguna función en un servidor.

Para esta entrada, realice unos códigos en Python en donde por medio de un servidor, abre una ventana en donde tenemos una imagen, y los clientes pueden controlar directamente esa imagen mandando comandos de 4 bytes por medio de sockets UDP.

En ambos códigos utilizo los siguientes comandos de 4 bytes, los empaqueto y los mando del cliente al servidor.

• INIT
• Este comando inicializa al momento de capturar un nuevo cliente en el servidor, se selecciona cuantas personas van a poder cambiar la imagen según cuantos INIT entraron al principio y el valor dado.

• EXIT
• Este comando sale de la aplicación y desconecta el socket.

• GRIS
• Este comando hace que la imagen se ponga en un estado de escala de grises.

• ORIG
• Este comando deshace las acciones anteriores y regresa a la imagen original.

• PROM
• Este comando saca un promedio de los pixeles vecinos, creando un efecto borroso.

• UMXX
• El comando umbral corresponde a un string de 4 bytes en donde:
• UM: indica que se va a realizar un umbral
• XX: son números parseados y anexados al comando dependiendo del valor del umbral escogido por el cliente mediante un slider.

Capturas de pantalla.

Comando PROM genera un efecto de borrado

Regresa a Original enviando comando ORIG

Genera un efecto de grises con el comando GRIS

Al momento de dar clic a umbral abre un slider en donde seleccionas la intensidad del umbral, se agrega al comando en los 4 bytes.

Diagramas de procedimiento.

Código servidor.



Código cliente.



Esto sería todo para la tarea 2, implementar un protocolo, espero que quede claro y si tienen alguna duda, favor de hacermela saber.

RFC 3315: DHCPv6

Para la clase de telecomunicaciones se nos pide realizar un reporte en donde expliquemos un RFC de las siglas Request for Comments, en donde encontraremos documentos de cada uno de los protocolos de la red y hacer un breve resumen sobre ello, es por eso que para esta entrada voy a escribir acerca del RFC 3315, el utilizado para el DHCPv6.


El DHCPv6 o en español el protocolo de configuración dinámica de host, es un protocolo utilizado para configurar nodos en alguna red, en donde se tiene una o mas direcciones IP versión 6, información de configuración de red o una o más prefijos IP versión 6.


Ofreciendo una función similar a la DHCPv4 pero para IPs versión 6 se especifica en el documento RFC que agrega modos adicionales de operación para el DHCPv6, uno el cual opera sin estado, en donde basicamente solo la información de configuración es intercambiada y un DHCPv6 que opera con estado, el cual funciona similar que el DHCPv4, esta no viene especificada en el RFC 3315, tiene su propio RFC, el 3736, cabe resaltar que esta versión 6 no es simplemente una actualización de la versión 4, el DHCPv6 es un protocolo separado y distinto al anterior, es por eso que tiene otro número de RFC.


Funcionamiento del DHCPv6

El funcionamiento del DHCPv6 empieza en el momento en el que el cliente escucha en el puerto 546 y los transmisores escuchan en el puerto 547, estos se comunican por medio de una liga local y direcciones multicast, entonces se puede decir que básicamente como se trabaja en este protocolo en un caso simple es de la siguiente manera:

• Un cliente envía una solicitud (SOLICIT) para encontrar servidores y dichos servidores están enviando mensajes indicando que están disponibles para el servicio (ADVERTISE), 

• Luego un cliente envía una solicitud para pedir los parámetros de configuración, (por ejemplo direcciones IPv6, prefijos IPv6, DNS, NIS, etc...) a los servidores con prioridad (REQUEST), dichos servidores son asignados según el administrador, 

• Para luego el servidor envíe una respuesta (REPLAY) con los permisos a las direcciones y a la información de configuración, si no responde, sigue buscando por orden de valoración hasta que se quede sin solicitudes, es cuando reinicia su búsqueda.

DHCPv6

Entre los requerimientos del RFC se encuentra el DUID, que es el DHCP Unique Identifier, es utilizado para identificar a los clientes, se utiliza un DUID para cada cliente DHCPv6, se especifican 3 diferentes DUID: 

• Dirección link-layer + el tiempo, es generada y guardada al inicio, 
• Link-layer sencilla, es usada si la interfaz de red es permanente y 
• Los que son generados por el fabricante.

Entre otros requerimientos del RFC también se encuentra la estructura de los mensajes los cuales se distribuyen de manera que la cabecera se divida en tres partes, 

• La información codificada en 32 bits, incluyendo el tipo de mensaje, el cual define la función a realizar y un identificador del intercambio. 
• Otra parte del mensaje incluye la información de direccionamiento y el campo de opciones.

En total DHCPv6 tiene 12 mensajes diferentes entre los cuales encontramos:

• DHCP Solicit: Mensaje de solicitud para saber si existen servidores DHCP.
• DHCP Advertise: Mensaje de respuesta en solicitud a un DHCP.
• DHCP Request: Solicitud de parámetros a un cliente sin dirección.
• DHCP Confirm: Mensaje de confirmación de validez de parametros.
• DHCP Renew: Mensaje para prolongar el uso de la dirección de IP.
• DHCP Rebind: Mensaje para prolongar el uso de otro servidor DHCP.
• DHCP Reply: Respuesta de petición de un cliente
• DHCP Release: liberación de direcciones IP.
• DHCP Decline: Mensaje para decir que ya hay direcciones asignadas.
• DHCP reconfigure-init: Mensaje para notificar la reconfiguración.

Al utilizar multicast en lugar de broadcast para procesar las solicitudes, lo veo como un punto positivo ya que solo se procesan solicitudes a los nodos que se requieran y no en todos los nodos a la vez, pero también de que existen todavía algunos sistemas operativos que no soportan el protocolo DHCPv6, entre ellos por ejemplo algunas versiones de Android y de Ubuntu, en donde se tiene que descargar herramientas aparte de las que ya vienen incluidas en el sistema, pero igual y esto irá cambiando con el tiempo, aparte algo que se quejan las personas que desarrollan los estándares es que DHCPv6 ya no da un gateway por defecto, por lo que todavía están en proceso de cambiar este problema para algunos, esto hace que no tengamos como anteriormente un mediador entre las redes.

Algunos aspectos diferentes entre el DHCPv4, es que la versión 6 únicamente es protocolo en capa 3,  esto es que todo el protocolo de DHCPv6 se hace en la capa de red, cuando para la asignación que se trabaja en la v4 es en la capa de aplicación, por lo que considero que, la versión 4 a mi parecer tiene mayor encaje al momento de entender cómo se trabaja en el protocolo, ya que considero que el servidor de DHCP es más que todo una aplicación a la red y no pertenece a la gestión de la red en sí.

Si deseas tener más información, puedes ver el RFC 3315

Redes de telecomunicaciones

Redes de telecomunicaciones