UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS...

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDASFACULTAD DE INGENIERÍA

INGENIERÍA ELECTRÓNICA

PROYECTO DE GRADOMODALIDAD DE MONOGRAFÍA

Aplicación de las Redes Definidas por Software en el Contexto delInternet de las Cosas

Autores:

Miguel Angel Baquero RojasFabián René Garćıa Perdomo

Director:

Gustavo Adolfo Puerto Leguizamón

Bogotá, Julio 2018

Índice general

Índice de figuras 3

Índice de tablas 6

Introducción 7

1. Generalidades 81.1. Justificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . 91.2.2. Objetivos Espećıficos . . . . . . . . . . . . . . . . . . . . . 9

1.3. Alcances y limitaciones . . . . . . . . . . . . . . . . . . . . . . . . 10

2. Marco Teórico 112.1. Redes de sensores inalámbricos . . . . . . . . . . . . . . . . . . . 11

2.1.1. Tipos de tecnoloǵıas implementadas en WSN . . . . . . . . 122.2. Internet de las cosas (IoT) . . . . . . . . . . . . . . . . . . . . . . 132.3. Redes definidas por software . . . . . . . . . . . . . . . . . . . . . 132.4. OpenFlow (OF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.5. OpenvSwitch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.6. Controladores SDN . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.6.1. FLOODLIGHT . . . . . . . . . . . . . . . . . . . . . . . . 162.6.2. OPENDAYLIGHT . . . . . . . . . . . . . . . . . . . . . . 162.6.3. POX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.6.4. ONOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.7. Parámetros QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.7.1. Rendimiento (Throughput) . . . . . . . . . . . . . . . . . 172.7.2. Retardo (Delay) . . . . . . . . . . . . . . . . . . . . . . . . 182.7.3. Variabilidad (Jitter) . . . . . . . . . . . . . . . . . . . . . 182.7.4. Tasa de paquetes perdidos . . . . . . . . . . . . . . . . . . 18

3. Antecedentes 20

4. Propuestas de topoloǵıas de red 214.1. Topoloǵıa 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2. Topoloǵıa 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5. Implementación 235.1. Instalación de Mininet . . . . . . . . . . . . . . . . . . . . . . . . 235.2. Creación del switch . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.2.1. OvS con interfaz Ethernet . . . . . . . . . . . . . . . . . . 255.2.2. OvS con interfaz Wi-Fi . . . . . . . . . . . . . . . . . . . . 285.2.3. OvS con interfaces Wi-Fi y Ethernet. . . . . . . . . . . . . 30

5.3. Instalación del controlador ONOS . . . . . . . . . . . . . . . . . . 315.3.1. Instalación en máquina virtual . . . . . . . . . . . . . . . . 31

1

5.3.2. Instalación en sistema operativo . . . . . . . . . . . . . . . 345.4. Programación de módulos Wi-Fi . . . . . . . . . . . . . . . . . . . 375.5. Herramientas software adicionales . . . . . . . . . . . . . . . . . . 41

5.5.1. Iperf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.5.2. D-ITG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.5.3. Nmon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.5.4. FileZilla . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.5.5. Protocolo SSH . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.6. Montaje final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.6.1. Topoloǵıa 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 465.6.2. Topoloǵıa 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 475.6.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.7. Protocolo de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . 505.7.1. Conexión entre hosts . . . . . . . . . . . . . . . . . . . . . 515.7.2. Env́ıo de datos . . . . . . . . . . . . . . . . . . . . . . . . 515.7.3. Algoritmos para la comunicación Wi-Fi . . . . . . . . . . . 525.7.4. Configuración FileZilla . . . . . . . . . . . . . . . . . . . . 525.7.5. Medición . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.8. Emulación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6. Resultados 596.1. Topoloǵıa 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.1.1. Variaciones del ancho de banda interfaz ethernet asociadaal sensor 1. . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.1.2. Variaciones del ancho de banda interfaz ethernet asociadaal sensor 2. . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.1.3. Variaciones del ancho de banda interfaz Wi-Fi asociada alos sensores 3 y 4 . . . . . . . . . . . . . . . . . . . . . . . 71

6.2. Topoloǵıa 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766.2.1. Variaciones del ancho de banda interfaz ethernet del switch

1 asociada al sensor 1. . . . . . . . . . . . . . . . . . . . . 766.2.2. Variaciones del ancho de banda interfaz Wi-Fi del switch

1 asociada al sensor 3. . . . . . . . . . . . . . . . . . . . . 816.2.3. Variaciones del ancho de banda interfaz ethernet del switch

2 asociada al sensor 2. . . . . . . . . . . . . . . . . . . . . 846.2.4. Variaciones del ancho de banda interfaz Wi-Fi del switch

2 asociada al sensor 4. . . . . . . . . . . . . . . . . . . . . 90

7. Posibles casos de uso 937.1. Entorno 1: Sistema de monitoreo para

parámetros de un invernadero . . . . . . . . . . . . . . . . . . 937.2. Entorno 2: Sistema de monitoreo para

parámetros de salas de servidores . . . . . . . . . . . . . . . . 94

8. Conclusiones 96

Bibliograf́ıa 98

2

Índice de figuras

2.1. Ejemplo de la red.[1] . . . . . . . . . . . . . . . . . . . . . . . . . 112.2. Arquitectura LoRaWan. . . . . . . . . . . . . . . . . . . . . . . . 122.3. Diagrama de control de una red.[2] . . . . . . . . . . . . . . . . . 132.4. Diagrama de la solución planteada.[3] . . . . . . . . . . . . . . . . 142.5. Diagrama de los componentes del protocolo .[4] . . . . . . . . . . 152.6. Esquema OvS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1. Topoloǵıa de red 1. . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2. Topoloǵıa de red 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.1. Clonación del repositorio Git de Mininet. . . . . . . . . . . . . . . 235.2. Versiones de Mininet. . . . . . . . . . . . . . . . . . . . . . . . . . 245.3. Instalación OpenvSwitch. . . . . . . . . . . . . . . . . . . . . . . . 245.4. Instalación OpenFlow. . . . . . . . . . . . . . . . . . . . . . . . . 245.5. Instalación Mininet. . . . . . . . . . . . . . . . . . . . . . . . . . . 245.6. Creación topoloǵıa por defecto. . . . . . . . . . . . . . . . . . . . 255.7. Instalación adicional OpenvSwitch. . . . . . . . . . . . . . . . . . 255.8. Interfaces de red. . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.9. Creación del switch Ethernet. . . . . . . . . . . . . . . . . . . . . 265.10. Resultados ’ifconfig’ switch Ethernet. . . . . . . . . . . . . . . . . 275.11. Visualización de los puentes creados. . . . . . . . . . . . . . . . . 275.12. Desmantelación del puente OvS. . . . . . . . . . . . . . . . . . . . 275.13. Instalación del editor de redes inalámbricas. . . . . . . . . . . . . 285.14. Puesta en marcha del editor. . . . . . . . . . . . . . . . . . . . . . 285.15. Despliegue de redes disponibles. . . . . . . . . . . . . . . . . . . . 285.16. Configuración las caracteŕısticas de la red Wi-Fi. . . . . . . . . . . 295.17. Conexión a una red inalámbrica oculta. . . . . . . . . . . . . . . . 295.18. Estado de conexión de la Raspberry. . . . . . . . . . . . . . . . . 305.19. Construcción switch Wi-Fi y Ethernet. . . . . . . . . . . . . . . . 305.20. Asignación puerto Ethernet. . . . . . . . . . . . . . . . . . . . . . 305.21. Resultados ’ifconfig’ switch Ethernet-Wi-Fi. . . . . . . . . . . . . 315.22. Despliegue menú VirtualBox . . . . . . . . . . . . . . . . . . . . . 315.23. Login de usuario ONOS. . . . . . . . . . . . . . . . . . . . . . . . 315.24. Aplicación para creación de los controladores. . . . . . . . . . . . 325.25. Creación de la red emulada. . . . . . . . . . . . . . . . . . . . . . 335.26. Login de usuario para la GUI. . . . . . . . . . . . . . . . . . . . . 335.27. Uso de la aplicación ’fwd’. . . . . . . . . . . . . . . . . . . . . . . 345.28. Repositorio ONOS-instalación en sistema operativo . . . . . . . . 345.29. Comandos iniciales para la ejecución de ONOS. . . . . . . . . . . 345.30. Comandos iniciales para la ejecución de ONOS. . . . . . . . . . . 345.31. Creación del controlador en el sistema operativo. . . . . . . . . . . 355.32. Procesos activos del controlador. . . . . . . . . . . . . . . . . . . . 355.33. Interfaz de ĺınea de comandos de ONOS. . . . . . . . . . . . . . . 355.34. Login de la interfaz gráfica de ONOS. . . . . . . . . . . . . . . . . 365.35. Interfaz gráfica de ONOS. . . . . . . . . . . . . . . . . . . . . . . 36

3

5.36. Creación de una red de prueba en Mininet. . . . . . . . . . . . . . 365.37. Conexión entre el controlador y la red. . . . . . . . . . . . . . . . 375.38. Visualización de la topoloǵıa de la red en la GUI. . . . . . . . . . 375.39. Programa NODEMCU FIRMWARE PROGRAMER-ESP8266

FLASHER. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.40. Carga del firmware en el flasher . . . . . . . . . . . . . . . . . . . 385.41. Configuración de los parámetros del módulo . . . . . . . . . . . . 385.42. Diagrama de puertos del módulo ESP8266[5]. . . . . . . . . . . . 395.43. Interfaz de carga de firmware finalizado. . . . . . . . . . . . . . . 395.44. Interfaz para instalación sobre el IDE arduino . . . . . . . . . . . 405.45. Instalación del asistente de tarjeta ESP8266 . . . . . . . . . . . . 405.46. Selección del tipo de placa . . . . . . . . . . . . . . . . . . . . . . 415.47. Configuración servidor iperf. . . . . . . . . . . . . . . . . . . . . . 425.48. Configuración transmisor iperf. . . . . . . . . . . . . . . . . . . . 425.49. Recepción del tráfico de red ITGRecv. . . . . . . . . . . . . . . . 435.50. Creación del tráfico de red ITGSend. . . . . . . . . . . . . . . . . 435.51. Lectura de los resultados ITGDec. . . . . . . . . . . . . . . . . . . 435.52. Interfaz gráfica Nmon. . . . . . . . . . . . . . . . . . . . . . . . . 445.53. Monitor consumo de los recursos del sistema y rendimiento de la

red. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.54. Interfaz FileZilla FTP Client. . . . . . . . . . . . . . . . . . . . . 455.55. Interfaz FileZilla FTP Server. . . . . . . . . . . . . . . . . . . . . 455.56. Instalación del servidor y cliente SSH. . . . . . . . . . . . . . . . . 465.57. Consulta estado del protocolo SSH. . . . . . . . . . . . . . . . . . 465.58. Comandos para la creación del switch 1 con 4 interfaces ethernet. 465.59. Comandos para la creación del switch 1. . . . . . . . . . . . . . . 475.60. Comandos para la creación del switch 2. . . . . . . . . . . . . . . 475.61. Comandos para la creación del switch 3. . . . . . . . . . . . . . . 475.62. Creación del puente para el controlador. . . . . . . . . . . . . . . 485.63. Comando para habilitar la aplicación DHCP de ONOS. . . . . . . 495.64. Caracteŕısticas de DHCP de ONOS. . . . . . . . . . . . . . . . . . 495.65. Interfaz gráfica de ONOS. Topoloǵıa 1 . . . . . . . . . . . . . . . 505.66. Interfaz gráfica de ONOS. Topoloǵıa 2 . . . . . . . . . . . . . . . 505.67. Código implementado en los módulos Wi-Fi. . . . . . . . . . . . . 525.68. Código implementado en el servidor del host central. . . . . . . . 525.69. Conexión al servidor local FTP. . . . . . . . . . . . . . . . . . . . 535.70. Creación de los usuarios del servidor local FTP. . . . . . . . . . . 535.71. Selección de los archivos a compartir. . . . . . . . . . . . . . . . . 545.72. Comando de variación del ancho de banda . . . . . . . . . . . . . 545.73. Creación topoloǵıas en Mininet. . . . . . . . . . . . . . . . . . . . 565.74. Configuración del dispositivo central (servidor) en Mininet. . . . . 575.75. Configuración de los host (sensores) en Mininet. . . . . . . . . . . 575.76. Registro de los parámetros QoS a través de D-ITG. . . . . . . . . 58

6.1. Throughput sensor 1-topoloǵıa 1. . . . . . . . . . . . . . . . . . . 606.2. PLR sensor 1-topoloǵıa 1. . . . . . . . . . . . . . . . . . . . . . . 616.3. Delay sensor 1-topoloǵıa 1. . . . . . . . . . . . . . . . . . . . . . . 626.4. Jitter sensor 1-topoloǵıa 1. . . . . . . . . . . . . . . . . . . . . . . 63

4

6.5. Throughput sensores ethernet en función del sensor 1-topoloǵıa 1. 646.6. Throughput sensores Wi-Fi en función del sensor 1-topoloǵıa 1. . 656.7. Throughput sensor 2-topoloǵıa 1. . . . . . . . . . . . . . . . . . . 666.8. PLR sensor 2-topoloǵıa 1. . . . . . . . . . . . . . . . . . . . . . . 676.9. Delay sensor 2-topoloǵıa 1. . . . . . . . . . . . . . . . . . . . . . . 686.10. Jitter sensor 2-topoloǵıa 1. . . . . . . . . . . . . . . . . . . . . . . 696.11. Throughput sensores ethernet en función del sensor 2-topoloǵıa 1. 706.12. Throughput sensores Wi-Fi en función del sensor 2-topoloǵıa 1. . 706.13. Throughput sensor 3-topoloǵıa 1. . . . . . . . . . . . . . . . . . . 716.14. Throughput sensor 4-topoloǵıa 1. . . . . . . . . . . . . . . . . . . 726.15. PLR sensor 3-topoloǵıa 1. . . . . . . . . . . . . . . . . . . . . . . 736.16. PLR sensor 4-topoloǵıa 1. . . . . . . . . . . . . . . . . . . . . . . 746.17. Throughput sensores ethernet en función de la interfaz Wi-Fi-

topoloǵıa 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756.18. Throughput sensores Wi-Fi en función de la interfaz Wi-Fi-

topoloǵıa 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756.19. Throughput sensor 1-switch 1-topoloǵıa 2. . . . . . . . . . . . . . 766.20. PLR sensor 1-switch 1-topoloǵıa 2. . . . . . . . . . . . . . . . . . 776.21. Delay sensor 1-switch 1-topoloǵıa 2. . . . . . . . . . . . . . . . . . 786.22. Jitter sensor 1-switch 1-topoloǵıa 2. . . . . . . . . . . . . . . . . . 796.23. Throughput sensores ethernet en función del sensor 1-topoloǵıa 2. 806.24. Throughput sensores Wi-Fi en función del sensor 1-topoloǵıa 2. . 806.25. Throughput sensor 3-switch 1-topoloǵıa 2. . . . . . . . . . . . . . 816.26. PLR sensor 3-switch 1-topoloǵıa 2. . . . . . . . . . . . . . . . . . 826.27. Throughput sensores ethernet en función del sensor 3-topoloǵıa 2. 836.28. Throughput sensores Wi-Fi en función del sensor 3-topoloǵıa 2. . 846.29. Throughput sensor 2-switch 2-topoloǵıa 2. . . . . . . . . . . . . . 856.30. PLR sensor 2-switch 2-topoloǵıa 2. . . . . . . . . . . . . . . . . . 866.31. Delay sensor 2-switch 2-topoloǵıa 2. . . . . . . . . . . . . . . . . . 876.32. Jitter sensor 2-switch 2-topoloǵıa 2. . . . . . . . . . . . . . . . . . 886.33. Throughput sensores ethernet en función del sensor 2-topoloǵıa 2. 896.34. Throughput sensores Wi-Fi en función del sensor 2-topoloǵıa 2. . 896.35. Throughput sensor 4-switch 2-topoloǵıa 2. . . . . . . . . . . . . . 906.36. Throughput sensores ethernet en función de sensor 4-topoloǵıa 2. 916.37. Throughput sensores Wi-Fi en función de sensor 4-topoloǵıa 2. . . 92

7.1. Topoloǵıa de la red para el monitoreo de un invernadero. . . . . . 947.2. Topoloǵıa de la red para el monitoreo de salas de servidores. . . . 95

5

Índice de tablas

5.1. Asignación manual de IP topoloǵıa 1. . . . . . . . . . . . . . . . . 495.2. Asignación manual de IP topoloǵıa 2. . . . . . . . . . . . . . . . . 495.3. Variables de los sensores en las pruebas con ancho de banda sin

ninguna restricción. . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.1. Comparación throughput sensor 1 ethernet. . . . . . . . . . . . . 596.2. Comparación PLR sensor 1 ethernet. . . . . . . . . . . . . . . . . 606.3. Comparación delay sensor 1 ethernet. . . . . . . . . . . . . . . . . 616.4. Comparación jitter sensor 1 ethernet. . . . . . . . . . . . . . . . . 626.5. Throughput implementación f́ısica de las interfaces asociadas a los

sensores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.6. Throughput emulación de las interfaces asociadas a los sensores. . 646.7. Comparación throughput sensor 2 ethernet. . . . . . . . . . . . . 656.8. Comparación PLR sensor 2 ethernet. . . . . . . . . . . . . . . . . 666.9. Comparación delay sensor 2 ethernet. . . . . . . . . . . . . . . . . 676.10. Comparación jitter sensor 2 ethernet. . . . . . . . . . . . . . . . . 686.11. Throughput implementación f́ısica de las interfaces asociadas a los

sensores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.12. Comparación throughput sensor 3 Wi-Fi. . . . . . . . . . . . . . . 716.13. Comparación throughput sensor 4 Wi-Fi. . . . . . . . . . . . . . . 726.14. Comparación PLR sensor 3 Wi-Fi. . . . . . . . . . . . . . . . . . 736.15. Comparación PLR sensor 4 Wi-Fi. . . . . . . . . . . . . . . . . . 736.16. Throughput implementación f́ısica de las interfaces asociadas a los

sensores ethernet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 746.17. Comparación throughput sensor 1 ethernet-switch 1. . . . . . . . 766.18. Comparación PLR sensor 1 ethernet-switch 1. . . . . . . . . . . . 776.19. Comparación delay sensor 1 ethernet-switch 1. . . . . . . . . . . . 786.20. Comparación jitter sensor 1 ethernet-switch 1. . . . . . . . . . . . 786.21. Throughput implementación f́ısica de las interfaces asociadas a los

sensores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796.22. Comparación throughput sensor 3 Wi-Fi-switch 1. . . . . . . . . . 816.23. Comparación PLR sensor 3 Wi-Fi-switch 1. . . . . . . . . . . . . 826.24. Throughput implementación f́ısica de las interfaces asociadas a los

sensores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836.25. Comparación throughput sensor 2 ethernet-switch 2. . . . . . . . 846.26. Comparación PLR sensor 2 ethernet-switch 2. . . . . . . . . . . . 856.27. Comparación delay sensor 2 ethernet-switch 2. . . . . . . . . . . . 866.28. Comparación jitter sensor 2 ethernet-switch 2. . . . . . . . . . . . 876.29. Throughtput implementación f́ısica de las interfaces asociadas a

los sensores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886.30. Comparación throughput sensor 4 Wi-Fi-switch 2. . . . . . . . . . 906.31. Comparación PLR sensor 4 Wi-Fi-switch 2. . . . . . . . . . . . . 916.32. Throughput implementación f́ısica de las interfaces asociadas a los

sensores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

6

Introducción

El entorno tecnológico de hoy en d́ıa está lleno de nuevos métodos cada vezmás innovadores implementados en prácticamente todos los procesos a gran es-cala que se llevan a cabo a nivel industrial. Los procesos de monitoreo de estadode determinados parámetros y procesos, es un área muy importante en diver-sos campos: industria, sector agŕıcola, domótica, entre otros, de manera que lastecnoloǵıas encaminadas al monitoreo y control, han evolucionado mucho conel paso de los años. Alrededor de 1980, sectores militares empezaron iniciativasde investigación con respecto a las redes de sensores para el monitoreo, deno-minadas inicialmente como Redes de Sensores Distribuidos (DSN); hoy en d́ıaencontramos el concepto de redes de sensores inalámbricos (WSN), los cuales sonimplementados en variados procesos como lo son procesos de agricultura de pre-cisión, monitoreo de parámetros de camiones mineros, monitoreo en daños porfatiga en puentes de carreteras, procesos de temperatura en plantas de enerǵıasolar, entre otras muchas aplicaciones, todos estos aspectos se enmarcan en elconcepto del Internet de las Cosas (IoT).Aun aśı, aunque dicho desarrollo tecnológico es muy prometedor, en este momen-to, cuenta con ciertas dificultades, como el hecho que la red responde ante loscambios del entorno que monitoreo, de manera que no se emplea adecuadamentelos recursos con los que se cuenta, la falta de un control centralizado para unagran cantidad y variedad de dispositivos conectados, cada uno de ellos ejecutan-do aplicaciones de diferente ı́ndole hace que se deba recurrir a nuevas propuestasy paradigmas como los presentados por los futuros sistemas móviles de quintageneración. Con estos sistemas se busca la convergencia e interoperabilidad entrediferentes protocolos y tecnoloǵıas de comunicación con el fin de proveer flexi-bilidad y mayor capacidad a la hora de brindar soluciones de comunicación enentornos humano a máquina y máquina a máquina. Aśı, el paradigma de las redesdefinidas por software (SDN) ofrece una propuesta que soporta la interoperabili-dad y escalabilidad en redes de sensores.

7

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 conectadosen el año 2020, esto deriva en la necesidad de un sistema de gestión centralizadoy asignación de recursos flexible en función del servicio establecido. Este proyectova orientado a abordar esta temática implementando conceptos de las redes denueva generación tal como los futuros sistemas 5G, con el fin de determinar losalcances 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 queen un futuro el mundo buscará estar totalmente interconectado no solo a nivel dedispositivos de computación y dispositivos móviles, sino que cada dispositivo quetenga la posibilidad de ser conectado a un sensor inalámbrico, estará conectado aredes convergentes de datos. Hay miles de posibilidades basadas en este concep-to, desde el monitoreo del hogar a larga distancia, saber si alguien abre la puertadel apartamento mientras se está trabajando; hasta medir la presión por área enun puente vehicular para determinar periodos de mantenimiento. La implemen-tación de sensores inalámbricos presenta ventajas que van mucho más allá delsimple hecho de no estar conectados f́ısicamente, sino que presentan facilidadesde configuración de parámetros espećıficos del sensor. El paradigma de las SDNbrinda un entorno que soporta completamente toda la idea planteada, donde esposible tener un control y monitoreo óptimo centralizado pensando en una redescalable que está en constantemente crecimiento y cambio, donde los recursospueden 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 imple-mentación de nuevas tecnoloǵıas y que podrá ser monitoreada en tiempo real ono, desde lugares remotos a través de la red es una idea que aporta al desarrollode este concepto y se prepara para la llegada de toda esta nueva tecnoloǵıa.

8

1.2. Objetivos

1.2.1. Objetivo General

Determinar la aplicabilidad de las redes definidas por software en un entornode 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 posiblesplataformas hardware y software para su implementación.

Reconocer los alcances y viabilidad de la implementación de un controladorpara redes definidas por software.

Evaluar la viabilidad de la implementación f́ısica del controlador de redesdefinidas por software.

Determinar una topoloǵıa de red para identificar las caracteŕısticas queimponen una red definida por software en un entorno de aplicación paraIoT.

Comparar resultados entre la emulación e implementación real.

Desarrollar un protocolo de pruebas que permita evaluar correctamente elfuncionamiento de la red.

9

1.3. Alcances y limitaciones

Cabe recalcar que el presente proyecto está encaminado principalmente a laimplementación f́ısica de una red con control centralizado, de manera que como semencionó anteriormente algunas actividades son fundamentales para el desarrollode este. Algunas de estas son: implementación de un switch virtual a través de unsistema operativo, que soporte el protocolo de OpenFlow, gestión de los paráme-tros de dispositivos a través del controlador ONOS implementando el paradigmade las redes definidas por software (SDN).

Sin embargo se debe mencionar que debido a las limitaciones económicas yde hardware, la topoloǵıa de red que se va a utilizar, será reducida en cuanto alnúmero de elementos, y por ende a la cantidad de enlaces de la misma, por endecuando se emule la red para la comparación de los resultados, se hará de igual deforma con una topoloǵıa reducida.

10

2. Marco Teórico

2.1. Redes de sensores inalámbricos

Las redes de sensores inalámbricos (WSN) son compuestas por diferentes no-dos de sensores equipados con interfaces de radio, que se encuentran ubicadasen una región en particular. Cada nodo mide diferentes variables y su trabajoes enviar dichas mediciones a un nodo coordinador, siguiendo un protocolo enparticular para la comunicación entre estos [6]. En la figura 2.1, se puede apreciarun ejemplo de este tipo de redes.

Figura 2.1: Ejemplo de la red.[1]

Mientras que muchos sensores se conectan directamente a los controladoresy estaciones de procesamiento, un número creciente de sensores comunican losdatos recogidos de forma inalámbrica a una estación de procesamiento centrali-zada. En muchas aplicaciones de red requieren múltiples nodos de sensores, enocasiones implementados en áreas remotas e inaccesibles. Por lo tanto, un sensorinalámbrico no dispone únicamente de un componente de detección, sino tambiéncapacidades de procesamiento, comunicación y almacenamiento a bordo. Con es-tas mejoras, un nodo sensor a menudo no solo es responsable de la recopilación dedatos, sino también del análisis dentro de la red de sus propios datos de sensoresy datos de otros nodos de sensores. Cuando muchos sensores controlan conjunta-mente 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 esta-ción base (BS) que usa sus radios inalámbricas, lo que les permite transmitir susdatos de sensores a sistemas remotos de procesamiento, visualización, análisis yalmacenamiento. [7]

11

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 defineespecificaciones para conectividad inalámbrica de baja velocidad de datos entredispositivos relativamente simples que consumen relativamente poco, funciona enbandas 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 procesamientode 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 dela potencia de salida[8].

2.1.1.2. LoRaWAN

LoRaWAN es una especificación de protocolo construida sobre la tecnoloǵıaLoRa desarrollada por LoRa Alliance. Utiliza el espectro de radio sin licencia enlas bandas Industrial, Cient́ıfica y Médica (ISM) para permitir la comunicaciónde baja potencia y gran área entre los sensores remotos y las puertas de enlaceconectadas a la red. Este enfoque basado en estándares para construir una PWANpermite la configuración redes IoT a través de hardware (ver figura 2.2) y softwareseguro, 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 entreśı y directamente a la nube usando protocolos en una red de malla inalámbrica debaja potencia. Mientras que las tecnoloǵıas de red 802.15.4 tienen sus propias ven-tajas, también existe problemas como la incapacidad de soportar comunicacionesbasadas IPv6.

12

2.1.1.4. 802.11

802.11 es un estándar para redes inalámbricas el cual permite throughputde 1-2 Mbps. Este estándar ofrece una conectividad inalámbrica para estacionesmóviles que ofrece la posibilidad de configurar la red. Adicionalmente admite IR(infrarrojo) y frecuencia de radio como medios de transmisión. Para aumentarel 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 puedetener la capacidad de asociarse a una red masiva de comunicaciones. El origen deeste concepto se atribuye a miembros de la Auto-ID center del Instituto Tecnológi-co de Massachusetts donde se originó la comunidad de identificación por radiofrecuencia RFID (Radio Frecuency Identification), alrededor del año 2000. Bajoel 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 ytodos convergen en una base de datos [11].

2.3. Redes definidas por software

Las redes definidas por software SDN (Software Defined Networks por sussiglas en inglés), es un paradigma en relación al área de las redes que empieza asurgir aproximadamente entre el 2000 y el 2010 con el concepto de separar dentrode un switch el plano de control del plano de datos. Esto con el fin de obtenerbeneficios en implementación de servicios y reducción de gastos.

Dentro de las redes tradicionales, se habla de dispositivos switch que contienenen śı mismos el plano de control y el plano de datos. Plano de control encargadode tomar decisiones respecto al enrutamiento y otros factores; y plano de datosencargado 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 for-mato y el plano de control de cada uno de los dispositivos le dice que acción debe

13

tomar con dichos datos. De esta manera, el control de la red está distribuido a lolargo de esta y cada uno de los dispositivos es independiente de tomar decisionesrespecto al manejo de los datos que recibe, aśı, si la red desea dirigir un mensajea un lugar determinado, cada uno de los dispositivos tiene que tomar decisionespara llevar el mensaje a su destino. Esto crea una idea donde se puede pensarque hay cierto sobre esfuerzo de procesamiento en cada uno de los dispositivosal tener que repetir procesos de enrutamiento cada vez que el mensaje llega a undispositivo nuevo, esto pensando en la red como un todo. Del mismo modo, si sepiensa en agregar un dispositivo más a la red, significa que se agrega un procesode decisión más, sin hablar de que incluirlo desde el contexto técnico significaŕıatambién, tener que hacer una nueva instalación y programación de dicho dispo-sitivo, por lo tanto el hecho de que la red crezca significa una dificultad en varioscontextos para el administrador de la red [13].

Las SDN ofrecen una solución a esto mediante una separación y centralizacióndel 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 dispositivocentral al cual puede acceder el administrador de la red a través de interfaces deaplicación programables basadas en diferentes lenguajes. Aśı, el controlador de lared, se comunica con los dispositivos mediante un protocolo llamado OpenFlow.Ya que el paradigma es reciente, no todos los switch del mercado soportan esteprotocolo y aquellos que lo soportan derivan en una inversión considerable. Aligual que en la arquitectura tradicional, se tiene un plano de datos distribuido, conla diferencia de que este es dirigido por un solo controlador que toma decisionespara toda la red. Esto, convierte a la red en un sistema más eficiente al acelerarla implementación y distribución de aplicaciones, un sistema escalable, que esmenos sensible a la variación de tamaño de la red [3].

14

2.4. OpenFlow (OF)

Pensando en el funcionamiento ya mencionado de las SDN [12], el protocoloque permite que esto se desarrolle es denominado OpenFlow. Este, es el protocoloejecutado por Open Networking Forum (ONF) [14] que permite al controladordar las ordenes a los dispositivos de enrutamiento, este también manipula el es-tado de configuración de los dispositivos de enrutamiento de paquetes.

Este protocolo se puede dividir en 4 componentes básicos [4]: capa de mensa-je, 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 capadefine la estructura y semántica válida para todos los mensajes. Esta capa demensajes tiene la capacidad de construir, copiar, comparar, imprimir y manipu-lar mensajes.La máquina de estados define el comportamiento de bajo nivel del núcleo delprotocolo. T́ıpicamente, se usa para describir acciones como negociación entredispositivos, 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 quele rodea. Por lo general, identifica las interfaces necesarias y opcionales junto conlas funciones que se le pueden asignar, como el uso de TLS y TCP como canalesde transporte.A nivel de capa de configuración, casi todos los aspectos del protocolo tienen con-figuraciones o valores iniciales. La configuración puede abarcar desde tamaños debuffer predeterminados e intervalos de respuesta.Otra forma de considerar el protocolo OF es comprender su modelo de datos sub-

15

yacente. Cada interruptor mantiene un modelo de datos relacionales que contienelos atributos para cada abstracción de OF. Estos atributos describen una capa-cidad de abstracción, su estado de configuración o algún conjunto de estad́ısticasactuales [4].

2.5. OpenvSwitch

OpenvSwitch es un conmutador virtual multicapa de calidad de producciónbajo licencia de código abierto Apache 2.0 . Está diseñado para permitir la auto-matización masiva de redes a través de la extensión programática, al tiempo queadmite 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 puentevirtual que puede dar acceso a diferentes puertos o interfaces de un mismo dispo-sitivo lo cual es una herramienta muy útil cuando el usuario desea tener accesoa un dispositivo, la red usa una misma dirección IP desde diferentes máquinasvirtuales con interfaces virtuales diferentes. También permite asignar a diferentesinterfaces reales de un dispositivo la misma interfaz virtual, de modo que permitetener una gran interfaz IP con diferentes puertos de recepción (Ver figura 2.6).

2.6. Controladores SDN

2.6.1. FLOODLIGHT

’Floodlight’ no es solamente otro controlador OpenFlow, puesto que integraadicionalmente aplicaciones que permiten controlar y consultar parámetros es-pećıficos de la red, y por medio de algunas herramientas que ofrece poder resolvernecesidades 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 implementacio-nes SDN en redes modernas de múltiples proveedores heterogéneas. ’OpenDay-

16

light’ proporciona una plataforma de abstracción de servicios impulsada por mo-delos que permite a los usuarios escribir aplicaciones que funcionen fácilmente enuna 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 utilizan-do el protocolo ’OpenFlow’. Los desarrolladores pueden usar ’POX’ para crearun controlador SDN utilizando el lenguaje de programación ’Python’. Los com-ponentes de ’POX’ son programas adicionales que se pueden ejecutar cuando seinicia el controlador desde la ĺınea de comando, estos componentes implementanla funcionalidad de red en la red definida por software [18].

2.6.4. ONOS

’ONOS’ (Open Network Operating System) proporciona el plano de controlpara una red definida por software (SDN), adicionalmente administra los compo-nentes de red, como switch y enlaces, y ejecuta aplicaciones que se traducen endiferentes 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, almismo tiempo que brinda tolerancia a fallas ante fallas del servidor [19].

’ONOS’ y ’OpenDaylight’ son los controladores más destacados. Estos doscontroladores están codificados en ’Java’ ambos presentan una excelente ’GUI’.Al estar bajo la asociación de conocidos proveedores de redes y comunidades deinvestigación, tienen un plan de desarrollo claro y una buena documentación.Además, su compatibilidad con el esquema distribuido les permite realizar unaimplementación real de ’SDN’. La arquitectura ’ONOS’ está diseñada para man-tener redes de alta velocidad y gran escala. Su principal caracteŕıstica distintivaes su soporte para redes h́ıbridas [20].

2.7. Parámetros QoS

La Calidad de Servicio (QoS), se puede entender como la medida del compor-tamiento de la capacidad de la red con respecto a ciertas caracteŕısticas de losservicios definidos, o como la capacidad de una red para proveer mejor serviciopara 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 othroughput, pérdida de paquetes. Basándose en las poĺıticas de QoS, la red debegarantizar que tiene la capacidad de ofrecer un nivel de Calidad de Servicio paracierto 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 através de la red. Esta medida se da en referencia a un tiempo determinado con

17

unidades de bits/s o pps. El Throughput es medido después de la transmisión dedatos porque un sistema añade retardo causado por limitaciones del procesador,congestión de la red, ineficiencias del proceso de almacenamiento de datos en losbuffers, transmisión de bits errados, carga de tráfico, hardware inadecuado. ElThroughput vaŕıa con el tiempo durante la transmisión de datos debido al tráficoy la congestión.

2.7.2. Retardo (Delay)

El retardo en transmisión o delay es usualmente definido como el tiempo quetranscurre entre la emisión de los datos, hasta el momento en que llegan al re-ceptor. El retardo es una medida que expresa el tiempo gastado en el subsistemade comunicación. Este parámetro es también conocido en el ámbito de las tele-comunicaciones como latencia (latency). La causa de este retardo es que cuandola data es procesada esta fluye a través de una gran cantidad de componentes ysubsistemas de comunicación, situados en el sistema receptor, aśı como en la red.Cada uno de esos componentes pueden ser caracterizados por su velocidad deprocesamiento y por la capacidad de almacenamiento (buffers) donde los datosesperan para ser procesados. La suma de todas las contribuciones de retardosindividuales vista como un todo es lo que genera el parámetro reconocido comoretardo. El máximo retardo que es el que ocurre de extremo a extremo conocidocomo mouth-to-ear (de boca a óıdo) recomendado para conversaciones en tiemporeal no debe exceder los 150 ms [21]. Este retardo se calcula como el promedio delos retardos paquete a paquete [22].

∑ni=1 xin

(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 lavariación en el tiempo de llegada al punto receptor, sufrida entre paquetes dedatos sucesivos [23].

√∑ni=1 xi2 − n ∗D2

n− 1(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 viajanen una red IP fallan en alcanzar su destino. La causa de la pérdida de paquetes es

18

debido a varios factores, entre los que se puede nombrar: degradación de la señalal viajar por el medio, interconexiones de la red sobre-saturadas, paquetes conerror rechazados en el tránsito, falla en el hardware de la red o rutinas normalesde enrutamiento. Cuando la pérdida de paquetes es causada por problemas en lared, los paquetes perdidos pueden resultar en problemas de desempeño que causenfallas notables en el desempeño de esta, sin embargo, la pérdida de paquetes nosiempre es tan dañina, como por ejemplo cuando es usada para contrarrestar lalatencia [23].

19

3. Antecedentes

Dentro del entorno de las redes definidas por software se pueden encontraraplicaciones enfocadas a la configuración de recursos y virtualización, dondecomúnmente el controlador SDN es el encargado del corte de slice de recursosen un entorno.

En ’Flowvisor: A network virtualization layer’ [24] R. Sherwood et al. Hacenuna combinación entre el concepto de virtualización y SDN creando una arqui-tectura llamada ’Flowvisor’ cuyo objetivo es crear slices como múltiples subredeslógicas donde cada red está completamente aislada de las demás con el fin de op-timizar recursos de red y ofrecer servicios diferenciados a diferentes usuarios. Enesta arquitectura hay un controlador de red dedicado a cada slice con ’Flowvisor’actuando como monitor y árbitro interceptando los mensajes entre el plano decontrol 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 con-troladores propuesto por Flowvisor. El proyecto recibe el nombre de FlowN. Enesta propuesta se tiene una centralización donde cada usuario ve su red virtualcomo independiente. A cada usuario se le otorga total libertad respecto a su pro-pia topoloǵıa y le brinda una dirección exclusiva dentro de una red virtual conuna 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 encarguende encapsular los paquetes recibidos en función de las identificaciones VLAN decada cliente. Aśı, cada usuario tiene acceso a una red espećıfica sin interferir en lasaplicaciones de las demás redes virtuales. Como parte de la aplicación FlowN to-dos los datos respecto a las direcciones de capa f́ısica y el mapeo entre los enlacesvirtuales se almacenan en una base de datos SQL. Con base en esta informaciónel controlador maneja los paquetes de cada red virtual.

20

4. Propuestas de topoloǵıas dered

Teniendo en cuenta las limitaciones a nivel de hardware para el desarrollodel presente proyecto, se plantean dos topoloǵıas cuyas implementaciones sonposibles, 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 ycuatro 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 siendousadas por dos hosts que actuaran como sensores ethernet. La interfaz Wi-Fi seráimplementada para establecer una conexión que permita el intercambio de datosdirectos entre los módulos Wi-Fi y el dispositivo central (servidor). El switchimplementado soportará el protocolo OpenFlow, será controlado y monitoreadopor ONOS desde un dispositivo externo conectado a través de la interfaz ethernetrestante. El controlador a usar será ONOS, dado que este ofrece la posibilidadde ser implementado en una topoloǵıa real, brinda facilidades al usuario que elresto de controladores no ofrecen, provee una gama de aplicaciones que al ser uncontrolador esta regido por poĺıtica, aplicaciones que ofrecen al usuario la po-sibilidad de monitorear aparte de controlar el funcionamiento de la red. Estasherramientas de monitoreo aportan a las aplicaciones planteadas en esta sección.

Figura 4.1: Topoloǵıa de red 1.

21

4.2. Topoloǵıa 2

Se propone como segunda arquitectura: tres switch conectados en delta através del controlador, donde dos de los switch tendrán dos sensores asociadospor switch y uno de ellos estará conectados al dispositivo central (servidor) quetendrá acceso a todos los datos recogidos por la red. A cada uno de los switch seconecta 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 atravé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 posibi-lidades que ofrece el paradigma de las SDN, se puede pensar en la aplicabilidaddel concepto de virtualización [26] de la red para ver el impacto que puede teneren la implementación real el hecho de gestionar anchos de banda. Ya que las redesde los entornos planteados cuentan con diferentes tipos de tecnoloǵıas de comu-nicación, el variar la capacidad de las interfaces puede tener un impacto tantoen capacidad de enrutamiento por parte de los switch, como en la capacidad deprocesamiento por parte de los dispositivos que albergan los switch y host. El usode dos tecnoloǵıas diferentes permite analizar la gestión de los recursos de la red.

22

5. Implementación

La problemática que se planteó es la implementación de un controlador parauna red enfocada al internet de las cosas, y las redes de sensores, mediante he-rramientas que serán descritas a continuación, se llevo a cabo la implementaciónf́ısica. En este proyecto, se hizo uso de un sistema operativo de software libre, yaque estas distribuciones ofrecen muchas facilidades tecnológicas en cuanto a lasSDN.Debido a que el enfoque con el que se desarrolló el presente proyecto fue la imple-mentación de una red real, se determinó utilizar como contenedor de los dispositi-vos ’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 queel software libre ofrece a través de un dispositivo práctico para la implementaciónde 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 momen-to de establecer los puentes virtuales OvS, problemas que no se presentaron altrabajar sobre ’Ubuntu’.Puesto que el paradigma de las redes definidas por software define un plano dedatos 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 interpretedicho protocolo y pueda ser instalado sobre un sistema embebido. Esto se hizo através del software OpenvSwitch [29] con el cual se crean los puentes de comuni-cació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 ins-talación y creación de las herramientas que permitieron hacer la implementaciónreal 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 dis-tribució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 ’Mini-net’, 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 uncomando que permite visualizarlas, el cual se puede apreciar a continuación.

23

Figura 5.2: Versiones de Mininet.

Al ejecutar esta ĺınea, se habrá clonado una carpeta llamada ’mininet’, en lacual se encontrará el directorio ’util’ donde estará el archivo ’install.sh’ el cualpermite instalar aplicaciones particulares de ’Mininet’.

Para ejecutar el archivo ’install.sh’ se debe hacer uso de la siguiente ĺınea mos-trada en la figura 5.5. Dependiendo de lo que se desee utilizar, el software ofrecemúltiples opciones (ver figuras 5.3 y 5.4). Al usar la opción ’–a’ se instala todolo 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 figura5.6) para verificar que se haya instalado correctamente el software, el cual generauna topoloǵıa por defecto y efectúa pruebas ICMP por medio de ping entre loshosts.

24

Figura 5.6: Creación topoloǵıa por defecto.

5.2. Creación del switch

Como se mencionó anteriormente se implementó el OpenvSwitch en ’Rasp-berry Pi 3’ modelo B, para esto se trabajó con el sistema operativo de UbuntuMate.

Es necesario mencionar que se implementaron tres tipos de switch, en funciónde 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 et-hernet, para esto fue necesario instalar los paquetes OpenvSwitch, como se puedever 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 inter-faces de red que posee el dispositivo, en este caso la ’Raspberry Pi 3’; En la figura5.8 se visualiza las diferentes interfaces, donde ’enp8s0’ es la que corresponde aethernet, ’lo’ es la interfaz de red virtual, y por ultimo ’wlo1’ es la tarjeta de redinalámbrica.

25

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.1con mascara de 24 bits al switch, se deshabilita el puerto ethernet para que noentre en conflicto con el puente, y se le atribuye la dirección MAC al switch, todoslos 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 figura5.10), donde debe aparecer el nuevo puente con la IP asignada anteriormente, laMAC 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 conflictolos puertos de red.

26

Figura 5.10: Resultados ’ifconfig’ switch Ethernet.

Existe otro comando que permite visualizar los puentes creados, y sus carac-teŕısticas, las cuales son los puertos asociados al puente y la versión del OpenvS-witch, 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 cabohaciendo uso del software OvS, como se aprecia en la siguiente figura.

Figura 5.12: Desmantelación del puente OvS.

27

5.2.2. OvS con interfaz Wi-Fi

Para el desarrollo de esta etapa, se requiere instalar un editor de redes inalámbri-cas, 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 tantode la versión que se haya instalado, puesto que sin esta información no es posibleacceder 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 debeseleccionar la opción de añadir, y escoger ‘Wi-Fi Compartida’ entre las diferentesposibles.

Figura 5.15: Despliegue de redes disponibles.

Adicionalmente se deben configurar las caracteŕısticas de la red Wi-Fi que fuecreada, tales como el nombre, la banda de frecuencia, y si se desea la seguridadde la red (ver figura 5.16).

28

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 conectara su propia red, para ello se debe seleccionar la opción de ‘Conectar a una redinalámbrica oculta’, y seleccionar la red creada, como se puede apreciar en lassiguientes 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 laRaspberry este conectada a la red creada con antelación (ver figura 5.18).

29

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 conel 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 lasalvedad que se debe añadir el puerto ‘wlo1’ que corresponde a la tarjeta de redinalámbrica del dispositivo, esta se debe deshabilitar, se puede asignar la MACdel 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 puertoshayan 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 asignadasexitosamente, se implementa el comando ’ifconfig’ seguido del nombre del puente,como se puede ver a continuación.

30

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 pri-mera en una maquina virtual, y la segunda en un sistema operativo, explicadasa continuación:

5.3.1. Instalación en máquina virtual

Como lo menciona el tutorial de ’ONOS’ [19], para esta instalación en parti-cular, es necesario contar con el software ’Oracle VM VirtualBox’ [32] y adicio-nalmente ’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 ’Virtual-Box’, se escoge la opción ’importar’ y el controlador se instalará como un sistemaoperativo, 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 lacual es ’rocks’ por defecto (ver figura 5.23).

Figura 5.23: Login de usuario ONOS.

31

Cabe mencionar que esta modalidad de instalación es recomendada únicamen-te 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 con-trolador, una vez se hayan creado los controladores, la misma terminal desplegarála CLI (consola de comandos de ’ONOS’) del controlador como se observa en lafigura 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 conel comando ’ifconfig’.

32

Figura 5.25: Creación de la red emulada.

Para hacer uso de la herramienta visual que provee el controlador que se deno-mina 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 necesarioque 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 laaplicación la comunicación entre ellos queda inhabilitada (ver figura 5.27).

33

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 diferentesmé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 repositoriosde ’ONOS’. Este procedimiento se logra al ejecutar el siguiente comando paraclonar 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’, seaccede por medio del comando ’cd onos’. Posteriormente, se ejecutan dos coman-dos (ver figuras 5.29 y 5.30) que el sistema operativo implementará de formaautomá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 decó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 parala ejecución del servicio de ’ONOS’. La manera en la que se ha instalado, exige

34

que el proceso de ’ONOS’ se inicie y se mantenga latente a lo largo de todo eluso 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 esnecesario 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, estosmensajes 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 yacceder a la siguiente dirección URL ’ direcciónIP :8181/onos/ui/login.html’. Enel 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 asignadasa las interfaces de red.

35

Figura 5.34: Login de la interfaz gráfica de ONOS.

’ONOS’ tiene como objetivo futuro personalizar cada una de las sesiones desus usuarios, por lo tanto, plantea un esquema de usuario y contraseña; a pesarde esto, en el momento no se encuentra disponible este servicio, de modo que solohay un usuario el cual es ‘ONOS’ y la contraseña de acceso es ‘rocks’, como seha comentado anteriormente.

Figura 5.35: Interfaz gráfica de ONOS.

Para verificar que el controlador este funcionando correctamente, el métodoideal 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 controla-dor, por lo cual se utilizó la IP ’localhost’ para asignarlo, como se observa en

36

la figura 5.38 se despliega un mensaje que corrobora que este proceso se ejecutocorrectamente.

Figura 5.37: Conexión entre el controlador y la red.

Al haber asignado correctamente el controlador a la SDN, se puede visualizarla 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 decomunicación Wi-Fi ’ESP8266’ [33], debido a que es un microcontrolador concapacidades 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] uti-lizando comunicación serial. Uno de los beneficios que ofrece el uso este móduloes que soporta un firmware de ’Arduino’ [35], permitiendo aśı configurarlo comoun microcontrolador tradicional.El módulo no contiene por defecto el firmware de ’Arduino’, de modo que secargó el firmware con la aplicación ’NODEMCU FIRMWARE PROGRAMER-ESP8266 FLASHER’. (ver figura 5.39).

37

Figura 5.39: Programa NODEMCU FIRMWARE PROGRAMER-ESP8266FLASHER.

Posteriormente, se seleccionó la versión de firmware como se observa en lafigura 5.40, se aconseja utilizar ’AI-v0.9.5.0 AT Firmware.bin’ este se adquierefá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́dulocomo muestra en la figura 5.41. El baudrate por defecto del módulo puede ser de9600 o 115200 baudios. Para verificar el valor de este parámetro se puede conectarel 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 co-nectar la placa de manera apropiada. El módulo trabaja con 3.3 V, es importanteenergizarlo con la fuente adecuada, ya que, en caso contrario no se puede cargarla Flash.

38

La placa cuenta con 8 pines: el pin ’VCC’ y ’ENABLE’ que requieren una ali-mentació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 elpin ’GPIO0’ a tierra para ingresar al modo de escritura de la memoria flash delmó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 avancese ha completado y aparecerá un testigo en color verde. Si en algún momento sevisualiza 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 cargarel firmware.

El siguiente paso a seguir es acondicionar el ’IDE’ de Arduino para identificarla placa ’ESP8266’, esto se logró accediendo a la pestaña de archivo del ’IDE’ yse escogió en la opción de preferencias. En este cuadro emergente, se ingresó enla sección ‘Gestor de URLs Adicionales de Tarjetas’ el siguiente enlace [?]:http://arduino.esp8266.com/stable/package esp8266com index.json

39

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 seencontró el paquete que soporta el módulo, se debe instalar la versión ’1.6.5-947-g38919f0’, 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:’ seencuentra la opción ’Generic ESP8266 module’ la cual fue implementada. De ma-nera que, el módulo es reconocido finalmente como un microcontrolador común.

40

Figura 5.46: Selección del tipo de placa

Es de recalcar, que al momento de programar el módulo hay que cerciorarse delos valores con que se polariza, y que este conectado el pin ‘GPIO0’ a tierra paracolocar el módulo en modo de escritura de memoria flash. De la misma manerapuede que haya que modificar el ’IDE’ de ’Arduino’ en la sección ‘Placa:’ respectoa 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, bastacon reiniciar el módulo.

5.5. Herramientas software adicionales

Al momento de sintetizar los programas anteriormente descritos con el fin dedesarrollar las topoloǵıas descritas en el caṕıtulo 4, fue necesario indagar sobresoftware 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 alojadosen una misma red.

Estos programas se listan a continuación:

41

5.5.1. Iperf

Esta herramienta se implemento para medir el ancho de banda máximo entredos hosts, permite ajustar diversos parámetros tales como el tiempo de la medi-ción y los protocolos, al finalizar la prueba visualiza el rendimiento medido en latasa de bits [36, 37].Para la instalación, se ejecuta el comando en la terminal de ’Ubuntu’: ’sudo apt-get install iperf’ en la consola de comandos, se recomienda utilizar la versión2.0.10, debido a que permite la medición entre hosts con sistemas operativosdiferentes, 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 compati-bilidad.

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’ sedebe deshabilitar el ’firewall’ y el antivirus en caso de tenerlo.

Host transmisor (ver figura 5.48): Para ejecutar este comando se deben teneren cuenta las mismas consideraciones que en el servidor, sin embargo estecontiene parámetros que pueden ser modificados, el comando ’-c’ requiere laIP del host servidor, y la opción ’-t’ el tiempo en el cual se van a transmitirdatos.

Figura 5.47: Configuración servidor iperf.

Cabe recalcar que la interfaz en la cual se mide el ancho de banda, es aquellaque 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 deservicio) [38].

Para instalar ’D-ITG’ se realizó mediante la ĺınea de código: ’sudo apt-getinstall d-itg’ en la consola de Ubuntu, esta aplicación se implemento únicamenteen la emulación, a continuación se listan y describen las herramientas mas im-portantes que se exploraron de este software.

42

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́ delos datos, ofrece configurar el protocolo de comunicación ’-T’, seleccionar al hostal cual se va transmitir ’-a’, el tamaño de bytes que se env́ıa, el tamaño de cadapaquete ’-c’, la cantidad de paquetes por segundo ’-C’, el tiempo total ’-t’, y porú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 losresultados y estad́ısticas del tráfico generado, esto se realizó con el comandoITGDec (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 recursode los switch, para esto se indago en la literatura existente, y se encontró elsoftware ’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

Figura 5.52: Interfaz gráfica Nmon.

Como se puede ver en la figura 5.52, ’Nmon’ permite monitorear los recursosdel sistema (ver figura 5.53) por medio de la opción ’l’ despliega el consumo delos 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 lared.

5.5.4. FileZilla

FileZilla [40] es un cliente multiplataforma de ’FTP’, ’SFTP’ y ’FTPS’ conuna amplia lista de funciones que puede ser instalado Windows, Mac OS X, Li-nux y más. Las herramientas dinámicas de ’FileZilla’ permiten transferir archivosentre 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 archi-vos 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 ins-tall filezilla’, y en Windows se descarga el instalador y se ejecuta, el clientese puede conectar a varios servidor de forma simultanea.

44

Figura 5.54: Interfaz FileZilla FTP Client.

El segundo software es ’FileZilla FTP Server’(ver figura 5.55) que solo puedeser ejecutado en Windows, esta herramienta permite crear un servidor FTP,y establecer que archivos serán compartidos, y restringir el acceso a usuariospreviamente definidos desde el servidor, para que funcione correctamentese 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 bastacon utilizar las siguientes dos ĺıneas de comandos en la consola de Ubuntu (verfigura 5.56).

45

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 muestrana continuación. Se presentan la creación de los puentes en cada uno de los switchcon 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 puentecon los puertos e interfaces apropiados. A continuación, se presentan los coman-dos que se deben ejecutar en el switch de esta topoloǵıa.

Por otra parte con el controlador, no es necesario ejecutar ningún procedi-miento 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. Sedenominan a los dispositivos conectados a las interfaces ethernet como ’Sensor1’ y ’Sensor 2’, mientras que los dispositivos conectados a las interfaces Wi-Fi sedenominan ’Sensor 3’ y ’Sensor 4’.

Figura 5.58: Comandos para la creación del switch 1 con 4 interfaces ethernet.

46

5.6.2. Topoloǵıa 2

Del mismo modo que en el caso descrito anteriormente, se presentan las ĺıneasde comandos para crear el puente con las interfaces para esta topoloǵıa en cadauno de los switch. En este caso es muy importante prestar atención a las direc-ciones MAC con las que se crean los puentes, puesto que la instrucción ’ovs-vsctladd-br’ puede asignar direcciones MAC idénticas en los switch, por tanto la redentrara en conflicto y no funcionará de forma adecuada.

Figura 5.59: Comandos para la creación del switch 1.



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

Posterior a la creación de los switch, es necesario iniciar los servidores SSH encada uno de ellos, para aśı tener acceso a información de procesos dentro de cadadispositivo y controlar los anchos de banda de cada interfaz. Teniendo el controlde los dispositivos, el monitoreo remoto se hace a través de la aplicación NMON.

Ahora, lo único que resta por hacer, es configurar un puente en el controla-dor ya que recibirá 3 conexiones ethernet de parte de los switch. Los comandosnecesarios para la creación del puente se presentan a continuación:

Figura 5.62: Creación del puente para el controlador.

La topoloǵıa final es definida como se muestra en la figura 4.2, donde sedefinen como ’Sw3’ al switch que va conectado al dispositivo central, ’Sw2’ y’Sw1’ como los switch que se encuentran en el segundo nivel del red tipo-deltacreada. Al switch ’Sw1’ se conectan los dispositivos “Sensor 1” a través de lainterfaz ethernet y “Sensor 3” a través de la interfaz Wi-Fi. A ’Sw2’ se conecta“Sensor 2” a través de la interfaz ethernet y “Sensor 4” a través de la interfazWi-Fi.

5.6.3. DHCP

Ya teniendo toda la topoloǵıa montada, el paso final para que la red entre enfuncionamiento es la asignación de direcciones IP a cada uno de los dispositivos.Como se puede ver en la subsección anterior la asignación de direcciones para losswitch y el controlador debe hacerse manualmente, puesto que antes de que estosestén conectados no hay manera de que alguien asigne direcciones.

Como se puede ver en las figuras anteriores, se utilizaron direcciones IP de redprivada clase A [41] con mascara de red 255.255.255.0 y la subred ’10.1.11.x/24’.Donde fueron asignadas manualmente de la siguiente manera:

48

Cuadro 5.1: Asignación manual de IP topoloǵıa 1.

Dispositivo IPControlador 10.1.11.10/24

Sw1 10.1.11.1/24

Cuadro 5.2: Asignación manual de IP topoloǵıa 2.

Dispositivo IPCtrl 10.1.11.10/24Sw1 10.1.11.1/24Sw2 10.1.11.2/24Sw3 10.1.11.3/24

El controlador ONOS cuenta con una aplicación llamada ’app.onosproject.dhcp’la cual crea un servidor DHCP y le provee al controlador la capacidad de asig-nar direcciones IP a los dispositivos conectados a la red. Para hacer uso de estaherramienta de ONOS es necesario usar en consola el siguiente comando.

Figura 5.63: Comando para habilitar la aplicación DHCP de ONOS.

El archivo que se ejecuta es un código ’.json’ que tiene la información con laque trabajará el servidor DHCP.

Figura 5.64: Caracteŕısticas de DHCP de ONOS.

Posterior a esto, se debe activar en la CLI de ONOS la aplicación con elcomando ’app act́ıvate app.onosproject.dhcp’.

49

El resultado obtenido para de las redes visto desde la interfaz gráfica de ONOSse muestra a continuación:

Figura 5.65: Interfaz gráfica de ONOS. Topoloǵıa 1

Figura 5.66: Interfaz gráfica de ONOS. Topoloǵıa 2

Es pertinente decir que los enlaces entre los switch mostrados en la figura 5.66,son enlaces virtuales que crea el controlador al haber conectado los switch. Estosenlaces no representan son una conexión f́ısica o un enlace Wi-Fi en la realidad,mientras que el resto de enlaces que se muestran si representan un enlace real enla implementación.

5.7. Protocolo de pruebas

Para evaluar el rendimiento de las redes planteadas se proponen la siguienteserie de pruebas.

50

5.7.1. Conexión entre hosts

El primer paso a seguir fue comprobar la conexión entre los hosts de la red,esto se logró haciendo ping entre ellos hasta saber que todos esta en red. En casode que no se logre realizar el ping desde o hacia algún host las razones puedenser las siguientes.

Es apropiado comprobar que las conexiones de los hosts aparecen en lainterfaz gráfica de ONOS, ya que si el controlador no los identifica puedeque haya algún error de conexión en la red y esto evidentemente impediráel intercambio de paquetes.

Dependiendo del sistema operativo que utilicen los hosts, puede que las ba-rreras ’Firewall’ interfieran en el intercambio de ciertos mensajes, de modoque en caso de fallos es apropiado configurar los permisos de estas aplica-ciones.

En cuyo caso lo anterior se haya revisado y no haya ningún problema, puedeque la aplicación ’fwd’ de ONOS este desactivada. Si este es el caso, bastacon ir a la CLI del controlador y usar el comando ’app activate fwd’.

5.7.2. Env́ıo de datos

Para la evaluación de la red se propuso tomar medida de los parámetros decalidad de servicio jitter, delay, PLR y throughput. Con el fin de evaluar la reden un entorno de desempeño real, se hizo envió real de datos y se monitoreó eltráfico a través del software ’WireShark’.

Para las medidas de retardo como el delay y jitter, se inicio el monitoreo detráfico de manera sincronizada y el retardo de llegada de un paquete desde elhost de seguridad (Sensor 1 y 2) hasta el host central. Ya teniendo los retardosde cada paquete enviado el delay se calculó a través del promedio de los retardosde todos los paquetes, y el jitter se calculo a partir de dichos retardos, el retardogeneral y la cantidad de paquetes enviados. Estas medidas de tiempo se tomaronsolamente para las interfaces ethernet ya que en los módulos Wi-Fi no hay ma-nera de monitorear el envió de datos de manera apropiada, no es posible tenerun software de monitoreo. Para las medidas de throughput y PLR, se monitoreósolo el host central. Para la tasa de paquetes perdidos el software ’WireShark’directamente muestra los paquetes perdidos y retransmitidos. Mientras que parael cálculo del throughput se encuentra la relación entre la cantidad de bits dedatos recibidos por unidad de tiempo determinada.

Aśı, se enviaron diferentes tipos de datos a la vez por cada interfaz con la fi-nalidad de saturar la red.

A través de las interfaces ethernet, por medio del programa FileZilla, se env́ıoun v́ıdeo 78.913.536 bytes. Mientras que por la interfaz Wi-Fi se enviaron segui-damente 2020 bytes de datos formados por un string de relleno.

51

5.7.3. Algoritmos para la comunicación Wi-Fi

Para la comunicación Wi-Fi, se programaron los módulos Wi-Fi en lenguajeC sobre un firmware de ’Arduino’, con el siguiente código.

Figura 5.67: Código implementado en los módulos Wi-Fi.

Ahora, para montar un servidor para los módulos Wi-Fi en el host centralse utilizó el siguiente código en lenguaje ’Python’, el cual se encarga de abrir lospuertos de escucha, establecer un enlace entre él y los dos módulos Wi-Fi y enviarun eco, con el fin de tener env́ıo de datos bidireccional.

Figura 5.68: Código implementado en el servidor del host central.

5.7.4. Configuración FileZilla

Como se menciono anteriormente existen 4 sensores en ambas topoloǵıas yun dispositivo central que actúa como servidor, puesto que recibe todos los datostransmitidos, para el env́ıo del v́ıdeo por las interfaces ethernet, se implemento

52

un cliente y servidor FTP, sin embargo para ’FileZilla’ servidor es quien aloja losdatos y transmite, mientras que el servidor recibe y almacena los datos transmi-tidos, por tal razón en los sensores 1 y 2 se ejecuto el software ’FileZilla FTPServer’ mientras que en el dispositivo central (servidor) se ejecuto ’FileZilla FTPClient’, como se explica a continuación:

Configuración sensores 1 y 2 con ’FileZilla FTP Server’: Al ejecutar el pro-grama, se desplegará una ventana que solicitará conectar al servidor, demanera que se conecta al propio host que esta actuando como sensor, serecomienda habilitar la opción ’Always connect to this server’, para evi-tar repetir este procedimiento cada vez que se desee enviar un archivo (verfigura 5.69).

Figura 5.69: Conexión al servidor local FTP.

Posterior a esto se debe añadir los usuarios que podrán acceder al servidory que soliciten la transferencia de los archivos, para esto se ingresa al menúeditar y se selecciona usuarios (ver figura 5.70), se añade uno, puesto quese conectará un host a los sensores ethernet, el cual es el dispositivo central(servidor), se hace especial énfasis tanto en el nombre y contraseña que sonasignadas al usuario nuevo, debido a que mas adelante estos datos seránrequeridos por parte del cliente para establecer la conexión.

Figura 5.70: Creación de los usuarios del servidor local FTP.

53

El último ajuste que se debe realizar, es seleccionar la carpeta que contienelos archivos que serán compartidos, como se puede ver en la figura 4.71, estacarpeta compartida debe estar asociada al usuario anteriormente creado.

Figura 5.71: Selección de los archivos a compartir.

Configuración dispositivo central (servidor) con ’FileZilla FTP Client’: Estaconfiguración es mas simple, debido a que se debe ejecutar el software, yacceder al menú conectar al servidor (ver figura 5.54), para esto se debeconocer las direcciones IP de los sensores, los puertos que se determinaronpara la comunicación, el nombre y la contraseña de los usuarios creados,luego de esto se selecciona el archivo y se descarga.

5.7.5. Medición

Finalmente, teniendo la red en funcionamiento solo falta evaluar los paráme-tros QoS anteriormente nombrados, mientras se realiza la variaciones la capacidadde ancho de banda de las interfaces asociadas a los sensores. Para realizarlo desdeel controlador se accede al SSH de los switch con el comando:

ssh @ssh [email protected]

Al haber accedido al switch, el ancho de banda de las interfaces se configuracon la siguiente ĺınea.

Figura 5.72: Comando de variación del ancho de banda

Con el fin de dar sentido a los resultados obtenidos, se mide el ancho de bandaneto utilizando la herramienta IPERF según se varia en las interfaces.

5.8. Emulación

Para esta sección, se implementaron los software ’Mininet’ como herramientapara emular las topoloǵıas 1 y 2 anteriormente descritas, ’ONOS’ para que actuécomo controlador de la red SDN tal como en la implementación f́ısica, ’D-ITG’

54

para enviar la información de los sensores y calcular los parámetros ’QoS’ en cadaprueba, y finalmente ’iperf’ para medir los anchos de banda entre host.

Debido a que en los objetivos espećıficos se planteo comparar resultados entrela emulación e implementación real, se requiere que se ejecute la emulación bajolas mismas condiciones que se realizo en la implementación, se establecieron losmismos valores de ancho de banda de las interfaces, sin embargo en la topoloǵıa1 surgieron inconvenientes, ya que ’Mininet’ no permite la emulación de hostinalámbricos, de manera que se hizo uso de host con interfaces ethernet y seestablecieron los anchos de banda tal como si fuera interfaz Wi-Fi.

Fue necesario crear las topoloǵıas en ’Mininet’ (ver figura 5.73), al relacionarlos host con los sensores anteriormente descritos, se obtiene que:

Topoloǵıa 1:Host 2 y 4 asociados a interfaces ethernet equivalen a los sensores 1 y 3asociadas a interfaces ethernet.Host 3 y 5 asociados a interfaces ethernet equivalen a los sensores 2 y 4asociadas a la misma interfaz Wi-Fi.Host 1 equivale al dispositivo central (servidor).

Topoloǵıa 2: Switch 1:Host 1 asociado a interfaz ethernet equivale al sensor 1 asociado a interfazethernet.Host 2 asociado a interfaz ethernet equivale al sensor 2 asociado a interfazWi-Fi.Switch 2:Host 3 asociado a interfaz ethernet equivale al sensor 3 asociado a interfazethernet.Host 4 asociado a interfaz ethernet equivale al sensor 4 asociado a interfazWi-Fi.Switch 3:Host 5 equivale al dispositivo central (servidor).

55

Figura 5.73: Creación topoloǵıas en Mininet.

No se pudo hacer uso de ’FileZilla’ en la emulación, puesto que la creacióndel servidor ’FTP’ aun no esta soportada en ’Ubuntu’ , de manera que se generóel tráfico con ’D-ITG’, para esto fue necesario calcular las siguientes variables apartir de los resultados obtenidos de la implementación f́ısica.

Paquetes enviados por segundo.

Tamaño promedio de cada paquete en bytes.

Tamaño total de la información enviada en kilobytes.

Tiempo necesario para el envió de la información total en milisegundos.

Cuadro 5.3: Variables de los sensores en las pruebas con ancho de banda sinninguna restricción.

Sensor Paquetesenviados por

segundo

Tamaño decada paquete

(Bytes)

Tamaño total(kB)

Tiempo total(ms)

Sensor 1 156 1448 79000 305.7572Sensor 2 1 1448 172 121.4Sensor 3 156 1448 79000 350.7572Sensor 4 1 1448 172 119.96

Esto se puede observar en las figuras 5.74 y 5.75, esta pruebas correspondena la topoloǵıa 1, el cálculo de las variables por cada sensor, esto solo se efectuóen los resultados con ancho de banda a su máxima capacidad, es decir cuando nose hab́ıa limitado.

56

Figura 5.74: Configuración del dispositivo central (servidor) en Mininet.

Figu

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS...

Documents

Transcript of UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS...