Aplicación de las redes definidas por software en el contexto del internet de las cosas

Texto completo

(1)UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA INGENIERÍA ELECTRÓNICA. PROYECTO DE GRADO MODALIDAD DE MONOGRAFÍA. Aplicación de las Redes Definidas por Software en el Contexto del Internet de las Cosas. Autores: Miguel Angel Baquero Rojas Fabián René Garcı́a Perdomo Director: Gustavo Adolfo Puerto Leguizamón. Bogotá, Julio 2018.

(2) Índice general Índice de figuras. 3. Índice de tablas. 6. Introducción. 7. 1. Generalidades 1.1. Justificación . . . . . . . . . 1.2. Objetivos . . . . . . . . . . 1.2.1. Objetivo General . . 1.2.2. Objetivos Especı́ficos 1.3. Alcances y limitaciones . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 2. Marco Teórico 2.1. Redes de sensores inalámbricos . . . . . . 2.1.1. Tipos de tecnologı́as implementadas 2.2. Internet de las cosas (IoT) . . . . . . . . . 2.3. Redes definidas por software . . . . . . . . 2.4. OpenFlow (OF) . . . . . . . . . . . . . . . 2.5. OpenvSwitch . . . . . . . . . . . . . . . . 2.6. Controladores SDN . . . . . . . . . . . . . 2.6.1. FLOODLIGHT . . . . . . . . . . . 2.6.2. OPENDAYLIGHT . . . . . . . . . 2.6.3. POX . . . . . . . . . . . . . . . . . 2.6.4. ONOS . . . . . . . . . . . . . . . . 2.7. Parámetros QoS . . . . . . . . . . . . . . . 2.7.1. Rendimiento (Throughput) . . . . 2.7.2. Retardo (Delay) . . . . . . . . . . . 2.7.3. Variabilidad (Jitter) . . . . . . . . 2.7.4. Tasa de paquetes perdidos . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 8 8 9 9 9 10. . . . . . . en WSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. 11 11 12 13 13 15 16 16 16 16 17 17 17 17 18 18 18. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 3. Antecedentes. 20. 4. Propuestas de topologı́as de red 4.1. Topologı́a 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2. Topologı́a 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 21 21 22. 5. Implementación 5.1. Instalación de Mininet . . . . . . . . . . . . 5.2. Creación del switch . . . . . . . . . . . . . . 5.2.1. OvS con interfaz Ethernet . . . . . . 5.2.2. OvS con interfaz Wi-Fi . . . . . . . . 5.2.3. OvS con interfaces Wi-Fi y Ethernet. 5.3. Instalación del controlador ONOS . . . . . . 5.3.1. Instalación en máquina virtual . . . .. 23 23 25 25 28 30 31 31. 1. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . ..

(3) 5.4. 5.5.. 5.6.. 5.7.. 5.8.. 5.3.2. Instalación en sistema operativo . . . . Programación de módulos Wi-Fi . . . . . . . . Herramientas software adicionales . . . . . . . 5.5.1. Iperf . . . . . . . . . . . . . . . . . . . 5.5.2. D-ITG . . . . . . . . . . . . . . . . . . 5.5.3. Nmon . . . . . . . . . . . . . . . . . . 5.5.4. FileZilla . . . . . . . . . . . . . . . . . 5.5.5. Protocolo SSH . . . . . . . . . . . . . . Montaje final . . . . . . . . . . . . . . . . . . 5.6.1. Topologı́a 1 . . . . . . . . . . . . . . . 5.6.2. Topologı́a 2 . . . . . . . . . . . . . . . 5.6.3. DHCP . . . . . . . . . . . . . . . . . . Protocolo de pruebas . . . . . . . . . . . . . . 5.7.1. Conexión entre hosts . . . . . . . . . . 5.7.2. Envı́o de datos . . . . . . . . . . . . . 5.7.3. Algoritmos para la comunicación Wi-Fi 5.7.4. Configuración FileZilla . . . . . . . . . 5.7.5. Medición . . . . . . . . . . . . . . . . . Emulación . . . . . . . . . . . . . . . . . . . .. 6. Resultados 6.1. Topologı́a 1 . . . . . . . . . . . . . . . . . . . 6.1.1. Variaciones del ancho de banda interfaz al sensor 1. . . . . . . . . . . . . . . . 6.1.2. Variaciones del ancho de banda interfaz al sensor 2. . . . . . . . . . . . . . . . 6.1.3. Variaciones del ancho de banda interfaz los sensores 3 y 4 . . . . . . . . . . . . 6.2. Topologı́a 2 . . . . . . . . . . . . . . . . . . . 6.2.1. Variaciones del ancho de banda interfaz 1 asociada al sensor 1. . . . . . . . . . 6.2.2. Variaciones del ancho de banda interfaz 1 asociada al sensor 3. . . . . . . . . . 6.2.3. Variaciones del ancho de banda interfaz 2 asociada al sensor 2. . . . . . . . . . 6.2.4. Variaciones del ancho de banda interfaz 2 asociada al sensor 4. . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . ethernet asociada . . . . . . . . . . . ethernet asociada . . . . . . . . . . . Wi-Fi asociada a . . . . . . . . . . . . . . . . . . . . . . ethernet del switch . . . . . . . . . . . Wi-Fi del switch . . . . . . . . . . . ethernet del switch . . . . . . . . . . . Wi-Fi del switch . . . . . . . . . . .. 34 37 41 42 42 43 44 45 46 46 47 48 50 51 51 52 52 54 54 59 59 59 65 71 76 76 81 84 90. 7. Posibles casos de uso 7.1. Entorno 1: Sistema de monitoreo para parámetros de un invernadero . . . . . . . . . . . . . . . . . . 7.2. Entorno 2: Sistema de monitoreo para parámetros de salas de servidores . . . . . . . . . . . . . . . .. 93. 8. Conclusiones. 96. Bibliografı́a. 98. 2. 93 94.

(4) Índice de figuras 2.1. 2.2. 2.3. 2.4. 2.5. 2.6.. Ejemplo de la red.[1] . . . . . . . . . . . . . . . Arquitectura LoRaWan. . . . . . . . . . . . . . Diagrama de control de una red.[2] . . . . . . . Diagrama de la solución planteada.[3] . . . . . . Diagrama de los componentes del protocolo .[4] Esquema OvS. . . . . . . . . . . . . . . . . . . .. . . . . . .. 11 12 13 14 15 16. 4.1. Topologı́a de red 1. . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2. Topologı́a de red 2 . . . . . . . . . . . . . . . . . . . . . . . . . .. 21 22. 5.1. Clonación del repositorio Git de Mininet. . . . . . . 5.2. Versiones de Mininet. . . . . . . . . . . . . . . . . . 5.3. Instalación OpenvSwitch. . . . . . . . . . . . . . . . 5.4. Instalación OpenFlow. . . . . . . . . . . . . . . . . 5.5. Instalación Mininet. . . . . . . . . . . . . . . . . . . 5.6. Creación topologı́a por defecto. . . . . . . . . . . . 5.7. Instalación adicional OpenvSwitch. . . . . . . . . . 5.8. Interfaces de red. . . . . . . . . . . . . . . . . . . . 5.9. Creación del switch Ethernet. . . . . . . . . . . . . 5.10. Resultados ’ifconfig’ switch Ethernet. . . . . . . . . 5.11. Visualización de los puentes creados. . . . . . . . . 5.12. Desmantelación del puente OvS. . . . . . . . . . . . 5.13. Instalación del editor de redes inalámbricas. . . . . 5.14. Puesta en marcha del editor. . . . . . . . . . . . . . 5.15. Despliegue de redes disponibles. . . . . . . . . . . . 5.16. Configuración las caracterı́sticas de la red Wi-Fi. . . 5.17. Conexión a una red inalámbrica oculta. . . . . . . . 5.18. Estado de conexión de la Raspberry. . . . . . . . . 5.19. Construcción switch Wi-Fi y Ethernet. . . . . . . . 5.20. Asignación puerto Ethernet. . . . . . . . . . . . . . 5.21. Resultados ’ifconfig’ switch Ethernet-Wi-Fi. . . . . 5.22. Despliegue menú VirtualBox . . . . . . . . . . . . . 5.23. Login de usuario ONOS. . . . . . . . . . . . . . . . 5.24. Aplicación para creación de los controladores. . . . 5.25. Creación de la red emulada. . . . . . . . . . . . . . 5.26. Login de usuario para la GUI. . . . . . . . . . . . . 5.27. Uso de la aplicación ’fwd’. . . . . . . . . . . . . . . 5.28. Repositorio ONOS-instalación en sistema operativo 5.29. Comandos iniciales para la ejecución de ONOS. . . 5.30. Comandos iniciales para la ejecución de ONOS. . . 5.31. Creación del controlador en el sistema operativo. . . 5.32. Procesos activos del controlador. . . . . . . . . . . . 5.33. Interfaz de lı́nea de comandos de ONOS. . . . . . . 5.34. Login de la interfaz gráfica de ONOS. . . . . . . . . 5.35. Interfaz gráfica de ONOS. . . . . . . . . . . . . . .. 23 24 24 24 24 25 25 26 26 27 27 27 28 28 28 29 29 30 30 30 31 31 31 32 33 33 34 34 34 34 35 35 35 36 36. 3. . . . . . .. . . . . . .. . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..

(5) 5.36. Creación de una red de prueba en Mininet. . . . . . . . . . . . . . 5.37. Conexión entre el controlador y la red. . . . . . . . . . . . . . . . 5.38. Visualización de la topologı́a de la red en la GUI. . . . . . . . . . 5.39. Programa NODEMCU FIRMWARE PROGRAMER-ESP8266 FLASHER. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.40. Carga del firmware en el flasher . . . . . . . . . . . . . . . . . . . 5.41. Configuración de los parámetros del módulo . . . . . . . . . . . . 5.42. Diagrama de puertos del módulo ESP8266[5]. . . . . . . . . . . . 5.43. Interfaz de carga de firmware finalizado. . . . . . . . . . . . . . . 5.44. Interfaz para instalación sobre el IDE arduino . . . . . . . . . . . 5.45. Instalación del asistente de tarjeta ESP8266 . . . . . . . . . . . . 5.46. Selección del tipo de placa . . . . . . . . . . . . . . . . . . . . . . 5.47. Configuración servidor iperf. . . . . . . . . . . . . . . . . . . . . . 5.48. Configuración transmisor iperf. . . . . . . . . . . . . . . . . . . . 5.49. Recepción del tráfico de red ITGRecv. . . . . . . . . . . . . . . . 5.50. Creación del tráfico de red ITGSend. . . . . . . . . . . . . . . . . 5.51. Lectura de los resultados ITGDec. . . . . . . . . . . . . . . . . . . 5.52. Interfaz gráfica Nmon. . . . . . . . . . . . . . . . . . . . . . . . . 5.53. Monitor consumo de los recursos del sistema y rendimiento de la red. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.54. Interfaz FileZilla FTP Client. . . . . . . . . . . . . . . . . . . . . 5.55. Interfaz FileZilla FTP Server. . . . . . . . . . . . . . . . . . . . . 5.56. Instalación del servidor y cliente SSH. . . . . . . . . . . . . . . . . 5.57. Consulta estado del protocolo SSH. . . . . . . . . . . . . . . . . . 5.58. Comandos para la creación del switch 1 con 4 interfaces ethernet. 5.59. Comandos para la creación del switch 1. . . . . . . . . . . . . . . 5.60. Comandos para la creación del switch 2. . . . . . . . . . . . . . . 5.61. Comandos para la creación del switch 3. . . . . . . . . . . . . . . 5.62. Creación del puente para el controlador. . . . . . . . . . . . . . . 5.63. Comando para habilitar la aplicación DHCP de ONOS. . . . . . . 5.64. Caracterı́sticas de DHCP de ONOS. . . . . . . . . . . . . . . . . . 5.65. Interfaz gráfica de ONOS. Topologı́a 1 . . . . . . . . . . . . . . . 5.66. Interfaz gráfica de ONOS. Topologı́a 2 . . . . . . . . . . . . . . . 5.67. Código implementado en los módulos Wi-Fi. . . . . . . . . . . . . 5.68. Código implementado en el servidor del host central. . . . . . . . 5.69. Conexión al servidor local FTP. . . . . . . . . . . . . . . . . . . . 5.70. Creación de los usuarios del servidor local FTP. . . . . . . . . . . 5.71. Selección de los archivos a compartir. . . . . . . . . . . . . . . . . 5.72. Comando de variación del ancho de banda . . . . . . . . . . . . . 5.73. Creación topologı́as en Mininet. . . . . . . . . . . . . . . . . . . . 5.74. Configuración del dispositivo central (servidor) en Mininet. . . . . 5.75. Configuración de los host (sensores) en Mininet. . . . . . . . . . . 5.76. Registro de los parámetros QoS a través de D-ITG. . . . . . . . .. 44 45 45 46 46 46 47 47 47 48 49 49 50 50 52 52 53 53 54 54 56 57 57 58. 6.1. 6.2. 6.3. 6.4.. 60 61 62 63. Throughput sensor 1-topologı́a PLR sensor 1-topologı́a 1. . . Delay sensor 1-topologı́a 1. . . Jitter sensor 1-topologı́a 1. . .. 1. . . . . . .. 4. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 36 37 37 38 38 38 39 39 40 40 41 42 42 43 43 43 44.

(6) 6.5. Throughput sensores ethernet en función del sensor 1-topologı́a 1. 6.6. Throughput sensores Wi-Fi en función del sensor 1-topologı́a 1. . 6.7. Throughput sensor 2-topologı́a 1. . . . . . . . . . . . . . . . . . . 6.8. PLR sensor 2-topologı́a 1. . . . . . . . . . . . . . . . . . . . . . . 6.9. Delay sensor 2-topologı́a 1. . . . . . . . . . . . . . . . . . . . . . . 6.10. Jitter sensor 2-topologı́a 1. . . . . . . . . . . . . . . . . . . . . . . 6.11. Throughput sensores ethernet en función del sensor 2-topologı́a 1. 6.12. Throughput sensores Wi-Fi en función del sensor 2-topologı́a 1. . 6.13. Throughput sensor 3-topologı́a 1. . . . . . . . . . . . . . . . . . . 6.14. Throughput sensor 4-topologı́a 1. . . . . . . . . . . . . . . . . . . 6.15. PLR sensor 3-topologı́a 1. . . . . . . . . . . . . . . . . . . . . . . 6.16. PLR sensor 4-topologı́a 1. . . . . . . . . . . . . . . . . . . . . . . 6.17. Throughput sensores ethernet en función de la interfaz Wi-Fitopologı́a 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.18. Throughput sensores Wi-Fi en función de la interfaz Wi-Fitopologı́a 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.19. Throughput sensor 1-switch 1-topologı́a 2. . . . . . . . . . . . . . 6.20. PLR sensor 1-switch 1-topologı́a 2. . . . . . . . . . . . . . . . . . 6.21. Delay sensor 1-switch 1-topologı́a 2. . . . . . . . . . . . . . . . . . 6.22. Jitter sensor 1-switch 1-topologı́a 2. . . . . . . . . . . . . . . . . . 6.23. Throughput sensores ethernet en función del sensor 1-topologı́a 2. 6.24. Throughput sensores Wi-Fi en función del sensor 1-topologı́a 2. . 6.25. Throughput sensor 3-switch 1-topologı́a 2. . . . . . . . . . . . . . 6.26. PLR sensor 3-switch 1-topologı́a 2. . . . . . . . . . . . . . . . . . 6.27. Throughput sensores ethernet en función del sensor 3-topologı́a 2. 6.28. Throughput sensores Wi-Fi en función del sensor 3-topologı́a 2. . 6.29. Throughput sensor 2-switch 2-topologı́a 2. . . . . . . . . . . . . . 6.30. PLR sensor 2-switch 2-topologı́a 2. . . . . . . . . . . . . . . . . . 6.31. Delay sensor 2-switch 2-topologı́a 2. . . . . . . . . . . . . . . . . . 6.32. Jitter sensor 2-switch 2-topologı́a 2. . . . . . . . . . . . . . . . . . 6.33. Throughput sensores ethernet en función del sensor 2-topologı́a 2. 6.34. Throughput sensores Wi-Fi en función del sensor 2-topologı́a 2. . 6.35. Throughput sensor 4-switch 2-topologı́a 2. . . . . . . . . . . . . . 6.36. Throughput sensores ethernet en función de sensor 4-topologı́a 2. 6.37. Throughput sensores Wi-Fi en función de sensor 4-topologı́a 2. . . 7.1. Topologı́a de la red para el monitoreo de un invernadero. . . . . . 7.2. Topologı́a de la red para el monitoreo de salas de servidores. . . .. 5. 64 65 66 67 68 69 70 70 71 72 73 74 75 75 76 77 78 79 80 80 81 82 83 84 85 86 87 88 89 89 90 91 92 94 95.

(7) Índice de tablas 5.1. Asignación manual de IP topologı́a 1. . . . . . . . . . 5.2. Asignación manual de IP topologı́a 2. . . . . . . . . . 5.3. Variables de los sensores en las pruebas con ancho de ninguna restricción. . . . . . . . . . . . . . . . . . . . 6.1. 6.2. 6.3. 6.4. 6.5.. . . . . . . . . banda . . . .. . . . . . . sin . . .. Comparación throughput sensor 1 ethernet. . . . . . . . . . . . . Comparación PLR sensor 1 ethernet. . . . . . . . . . . . . . . . . Comparación delay sensor 1 ethernet. . . . . . . . . . . . . . . . . Comparación jitter sensor 1 ethernet. . . . . . . . . . . . . . . . . Throughput implementación fı́sica de las interfaces asociadas a los sensores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6. Throughput emulación de las interfaces asociadas a los sensores. . 6.7. Comparación throughput sensor 2 ethernet. . . . . . . . . . . . . 6.8. Comparación PLR sensor 2 ethernet. . . . . . . . . . . . . . . . . 6.9. Comparación delay sensor 2 ethernet. . . . . . . . . . . . . . . . . 6.10. Comparación jitter sensor 2 ethernet. . . . . . . . . . . . . . . . . 6.11. Throughput implementación fı́sica de las interfaces asociadas a los sensores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.12. Comparación throughput sensor 3 Wi-Fi. . . . . . . . . . . . . . . 6.13. Comparación throughput sensor 4 Wi-Fi. . . . . . . . . . . . . . . 6.14. Comparación PLR sensor 3 Wi-Fi. . . . . . . . . . . . . . . . . . 6.15. Comparación PLR sensor 4 Wi-Fi. . . . . . . . . . . . . . . . . . 6.16. Throughput implementación fı́sica de las interfaces asociadas a los sensores ethernet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.17. Comparación throughput sensor 1 ethernet-switch 1. . . . . . . . 6.18. Comparación PLR sensor 1 ethernet-switch 1. . . . . . . . . . . . 6.19. Comparación delay sensor 1 ethernet-switch 1. . . . . . . . . . . . 6.20. Comparación jitter sensor 1 ethernet-switch 1. . . . . . . . . . . . 6.21. Throughput implementación fı́sica de las interfaces asociadas a los sensores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.22. Comparación throughput sensor 3 Wi-Fi-switch 1. . . . . . . . . . 6.23. Comparación PLR sensor 3 Wi-Fi-switch 1. . . . . . . . . . . . . 6.24. Throughput implementación fı́sica de las interfaces asociadas a los sensores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.25. Comparación throughput sensor 2 ethernet-switch 2. . . . . . . . 6.26. Comparación PLR sensor 2 ethernet-switch 2. . . . . . . . . . . . 6.27. Comparación delay sensor 2 ethernet-switch 2. . . . . . . . . . . . 6.28. Comparación jitter sensor 2 ethernet-switch 2. . . . . . . . . . . . 6.29. Throughtput implementación fı́sica de las interfaces asociadas a los sensores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.30. Comparación throughput sensor 4 Wi-Fi-switch 2. . . . . . . . . . 6.31. Comparación PLR sensor 4 Wi-Fi-switch 2. . . . . . . . . . . . . 6.32. Throughput implementación fı́sica de las interfaces asociadas a los sensores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 6. 49 49 56 59 60 61 62 63 64 65 66 67 68 69 71 72 73 73 74 76 77 78 78 79 81 82 83 84 85 86 87 88 90 91 91.

(8) Introducción El entorno tecnológico de hoy en dı́a está lleno de nuevos métodos cada vez más innovadores implementados en prácticamente todos los procesos a gran escala que se llevan a cabo a nivel industrial. Los procesos de monitoreo de estado de determinados parámetros y procesos, es un área muy importante en diversos campos: industria, sector agrı́cola, domótica, entre otros, de manera que las tecnologı́as encaminadas al monitoreo y control, han evolucionado mucho con el paso de los años. Alrededor de 1980, sectores militares empezaron iniciativas de investigación con respecto a las redes de sensores para el monitoreo, denominadas inicialmente como Redes de Sensores Distribuidos (DSN); hoy en dı́a encontramos el concepto de redes de sensores inalámbricos (WSN), los cuales son implementados en variados procesos como lo son procesos de agricultura de precisión, monitoreo de parámetros de camiones mineros, monitoreo en daños por fatiga en puentes de carreteras, procesos de temperatura en plantas de energı́a solar, entre otras muchas aplicaciones, todos estos aspectos se enmarcan en el concepto del Internet de las Cosas (IoT). Aun ası́, aunque dicho desarrollo tecnológico es muy prometedor, en este momento, cuenta con ciertas dificultades, como el hecho que la red responde ante los cambios del entorno que monitoreo, de manera que no se emplea adecuadamente los recursos con los que se cuenta, la falta de un control centralizado para una gran cantidad y variedad de dispositivos conectados, cada uno de ellos ejecutando aplicaciones de diferente ı́ndole hace que se deba recurrir a nuevas propuestas y paradigmas como los presentados por los futuros sistemas móviles de quinta generación. Con estos sistemas se busca la convergencia e interoperabilidad entre diferentes protocolos y tecnologı́as de comunicación con el fin de proveer flexibilidad y mayor capacidad a la hora de brindar soluciones de comunicación en entornos humano a máquina y máquina a máquina. Ası́, el paradigma de las redes definidas por software (SDN) ofrece una propuesta que soporta la interoperabilidad y escalabilidad en redes de sensores.. 7.

(9) 1. Generalidades 1.1.. Justificación. Se proyecta que las redes de sensores inalámbricos (Wireless Sensor Networks, WSN por sus siglas en inglés) tendrá alrededor de 20 millones de nodos conectados en el año 2020, esto deriva en la necesidad de un sistema de gestión centralizado y asignación de recursos flexible en función del servicio establecido. Este proyecto va orientado a abordar esta temática implementando conceptos de las redes de nueva generación tal como los futuros sistemas 5G, con el fin de determinar los alcances de las redes definidas por software en el contexto de sistemas IoT. Con el paradigma del IoT tomando cada vez más fuerza es fácil pensar en que en un futuro el mundo buscará estar totalmente interconectado no solo a nivel de dispositivos de computación y dispositivos móviles, sino que cada dispositivo que tenga la posibilidad de ser conectado a un sensor inalámbrico, estará conectado a redes convergentes de datos. Hay miles de posibilidades basadas en este concepto, desde el monitoreo del hogar a larga distancia, saber si alguien abre la puerta del apartamento mientras se está trabajando; hasta medir la presión por área en un puente vehicular para determinar periodos de mantenimiento. La implementación de sensores inalámbricos presenta ventajas que van mucho más allá del simple hecho de no estar conectados fı́sicamente, sino que presentan facilidades de configuración de parámetros especı́ficos del sensor. El paradigma de las SDN brinda un entorno que soporta completamente toda la idea planteada, donde es posible tener un control y monitoreo óptimo centralizado pensando en una red escalable que está en constantemente crecimiento y cambio, donde los recursos pueden ser modificados en función de los servicios ofrecidos por el sensor. Ası́, el crear un prototipo donde converja información, con los beneficios de la implementación de nuevas tecnologı́as y que podrá ser monitoreada en tiempo real o no, desde lugares remotos a través de la red es una idea que aporta al desarrollo de este concepto y se prepara para la llegada de toda esta nueva tecnologı́a.. 8.

(10) 1.2. 1.2.1.. Objetivos Objetivo General. Determinar la aplicabilidad de las redes definidas por software en un entorno de aplicación del Internet de las cosas.. 1.2.2.. Objetivos Especı́ficos. Identificar los estándares de comunicación en redes de sensores y las posibles plataformas hardware y software para su implementación. Reconocer los alcances y viabilidad de la implementación de un controlador para redes definidas por software. Evaluar la viabilidad de la implementación fı́sica del controlador de redes definidas por software. Determinar una topologı́a de red para identificar las caracterı́sticas que imponen una red definida por software en un entorno de aplicación para IoT. Comparar resultados entre la emulación e implementación real. Desarrollar un protocolo de pruebas que permita evaluar correctamente el funcionamiento de la red.. 9.

(11) 1.3.. Alcances y limitaciones. Cabe recalcar que el presente proyecto está encaminado principalmente a la implementación fı́sica de una red con control centralizado, de manera que como se mencionó anteriormente algunas actividades son fundamentales para el desarrollo de este. Algunas de estas son: implementación de un switch virtual a través de un sistema operativo, que soporte el protocolo de OpenFlow, gestión de los parámetros de dispositivos a través del controlador ONOS implementando el paradigma de las redes definidas por software (SDN). Sin embargo se debe mencionar que debido a las limitaciones económicas y de hardware, la topologı́a de red que se va a utilizar, será reducida en cuanto al número de elementos, y por ende a la cantidad de enlaces de la misma, por ende cuando se emule la red para la comparación de los resultados, se hará de igual de forma con una topologı́a reducida.. 10.

(12) 2. Marco Teórico 2.1.. Redes de sensores inalámbricos. Las redes de sensores inalámbricos (WSN) son compuestas por diferentes nodos de sensores equipados con interfaces de radio, que se encuentran ubicadas en una región en particular. Cada nodo mide diferentes variables y su trabajo es enviar dichas mediciones a un nodo coordinador, siguiendo un protocolo en particular para la comunicación entre estos [6]. En la figura 2.1, se puede apreciar un ejemplo de este tipo de redes.. Figura 2.1: Ejemplo de la red.[1] Mientras que muchos sensores se conectan directamente a los controladores y estaciones de procesamiento, un número creciente de sensores comunican los datos recogidos de forma inalámbrica a una estación de procesamiento centralizada. En muchas aplicaciones de red requieren múltiples nodos de sensores, en ocasiones implementados en áreas remotas e inaccesibles. Por lo tanto, un sensor inalámbrico no dispone únicamente de un componente de detección, sino también capacidades de procesamiento, comunicación y almacenamiento a bordo. Con estas mejoras, un nodo sensor a menudo no solo es responsable de la recopilación de datos, sino también del análisis dentro de la red de sus propios datos de sensores y datos de otros nodos de sensores. Cuando muchos sensores controlan conjuntamente grandes entornos fı́sicos, forman una red de sensores inalámbricos (WSN). Los nodos sensores se comunican no solo entre ellos sino también con una estación base (BS) que usa sus radios inalámbricas, lo que les permite transmitir sus datos de sensores a sistemas remotos de procesamiento, visualización, análisis y almacenamiento. [7]. 11.

(13) 2.1.1.. Tipos de tecnologı́as implementadas en WSN. 2.1.1.1.. ZigBee. ZigBee aprovecha en las ventajas de estándar IEEE, 802.15.4, el cual define especificaciones para conectividad inalámbrica de baja velocidad de datos entre dispositivos relativamente simples que consumen relativamente poco, funciona en bandas sin licencia en todo el mundo tales como: 2.4 GHz (global), 915 MHz (América) y 868 MHz (Europa). Se pueden lograr velocidades de procesamiento de datos sin procesar de 250 Kb a 2,4 GHz , 40 Kb a 915 MHz y 20 Kb a 868 MHz. Las distancias de transmisión varı́an de 10 metros a 100 metros, dependiendo de la potencia de salida[8]. 2.1.1.2.. LoRaWAN. LoRaWAN es una especificación de protocolo construida sobre la tecnologı́a LoRa desarrollada por LoRa Alliance. Utiliza el espectro de radio sin licencia en las bandas Industrial, Cientı́fica y Médica (ISM) para permitir la comunicación de baja potencia y gran área entre los sensores remotos y las puertas de enlace conectadas a la red. Este enfoque basado en estándares para construir una PWAN permite la configuración redes IoT a través de hardware (ver figura 2.2) y software seguro, interoperable y móvil [9].. Figura 2.2: Arquitectura LoRaWan. 2.1.1.3.. Thread. Thread permite conectar de manera fácil y segura cientos de dispositivos entre sı́ y directamente a la nube usando protocolos en una red de malla inalámbrica de baja potencia. Mientras que las tecnologı́as de red 802.15.4 tienen sus propias ventajas, también existe problemas como la incapacidad de soportar comunicaciones basadas IPv6.. 12.

(14) 2.1.1.4.. 802.11. 802.11 es un estándar para redes inalámbricas el cual permite throughput de 1-2 Mbps. Este estándar ofrece una conectividad inalámbrica para estaciones móviles que ofrece la posibilidad de configurar la red. Adicionalmente admite IR (infrarrojo) y frecuencia de radio como medios de transmisión. Para aumentar el rendimiento, el IEEE desarrolló tres extensiones de 802.11 (802.11b- 802.11a 802.11g) basado en nuevas técnicas de transmisión de RF [10].. 2.2.. Internet de las cosas (IoT). El internet de las cosas IoT (Internet of the Things por sus siglas en inglés) es un paradigma que define la interconexión de todo aquel dispositivo que puede tener la capacidad de asociarse a una red masiva de comunicaciones. El origen de este concepto se atribuye a miembros de la Auto-ID center del Instituto Tecnológico de Massachusetts donde se originó la comunidad de identificación por radio frecuencia RFID (Radio Frecuency Identification), alrededor del año 2000. Bajo el uso de esta tecnologı́a, se planteó la idea de interconectar una red de RFID, donde cada uno de estos contará con una etiqueta especı́fica de identificación y todos convergen en una base de datos [11].. 2.3.. Redes definidas por software. Las redes definidas por software SDN (Software Defined Networks por sus siglas en inglés), es un paradigma en relación al área de las redes que empieza a surgir aproximadamente entre el 2000 y el 2010 con el concepto de separar dentro de un switch el plano de control del plano de datos. Esto con el fin de obtener beneficios en implementación de servicios y reducción de gastos. Dentro de las redes tradicionales, se habla de dispositivos switch que contienen en sı́ mismos el plano de control y el plano de datos. Plano de control encargado de tomar decisiones respecto al enrutamiento y otros factores; y plano de datos encargado de ejecutar los mecanismos de envı́o [12].. Figura 2.3: Diagrama de control de una red.[2] Como se puede ver en la figura 2.3, cada dispositivo recibe datos en algún formato y el plano de control de cada uno de los dispositivos le dice que acción debe 13.

(15) tomar con dichos datos. De esta manera, el control de la red está distribuido a lo largo de esta y cada uno de los dispositivos es independiente de tomar decisiones respecto al manejo de los datos que recibe, ası́, si la red desea dirigir un mensaje a un lugar determinado, cada uno de los dispositivos tiene que tomar decisiones para llevar el mensaje a su destino. Esto crea una idea donde se puede pensar que hay cierto sobre esfuerzo de procesamiento en cada uno de los dispositivos al tener que repetir procesos de enrutamiento cada vez que el mensaje llega a un dispositivo nuevo, esto pensando en la red como un todo. Del mismo modo, si se piensa en agregar un dispositivo más a la red, significa que se agrega un proceso de decisión más, sin hablar de que incluirlo desde el contexto técnico significarı́a también, tener que hacer una nueva instalación y programación de dicho dispositivo, por lo tanto el hecho de que la red crezca significa una dificultad en varios contextos para el administrador de la red [13]. Las SDN ofrecen una solución a esto mediante una separación y centralización del plano de control.. Figura 2.4: Diagrama de la solución planteada.[3] Como se ilustra en la figura 2.4 las ’SDN’ proponen un control de dispositivo central al cual puede acceder el administrador de la red a través de interfaces de aplicación programables basadas en diferentes lenguajes. Ası́, el controlador de la red, se comunica con los dispositivos mediante un protocolo llamado OpenFlow. Ya que el paradigma es reciente, no todos los switch del mercado soportan este protocolo y aquellos que lo soportan derivan en una inversión considerable. Al igual que en la arquitectura tradicional, se tiene un plano de datos distribuido, con la diferencia de que este es dirigido por un solo controlador que toma decisiones para toda la red. Esto, convierte a la red en un sistema más eficiente al acelerar la implementación y distribución de aplicaciones, un sistema escalable, que es menos sensible a la variación de tamaño de la red [3]. 14.

(16) 2.4.. OpenFlow (OF). Pensando en el funcionamiento ya mencionado de las SDN [12], el protocolo que permite que esto se desarrolle es denominado OpenFlow. Este, es el protocolo ejecutado por Open Networking Forum (ONF) [14] que permite al controlador dar las ordenes a los dispositivos de enrutamiento, este también manipula el estado de configuración de los dispositivos de enrutamiento de paquetes. Este protocolo se puede dividir en 4 componentes básicos [4]: capa de mensaje, máquina de estados, interfaz de sistema y configuración (ver figura 2.5).. Figura 2.5: Diagrama de los componentes del protocolo .[4] La capa de mensajes es el núcleo de la pila de protocolos de OF. Esta capa define la estructura y semántica válida para todos los mensajes. Esta capa de mensajes tiene la capacidad de construir, copiar, comparar, imprimir y manipular mensajes. La máquina de estados define el comportamiento de bajo nivel del núcleo del protocolo. Tı́picamente, se usa para describir acciones como negociación entre dispositivos, descubrimiento de capacidad, control de flujo, entrega, recepción, entre otras cosas. La interfaz de sistema define como el protocolo que interactúa con el entorno que le rodea. Por lo general, identifica las interfaces necesarias y opcionales junto con las funciones que se le pueden asignar, como el uso de TLS y TCP como canales de transporte. A nivel de capa de configuración, casi todos los aspectos del protocolo tienen configuraciones o valores iniciales. La configuración puede abarcar desde tamaños de buffer predeterminados e intervalos de respuesta. Otra forma de considerar el protocolo OF es comprender su modelo de datos sub15.

(17) yacente. Cada interruptor mantiene un modelo de datos relacionales que contiene los atributos para cada abstracción de OF. Estos atributos describen una capacidad de abstracción, su estado de configuración o algún conjunto de estadı́sticas actuales [4].. 2.5.. OpenvSwitch. OpenvSwitch es un conmutador virtual multicapa de calidad de producción bajo licencia de código abierto Apache 2.0 . Está diseñado para permitir la automatización masiva de redes a través de la extensión programática, al tiempo que admite interfaces y protocolos de administración estándar (por ejemplo, NetFlow, sFlow, IPFIX, RSPAN, CLI, LACP, 802.1ag) [15].. Figura 2.6: Esquema OvS. OvS, brinda la posibilidad de crear sobre una dirección IP definida un puente virtual que puede dar acceso a diferentes puertos o interfaces de un mismo dispositivo lo cual es una herramienta muy útil cuando el usuario desea tener acceso a un dispositivo, la red usa una misma dirección IP desde diferentes máquinas virtuales con interfaces virtuales diferentes. También permite asignar a diferentes interfaces reales de un dispositivo la misma interfaz virtual, de modo que permite tener una gran interfaz IP con diferentes puertos de recepción (Ver figura 2.6).. 2.6. 2.6.1.. Controladores SDN FLOODLIGHT. ’Floodlight’ no es solamente otro controlador OpenFlow, puesto que integra adicionalmente aplicaciones que permiten controlar y consultar parámetros especı́ficos de la red, y por medio de algunas herramientas que ofrece poder resolver necesidades del usuario a través de la red [16].. 2.6.2.. OPENDAYLIGHT. ’OpenDaylight’ es una infraestructura de controlador altamente disponible, modular, extensible, escalable y multi-protocolo construida para implementaciones SDN en redes modernas de múltiples proveedores heterogéneas. ’OpenDay16.

(18) light’ proporciona una plataforma de abstracción de servicios impulsada por modelos que permite a los usuarios escribir aplicaciones que funcionen fácilmente en una amplia variedad de hardware y protocolos orientados al plano de datos [17].. 2.6.3.. POX. ’POX’ proporciona un método para comunicarse con los switch SDN utilizando el protocolo ’OpenFlow’. Los desarrolladores pueden usar ’POX’ para crear un controlador SDN utilizando el lenguaje de programación ’Python’. Los componentes de ’POX’ son programas adicionales que se pueden ejecutar cuando se inicia el controlador desde la lı́nea de comando, estos componentes implementan la funcionalidad de red en la red definida por software [18].. 2.6.4.. ONOS. ’ONOS’ (Open Network Operating System) proporciona el plano de control para una red definida por software (SDN), adicionalmente administra los componentes de red, como switch y enlaces, y ejecuta aplicaciones que se traducen en diferentes servicios. ONOS puede ejecutarse como un sistema distribuido en múltiples servidores, permitiéndole usar la CPU y los recursos de memoria de múltiples servidores, al mismo tiempo que brinda tolerancia a fallas ante fallas del servidor [19]. ’ONOS’ y ’OpenDaylight’ son los controladores más destacados. Estos dos controladores están codificados en ’Java’ ambos presentan una excelente ’GUI’. Al estar bajo la asociación de conocidos proveedores de redes y comunidades de investigación, tienen un plan de desarrollo claro y una buena documentación. Además, su compatibilidad con el esquema distribuido les permite realizar una implementación real de ’SDN’. La arquitectura ’ONOS’ está diseñada para mantener redes de alta velocidad y gran escala. Su principal caracterı́stica distintiva es su soporte para redes hı́bridas [20].. 2.7.. Parámetros QoS. La Calidad de Servicio (QoS), se puede entender como la medida del comportamiento de la capacidad de la red con respecto a ciertas caracterı́sticas de los servicios definidos, o como la capacidad de una red para proveer mejor servicio para un determinado tipo de tráfico. Los parámetros relacionados con QoS son: ancho de Banda, nivel de retardo, variación del retardo o jitter, rendimiento o throughput, pérdida de paquetes. Basándose en las polı́ticas de QoS, la red debe garantizar que tiene la capacidad de ofrecer un nivel de Calidad de Servicio para cierto tráfico con un conjunto especificado de parámetros [21].. 2.7.1.. Rendimiento (Throughput). Este parámetro especifica cuantos datos (máximo o media) son transferidos a través de la red. Esta medida se da en referencia a un tiempo determinado con 17.

(19) unidades de bits/s o pps. El Throughput es medido después de la transmisión de datos porque un sistema añade retardo causado por limitaciones del procesador, congestión de la red, ineficiencias del proceso de almacenamiento de datos en los buffers, transmisión de bits errados, carga de tráfico, hardware inadecuado. El Throughput varı́a con el tiempo durante la transmisión de datos debido al tráfico y la congestión.. 2.7.2.. Retardo (Delay). El retardo en transmisión o delay es usualmente definido como el tiempo que transcurre entre la emisión de los datos, hasta el momento en que llegan al receptor. El retardo es una medida que expresa el tiempo gastado en el subsistema de comunicación. Este parámetro es también conocido en el ámbito de las telecomunicaciones como latencia (latency). La causa de este retardo es que cuando la data es procesada esta fluye a través de una gran cantidad de componentes y subsistemas de comunicación, situados en el sistema receptor, ası́ como en la red. Cada uno de esos componentes pueden ser caracterizados por su velocidad de procesamiento y por la capacidad de almacenamiento (buffers) donde los datos esperan para ser procesados. La suma de todas las contribuciones de retardos individuales vista como un todo es lo que genera el parámetro reconocido como retardo. El máximo retardo que es el que ocurre de extremo a extremo conocido como mouth-to-ear (de boca a oı́do) recomendado para conversaciones en tiempo real no debe exceder los 150 ms [21]. Este retardo se calcula como el promedio de los retardos paquete a paquete [22]. Pn. i=1 xi. n. (2.1). xi : Retardo del i-ésimo paquete. n: Cantidad de paquetes.. 2.7.3.. Variabilidad (Jitter). El retardo por jitter o simplemente jitter es usualmente definida como la variación en el tiempo de llegada al punto receptor, sufrida entre paquetes de datos sucesivos [23].. √Pn. − n ∗ D2 n−1. i=1 xi. 2. (2.2). xi : Retardo del i-ésimo paquete. n: Cantidad de paquetes. D: Delay.. 2.7.4.. Tasa de paquetes perdidos. La pérdida de paquetes ocurre cuando uno o más paquetes de datos que viajan en una red IP fallan en alcanzar su destino. La causa de la pérdida de paquetes es 18.

(20) debido a varios factores, entre los que se puede nombrar: degradación de la señal al viajar por el medio, interconexiones de la red sobre-saturadas, paquetes con error rechazados en el tránsito, falla en el hardware de la red o rutinas normales de enrutamiento. Cuando la pérdida de paquetes es causada por problemas en la red, los paquetes perdidos pueden resultar en problemas de desempeño que causen fallas notables en el desempeño de esta, sin embargo, la pérdida de paquetes no siempre es tan dañina, como por ejemplo cuando es usada para contrarrestar la latencia [23].. 19.

(21) 3. Antecedentes Dentro del entorno de las redes definidas por software se pueden encontrar aplicaciones enfocadas a la configuración de recursos y virtualización, donde comúnmente el controlador SDN es el encargado del corte de slice de recursos en un entorno. En ’Flowvisor: A network virtualization layer’ [24] R. Sherwood et al. Hacen una combinación entre el concepto de virtualización y SDN creando una arquitectura llamada ’Flowvisor’ cuyo objetivo es crear slices como múltiples subredes lógicas donde cada red está completamente aislada de las demás con el fin de optimizar recursos de red y ofrecer servicios diferenciados a diferentes usuarios. En esta arquitectura hay un controlador de red dedicado a cada slice con ’Flowvisor’ actuando como monitor y árbitro interceptando los mensajes entre el plano de control y el plano de datos. Ası́ mismo, en ’Scalable network virtualization in software-defined networks’ [25] se presenta una arquitectura en donde se abandona el concepto de múltiples controladores propuesto por Flowvisor. El proyecto recibe el nombre de FlowN. En esta propuesta se tiene una centralización donde cada usuario ve su red virtual como independiente. A cada usuario se le otorga total libertad respecto a su propia topologı́a y le brinda una dirección exclusiva dentro de una red virtual con una dirección de máquina global a la que solamente el controlador puede acceder. El controlador da instrucciones a los switch de manera tal que estos se encarguen de encapsular los paquetes recibidos en función de las identificaciones VLAN de cada cliente. Ası́, cada usuario tiene acceso a una red especı́fica sin interferir en las aplicaciones de las demás redes virtuales. Como parte de la aplicación FlowN todos los datos respecto a las direcciones de capa fı́sica y el mapeo entre los enlaces virtuales se almacenan en una base de datos SQL. Con base en esta información el controlador maneja los paquetes de cada red virtual.. 20.

(22) 4. Propuestas de topologı́as de red Teniendo en cuenta las limitaciones a nivel de hardware para el desarrollo del presente proyecto, se plantean dos topologı́as cuyas implementaciones son posibles, a continuación se describen la composición de cada una de ellas.. 4.1.. Topologı́a 1. Se propone como primera arquitectura: un switch con una interfaz Wi-Fi y cuatro interfaces ethernet, y cuatro sensores. Un dispositivo central (servidor), el cual tendrá acceso a toda la información transmitida en la red , este estará conectada a una de las interfaces ethernet, mientras otras dos de estarán siendo usadas por dos hosts que actuaran como sensores ethernet. La interfaz Wi-Fi será implementada para establecer una conexión que permita el intercambio de datos directos entre los módulos Wi-Fi y el dispositivo central (servidor). El switch implementado soportará el protocolo OpenFlow, será controlado y monitoreado por ONOS desde un dispositivo externo conectado a través de la interfaz ethernet restante. El controlador a usar será ONOS, dado que este ofrece la posibilidad de ser implementado en una topologı́a real, brinda facilidades al usuario que el resto de controladores no ofrecen, provee una gama de aplicaciones que al ser un controlador esta regido por polı́tica, aplicaciones que ofrecen al usuario la posibilidad de monitorear aparte de controlar el funcionamiento de la red. Estas herramientas de monitoreo aportan a las aplicaciones planteadas en esta sección.. Figura 4.1: Topologı́a de red 1.. 21.

(23) 4.2.. Topologı́a 2. Se propone como segunda arquitectura: tres switch conectados en delta a través del controlador, donde dos de los switch tendrán dos sensores asociados por switch y uno de ellos estará conectados al dispositivo central (servidor) que tendrá acceso a todos los datos recogidos por la red. A cada uno de los switch se conecta un módulo Wi-Fi y un host que actuara como sensor ethernet. Ası́ mismo, cada uno de los switch soportará OpenFlow y será conectados al controlador a través de ethernet. En esta arquitectura los tres switch convergen al controlador ’ONOS’.. Figura 4.2: Topologı́a de red 2 Pensando en la implementación de ambas topologı́as y observando las posibilidades que ofrece el paradigma de las SDN, se puede pensar en la aplicabilidad del concepto de virtualización [26] de la red para ver el impacto que puede tener en la implementación real el hecho de gestionar anchos de banda. Ya que las redes de los entornos planteados cuentan con diferentes tipos de tecnologı́as de comunicación, el variar la capacidad de las interfaces puede tener un impacto tanto en capacidad de enrutamiento por parte de los switch, como en la capacidad de procesamiento por parte de los dispositivos que albergan los switch y host. El uso de dos tecnologı́as diferentes permite analizar la gestión de los recursos de la red.. 22.

(24) 5. Implementación La problemática que se planteó es la implementación de un controlador para una red enfocada al internet de las cosas, y las redes de sensores, mediante herramientas que serán descritas a continuación, se llevo a cabo la implementación fı́sica. En este proyecto, se hizo uso de un sistema operativo de software libre, ya que estas distribuciones ofrecen muchas facilidades tecnológicas en cuanto a las SDN. Debido a que el enfoque con el que se desarrolló el presente proyecto fue la implementación de una red real, se determinó utilizar como contenedor de los dispositivos ’switch’ un sistema embebido como lo es la ’RASPBERRY PI 3’ [27], ya que, es un computador de placa reducida, permite hacer uso de las herramientas que el software libre ofrece a través de un dispositivo práctico para la implementación de la red. Para esto se escogió el sistema operativo ’Ubuntu’ [28] en tanto que, al llevar a cabo los procesos ilustrados a continuación en la distribución nativa ’raspbian’ creada para la ’RASPBERRY PI 3’ hubo ciertos problemas al momento de establecer los puentes virtuales OvS, problemas que no se presentaron al trabajar sobre ’Ubuntu’. Puesto que el paradigma de las redes definidas por software define un plano de datos y de control separados que se comunican a través del protocolo ’OpenFlow’. Lo primero consistió en definir un método para construir un switch que interprete dicho protocolo y pueda ser instalado sobre un sistema embebido. Esto se hizo a través del software OpenvSwitch [29] con el cual se crean los puentes de comunicación. Como herramienta de simulación para la implementación real de la red se utilizó el emulador de SDN’s Mininet [30]. A continuación, se muestra el proceso de instalación y creación de las herramientas que permitieron hacer la implementación real de la red.. 5.1.. Instalación de Mininet. Para la instalación del emulador ’Mininet’, se siguieron los siguientes pasos: al iniciar el proceso es necesario tener instalado el software git, al usar una distribución basada en Debian se hace con el comando: ’sudo apt-get install git’. Como primera medida se debe obtener una copia de un repositorio Git de ’Mininet’, como se muestra en la figura 5.1.. Figura 5.1: Clonación del repositorio Git de Mininet. Puesto que existen diferentes versiones de ’Mininet’, el repositorio provee un comando que permite visualizarlas, el cual se puede apreciar a continuación.. 23.

(25) Figura 5.2: Versiones de Mininet. Al ejecutar esta lı́nea, se habrá clonado una carpeta llamada ’mininet’, en la cual se encontrará el directorio ’util’ donde estará el archivo ’install.sh’ el cual permite instalar aplicaciones particulares de ’Mininet’. Para ejecutar el archivo ’install.sh’ se debe hacer uso de la siguiente lı́nea mostrada en la figura 5.5. Dependiendo de lo que se desee utilizar, el software ofrece múltiples opciones (ver figuras 5.3 y 5.4). Al usar la opción ’–a’ se instala todo lo que incluye Mininet. En caso de complicaciones se puede usar la opción ’help’ para ver un menú de ayuda al respecto de como realizar el procedimiento.. Figura 5.3: Instalación OpenvSwitch.. Figura 5.4: Instalación OpenFlow.. Figura 5.5: Instalación Mininet. Al finalizar la instalación, se puede ejecutar el siguiente comando (ver figura 5.6) para verificar que se haya instalado correctamente el software, el cual genera una topologı́a por defecto y efectúa pruebas ICMP por medio de ping entre los hosts.. 24.

(26) Figura 5.6: Creación topologı́a por defecto.. 5.2.. Creación del switch. Como se mencionó anteriormente se implementó el OpenvSwitch en ’Raspberry Pi 3’ modelo B, para esto se trabajó con el sistema operativo de Ubuntu Mate. Es necesario mencionar que se implementaron tres tipos de switch, en función de sus interfaces, a continuación, se explica cómo se crearon y cuáles son.. 5.2.1.. OvS con interfaz Ethernet. En el primer switch implementado únicamente se hizo uso de la interfaz ethernet, para esto fue necesario instalar los paquetes OpenvSwitch, como se puede ver en el siguiente comando (ver figura 5.7).. Figura 5.7: Instalación adicional OpenvSwitch. Para la creación del switch, es importante tener en cuenta las diferentes interfaces de red que posee el dispositivo, en este caso la ’Raspberry Pi 3’; En la figura 5.8 se visualiza las diferentes interfaces, donde ’enp8s0’ es la que corresponde a ethernet, ’lo’ es la interfaz de red virtual, y por ultimo ’wlo1’ es la tarjeta de red inalámbrica.. 25.

(27) Figura 5.8: Interfaces de red. Posteriormente se crea un enlace o puente en el switch, se habilita esta nueva ‘interfaz’, se añade el puerto ethernet al enlace, luego se asigna la IP 192.168.0.1 con mascara de 24 bits al switch, se deshabilita el puerto ethernet para que no entre en conflicto con el puente, y se le atribuye la dirección MAC al switch, todos los comandos se pueden apreciar a continuación.. Figura 5.9: Creación del switch Ethernet. Para validar que el procedimiento anterior se haya realizado de manera exitosa, se vuelven a verificar las interfaces de red con el comando ’ifconfig’ (Ver figura 5.10), donde debe aparecer el nuevo puente con la IP asignada anteriormente, la MAC del puerto ethernet, y la interfaz ‘enp8s0’ no debe tener ninguna dirección, se hace especial énfasis en esto puesto que si ambas tienen IP, entra en conflicto los puertos de red.. 26.

(28) Figura 5.10: Resultados ’ifconfig’ switch Ethernet. Existe otro comando que permite visualizar los puentes creados, y sus caracterı́sticas, las cuales son los puertos asociados al puente y la versión del OpenvSwitch, como se ve en la siguiente figura:. Figura 5.11: Visualización de los puentes creados. Para finalizar, si se quiere eliminar el puente o enlace, se puede llevar a cabo haciendo uso del software OvS, como se aprecia en la siguiente figura.. Figura 5.12: Desmantelación del puente OvS.. 27.

(29) 5.2.2.. OvS con interfaz Wi-Fi. Para el desarrollo de esta etapa, se requiere instalar un editor de redes inalámbricas, luego de realizar la búsqueda en la literatura disponible, se seleccionó el editor ’plasma-nm’ [31] , como se puede ver en figura 5.13.. Figura 5.13: Instalación del editor de redes inalámbricas. Posterior a la instalación, se hizo uso del editor, se recomienda estar al tanto de la versión que se haya instalado, puesto que sin esta información no es posible acceder a este, en la siguiente figura se muestra el comando con el que se ejecuta.. Figura 5.14: Puesta en marcha del editor. El editor despliega una lista de las redes disponibles para el sistema, se debe seleccionar la opción de añadir, y escoger ‘Wi-Fi Compartida’ entre las diferentes posibles.. Figura 5.15: Despliegue de redes disponibles. Adicionalmente se deben configurar las caracterı́sticas de la red Wi-Fi que fue creada, tales como el nombre, la banda de frecuencia, y si se desea la seguridad de la red (ver figura 5.16).. 28.

(30) Figura 5.16: Configuración las caracterı́sticas de la red Wi-Fi. Después de esto la red ya esta creada, ahora el dispositivo se debe conectar a su propia red, para ello se debe seleccionar la opción de ‘Conectar a una red inalámbrica oculta’, y seleccionar la red creada, como se puede apreciar en las siguientes imágenes.. Figura 5.17: Conexión a una red inalámbrica oculta. Para verificar que la conexión se realizo correctamente, se corrobora que la Raspberry este conectada a la red creada con antelación (ver figura 5.18).. 29.

(31) Figura 5.18: Estado de conexión de la Raspberry.. 5.2.3.. OvS con interfaces Wi-Fi y Ethernet.. Para finalizar con los switch, se explicará como se instala el último y con el cual se trabajo en las pruebas que se presentaran en los siguientes capı́tulos, para esto se repite el procedimiento de la sección 3.2.1 al crear el puente, con la salvedad que se debe añadir el puerto ‘wlo1’ que corresponde a la tarjeta de red inalámbrica del dispositivo, esta se debe deshabilitar, se puede asignar la MAC del puerto Ethernet o Wi-Fi al switch como se puede apreciar en la figura 5.19.. Figura 5.19: Construcción switch Wi-Fi y Ethernet. Se asigna el puerto Ethernet, y se visualiza el puente para ver que los puertos hayan sido asociados correctamente (ver figura 5.20).. Figura 5.20: Asignación puerto Ethernet. Por último para verificar que las direcciones IP y la MAC fueron asignadas exitosamente, se implementa el comando ’ifconfig’ seguido del nombre del puente, como se puede ver a continuación.. 30.

(32) Figura 5.21: Resultados ’ifconfig’ switch Ethernet-Wi-Fi.. 5.3.. Instalación del controlador ONOS. El controlador ONOS proporciona dos posibles formas de instalación, la primera en una maquina virtual, y la segunda en un sistema operativo, explicadas a continuación:. 5.3.1.. Instalación en máquina virtual. Como lo menciona el tutorial de ’ONOS’ [19], para esta instalación en particular, es necesario contar con el software ’Oracle VM VirtualBox’ [32] y adicionalmente ’ONOS’, que se puede encontrar en este enlace: ‘downloads.onosproject.org/vm/onos-tutorial-1.13.1.ova’. Se ejecuta este instalador, a continuación se despliega un menú de ’VirtualBox’, se escoge la opción ’importar’ y el controlador se instalará como un sistema operativo, esto se verifica en la figura 5.22.. Figura 5.22: Despliegue menú VirtualBox Al iniciar el controlador en la máquina virtual, se solicita una contraseña la cual es ’rocks’ por defecto (ver figura 5.23).. Figura 5.23: Login de usuario ONOS. 31.

(33) Cabe mencionar que esta modalidad de instalación es recomendada únicamente como un método para reconocer las herramientas que brinda el controlador, a continuación se explica el ejemplo básico que brinda la comunidad de ’ONOS’ como primer paso dentro del proceso de inmersión al software. Se debe seleccionar la aplicación de ’Setup ONOS Cluster’, para iniciar el controlador, una vez se hayan creado los controladores, la misma terminal desplegará la CLI (consola de comandos de ’ONOS’) del controlador como se observa en la figura 5.24.. Figura 5.24: Aplicación para creación de los controladores. Como paso siguiente, se crea una red emulada con MININET (ver figura 5.25), para esto es necesario conocer la IP del controlador, que puede ser consultada con el comando ’ifconfig’.. 32.

(34) Figura 5.25: Creación de la red emulada. Para hacer uso de la herramienta visual que provee el controlador que se denomina GUI (Interfaz de usuario gráfica), se selecciona esta aplicación del escritorio, la cual solicitara un usuario y contraseña, que por defecto son ’ONOS’ y ’rocks’ como se observa en la figura 5.26.. Figura 5.26: Login de usuario para la GUI. Por último para que aparezcan los ’hosts’ en la GUI de ONOS, es necesario que se establezca una comunicación entre ellos, para ello se activa la aplicación ’org.onosproject.fwd’ que establece la comunicación entre ellos, si se desactiva la aplicación la comunicación entre ellos queda inhabilitada (ver figura 5.27).. 33.

(35) Figura 5.27: Uso de la aplicación ’fwd’.. 5.3.2.. Instalación en sistema operativo. La instalación del controlador ONOS se puede hacer a través de diferentes métodos, en este proyecto se realizó a través del sistema de compilación ’buck’. Se hace uso de git, para clonar carpetas directamente desde los repositorios de ’ONOS’. Este procedimiento se logra al ejecutar el siguiente comando para clonar las carpetas de ’ONOS’ (ver figura 5.28).. Figura 5.28: Repositorio ONOS-instalación en sistema operativo Al finalizar la clonación, se habrá construido una carpeta llamada ’onos’, se accede por medio del comando ’cd onos’. Posteriormente, se ejecutan dos comandos (ver figuras 5.29 y 5.30) que el sistema operativo implementará de forma automática cuando se den ciertas condiciones de ’ONOS’.. Figura 5.29: Comandos iniciales para la ejecución de ONOS. A partir de esto, se construye ’ONOS’ desde cero con la siguiente lı́nea de código, esto sin salir del directorio de ’ONOS’.. Figura 5.30: Comandos iniciales para la ejecución de ONOS. Al finalizar el proceso de construcción, se habrá creado todo lo necesario para la ejecución del servicio de ’ONOS’. La manera en la que se ha instalado, exige. 34.

(36) que el proceso de ’ONOS’ se inicie y se mantenga latente a lo largo de todo el uso del controlador (ver figura 5.31).. Figura 5.31: Creación del controlador en el sistema operativo. Es pertinente recordar que cada vez que se vaya a usar el controlador es necesario ejecutar este comando y mantener el proceso activo.. Figura 5.32: Procesos activos del controlador. Al terminar el proceso, quedarán mensajes de información en la consola, estos mensajes brindan información de lo que está ejecutando respecto al controlador. Para iniciar la interfaz de lı́nea de comandos CLI, se hace uso del comando ’onos localhost’ por fuera del directorio ’onos’ como se ve en la figura 5.33.. Figura 5.33: Interfaz de lı́nea de comandos de ONOS. Para acceder a la interfaz gráfica de ’ONOS’, se debe abrir el navegador y acceder a la siguiente dirección URL ’ direcciónIP :8181/onos/ui/login.html’. En el ejemplo mostrado a continuación (ver figura 5.34) se hizo uso la dirección ’localhost’, sin embargo es posible ingresar mediante las direcciones IP asignadas a las interfaces de red.. 35.

(37) Figura 5.34: Login de la interfaz gráfica de ONOS. ’ONOS’ tiene como objetivo futuro personalizar cada una de las sesiones de sus usuarios, por lo tanto, plantea un esquema de usuario y contraseña; a pesar de esto, en el momento no se encuentra disponible este servicio, de modo que solo hay un usuario el cual es ‘ONOS’ y la contraseña de acceso es ‘rocks’, como se ha comentado anteriormente.. Figura 5.35: Interfaz gráfica de ONOS. Para verificar que el controlador este funcionando correctamente, el método ideal es crear una red y conectarla a este, a través de Mininet (ver figura 5.36).. Figura 5.36: Creación de una red de prueba en Mininet. En este proyecto la red estuvo alojada en el mismo equipo que el controlador, por lo cual se utilizó la IP ’localhost’ para asignarlo, como se observa en 36.

(38) la figura 5.38 se despliega un mensaje que corrobora que este proceso se ejecuto correctamente.. Figura 5.37: Conexión entre el controlador y la red. Al haber asignado correctamente el controlador a la SDN, se puede visualizar la red en la interfaz gráfica de ’ONOS’.. Figura 5.38: Visualización de la topologı́a de la red en la GUI.. 5.4.. Programación de módulos Wi-Fi. Para cumplir los objetivos del proyecto, se implementaron los módulos de comunicación Wi-Fi ’ESP8266’ [33], debido a que es un microcontrolador con capacidades de conexión Wi-Fi y comunicación a través del protocolo TCP/IP. Este tipo de módulos deben ser programados a través de comandos ’AT’ [34] utilizando comunicación serial. Uno de los beneficios que ofrece el uso este módulo es que soporta un firmware de ’Arduino’ [35], permitiendo ası́ configurarlo como un microcontrolador tradicional. El módulo no contiene por defecto el firmware de ’Arduino’, de modo que se cargó el firmware con la aplicación ’NODEMCU FIRMWARE PROGRAMERESP8266 FLASHER’. (ver figura 5.39).. 37.

(39) Figura 5.39: Programa NODEMCU FIRMWARE PROGRAMER-ESP8266 FLASHER. Posteriormente, se seleccionó la versión de firmware como se observa en la figura 5.40, se aconseja utilizar ’AI-v0.9.5.0 AT Firmware.bin’ este se adquiere fácilmente en la red.. Figura 5.40: Carga del firmware en el flasher Una vez seleccionado el firmware, se configuran las caracterı́sticas del módulo como muestra en la figura 5.41. El baudrate por defecto del módulo puede ser de 9600 o 115200 baudios. Para verificar el valor de este parámetro se puede conectar el módulo a un terminal serial y ası́ consultar con que baudrate esta configurado.. Figura 5.41: Configuración de los parámetros del módulo Para programar el módulo fue necesario utilizar un módulo ’USB-Serial’ y conectar la placa de manera apropiada. El módulo trabaja con 3.3 V, es importante energizarlo con la fuente adecuada, ya que, en caso contrario no se puede cargar la Flash. 38.

(40) La placa cuenta con 8 pines: el pin ’VCC’ y ’ENABLE’ que requieren una alimentación de 3.3 V, ’Tx’ y ’Rx’ deben ir conectados al conversor ’USB-Serial’, y ’GND’ a tierra. Para el proceso de escribir sobre la flash, es necesario colocar el pin ’GPIO0’ a tierra para ingresar al modo de escritura de la memoria flash del módulo (ver figura 5.42).. Figura 5.42: Diagrama de puertos del módulo ESP8266[5]. Una vez conectado el módulo Wi-Fi de manera apropiada, se escoge el puerto ’COM’ al cual está conectado y se selecciona la opción ‘Flash’ en la pestaña ’Operation’ de la aplicación, como se ve en la figura 4.43.. Figura 5.43: Interfaz de carga de firmware finalizado. Si el proceso se desarrolló correctamente, se evidenciará que la barra de avance se ha completado y aparecerá un testigo en color verde. Si en algún momento se visualiza un sı́mbolo de ’stop’ rojo en la parte inferior izquierda de la interfaz, significa que el proceso ha fallado , y se debe reiniciar la placa para volver a cargar el firmware. El siguiente paso a seguir es acondicionar el ’IDE’ de Arduino para identificar la placa ’ESP8266’, esto se logró accediendo a la pestaña de archivo del ’IDE’ y se escogió en la opción de preferencias. En este cuadro emergente, se ingresó en la sección ‘Gestor de URLs Adicionales de Tarjetas’ el siguiente enlace [?]: http://arduino.esp8266.com/stable/package esp8266com index.json. 39.

(41) Figura 5.44: Interfaz para instalación sobre el IDE arduino Luego de esto, se seleccionó la pestaña de ’Herramientas’, y en la opción de ’Placa:’ se escogió ’Gestor de tarjetas’. Al final de esta ventana emergente se encontró el paquete que soporta el módulo, se debe instalar la versión ’1.6.5-947g38919f0’, puesto que las otras versiones presentan problemas.. Figura 5.45: Instalación del asistente de tarjeta ESP8266 Ahora, al dirigirse a la pestaña de ’Herramientas’, en la opción ’Placa:’ se encuentra la opción ’Generic ESP8266 module’ la cual fue implementada. De manera que, el módulo es reconocido finalmente como un microcontrolador común.. 40.

(42) Figura 5.46: Selección del tipo de placa Es de recalcar, que al momento de programar el módulo hay que cerciorarse de los valores con que se polariza, y que este conectado el pin ‘GPIO0’ a tierra para colocar el módulo en modo de escritura de memoria flash. De la misma manera puede que haya que modificar el ’IDE’ de ’Arduino’ en la sección ‘Placa:’ respecto a las caracterı́sticas del módulo, parámetros como el baudrate, el flash frecuency, entre otros. En caso de que haya mensajes de error al cargar el programa, basta con reiniciar el módulo.. 5.5.. Herramientas software adicionales. Al momento de sintetizar los programas anteriormente descritos con el fin de desarrollar las topologı́as descritas en el capı́tulo 4, fue necesario indagar sobre software que: En la implementación real y emulación, realicen las mediciones de: • Parámetros de calidad de servicio QoS. • Ancho de banda. Permitan monitorear los recursos de los switch. Realicen la transferencia de archivos entre hosts fı́sicos o emulados alojados en una misma red. Estos programas se listan a continuación:. 41.

(43) 5.5.1.. Iperf. Esta herramienta se implemento para medir el ancho de banda máximo entre dos hosts, permite ajustar diversos parámetros tales como el tiempo de la medición y los protocolos, al finalizar la prueba visualiza el rendimiento medido en la tasa de bits [36, 37]. Para la instalación, se ejecuta el comando en la terminal de ’Ubuntu’: ’sudo aptget install iperf’ en la consola de comandos, se recomienda utilizar la versión 2.0.10, debido a que permite la medición entre hosts con sistemas operativos diferentes, en el presente proyecto se realizó esta medición entre ’Windows’ y ’Ubuntu’, esto no es posible en la última versión 3.6 por problemas de compatibilidad. Para ejecutar el programa, es necesario tener dos hosts: Host servidor (ver figura 5.47) : Para poder implementar este comando en ’Ubuntu’ se requiere estar como superusuario, en el caso de ’Windows’ se debe deshabilitar el ’firewall’ y el antivirus en caso de tenerlo. Host transmisor (ver figura 5.48): Para ejecutar este comando se deben tener en cuenta las mismas consideraciones que en el servidor, sin embargo este contiene parámetros que pueden ser modificados, el comando ’-c’ requiere la IP del host servidor, y la opción ’-t’ el tiempo en el cual se van a transmitir datos.. Figura 5.47: Configuración servidor iperf. Cabe recalcar que la interfaz en la cual se mide el ancho de banda, es aquella que esta conectada directamente al host transmisor.. Figura 5.48: Configuración transmisor iperf.. 5.5.2.. D-ITG. Este software es un generador de tráfico, que soporta los protocolos ’IPv4’ e ’IPv6’, adicionalmente es capaz de medir los parámetros de ’QoS’(Calidad de servicio) [38]. Para instalar ’D-ITG’ se realizó mediante la lı́nea de código: ’sudo apt-get install d-itg’ en la consola de Ubuntu, esta aplicación se implemento únicamente en la emulación, a continuación se listan y describen las herramientas mas importantes que se exploraron de este software. 42.

(44) ITGRecv (ver figura 5.49): configuró al host, para que funcionará como servidor, y recibiera todo el tráfico enviado desde el transmisor.. Figura 5.49: Recepción del tráfico de red ITGRecv. ITGSend (ver figura 5.50): permitió generar el tráfico por medio del envió de los datos, ofrece configurar el protocolo de comunicación ’-T’, seleccionar al host al cual se va transmitir ’-a’, el tamaño de bytes que se envı́a, el tamaño de cada paquete ’-c’, la cantidad de paquetes por segundo ’-C’, el tiempo total ’-t’, y por último registra los resultados tanto del transmisor como del servidor, con ’-l’ y ’-x’ respectivamente.. Figura 5.50: Creación del tráfico de red ITGSend. Como se menciono anteriormente se crearon archivos que evidenciaran los resultados y estadı́sticas del tráfico generado, esto se realizó con el comando ITGDec (ver figura 5.51). Figura 5.51: Lectura de los resultados ITGDec.. 5.5.3.. Nmon. Con esta herramienta fue posible medir el rendimiento y el consumo de recurso de los switch, para esto se indago en la literatura existente, y se encontró el software ’Nmon’, para instalarlo se ejecutó la lı́nea: ’sudo apt-get install nmon’ en la consola, y para ejecutarlo se escribe el comando ’nmon’ [39].. 43.

(45) Figura 5.52: Interfaz gráfica Nmon. Como se puede ver en la figura 5.52, ’Nmon’ permite monitorear los recursos del sistema (ver figura 5.53) por medio de la opción ’l’ despliega el consumo de los recurso del sistema y ’n’ el rendimiendo de las interfaces de redes.. Figura 5.53: Monitor consumo de los recursos del sistema y rendimiento de la red.. 5.5.4.. FileZilla. FileZilla [40] es un cliente multiplataforma de ’FTP’, ’SFTP’ y ’FTPS’ con una amplia lista de funciones que puede ser instalado Windows, Mac OS X, Linux y más. Las herramientas dinámicas de ’FileZilla’ permiten transferir archivos entre una máquina local y un servidor. Esta aplicación consta de dos software: ’FileZilla FTP Client’(ver figura 5.54) que permite al host descargar archivos desde el servidor por medio del servidor ’FTP’, para la instalación en ’Ubuntu’ se ejecuta el siguiente comando en la terminal: ’sudo apt-get install filezilla’, y en Windows se descarga el instalador y se ejecuta, el cliente se puede conectar a varios servidor de forma simultanea. 44.

(46) Figura 5.54: Interfaz FileZilla FTP Client. El segundo software es ’FileZilla FTP Server’(ver figura 5.55) que solo puede ser ejecutado en Windows, esta herramienta permite crear un servidor FTP, y establecer que archivos serán compartidos, y restringir el acceso a usuarios previamente definidos desde el servidor, para que funcione correctamente se debe deshabilitar el firewall.. Figura 5.55: Interfaz FileZilla FTP Server.. 5.5.5.. Protocolo SSH. Para instalar los paquetes necesarios para hacer uso del protocolo SSH basta con utilizar las siguientes dos lı́neas de comandos en la consola de Ubuntu (ver figura 5.56).. 45.

(47) Figura 5.56: Instalación del servidor y cliente SSH.. Figura 5.57: Consulta estado del protocolo SSH.. 5.6.. Montaje final. La implementación final de cada una de las topologı́as realizadas se muestran a continuación. Se presentan la creación de los puentes en cada uno de los switch con los puertos e interfaces necesarios para cada una de las aplicaciones.. 5.6.1.. Topologı́a 1. Tal como se expuso en la sección 4.2, para el switch, se debe crear un puente con los puertos e interfaces apropiados. A continuación, se presentan los comandos que se deben ejecutar en el switch de esta topologı́a. Por otra parte con el controlador, no es necesario ejecutar ningún procedimiento en él, más que iniciar ONOS como se muestra en la figura 5.31. Ası́, la topologı́a queda totalmente definida como se muestra en la figura 4.1. Se denominan a los dispositivos conectados a las interfaces ethernet como ’Sensor 1’ y ’Sensor 2’, mientras que los dispositivos conectados a las interfaces Wi-Fi se denominan ’Sensor 3’ y ’Sensor 4’.. Figura 5.58: Comandos para la creación del switch 1 con 4 interfaces ethernet. 46.

(48) 5.6.2.. Topologı́a 2. Del mismo modo que en el caso descrito anteriormente, se presentan las lı́neas de comandos para crear el puente con las interfaces para esta topologı́a en cada uno de los switch. En este caso es muy importante prestar atención a las direcciones MAC con las que se crean los puentes, puesto que la instrucción ’ovs-vsctl add-br’ puede asignar direcciones MAC idénticas en los switch, por tanto la red entrara en conflicto y no funcionará de forma adecuada.. Figura 5.59: Comandos para la creación del switch 1.. Figura 5.60: Comandos para la creación del switch 2.. Figura 5.61: Comandos para la creación del switch 3. Como se puede ver, el switch 3 es aquel que irá conectado al host principal, por lo tanto, no es necesario añadir la interfaz wlan0. 47.