Analisis e integración de los componentes que conforman una red SDN-Edge Computing

Escuela de Ingenier´ ıa Inform´ atica TRABAJO FIN DE GRADO Grado en Ingenier´ ıa Inform´ atica Analisis e Integraci´ on de los Componentes que Conforman una red SDN-Edge Computing Autor: D. Jos´e Ignacio Hern´andez Velasco Tutores: Dr. D. Jes´us M. Vegas Hern´andez D. Daniel Velasco Benito Co-Tutor: Dra. D˜n. Noem´ı Merayo ´ Alvarez 2 Resumen El presente trabajo pretende abordar el an´alisis e integraci´on de los distintos componetes que conforman una red de acceso SDN-EdgeComputing. El objetivo es explicar los nuevos entornos de red y la necesidad de estos en el mundo actual ante el gran volumen de datos obtenidos por la aparici´on masiva de modernos dispositivos. Se explicar´a el estado actual de los distintos controladores SDN y las disparidades principales entre ellos, c´omo opera la red, as´ı como el software necesario para su funcionamiento. De igual manera, se analizar´an las disimilitudes para la integraci´on de 3 OLTs de diferentes fabricantes y qu´e supone esto en cuanto al desarrollo del software para esa red. Por ´ultimo, se analizar´a el desarrollo de una herramienta para la monitorizaci´on y exportaci´on de datos de la red, as´ı como las m´etricas utilizadas para el an´alisis de la misma. 3 4 Abstract The present work aims to address the analysis and integration of the different components that make up an SDN-EdgeComputing access network. The objective is to explain the new network environments and the need for these in today’s world before the large volume of data obtained by the massive appearance of modern devices. It will explain the current status of the different SDN controllers and the main disparities between them, how the network operates, as well as the software necessary for its operation. Likewise, the dissimilarities for the integration of 3 OLTs from different manufacturers will be analyzed and what this means in terms of software development for that network. Finally, we will analyze the development of a tool for monitoring and exporting data from the network, as well as the metrics used to analyze it 5 6 Tabla de Contenidos 1. Introducci´on 11 1.1. Objetivos .................................. 11 1.2. Contextoactual............................... 12 1.3. NFV..................................... 12 1.4. EdgeComputing .............................. 13 1.5. SDN y Caracter´ısticas de las SDN . . . . . . . . . . . . . . . . . . . . 14 2. Controladores SDN 17 2.1. OpenFlow.................................. 18 2.2. Controladores Openflow y Factores para elegir un Controlador . . . . 19 3. Contexto de la red 23 3.1. RedesPON ................................. 23 3.1.1. Componentes de una Red PON . . . . . . . . . . . . . . . . . . 23 3.1.2. Terminal de l´ınea ´optico (OLT) . . . . . . . . . . . . . . . . . . 24 3.1.3. Unidad de Red ´ Optica (ONU) y Terminal de red ´ Optico (ONT) 25 3.2. VOLTHA .................................. 26 3.2.1. Definici´on de VOLTHA . . . . . . . . . . . . . . . . . . . . . . 26 3.2.2. Adaptadores VOLTHA . . . . . . . . . . . . . . . . . . . . . . 27 3.2.3. OpenOLT.............................. 27 3.2.4. OpenOMCI............................. 31 3.3. ONOS.................................... 35 3.3.1. Funcionamiento de ONOS . . . . . . . . . . . . . . . . . . . . . 36 3.3.2. Niveles e funcionalidad de ONOS y Servicios Primarios . . . . 36 3.3.3. ONOSvsODL........................... 37 3.3.4. Aplicaciones ONOS . . . . . . . . . . . . . . . . . . . . . . . . 40 3.4. Esquema de la red y Topolog´ıa . . . . . . . . . . . . . . . . . . . . . . 42 3.4.1. Topolog´ıa de Red . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4. Integraci´on de los componentes de la red 49 4.1. Activaci´on de los componentes ONOS y VOLTHA . . . . . . . . . . . 49 4.1.1. Activaci´on de ONOS . . . . . . . . . . . . . . . . . . . . . . . . 49 4.1.2. Activaci´on de VOLTHA . . . . . . . . . . . . . . . . . . . . . . 52 4.2. Integraci´on OLT GPON Cel´estica . . . . . . . . . . . . . . . . . . . . . 55 4.2.1. Pre-provisionar OLT . . . . . . . . . . . . . . . . . . . . . . . . 55 4.2.2. Conexi´on de la ONT . . . . . . . . . . . . . . . . . . . . . . . . 61 7 4.2.3. Registro de la OLT . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.2.4. Creaci´on de Endpoint Cliente y prueba de Tr´afico . . . . . . . 64 4.3. Integraci´on OLT XGSPON Tibit . . . . . . . . . . . . . . . . . . . . . 66 4.3.1. Pre-provisionar OLT . . . . . . . . . . . . . . . . . . . . . . . 67 4.3.2. Conexi´on de la ONT . . . . . . . . . . . . . . . . . . . . . . . . 68 4.3.3. Registro de la OLT . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.3.4. Creaci´on de Endpoint Cliente y prueba de Tr´afico . . . . . . . 69 4.4. Integraci´on OLT XGSPON Edgecore . . . . . . . . . . . . . . . . . . . 70 4.4.1. Pre-provisionar OLT . . . . . . . . . . . . . . . . . . . . . . . . 70 4.4.2. Conexi´on de la OLT . . . . . . . . . . . . . . . . . . . . . . . . 73 4.4.3. Registro de la OLT . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.4.4. Pasos siguientes . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 5. Monitorizaci´on de la red 77 5.1. Estado Actual de la monitorizaci´on . . . . . . . . . . . . . . . . . . . . 77 5.1.1. Componentes de un Servicios de Monitorizaci´on . . . . . . . . 77 5.2. Recopilaci´on de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.3. Almacenamiento de datos . . . . . . . . . . . . . . . . . . . . . . . . . 81 5.3.1. Prometheus............................. 82 5.4. Visualizaci´on y An´alisis . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.4.1. Grafana............................... 83 5.5. Alertado................................... 83 5.6. Funcionamiento............................... 83 5.6.1. Dashboards Grafana . . . . . . . . . . . . . . . . . . . . . . . . 85 6. Conclusiones y trabajo futuro 89 6.1. Conclusiones ................................ 89 6.2. Trabajofuturo ............................... 90 8 Lista de Figuras 1.1. EsquemaNFV ............................... 13 2.1. Arquitectura de Controlador SDN. Figura en [5] . . . . . . . . . . . . 18 2.2. Funcionamiento de OpenFlow . . . . . . . . . . . . . . . . . . . . . . . 19 3.1. Esquema Redes PON. Obtenido de [15] . . . . . . . . . . . . . . . . . 24 3.2. OLT de Tibit. Obtenido de [22] . . . . . . . . . . . . . . . . . . . . . . 25 3.3. OLT de Edgecore. Obtenido de [19] . . . . . . . . . . . . . . . . . . . . 25 3.4. Arquitectura VOLTHA. Obtenido en [21] . . . . . . . . . . . . . . . . 27 3.5. Funcionamiento OpenOLT. . . . . . . . . . . . . . . . . . . . . . . . . 28 3.6. Funcionamiento protocolo gRPC . . . . . . . . . . . . . . . . . . . . . 29 3.7. Esquema de varios Adaptadores . . . . . . . . . . . . . . . . . . . . . . 30 3.8. Esquema de ´unico Adaptador . . . . . . . . . . . . . . . . . . . . . . . 31 3.9. Estados OMCI. Obtenido en [1] . . . . . . . . . . . . . . . . . . . . . . 35 3.10. Niveles de Funcionalidad de ONOS. Obtenido en [13] . . . . . . . . . . 37 3.11. Subsistemas actuales de ONOS. Obtenido en [13] . . . . . . . . . . . . 37 3.12.EsquemadeODL.............................. 38 3.13. Esquema Completo de red . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.14.Topolog´ıaCLOS .............................. 44 3.15. Topolog´ıa Hipercubo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.16. Topolog´ıa Toroidal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.17.Topolog´ıaMedusa ............................. 46 3.18.Topolog´ıaDCell .............................. 46 3.19. Topolog´ıa Mariposa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.1. Consola de comandos ONOS . . . . . . . . . . . . . . . . . . . . . . . 50 4.2. Switches conectados a ONOS . . . . . . . . . . . . . . . . . . . . . . . 51 4.3. Topolog´ıa de switches visto desde el GUI . . . . . . . . . . . . . . . . . 52 4.4. docker-compose-system-test.yml . . . . . . . . . . . . . . . . . . . . . . 53 4.5. Contenedores docker levantados . . . . . . . . . . . . . . . . . . . . . . 55 4.6. Comunicaci´on VOLTHA-OLT . . . . . . . . . . . . . . . . . . . . . . . 56 4.7. Diagrama secuencia creaci´on Endpoint volt . . . . . . . . . . . . . . . 57 4.8. Resgistro de Endpoint volt . . . . . . . . . . . . . . . . . . . . . . . . 58 4.9. Diagrama secuencia creaci´on Endpoint olt-control . . . . . . . . . . . . 59 4.10. Registro Endpoint olt-control . . . . . . . . . . . . . . . . . . . . . . . 59 4.11. Flows olt-control en L1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 9 16 Cap´ıtulo 2 Controladores SDN La arquitectura b´asica de las SDN [3] est´a compuesta por 3 capas: Infraestructura, Control y Aplicaciones. La l´ogica de la red en las SDN se encuentra en los controladores que mantienen la visi´on global de la red. Los switch delegan su “inteligencia” al controlador, y su cometido pasa a ser el de conmutar paquetes. Es en el controlador donde se configurar´a el enrutamiento, el cual se encuentra abierto a la implementaci´on de nuevas funcionalidades a trav´es de sus API. En cuanto a la capa de Infraestructura, est´a formada por los dispositivos de red. Estos exponen sus capacidades a trav´es de una interfaz de control que permite la comunicaci´on entre el controlador SDN y los dispositivos de red. Seguidamente, la capa de Control genera una interfaz que permite programar el control de las operaciones de reenv´ıo por parte del propio controlador. La interfaz de control se formaliza a trav´es del protocolo OpenFlow, el cual se ha convertido en el protocolo de facto a utilizar para la conexi´on remota entre el controlador SDN y los switches. Por lo tanto, la elecci´on del hardware y del software deben soportar el est´andar OpenFlow. En la capa de control se encuentra el controlador SDN, encargado de gestionar la conmutaci´on del tr´afico. El controlador equivaldr´ıa al sistema operativo de la red que maneja la comunicaci´on entre las aplicaciones y los dispositivos. Por ´ultimo, la capa de Aplicaci´on permite comunicar al controlador (mediante la APIs) tanto necesidades como el comportamiento que desean de la red, debido a que la definici´on de aplicaciones SDN es muy amplia (cubriendo desde servicios de redes, aplicaciones de negocio, etc.). Las diversas aplicaciones SDN hablan con la red de maneras diferentes y por lo tanto, requieren de interfaces diferentes. En la figura 2.1 se representan las 3 capas de la arquitectura SDN. 17 Figura 2.1: Arquitectura de Controlador SDN. Figura en [5] 2.1. OpenFlow OpenFlow [11] es un protocolo que permite comunicar a los switches de red d´onde enviar los paquetes requeridos. En una red convencional, cada switch tiene un software propietario que orienta las actividades a realizar. Con OpenFlow se estandarizan las decisiones de migraci´on de paquetes, de modo que la red se puede programar independientemente de los switches individuales. En un conmutador convencional, la transferencia de paquetes (la trayectoria de datos) y el enrutamiento de alto nivel (la trayectoria de control) suceden en el mismo dispositivo. Un switch separa la trayectoria de datos de la trayectoria de control. La porci´on de trayectoria de datos reside en el propio conmutador y un controlador separado toma las decisiones de enrutamiento de alto nivel. El conmutador y el controlador se comunican por medio del protocolo OpenFlow. Muchas empresas establecidas, incluyendo IBM, Google y HP, han utilizado completamente o han anunciado su intenci´on de soportar el est´andar de OpenFlow. Big Switch Networks [11], una compa˜n´ıa de SDN con sede en Palo Alto, California, ha implementado redes de OpenFlow que funcionan sobre redes tradicionales, lo que hace posible colocar m´aquinas virtuales en cualquier centro de datos para obtener capacidad de computaci´on. A principios de 2012, la red interna de Google estaba soportada completamente con OpenFlow. En la Figura 2.2 se muestra el funcionamiento de OpenFlow 18 Figura 2.2: Funcionamiento de OpenFlow 2.2. Controladores Openflow y Factores para elegir un Controlador Un controlador Openflow [3] ofrece una interfaz de programaci´on para los conmutadores OpenFlow. Un controlador SDN puede ser descrito como un sistema o colecci´on de sistemas que ofrecen: Gesti´on del estado de la red: implica una base de datos. Dichas bases sirven como un repositorio para la informaci´on de los elementos de red gestionados, incluyendo el estado de la red, alguna informaci´on de configuraci´on temporal e informaci´on sobre la topolog´ıa de la red. Un modelo de datos de alto nivel que captura las relaciones entre los recursos gestionados, las pol´ıticas y otros servicios prestados por el controlador. En muchos casos estos modelos de datos se construyen utilizando el lenguaje de modelado Yang. Un mecanismo de descubrimiento de dispositivos, topolog´ıa y servicio; un sistema de c´alculo de ruta y, potencialmente, otros servicios de informaci´on centrados en la red o en los recursos. Una sesi´on de control segura sobre el Protocolo de Control de Trasmisi´on (TCP por su nombre en ingles Transmission Control Protocolo entre el controlador y los agentes asociados en los elementos de la red, por ejemplo con el uso del protocolo TLS. 19 Un protocolo basado en est´andares (OpenFlow) para obtener el estado de la red impulsado por las aplicaciones de los elementos de red. Un conjunto de APIs, a menudo RESTful que exponen los servicios del controlador a las aplicaciones de gesti´on. Esto facilita la mayor parte de la interacci´on del controlador con estas aplicaciones. Esta interfaz se representa a partir del modelo de datos que describe los servicios y funciones del controlador. En algunos casos, el controlador y su API son parte de un entorno de desarrollo que genera el c´odigo de la API a partir del modelo de datos. Algunos controladores SDN que soportan OpenFlow: ODL, Ryu, Trema, POX, ONOS. Los factores [3] a tener en cuenta cuando elegimos un controlador SDN son los siguientes: Soporte OpenFlow: al elegir un controlador los administradores de red necesitan conocer las caracter´ısticas de las versiones de OpenFlow que el controlador soporta, as´ı como las posibilidades que ofrece el proveedor para migrar a las nuevas versiones del protocolo, tales como la v1.3 y la v1.4. Una raz´on por la que esto es necesario, es que algunas funciones importantes, como por ejemplo el soporte de IPv6, no son parte de OpenFlow v1.0 pues se incluyen a partir del est´andar OpenFlow v1.2. Virtualizaci´on de red: debido a los beneficios que ofrece la virtualizaci´on de red, un controlador SDN debe soportarla. Esta caracter´ıstica permite a los administradores crear din´amicamente las redes virtuales basadas en pol´ıticas, disociadas de las redes f´ısicas, para satisfacer una amplia gama de requisitos, como por ejemplo, la ampliaci´on horizontal de la capacidad, sin afectar a los flujos existentes. Otra de las muchas ventajas de la virtualizaci´on de red, es que permite un completo aislamiento entre cada segmento de red, lo que es muy ´util por razones de seguridad. Por ejemplo, para mantener aislados los datos generados por un grupo de usuarios de otros usuarios y permitir a los desarrolladores de aplicaciones ejecutar las mismas en un entorno de trabajo sin afectar el tr´afico. Para cumplir estos requisitos de manera eficiente, en los controladores SDN se deben configurar las redes virtuales de forma centralizada, con total aislamiento unas de otras. De igual manera, dichas configuraciones deben estar automatizadas. Funcionalidad de la red: para lograr mayor flexibilidad en t´erminos de c´omo los flujos son enrutados, es importante que el controlador SDN pueda tomar decisiones de enrutamiento basado en m´ultiples campos de la cabecera de OpenFlow. Tambi´en es importante que el controlador pueda definir los par´ametros de QoS flujo por flujo. Otra importante funcionalidad en un controlador SDN es su capacidad para descubrir m´ultiples caminos desde el origen del flujo a su destino y para dividir el tr´afico de un flujo dado a trav´es de m´ultiples enlaces. Esta capacidad elimina 20 la necesidad de STP (Protocolo de ´ Arbol Extendido o Spanning Tree Protocol) aumentando el rendimiento y la escalabilidad de la red permitiendo as´ı mismo, eliminar el requisito de a˜nadir a la complejidad de la red nuevos protocolos como TRILL (Transparent Interconnection of Lots of Links ) o SPB (Shortest Path Bridging). Escalabilidad: una consideraci´on fundamental en este apartado es el n´umero de conmutadores o switches que un controlador SDN puede soportar. En la actualidad, se debe esperar que los controladores soporten un m´ınimo de 100 switches, pero en ´ultima instancia esto depender de las aplicaciones que soportan. Otro factor que limita la escalabilidad de una red SDN es la proliferaci´on de entradas en la tabla de flujo. Al evaluar los controladores SDN, es necesario asegurarse que el controlador puede disminuir el impacto de sobrecarga de difusi´on de red, la cual limita la escalabilidad de la arquitectura de red implementada y reduce al m´ınimo la proliferaci´on de las entradas de la tabla de flujo. Otro aspecto de la escalabilidad es la capacidad del controlador de SDN para crear una SDN que pueda abarcar m´ultiples sitios. Esta habilidad permite el movimiento de m´aquinas virtuales y el almacenamiento virtual entre sitios. Para maximizar el beneficio de esta capacidad, el controlador SDN debe permitir que las pol´ıticas de red para el enrutamiento y reenv´ıo se apliquen autom´aticamente para la migraci´on de servidores y/o almacenamiento. Rendimiento: una de las principales funciones de un controlador SDN es establecer flujos. Por ello, dos de los indicadores claves de rendimiento asociados con un controlador SDN son el tiempo de conformaci´on de flujo y el n´umero de flujos por segundo que puede establecer el controlador. Estas m´etricas de desempe˜no influyen en gran medida cuando se requiere a˜nadir controladores, como por ejemplo, cuando los switches inician m´as flujos de los que pueden ser soportados por el controlador o los controladores SDN existentes. Programaci´on de red: una de las caracter´ısticas fundamentales de las SDN es la existencia de interfaces para la programaci´on del controlador, lo que posibilita que se ofrezcan varias funcionalidades. Algunos ejemplos de programaci´on que se deben buscar en un controlador SDN, son la capacidad de redirigir el tr´afico (por razones de seguridad se puede disponer que el tr´afico entrante a un servidor pase a trav´es de un corta fuegos o firewall, pero para no consumir los recursos del servidor de seguridad con tr´afico limpio se puede decidir que no pase por el firewall el tr´afico saliente del mismo servidor) y la posibilidad de aplicar filtros sofisticados a los paquetes los cuales pueden ser pensados como ACLs (Listas de Control de Acceso o Access Control List por sus siglas en ingl´es) din´amicas e inteligentes como combinaciones complejas de m´ultiples campos de cabecera de paquetes. Soporte comercial al controlador SDN: dado el creciente inter´es en las SDN, numerosos fabricantes han entrado en el mercado y muchos m´as han anunciado su intenci´on de hacerlo. Debido a la volatilidad del mercado SDN en general, y del mercado del controlador SDN en particular, las organizaciones que deben 21 evaluar controladores SDN para sus redes deben centrarse no s´olo en los atributos t´ecnicos del controlador, sino tambi´en en las caracter´ısticas del vendedor. Entre estas, se encuentra la competencia t´ecnica y financiera del proveedor pues las organizaciones no pueden permitirse tener las SDN perjudicadas por adquirir controladores de un proveedor que no puede mantenerse al d´ıa en el cambiante entorno SDN. 22 Cap´ıtulo 3 Contexto de la red En este cap´ıtulo se pretende explicar los diferentes componentes que conforman la red que se va a implementar. Se comenzar´a exponiendo los componentes que conforman una red PON; se continuar´a con los componentes software que estamos utilizando (ONOS y VOLTHA) y por ´ultimo, se formular´a un esquema completo de la red y la topolog´ıa que se est´a usando in situ. La red con la que estamos trabajando est´a formada por 6 switches que hablan OpenFlow, un conjunto de Host en los que se almacenan los diferentes servicios y componentes software, una OLT y una ONU. La creaci´on y gesti´on de las diferentes MV que almacenan los servicios se hace a trav´es de OpenNebula, una plataforma de cloud computing. 3.1. Redes PON A lo largo del tiempo, las tecnolog´ıas usadas en las redes de acceso se han ido actualizando. Se comenz´o con redes implementadas solo con cobre y posteriormente se pas´o a redes h´ıbridas, implicando un aumento del ancho de banda y disminuci´on de latencia. En los ´ultimos a˜nos, las compa˜n´ıas de telecomunicaciones de todo el mundo han empezado a modernizar su infraestructura adoptando la tecnolog´ıa, denominada fibra, hasta el hogar (FTTH). Esto a hecho que los proveedores de estos sistemas est´en avanzando r´apidamente. Existen dos tipos importantes de sistemas que hacen posibles las conexiones de banda ancha FTTH: redes ´opticas activas (AON) y redes ´opticas pasivas (PON). Una red ´optica pasiva (PON) [15] es un sistema de red con cableado de fibra ´optica que env´ıa la se˜nal de todo, o casi todo, el recorrido hasta el usuario final. El sistema se describe de diferente forma seg´un d´onde termine la red PON, as´ı pues, tendr´ıamos: fibra hasta la acera (FTTC), fibra hasta el edificio (FTTB) o fibra al hogar (FTTH). Los componentes principales de PON son los siguientes: OLT, ONT/ONU. 3.1.1. Componentes de una Red PON Una PON (Red ´ Optica Pasiva) es un terminal de l´ınea ´optica (OLT) [15], situada en la centralita de la empresa de comunicaciones proveedora, y en varias unidades de red ´optica (ONU), ubicadas cerca de los usuarios finales. Actualmente hay dos 23 Figura 3.1: Esquema Redes PON. Obtenido de [15] est´andares principales de PON: Red ´optica pasiva con capacidad de Gigabit (GPON) y Red ´optica pasiva preparada para Ethernet (GEPON). Las red PON que est´a integrada en Espa˜na son las GPON. La Figura 3.1 muestra el sistema de red PON Un sistema de red ´optica pasiva Gigabit (GPON) generalmente se compone de un terminal de l´ınea ´optica (OLT) en la centralita del proveedor del servicio y varias unidades de red ´optica (ONU) o terminales de red ´optica cerca de los usuarios finales. Se utiliza la red de distribuci´on ´optica (ODN) durante la transmisi´on entre OLT y ONU/ONT. La ODN es el medio de transmisi´on ´optica para la conexi´on f´ısica de las ONU a las OLT. En la figura 3.1 la ODN hace referencia al tramo de la conexi´on entre la OLT y las distintas ONU. 3.1.2. Terminal de l´ınea ´optico (OLT) OLT es un equipo que integra la funci´on de switch L2/L3 en el sistema GEPON [15]. En general, el equipo OLT contiene un bastidor, un m´odulo de control de conmutaci´on, un ELM (m´odulo de enlace EPON, tarjeta PON), un sistema de protecci´on de redundancia, m´odulos de fuente de alimentaci´on y ventiladores. En estas partes, la tarjeta PON y la fuente de alimentaci´on admiten el intercambio en caliente. La funci´on principal del OLT es controlar desde una centralita la informaci´on transmitida en ambas direcciones a trav´es de la ODN . La distancia m´axima admitida de transmisi´on a trav´es de la ODN es de 20 km. La OLT controla los dos sentidos de la transmisi´on de informaci´on: ascendente (obteniendo una clase diferente de distribuci´on del tr´afico de informaci´on y voz de los usuarios) y descendente (obteniendo tr´afico de datos, voz y v´ıdeo desde una red metro o una red de larga distancia y enviando todos los m´odulos ONT en el ODN). 24 Es importante aclarar que las diferencias entre las OLT dependen de los fabricantes y aunque el funcionamiento es igual desde el punto de vista del usuario, desde la perspectiva de un desarrollador surge un problema: cada OLT funciona internamente con un protocolo propietario diferente. Es decir, con cada hardware que adquiramos deberemos estar en contacto con dicho proveedor para saber de sus correspondientes especificaciones y manejo de su OLT. Esto genera una problem´atica desde el abordaje que mencion´abamos previamente. Apuntan las redes definidas por software, cuya ventaja reside en controladores centrales independientes al hardware que usemos. Es decir, tenemos una OLT que habla un lenguaje espec´ıfico (protocolo propietario) y una red SDN que habla otro lenguaje distinto (OpenFlow). Surge pues una necesidad de abstraer la capa propietaria. Para esta SDN usaremos varias OLT. Partiendo de una integraci´on de una OLT GPON de Cel´estica, la siguiente integraci´on ser´a con una OLT de Tibit XGSPON (XGSPON;10 Gigabit symetric PON). Por ´ultimo, se realizar´a una integraci´on con una OLT XGSPON de Edgecore. La integraci´on con esta ´ultima OLT resulta diferente en cuanto a las otras dos, lo cual se mostrar´a m´as adelante. Tanto GPON como XGSPON son est´andares en la transmisi´on de datos de las redes PON. La principal diferencia entre GPON y XGSPON es la tasa de transferencia de datos, teniendo GPON una tasa de transferencia de subida de 1.2G y de 2.5G en bajada y XGSPON una tasa de 10G sim´etrica. Las Figuras 3.2 y 3.3 representan las OTLs que se van a integrar. Figura 3.2: OLT de Tibit. Obtenido de [22] Figura 3.3: OLT de Edgecore. Obtenido de [19] 3.1.3. Unidad de Red ´ Optica (ONU) y Terminal de red ´ Optico (ONT) La ONU convierte las se˜nales ´opticas transmitidas a trav´es de la fibra en se˜nales el´ectricas para su posterior distribuci´on a los suscriptores individuales. En general, 25 esclavo. Un ´unico OLT, empleando diversas instancias del protocolo sobre canales de control independientes, puede controlar m´ultiples ONTs. Los requerimientos de la OMCI dados en la recomendaci´on G.984.4 de la ITU-T son necesarios para manejar la ONT en las siguientes ´areas: Gesti´on de la configuraci´on Gesti´on de fallos Gesti´on del rendimiento Gesti´on de la seguridad Funcionamiento de OpenOMCI OMCI es el protocolo que hablan las diferentes ONT en GPON, por lo que el adaptador OpenOMCI manda una secuencia de mensajes de activaci´on a la ONT. El mecanismo de activaci´on consta de 7 estados [2]: O1-Initial state O2-Standby state O3-Serial-Number state O4-Ranging state O5-Operation state O6-POPUP state O7-Emergency Stop state Definici´on de los estados: O1-Initial state: la ONU se enciende. Se afirma LOS / LOF. Una vez que se recibe el tr´afico en sentido descendente, se borran LOS y LOF y entonces la ONU pasa al estado de espera (O2). O2-Standby state: la ONU recibe el tr´afico descendente. La ONU espera los par´ametros de la red global. Una vez que se recibe el mensaje OverstreamOverhead, la ONU configura estos par´ametros (por ejemplo, el valor del delimitador, el modo de nivel de potencia y el retraso preasignado). Seguidamente pasa al estado del n´umero de serie (O3). O3-Serial-Number state: al responder a las solicitudes de n´umero de serie enviadas por la OLT, la ONU se da a conocer a la OLT y permite que la OLT descubra el n´umero de serie de la ONU. Una vez que la ONU ha respondido a una solicitud de n´umero de serie, espera la asignaci´on de ID de ONU ´unica de la OLT. La ONU-ID se asigna utilizando el mensaje Assign-ONU-ID. Una vez asignada, la ONU pasa al estado de rango (O4). 32 La OLT puede, a su discreci´on, usar el mensaje Extended-Burst-Length para comunicar los par´ametros de la sobrecarga extendida a todas las ONU en la PON. Si la ONU en estado de n´umero de serie (O3) recibe el mensaje ExtendedBurst-Length antes de recibir cualquier solicitud de n´umero de serie, configura las longitudes de pre´ambulo de tipo 3 de acuerdo con los valores recibidos. O4-Ranging state: la transmisi´on en sentido ascendente desde las diferentes ONU debe sincronizarse con los l´ımites de trama GTC en sentido ascendente. Para hacer que las ONU parezcan estar a la misma distancia de la OLT, se requiere un retardo de ecualizaci´on por ONU. Este retardo de ecualizaci´on se mide cuando la ONU est´a en el estado de rango. Una vez que la ONU recibe el mensaje Ranging-Time, pasa al estado de operaci´on (O5). O5-Operation state: una vez en este estado, la ONU puede enviar datos en sentido ascendente y mensajes PLOAM como lo indica la OLT. Se pueden establecer conexiones adicionales con la ONU, seg´un sea necesario, mientras se encuentre en este estado. Una vez que la red tiene rango, y todas las ONU funcionan con su retardo de ecualizaci´on correcto, todas las r´afagas en sentido ascendente se sincronizar´an entre todas las ONU. Las transmisiones ascendentes llegar´an por separado, cada una en su ubicaci´on correcta dentro de la trama GTC ascendente. O6-POPUP state: a ONU ingresa a este estado desde el estado de Operaci´on (O5) luego de la detecci´on de las alarmas LOS o LOF. Al ingresar al estado POPUP (O6), la ONU detiene inmediatamente la transmisi´on en sentido ascendente. Como resultado, la OLT detectar´a una alarma LOS para esa ONU. En el estado POPUP, la ONU primero intenta volver a adquirir la se˜nal ´optica y restaurar la sincronizaci´on de trama GTC, eliminando as´ı las condiciones LOS y LOF. Una vez que tiene ´exito, la ONU comienza a procesar el campo PCBd de las tramas GTC en sentido descendente y reinicia la m´aquina de estado de sincronizaci´on de supertrama. Se tiene que tener en cuenta que en el caso de la protecci´on de Tipo B, la se˜nal puede provenir de la OLT de respaldo o de la OLT primaria. Mientras se encuentra en el estado POPUP, la ONU genera un evento de recepci´on de mensaje PLOAM solo en respuesta a los mensajes Disable-ONUID, Deactivate-Serial-Number y POPUP. Si la ONU recibe un mensaje POPUP dirigido, pasa al estado de operaci´on (O5). Si la ONU recibe un mensaje POPUP de difusi´on, pasa al estado de rango (O4). Una vez que la ONU est´a en el estado de Operaci´on (O5), la OLT puede probar la ONU antes de devolverla al servicio completo. En particular, es posible que se haya programado un evento de cambio de clave de cifrado en el estado POPUP (O6). Para garantizar una recuperaci´on correcta en tal situaci´on, la OLT debe reiniciar el intercambio de claves y el procedimiento de cambio con la ONU. Si la ONU no puede volver a adquirir la se˜nal ´optica o restaurar la sincronizaci´on de trama GTC, no recibir´a el mensaje POPUP (emitido o dirigido) y pasar´a al estado inicial (O1), luego del tiempo de espera (TO2). 33 O7-Emergency Stop state: una ONU que recibe un mensaje Disable-SerialNumber con la opci´on ’deshabilitar’ pasa al estado de parada de emergencia (O7) y apaga su l´aser. Durante la parada de emergencia, la ONU tiene prohibido enviar datos en sentido ascendente. Si la ONU no se mueve al estado de parada de emergencia, es decir, despu´es de que el mensaje Disable-Serial-Number se haya enviado tres veces, la OLT contin´ua recibiendo las transmisiones de la ONU en las asignaciones de ancho de banda ascendente proporcionadas. Una alarma DFi se afirma en la OLT. Cuando el funcionamiento defectuoso de la ONU desactivada es fijo, la OLT puede activar la ONU para que vuelva a funcionar correctamente. Dicha activaci´on se logra enviando un mensaje Disable-Serial-Number con la opci´on ’habilitar’ a la ONU. Como resultado, la ONU vuelve al estado de espera (O2). Todos los par´ametros (incluidos el n´umero de serie y la ONU-ID) se reexaminan. En la Figura 3.9 podemos ver de una manera gr´afica los diferentes estados y la transici´on entre ellos. 34 Figura 3.9: Estados OMCI. Obtenido en [1] 3.3. ONOS En esta parte vamos a hablar sobre los servicios software que forman parte de la red, en este casode ONOS, el controlador elegido para esta red de acceso. Previamente hemos hablado de VOLTHA y la posibilidad que ofrece de comunicarnos con m´ultiples OLT y ONT. El uso de VOLTHA es necesario. Tenemos varias OLT que usan diferentes protocolos. El mismo problema ocurre en el caso de los switches. En esta red disponemos de 6 switches que se comunican a trav´es de Openflow, por lo que necesitamos un controlador que tambi´en tenga la posibilidad de usarlo. Es aqu´ı donde entra ONOS, el encargado de tomar el control de los switches a trav´es del protocolo Openflow. ONOS no es el ´unico controlador disponible, sin embargo es uno de los m´as usados actualmente. Otro de los controladores que podemos encontrar en esta l´ınea es ODL (OpenDaylight) 35 3.3.1. Funcionamiento de ONOS El n´ucleo de ONOS est´a dise˜nado con una arquitectura modular. Debido a que los proveedores de servicio requieren la capacidad de escalar sus redes, ONOS puede hacerlo para adaptarse a un sistema de dispositivos distribuidos f´ısicamente. Esto permite agregar nuevos conmutadores o componentes sin interferir con el resto del sistema. Mientras que el n´ucleo de ONOS se distribuye para proporcionar accesibilidad a cada dispositivo de la red, el controlador de ONOS permanece l´ogicamente centralizado y las diferentes instancias separadas de la arquitectura se pueden ver y acceder como en un solo sistema, a trav´es de la interfaz gr´afica de usuario (GUI; graphic user interface) que proporciona ONOS. ONOS sirve distintas APIs en las capas Norte y Sur. Para comunicarse con la capa Norte, ONOS utiliza su subsistema Intent Framework, el cual permite que las aplicaciones especifiquen los recursos necesarios al sistema. Por ejemplo, si una aplicaci´on necesita m´as ancho de banda. Cuando una aplicaci´on solicita esos recursos el sistema se configura en consecuencia. Cada instancia de ONOS interact´ua con el entorno de red y los dispositivos a trav´es de una API en direcci´on Sur que se comunica con componentes de nivel inferior. El n´ucleo descubre qu´e protocolos se pueden usar para interactuar con el dispositivo, y la API hacia el Sur usa ese protocolo para interactuar con el dispositivo. ONOS dispone de una gran cantidad de apps con las que gestionar y crear los diferentes flows. No obstante, las que se van a utilizar son la CLOSAPP y la OLTAPP (de las que hablaremos m´as adelante en este cap´ıtulo). Es importante decir que ONOS funciona en cluster. En versiones anteriores de ONOS, la capacidad de crear y a˜nadir nodos al cluster era responsabilidad del propio ONOS, pero en versiones m´as recientes (onos 1.14 en adelante) esa responsabilidad se ha escindido del propio ONOS y los desarrolladores han creado otro software de cluster llamado ATOMIX. Este es el encargado de formar y gestionar los nodos que conforman el cluster. Por defecto, cuando arrancamos ONOS este se inicia como un cluster de un solo nodo sin necesidad de tener corriendo ATOMIX en nuestras m´aquinas. 3.3.2. Niveles e funcionalidad de ONOS y Servicios Primarios En este punto se describen algunos de los subsistemas que forman parte de ONOS. En la figura 3.10 podemos ver los niveles de funcionalidad divididos en capas. [13]. Dispositivos: gestiona el inventario de todos los switches de la infraestructura. Enlaces: administra el inventario de enlaces de la infraestructura. Un enlace es una conexi´on directa entre dos puntos. Host: dirige el inventario de los nodos de computaci´on (host) y su ubicaci´on en la red. Topolog´ıa: servicio que administra Snapshots de la topolog´ıa de la red. 36 Figura 3.10: Niveles de Funcionalidad de ONOS. Obtenido en [13] Servicio de rutas: calcula y encuentra rutas entre los dispositivos de la infraestructura de red usando el Snapshot de la topolog´ıa m´as reciente. Flows: servicio que gestiona las reglas de flujo instaladas en los dispositivos y proporciona m´etricas de flujo. Paquetes: permite que las aplicaciones escuchen los paquetes de datos recibidos de los dispositivos de la red y emiten paquetes de datos a la red por medio de uno o m´as dispositivos de la misma. En la Figura 3.11 se pueden ver algunos de los subsistemas actuales dentro de ONOS. (HOST, TUNNEL, FLOWS, LINKS, etc.) Figura 3.11: Subsistemas actuales de ONOS. Obtenido en [13] 3.3.3. ONOS vs ODL Muchos son los controladores SDN existentes, pero principalmente los dos m´as conocidos hoy d´ıa son OpenDaylight y ONOS, proyectos de c´odigo de abierto y tienen 37 apoyos de muchas empresas. En el caso de ODL, tiene apoyo de empresas como IBM, Cisco, RedHat, Microsoft, etc. Por su parte, ONOS se encuentra en Samsung, Google, Edge-Core e Intel entre otras. ODL OpenDaylight [14] es un controlador SDN de c´odigo abierto que tiene 6 a˜nos de historia y 8 releases (aproximadamente una release cada 6 meses. Figura 3.12 se aprecia el esquema de ODL. Figura 3.12: Esquema de ODL El desarrollo y evoluci´on se hace en base a 4 casos de uso principales: Nube y NFV Delivery Autom´atico de Servicios Optimizaci´on de Recursos de Red Visibilidad y Control Dentro del desarrollo de ODL, parte de los proyectos son “gestionados” (managed) y se incluyen en las releases oficiales. Otros son “no gestionados” que no se siguen de manera continua. Una posible analog´ıa ser´ıa el kernel de Linux, cuya gesti´on ser´ıa similar a la de los proyectos gestionados, mientras que el resto de los elementos de las distribuciones de Linux entrar´ıan dentro de la categor´ıa de “no gestionados”. La mayor parte del uso de OpenDaylight no es del propio controlador, tal y como se distribuye de forma abierta, sino de soluciones basadas en [20] (programa “Powered by OpenDaylight”). Esto conlleva una fragmentaci´on de su uso y desarrollo. 38 Puntos en com´un Tanto ONOS como ODL est´an escritos en Java, dise˜nados para uso modular con una infraestructura personalizable y ambos cuentan con los mismos socios casi en su mayor´ıa. Ambos proyectos son parte de la Linux Foundation y disponen de interfaces Southbound con un n´umero elevado de protocolos, desde OpenFlow, pasando por P4 e incluyendo Netconf. Diferencias Licencia: ONOS tiene una licencia de Apache 2.0, mientras que ODL usa la licencia p´ublica de Eclipse. ONOS est´a m´as orientado a las necesidades del proveedor de servicios / proveedor de nube. Estructura: ONOS consiste en una serie compleja de subsistemas, as´ı como funciones escalables para sistemas de telecomunicaciones. ODL, por el contrario, utiliza una plataforma de mvc y opera desde una capa de abstracci´on central. Clientes objetivo: ODL y ONOS tienen estrategias comerciales h´ıbridas, pero hay diferencias en cuanto a qu´e compa˜n´ıa est´a apelando a qu´e proveedores. Mientras The Whole Stack conectaba ONOS a las telecomunicaciones, ODL estaba m´as centrado en los centros de datos. Enfoque: ODL se centra en unir el legado (BGP, SNMP, etc.) y NGN (redes de pr´oxima generaci´on OpenFlow y SDN). ONOS se enfcoca m´as en los aspectos de rendimiento y en la agrupaci´on en cl´usteres para aumentar la disponibilidad y la escalabilidad, por lo que, resulta de m´as inter´es para los operadores. Como resultado, ONOS se centra m´as en las redes de nivel de operador y las empresas de telecomunicaciones abogan m´as por sus proyectos. Por otro lado, numerosos proveedores de equipamiento como Cisco, Juniper y NES, est´an construyendo soluciones basadas en ODL, situaci´on que no se da en el caso de ONOS. Abstracci´on en direcci´on norte (Intent): ONOS presenta 2 capas de interfaz en direcci´on Norte: Intent Framework y Vista de red global. Intent Framework protege la complejidad de las operaciones de servicio, permitiendo que las aplicaciones soliciten servicios de red extra´ıdos de los detalles espec´ıficos de las operaciones de servicio. Casos de uso: ONOS tiene como principal caso de uso CORD (Central Office Re-architected as a Datacentre) desde su inicio, con el objetivo de convertir las centrales en n´ucleos de procesamiento de datos multiacceso; OpenDaylight ha empezado a soportar recientemente vCO (virtual Central Office), cuyo principal objetivo es virtualizar el acceso fijo. Governanza: el principal ´organo de gobierno de ODL (TSC) est´a principalmente compuesto por fabricantes de equipamiento (Ericsson, Lumina Networks) y de software (Red Hat), no habiendo ning´un operador en el mismo. En el caso de 39 ONOS, los miembros del Board [8] son proveedores de servicios y operadores de telecomunicaciones en la mayor parte de los casos. Los desarrolladores de aplicaciones pueden hacer su trabajo y solo necesitan elevar sus intenciones operativas. ODL se orienta en la misma direcci´on con el proyecto Network Intent Composition, el cual permitir´a a los desarrolladores describir f´acilmente sus propios prop´ositos. ODL espera crear una plataforma de intento uniforme para integrar muchas interfaces de Northbound con intenci´on de usuario. En este aspecto, ODL no se enceuntra tan avanzada como ONOS. En ´ultima instancia, hoy d´ıa, ONOS cuenta con la mejor ascendencia y ser´a la mejor opci´on para las empresas que deseen actualizar radicalmente su modo de acceso a la red (con limitaciones en las experiencias del mundo real). 3.3.4. Aplicaciones ONOS Como hemos visto ONOS dispone de una serie de aplicaciones con las que hacer uso de todos los servicios que propone. Para nuestra red disponemos de dos aplicaciones propias de Telef´onica para hacer uso de los servicios que propone ONOS: CLOSAPP y OLTAPP. Cada una de ellas se encuentra destinada a la instalaci´on de los flows en cada uno de los switches que permitiran la conmutaci´on de paquetes y el tr´afico dentro de nuestra red. CLOSFWD Esta aplicaci´on ser´a la encargada de comunicar a ONOS cu´ales son los flows requeridos para instalar y en qu´e dispositivos. Esto se consigue a trav´es de una estructura de datos denominada Endpoint. Un Endpoint es una estructura de datos (JSON) en la que definimos unos atributos dependiendo del tipo de Endpoint que necesitemos crear. Con los atributos definidos en el Endpoint, podremos decirle a onos que instale un flow con las caracter´ısticas proporcionadas (mac-origen, mac-destino, device, etc). Una vez tengamos los flows instalados, los switches conmutar´an el tr´afico de una forma u otra, dependiendo del tr´afico y paquetes entrantes. El funcionamiento de la aplicaci´on es sencillo. A trav´es de la API de la aplicaci´on mandamos el Endpoint que queremos crear. Tenemos muchos tipos de Endpoint, sin embargo para este caso solo se emplear´an: volt-endpoint, olt-cliente, olt-control y vpdchost. Algunas de las funcionalidades de las que disponemos son las siguientes: Creaci´on de Ednpoints Eliminaci´on de Endpoints Consulta de los flows instalados Consulta del registro de Endpoint Ejemplo de Endpoint: 40 1POST /onos/closfwd−app/closfwdapp/register 2Host: <ip nodo onos>:8181 3Accept: application /json 4Content−Type: application/json 5Cache−Control: no−cache 6 7[{ 8”@type”: ”volt”, 9”device”: ”of:0000000000000003”, 10 ”port”: ”45”, 11 ”vlan”: ”7”, 12 ”mac”:”02:42:ac:44:01:02” 13 }] En el cap´ıtulo de integraci´on se explicar´a para qu´e se usa cada Endpoint. Una vez que se realiza la petici´on, en primer lugar se procesa comprobando los posibles errores (error en el formato, variables incorrectas, etc); despu´es, la solicitud ir´a al Manager, y dependiendo del tpo de Endpoint que tengamos, se le pasar´a al controlador de ese Endpoint. Finalmente ese controlador le dir´a al driver de ONOS que instales el Flow. Cuando realicemos la integraci´on podremos ver un diagrama de secuencia en la creaci´on de los Endpoints. OltAPP Esta aplicaci´on es la que usaremos para registrar las OLT que a˜nadamos a nuestra CLOS, de la misma forma que con la aplicaci´onde de la CLOS haremos una petici´on a la API en la que mandaremos la estructura de datos. Este caso no precisa de gran dificultad puesto que la OLT solo tiene dos funcionalidades. Registrar la OLT en la clos Registrar un Usaurio para la OLT registrada Para el registro de la OLT le pasaremos el identificados de la OLT y el uplink (puerto l´ogico por el cual la OLT se conecta a L1). Endpoint registro olt: 1POST /onos/ctpd−olt−app/oltapp/register 2Host: <ip nodo onos>:8181 3Accept: application /json 4Content−Type: application/json 5Cache−Control: no−cache 6 7[{ 8”device”: ”of:0000000cd5000540”, 9”uplink”: ”129” 10 }] 41 48 Cap´ıtulo 4 Integraci´on de los componentes de la red Este cap´ıtulo esta dedicado a la integraci´on y comunicaci´on de cada uno de los componentes que conforman la red. Describiremos el procedimiento de activaci´on y los mecanismos de los que disponemos para verificar su correcta comunicaci´on. 4.1. Activaci´on de los componentes ONOS y VOLTHA Antes de comenzar con la conexi´on de las diferentes OLTs, necesitamos tener arrancado el software ONOS y VOLTHA. Actualmente ambos est´an funcionando como servicios en m´aquinas virtuales. 4.1.1. Activaci´on de ONOS Para arrancar ONOS como un servicio necesitamos realizar previamente estos pasos: En primer lugar, copiamos el script de arranque de ONOS dentro de /etc/init.d 1cp /opt/onos/init/onos. initd /etc/ init .d/onos En el caso de que tengamos ONOS en un Ubuntu 16.04, se requerir´an los siguientes pasos adicionales: A˜nadimos el fichero onos.service a /etc/systemd/system para tratar a ONOS como un servicio m´as. 1cp /opt/onos/init/onos. service /etc/systemd/system/ 2systemctl daemon−reload 3systemctl enable onos Una vez realizado esto solo necesitamos arrancar ONOS. 1sudo service onos start Tenemos varias formas de interactuar con ONOS: a trav´es de la consola de comandos o el GUI que nos proporciona accesibilidad via web. Para acceder a la consola de comandos se hace a trav´es de ssh al puerto 8181, con el usuario y contrase˜na por defecto karaf. 49 1ssh karaf@<ip maquina>−p 8101 2 Al entrar nos encontrar´ıamos con la salida que muestra la Figura 4.1: Figura 4.1: Consola de comandos ONOS En un primer momento necesitamos activar la aplicaci´on que implementa el protocolo Openflow, ya que si no es as´ı, no podremos ver ning´un switch en ONOS. Los haremos con el siguiente comando: 1app activate org. onosproject .openflow Una vez arrancada la aplicaci´on deber´ıamos ser capaces de ver todos los switches que tenemos conectados (L1, L2, L3, L4, S1 y S2) usando el comando ”devices”. Figura 4.2 salida del comando devices. 50 Figura 4.2: Switches conectados a ONOS Los identificadores que se observan en la imagen corresponden a cada uno de los switches. ONOS es capaz de descubrir a todos sus switches a trav´es de una red de gesti´on. Igualmente, podemos hacer la misma comprobaci´on desde el GUI de ONOS accediendo a trav´es de este enlace: 1http://<IP ONOS>:8181/onos/ui El usuario y contrase˜na por defecto es onos/rocks. Desde el GUI podemos interactuar con ONOS de una forma m´as intuitiva viendo los diferentes dispositivos, links y aplicaciones funcionando en ese momento en ONOS. Al ver que tenemos lo switches 51 Figura 4.3: Topolog´ıa de switches visto desde el GUI conectados y funcionando podemos decir que ONOS se ha iniciado de forma correcta. La figura 4.3 representa la topolog´ıa clos vista desde el GUI. 4.1.2. Activaci´on de VOLTHA VOLTHA funciona como un sistema distribuido formado por una serie de contenedores docker que se comunican entre s´ı, aunque no todos son imprescindibles. Algunos se encargan de generar alarmas o crear gr´aficas de estad´ısticas; sin embargo otros, como el propio contenedor de VOLTHA o el contenedor que implenta el agente openflow (ofagent), son estrictamente necesarios. Para este supuesto no hemos eliminado el uso de ninguno de los contenedores. En primer lugar, antes de arrancar VOLTHA deberemos a˜nadir al archivo de configuraci´on docker-compose-system-test.yml la IP de las m´aquinas donde tengamos arrancados nuestros ONOS. En este compose de docker se muestra la configuraci´on de cada uno de los contenedores. En la configuraci´on del contenedor de ofagent deberemos a˜nadir la IP que tiene asignada ONOS. 1˜/cord/incubator/VOLTHA/compose/docker−compose−system−test.yml 52 Figura 4.4: docker-compose-system-test.yml Figura 4.4 muestra la captura archivo de configuraci´on docker-compose-systemtest.yml. Una vez a˜nadida la IP a ese archivo debemos asegurarnos de que todos los adaptadores que vayamos a usar est´en en el directorio: 1˜/cord/incubator/VOLTHA/VOLTHA/adapters El c´odigo de los adaptadores podemos obtenerlo de varias formas: en el repositorio de VOLTHA en GitHub tenemos acceso a los adaptadores disponibles. Despu´es de estos pasos solo ser´a necesario arrancar VOLTHA con el siguiente comando: 1DOCKERS UP=$(docker−compose −f compose/docker−compose−system−test.yml ps | 2grep ’ Up ’ |wc −l) Si todo se ha iniciado de forma correcta deber´ıamos ver levantados 15 contenedores docker. La Figura 4.5 es la salida al comando docker-ps que nos muestra todos los 53 contenedores arrancados. Cada uno de los contenedores desempe˜na una funci´on. Compose-VOLTHA-1: Este es el contenedor principal de VOLTHA, todos los adaptadores espec´ıficos del dispositivo son parte de este contenedor Compone-nginx-1: NGINX (servidor web/proxy) Compose-envoy-1: servicio REST de VOLTHA Compose-ofagent-1: Agente Openflow Compose-netconf-1: Agente Netconf (Netconf; protocolo de configuraci´on de red) Compose-consul-1: Servicio de descubrimiento de contenedores Compose-registrator-1: Servicio de directorio de configuraci´on de registro Compose-kafka-1: Servicio mensajes bus Compose-grafana-1: Servicio de visualizaci´on de m´etricas Compose-flientd-1: Servicio para la recolecci´on de datos Compose-zookeeper-1: Servicio para la coordinaci´on de procesos distribuidos Compose-vcli-1: Servicio de CLI (consola de comandos) Compose-dashd-1: Servicio de gesti´on de dashboards para grafana Compose-shovel-1: Servicio de puente para m´etricas en kafka a graphite Compose-portainer-1: Servicio GUI Ahora que hemos levantado ONOS y VOLTHA es el momento de integrar las OLTs objeto de estudio. 54 Figura 4.5: Contenedores docker levantados 4.2. Integraci´on OLT GPON Cel´estica Previamente, comenzaremos con la integraci´on de la OLT GPON de Cel´estica. Usaremos el adaptador espec´ıfico microsemi. Comprobaremos que todos los componentes interactuan entre s´ı y realizaremos una prueba de tr´afico para el tramo ´optico (Tr´afico entre un cliente y un Host) 4.2.1. Pre-provisionar OLT Primero, necesitamos pre-provionar la OLT. Es decir, necesitamos que la OLT y VOLTHA se comuniquen para que VOLTHA pase a tomar el control de la OLT. La Figura 4.6 se muestra el trayecto ente la comunicaci´on entre la OLT y VOLTHA. 55 Figura 4.6: Comunicaci´on VOLTHA-OLT En la siguiente figura se describe el recorrido de las comunicaciones entre ambos actores. Necesitamos que VOLTHA tome control de la OLT y que el tr´afico entre la OLT y VOLTHA sea a trav´es de la CLOS. Tanto ONOS como los switches de la CLOS est´an conectados a una red de gesti´on. ONOS y los siwtches se ven a trav´es de esta red gesti´on, pero el tr´afico a los servicios en los diferentes Host es el que recorre la CLOS. Esto es importante ya que como hemos explicado, precisamos de un flow que indique el tipo de tr´afico entrante (en este caso OLT-VOLTHA) y que permitir´a que la red se encargue de gestionarlo. Esto supone que el primer paso implica crear los Endpoints para permitir el tr´afico dentro de la red entre la OLT y VOLTHA. Para ello usaremos la aplicaci´on ya mencionada de CLOSAPP. Creaci´on de Endpoints Se necesitan crear dos Endpoint para permitir el tr´afico dentro de la CLOS: un Endpoint del tipo volt y un Endpoint del tipo olt-control. Aunque en estas pruebas todos los Endpoints se instauran a mano, en un escenario final se cuenta con un entorno software que crea autom´aticamente todos los Endpoints necesarios. 1POST /onos/closfwd−app/closfwdapp/register HTTP/1.1 2Host: <ip nodo onos>:8181 3Accept: application /json 4Content−Type: application/json 5Cache−Control: no−cache 6 7[{ 8”@type”: ”volt”, 56 9”device”: ”of:0000000000000003”, 10 ”port”: ”45”, 11 ”vlan”: ”7”, 12 ”mac”:”02:42:ac:44:01:02” 13 }] 14 En el siguiente diagrama podemos ver cu´al es el proceso de creaci´on para este Endpoint. Figura 4.7, diagrama de creaci´on Endpoint volt. Figura 4.7: Diagrama secuencia creaci´on Endpoint volt Al crear este Endpoint se nos devuleve la siguiente respuesta. 1{ 2{ 3”@type”: ”volt”, 4”device”: ”of:0000000000000003”, 5”mac”: ”02:42:AC:44:01:02”, 6”port”: ”45”, 7”ip”: ”::/0”, 8”vlan”: ”7”, 9”id”: ”7b450b09−a0f2−3cf5−b0ff−7e5faf8ee6ee”, 10 ”reference”: 0, 11 ”externalAccessFlag”: false , 12 ” clientAccessFlag ”: false 13 } 14 } 57 4.2.4. Creaci´on de Endpoint Cliente y prueba de Tr´afico El ´ultimo paso es crear los Endpoints OLT y vpdchost. Este paso es necesario antes de empezar a meter tr´afico. El primer Endpoint . O LT”se instala en L1 para identificar el tr´afico que llega de la OLT. 1POST /onos/closfwd−app/closfwdapp/register HTTP/1.1 2Host: <ip nodo onos>:8181 3Accept: application /json 4Content−Type: application/json 5Cache−Control: no−cache 6 7[{ 8”@type”: ”olt”, 9”device”: ”of:0000000000000001”, 10 ”port”: ”37”, 11 ”vlan”: ”2” 12 }] La vlan es por la que ir´a el tr´afico del cliente, la vlan de esa OLT. Al crearlo nos devolver´a un id para este Endpoint. 1{ 2”776c7d00−0f1a−373d−84e5−3cba5d72c588”: { 3”@type”: ”olt”, 4”device”: ”of:0000000000000001”, 5”port”: ”37”, 6”vlan”: ”2”, 7”id”: ”776c7d00−0f1a−373d−84e5−3cba5d72c588”, 8”reference”: 0, 9”externalAccessFlag”: false , 10 ” clientAccessFlag ”: false , 11 ”mac”: ”00:00:00:00:00:00” 12 } 13 } El ID que recibimos es necesario proprorcion´arselo al siguiente Endpoint que crearemos: el ”vpdchost”. 1POST /onos/closfwd−app/closfwdapp/register HTTP/1.1 2Host: <ip nodo onos>:8181 3Accept: application /json 4Content−Type: application/json 5Cache−Control: no−cache 6 7[{ 8”@type”: ”vpdchost”, 9”device”: ”of:0000000000000003”, 10 ”port”: ”45”, 11 ”vlan”: ”2”, 12 ” ip client list ”: [<lista rango ips cliente >], 13 ” ip service list ”:[<ips de servicio >], 14 ” external access clients ”: ”true”, 64 15 ” olt id ”: ”876d2ec4−9d97−3e88−8fca−d806f976de68” 16 }] En este endpoint a˜nadimos la IP de los clientes y tambi´en el ID generado por el anterior Endpoint, ya que el Endpoint de vpdchost es dependiente del Endpoint de OLT. El Endpoint de vpdhost es un conjunto de vpdcs. Cada vpdchost est´a asociado a una OLT y cada vpdc pertenece a un cliente de esa misma OLT. Un vpdc es un router”para cada cliente. Haremos una prueba de conectividad para el tramo ´optico, mandando el tr´afico por un cliente (raspberry) a trav´es de la HGU y comprobaremos si tenemos conectividad con una m´aquina virtual dentro de un host conectada a L2. El recorrido que realizar´a el tr´afico es sencillo. El tr´afico entra a la red con un doble etiquetado (S-TAG y C-TAG). En este caso, como la vlan de la OTL es la 2 la S-TAG es 2 y la C-TAG es la VLAN del cliente, en este caso la 1 (la vlan se asigna por orden de llegada). Figura 4.18: Tr´afico entre Cliente-VM La Figura 4.18 muestra la comunicaci´on entre el cliente y el host. Entra a L1 con el doble etiquetado (1,2). El paquete sube a S1 y posteriormente baja a L2. El paquete al tener la vlan exterior 2 entrar´a por la interfaz de red del host ens1.2 que le quitar´a la primera VLAN. Posteriormente pasa a un OVS (switch virtual) que le quita la segunda etiqueta (la 1). 65 El paquete baja hasta la interfaz de la VM. La respuesta del paquete sale de la VM sin etiquetar. Pasa al OVS donde se le pone la etiqueta 1. Sube a la interfaz de red del host ens1.2 donde se le pondr´a la segunda etiqueta. El paquete sube por L2 a S1 y luego vuelve a bajar a L1. El paquete baja por la OLT donde se le quita la vlan 2. El paquete baja a la HGU donde se le quita la vlan 1. Finalmente recibiremos la respuesta en el cliente. Para comprobar que esta secuencia se ha completado correctamente, se ha realizado un ping desde una raspberry conectada a la ONT (cliente) hasta una m´aquina virtual ubicada en el host. 4.3. Integraci´on OLT XGSPON Tibit Como segundo caso, vamos a integrar la OLT XGSPON de Tibit. Para esta OTL usaremos el adaptador espec´ıfico de Tibit. Al igual que en el caso anterior, comprobaremos que todos los componentes interact´uan entre s´ı y que podemos transmitir tr´afico a trav´es de la red. 66 Figura 4.19: Comunicaci´on VOLTHA-OLT 4.3.1. Pre-provisionar OLT El primer paso es la preprovisi´on de la OLT. La comunicaci´on entre la OLT y VOLTHA se produce a trav´es de la CLOS al igual que con la OLT de Cel´estica. Por lo tanto, antes de realizar la pre-provisi´on de la OLT es necesario crear los Endpoints. Creaci´on de Endpoints Comenzamos con la creaci´on de los Endpoints volt y OLT-control: 1POST /onos/closfwd−app/closfwdapp/register HTTP/1.1 2Host: <ip nodo onos>:8181 3Accept: application /json 4Content−Type: application/json 5Cache−Control: no−cache 6 7[{ 8”@type”: ”volt”, 9”device”: ”of:0000000000000003”, 10 ”port”: ”40”, 11 ”mac”: ”02:00:5e:b9:85:30”, 12 ”vlan”: ”7” 13 }] 1POST /onos/closfwd−app/closfwdapp/register HTTP/1.1 2Host: <ip nodo onos>:8181 3Accept: application /json 67 4Content−Type: application/json 5Cache−Control: no−cache 6 7[{ 8”@type”: ”olt−control”, 9”device”: ”of:0000000000000001”, 10 ”port”: ”47”, 11 ”vlan”: ”7”, 12 ”mac”: ”70:b3:d5:52:31:31”, 13 ” explicit vlan ”:”true”, 14 ” volt id ”:”ced340cf−2936−3a53−8f2b−008a6c3bb8e0” 15 }] Pre-provisi´on Seguidamente pre-provisionamos la OLT. Accederemos a la consola de VOLTHA y usaremos los siguientes comandos: 1preprovisin olt −−device−type=tibit olt −−mac−address=70:b3:d5:52:31:31 2enable La OLT que usamos es de Tibit, por lo que el adaptador tambi´en es espec´ıfico para Tibit. Si la conexi´on se ha realizado correctamente deberemos de ser capaces de ver la OLT de Tibit en la lista de los dispositivos. De la misma forma, el dispositivo tambien debe ser visible desde la consola de ONOS. 4.3.2. Conexi´on de la ONT El pr´oximo paso es la conexi´on de la ONT. Conectamos el cable de fibra que va desde la OLT hasta la ONT. Para esta integraci´on estamos usando una ONT de Alpha y el adaptador de la ONT que usaremos es el brcm-openomci-onu. Si todo ocurre de forma correcta deberemos ver la ONT en VOLTHA. 4.3.3. Registro de la OLT Ahora que tenemos conexi´on entre los diferentes componentes, el siguiente paso ser´a registrar la OLT en la CLOS. 1POST /onos/ctpd−olt−app/oltapp/register 2Host: <ip nodo onos>:8181 3Accept: application /json 4Content−Type: application/json 5Cache−Control: no−cache 6[{ 7device : of :000170 b3d5523131 , 8uplink : 2 9 10 }] 68 1{ 2”vlan”: 4 3} Por ´ultimo, registramos a los usuarios: 1POST /onos/ctpd−olt−app/oltapp/register 2Host: <ip nodo onos>:8181 3Accept: application /json 4Content−Type: application/json 5Cache−Control: no−cache 6[{ 7bandwidth : 4500 , 8vlan : 0 , 9port : 73 10 }] 4.3.4. Creaci´on de Endpoint Cliente y prueba de Tr´afico Finalmente, para la prueba de tr´afico en el tramo ´optico crearemos los Endpoints de olt y vpdchost: 1POST /onos/closfwd−app/closfwdapp/register HTTP/1.1 2Host: <ip nodo onos>:8181 3Accept: application /json 4Content−Type: application/json 5Cache−Control: no−cache 6[{ 7@type : olt , 8device : of :0000000000000001 , 9port : 47 , 10 vlan : 4 ” 11 }] El identificador que obtenemos es el que debemos a˜nadir a la creaci´on del Endpoint vpdchost: 1POST /onos/closfwd−app/closfwdapp/register HTTP/1.1 2Host: <ip nodo onos>:8181 3Accept: application /json 4Content−Type: application/json 5Cache−Control: no−cache 6 7[{ 8”@type”: ”vpdchost”, 9”device”: ”of:0000000000000003”, 10 ”port”: ”55”, 11 ”vlan”: ”4”, 12 ” ip client list ”: [<lista rango ips cliente >], 13 ” ip service list ”:[<ips servicios >], 14 ” external access clients ”: ”true”, 15 ” olt id ”: ”873923akjc4−9r17−4ee58−8zca−d806f912ja1234” 69 16 }] 17 18 El tratamiento y recorridos que se producen con el tr´afico en esta OLT es el mismo que con la OLT de Cel´estica. 4.4. Integraci´on OLT XGSPON Edgecore Como ´ultimo caso, procederemos con la integraci´on de la OLT de Edgecore haciendo uso de los adaptadores gen´ericos de OpenOLT y brcm-openomci-onu. Anteriormente hemos explicado c´omo funciona openOLT, y en este caso veremos las clases implicadas y secuencia de pasos. 4.4.1. Pre-provisionar OLT Al igual que en los ejemplos anteriores, lo primero es conectar la OLT con VOLTHA. O lo que es lo mismo: pre-provisionarla. Aunque este caso es un poco distinto, puesto que la comunicaci´on entre la OLT y VOLTHA no circula por la CLOS si no que se realiza de forma directa a trav´es de una red de gesti´on. La Figura 4.20 muestra el nuevo esquema de comunicaci´on en tre la OLT y VOLTHA. Figura 4.20: Comunicaci´on VOLTHA-OLT Edgecore Esto quiere decir que no necesitamos crear los Endpoints del tipo volt y olt-control para permitir que circule el tr´afico por la CLOS, ya que directamente el tr´afico entre OLT y VOLTHA no atraviesa la CLOS. Iremos a la consola de comando de VOLTHA y usaremos el siguiente comando: 1pre−provisin olt −t openolt −H 192.168.83.17:9191 2enable Si el proceso se ha completado con ´exito deberemos ver el dispositivo a˜nadido. De la misma manera, el dispositivo deber´ıa poder verse en ONOS: 70 Figura 4.22: OLT de Edgecore visible en ONOS Funcionamiento de OpenOLT En el cap´ıtulo anterior hemos explicado qu´e es OpenOLT y c´omo funciona. Ahora comprobaremos cu´ales son las clases implicadas en el proceso de pre-provisi´on. En la siguiente Figura aparecen todas las clases que forman el adaptador OpenOLT y en la Figura 4.24 tenemos el diagrama de secuencia para la pre-provisi´on. Las clases Figura 4.23: Conjunto de clases OpenOLT involucradas con openolt, openolt device y openolt resource manager. 71 Figura 4.24: Diagrama de secuencia pre-provisi´on OLT Edgecore Podemos ver que las clases implicadas son OpenOLT, OpenOLT-device y OpenOLTresource-manager. En primer lugar, se inicia el agente del adaptador. Este paso se inicia despu´es de introducir los comandos en VOLTHA de pre-provisi´on y enable. Es en este momento cuando comienza la comunicaci´on entre la OLT y VOLTHA. Se comprueba el tipo de dispositivo que tenemos. Los datos de la OLT (fabricante, tipo, etc) los proporciona la OLT. Se manada un mensaje a openOLT-device para a˜nadir ese dispositivo que ha detectado. Se a˜nade el dispositivo conectado a la lista de dispositivos. Se inicia la adopci´on del dispositivo y se le asigna a un hilo que comprueba el estado periodicamente. Una vez a˜nadido se le asigna a un hilo la tarea de comprobar el estado del dispositivo (conectado, desconectado, alcanzable, etc). Se manda un mensaje con un evento a OpenOLT-resource-manager para relizar la conexi´on con la OLT. Una vez disponemos de los datos de la OLT podemos comenzar con la conexi´on. 72 Se inicializa el dispositivo con unos valores determinados. Los valores como identificador, fabricante y estado se cargar cuando se incializa el dispositivo. En OpenOLT-device, despu´es de recibir los valores de la conexi´on, hace que se ponga el dispositivo como up. Una vez terminada de cargar los valores y la configuraci´on del dispositivo, este pasa a estar activo. Por ´ultimo, la clase OpenOLT manda un mensaje a OpenOLT-device para que instale los flows para la comunicaci´on en ese dispositivo. En caso de que tengamos estos flows previamente a˜nadidos, esta comprobaci´on se hace peri´odicamente. OpenOLT-device actualiza los flows. Al igual que el mensaje anterior este se realiza peri´odicamente si se encuentra con flows nuevos que instalar o actualizar. Todos estos pasos en la activaci´on de la OLT van ligados a las respuestas de la OLT. Sin embargo, no es posible comprobar qu´e clases se ejecutan dentro de la OLT, ya que no tenemos acceso al c´odigo del agente OpenOLT de la OLT. 4.4.2. Conexi´on de la OLT Despu´es de la conexi´on entre la OLT y VOLTHA, el siguiente paso es la conexi´on de la ONT a la OLT. Figura 4.25: Conexi´on de la ONT con VOLTHA Edgecore 73 17 ” driver ”: ”ofdpa3”, 18 ” chassisId ”: ”4”, 19 ”lastUpdate”: ”1558947526421”, 20 ”humanReadableLastUpdate”: ”connected 22h51m ago”, 21 ”annotations”: { 22 ”channelId”: ”192.168.83.14:57974”, 23 ”managementAddress”: ”192.168.83.14”, 24 ”protocol”: ”OF 13” 25 } 26 }, De esta consulta seleccionamos para almacenar available ylastUpdate (lastUpdate se obtiene en formato epoch. Hay que transformarlo a un formato apto para la lectura) Almacenando estos datos queremos analizar lo siguiente: El estado de los dispositivos. Si alg´un dispositivo se desconecta podremos generar alarmas para avisarnos. Cada cu´anto cambia el estado en los dispositivos. Ports: estad´ısticas sobre los puertos. 1GET /onos/v1/statistics/ports 2Host: <ip nodo onos>:8181 3Accept: application /json 4Content−Type: application/json 5Cache−Control: no−cache 6” statistics ”: [ 7{ 8”device”: ”of:0000000000000004”, 9”ports”: [ 10 { 11 ”port”: 1, 12 ”packetsReceived”: 1063473, 13 ”packetsSent”: 1522442, 14 ”bytesReceived”: 124629690, 15 ”bytesSent”: 842444432, 16 ”packetsRxDropped”: 169477, 17 ”packetsTxDropped”: 0, 18 ”packetsRxErrors”: 0, 19 ”packetsTxErrors”: −1, 20 ”durationSec”: 0 21 }, De esta consulta seleccionamos todos los datos menos el campo durationSec, con los que analizaremos: El estado de los puertos. Ante cambios bruscos en el tr´afico de datos podremos saber si alg´un componente ha fallado. 80 Cantidad de dato que pasan por los puertos y elaboraci´on de estad´ısticas con ellos. Links: conjunto de conexiones entre los diferentes dispositivos. 1GET /onos/v1/links 2Host: <ip nodo onos>:8181 3Accept: application /json 4Content−Type: application/json 5Cache−Control: no−cache 6” links ”: [ 7{ 8”src”: { 9”port”: ”5”, 10 ”device”: ”of:0000000000000f02” 11 }, 12 ”dst”: { 13 ”port”: ”5”, 14 ”device”: ”of:0000000000000002” 15 }, 16 ”type”: ”DIRECT”, 17 ”state”: ”ACTIVE” 18 }, Con este scanner realizamos dos consultas: una a los links y otra a las estad´ısticas de los puertos para conocer, no solo el estado de link, si no tambi´en el estado de los puertos que forman parte de ese link. Con los datos recogidos pretendemos analizar: El estado de los links. Si alg´un enlace se cae, generaremos alarmas que nos avisar´a. El estado de un puerto de un link. En el caso de que un link no est´e ca´ıdo, pero tampoco tengamos tr´afico, podremos ver el estado de los puertos que forman parte de ese link y analizar qu´e ocurre. No todos los puertos forman parte de un link, por eso es necesario una consulta previa para saber las estad´ısticas de todos los puertos. Con la consulta a los links podemos saber el estado concreto de los puertos que forman parte de esos links. 5.3. Almacenamiento de datos El almacenamiento de datos se realiza usando una de las herramientas de monitorizaci´on que nos proporciona el entorno Prometheus. 81 5.3.1. Prometheus Es un conjunto de herramientas de monitorizaci´on [9] y alertado de sistemas Open Source construido por SoundCloud. Es un proyecto que se mantiene independientemente de cualquier compa˜n´ıa. Las caracter´ısticas principales de Prometheus son las siguientes: Un modelo de datos multidimensional con datos de series de tiempo identificados por nombre de m´etrica y pares clave/valor. PromQl, como lenguaje de consulta. Nodos de servidor aut´onomos. M´ultiples modos de gr´aficos. Algunos los componentes que tiene Prometheus son su servidor principal el cual almacena los datos, bibliotecas para desarrollar c´odigo, exporters para diferentes servicios como HAProxy o Graphite, un administrador de alertas y varias herramientas de apoyo. En la siguiente figura se muestra un esquema de la arquitectura de Prometheus. Figura 5.1: Arquitectura Prometheus, obtenido de [9] 82 5.4. Visualizaci´on y An´alisis Prometheus viene incorporado con un servicio para la visualizaci´on de los datos almacenados, aunque se ha optado por una opci´on m´as especializada para la visualizaci´on de m´etricas: Grafana. Tambi´en usamos Grafana para el an´alisis de las m´etricas. 5.4.1. Grafana Grafana [6] es un sistema de an´alisis y visualizaci´on de m´etricas que funciona con m´ultiples or´ıgenes de datos, entre ellos Prometheus, aunque tambi´en nos encontrar´ıamos con Loki, MySQL, Graphite, etc. Grafana nos proporciona una serie de servicios, entre ellos el de Alertado, al igual que Prometheus. 5.5. Alertado Para generar alertas se est´a haciendo uso de dos herramientas: una de ellas es el servicio de alertado que proporciona Grafana, y el otro es una de las herramientas que incluye Prometheus, Alert-manager. Para este supuesto solo haremos uso del sistema de alertado que nos proporciona Grafana 5.6. Funcionamiento En la Figura 5.2 se aprecia un esquema de c´omo est´an conectados los componentes del sistema de monitorizaci´on. Por un lado tenemos los exporters (aplicaciones que Figura 5.2: Esquema conexi´on de componentes 83 recogen y transmiten datos), estando entre ellos la aplicaci´on que se ha desarrollado. Esos exporters se conectan al servidor de Prometheus, donde se almacenan los datos. Grafana se conecta al servidor de Prometheus para recoger esos datos y visualizarlos. Podemos acceder al servidor de Prometheus v´ıa web y comprobar desde d´onde est´a recibiendo datos. En la Figura 5.3 observamos los targets (exportadores de datos) que est´an mandando datos a Prometheus y en la Figura 5.4 observamos el target de nuestra app. 1http://<ip maquina prometheus>:8181/targets Figura 5.3: Target de la app Uno de los targets activos ser´a nuestra App. Figura 5.4: Targets de prometheus Accediendo via web a 1http://<ip app monitoring>:<puerto publicado>/metrics 84 2 Se pueden comprobar los datos que estamos exportando. La figura 5.5 muestra los datos que estamos recogiendo, sin aplicar ning´un tipo de filtrado. Figura 5.5: Targets de prometheus Estos son algunos de los datos que estamos recibiendo. En concreto, los bytes mandados por cada uno de los puertos. A partir de estos datos elaboraremos las m´etricas de visualizaci´on en Grafana. 5.6.1. Dashboards Grafana Los targets de Prometheus nos muestran los or´ıgenes desde donde estamos recogiendo los datos. Grafana nos permite seleccionar a Prometheus como fuente de datos para crear sistemas de visualizaci´on (gr´acficas, tablas, etc). Para este supuesto vamos crear una tabla donde veremos los links de ONOS y su estado. En primer lugar necesitamos acceder a Grafana v´ıa web: 1<ip maquina grafana>:8080/grafana La primera vez que entramos en Grafana, vemos la salida que muestra la siguiente Figura. En el panel elegiremos la opci´on Choose Visualization y se nos mostrar´an los 85 Figura 5.6: GUI Grafana sistemas de visualizaci´on que tiene ofrece Grafana. Para este supuesto elegiremos la tabla como medio de visualizaci´on. Figura 5.7: Opciones de sistemas de visualizaci´on Grafana El siguiente paso ser´a elegir el origen de datos y los datos que queremos representar. En la siguiente Figura se muestra la elecci´on de los datos que vamos a representar y el origen de datos. Con la siguiente sentencia elegimos la m´etrica onos link y dentro de esos datos seleccionamos que tengan el estado ACTIVE 1onos link ( state=”ACTIVE”) 86 Figura 5.8: Selecci´on de datos a representar Los datos que hemos elegido se muestran en la siguiente tabla. Podemos comprobar que lo est´a haciendo de forma correcta, lo que significa que el sistema de monitorizaci´on est´a funcionando de forma correcta. Recogemos los datos, los cuales se almacenan en Prometheus y posteriormente son visualizados en Grafana. 87 88 Cap´ıtulo 6 Conclusiones y trabajo futuro 6.1. Conclusiones El trabajo realizado en este proyecto se enmarca dentro de las actividades de la iniciativa OnLife Networks de Telef´onica, en el que se est´a desarrollando una arquitectura de Edge Computing basada en SDN. En este proyecto, y tal como se describe en el primer cap´ıtulo de este trabajo, se ha constatado que las redes actuales se encuentran en una situaci´on de menor desarrollo que los sistemas, las cuales han evolucionado hacia configuraciones m´as flexibles, din´amicas y escalables. De esta manera, hoy en d´ıa, las redes no est´an preparadas para abordar la complejidad que implica satisfacer los nuevos servicios y aplicaciones demandados por los usuarios y soportar el uso que estas hacen de la red. Adicionalmente, las nuevas tecnolog´ıas aumentan la complejidad, ya que se despliegan y conviven con tecnolog´ıas anteriores e incluso legadas. En este contexto, se ha verificado que SDN es la mejor opci´on para introducir la softwarizaci´on en las redes y poder dar respuesta a los nuevos servicios y aplicaciones, demandados por los usuarios. Por esta raz´on, en este trabajo se han analizado los diferentes protocolos de comunicaci´on de SDN, identificando OpenFlow como un est´andar de facto debido a la popularizaci´on de su uso. Tambi´en se han analizado los distintos controladores SDN existentes, centrando el trabajo en ODL y ONOS, puesto que son los m´as implantados en m´ultiples entornos, identificando sus caracter´ısticas, sus fortalezas y sus debilidades. En este an´alisis se ha concluido que ONOS tiene un gran potencial para los operadores de telecomunicaciones, ya que mediante el proyecto CORD, se est´a impulsando un nuevo modelo redes donde la central telef´onica se convierte en un centro de procesamiento de datos desde el que se pueden prestar nuevos servicios y aplicaciones. Por otro lado, una conclusi´on clave de este trabajo es que el software se convierte en un elemento clave para hacer una realidad este nuevo modelos de redes, en el que existe una clara separaci´on entre hardware y software y donde el hardware tiende a comoditizarse. Para desarrollar este software es necesaria una estrecha colaboraci´on con las empresas fabricantes de hardware, pues aunque el objetivo es el de independizar el hardware totalmente del software, es algo que todav´ıa queda lejos ya que todav´ıa 89