Resumen de Monitoring and orchestration of network slices for 5g networks
Ramón Pérez Hernández
Uno de los retos científicos de mayor envergadura en el campo de las ICT es la definición de las futuras redes 5G. Estas redes tendrán que soportar requisitos muy extremos en términos de latencia, capacidad y número de dispositivos. Existe un amplio consenso en la comunidad científica y la industrial que la simple evolución de las arquitecturas de red actuales no será suficiente para poder soportar estos requisitos, y que es necesario un cambio de paradigma.
En este sentido, el concepto de Network Slicing ha estado siempre ligado a la evolución de las arquitecturas de red, proporcionando la capacidad de soportar múltiples redes lógicas sobre la misma infraestructura. Esta tecnología, unida a la cloudificación de la red, que implica la virtualización de las funciones de red y su localización en la ubicación más adecuada de acuerdo con los requisitos impuestos, son algunas de las herramientas más prometedoras para asegurar el cumplimiento de estos requisitos de la manera más flexible posible.
Si bien hasta la fecha se ha dedicado un esfuerzo significativo a la virtualización y softwarización de arquitecturas de red, con iniciativas tales como NFV y SDN, la aplicación de estas tecnologías a las redes 5G presenta dos retos fundamentales: (i) existen funciones que introducen ciertas restricciones a causa de las dependencias temporales que tienen los distintos módulos entre, lo cual dificulta su virtualización; y (ii) a la hora de decidir la localización de una función hay que tener en cuenta varios aspectos tales como la topología de la red, las características del servicio a proporcionar y las ventajas de centralizar ciertas funciones.
En este ámbito, este trabajo pretende abordar el estudio de arquitecturas cloudificadas para redes 5G basadas en Network Slices que aborden estos problemas. Bajo este diseño, múltiples usuarios pueden hacer uso de la misma plataforma, requiriendo el cumplimiento de ciertos requisitos en cuanto a métricas de rendimiento de red, entre otras.
Para este fin, de cara a poder explotar de forma adecuada la flexibilidad que proporciona una arquitectura cloudificada, el diseño de las arquitecturas y los algoritmos involucrados se han realizado siguiendo un enfoque holístico, tratando de no ser un caso particular para un cierto conjunto de tecnologías, sino siendo arquitecturas generales que puedan aplicarse en multitud de casos, independientemente de la tecnología subyacente. Además de los aspectos arquitecturales, una de las contribuciones fundamentales del trabajo es el modelado y optimización de la tecnología propuesta mediante la aplicación de métodos experimentales.
Para ello, el estudio se ha dividido en tres grandes ámbitos, perteneciendo todos al ecosistema creado por las redes 5G: (i) la monitorización efectiva de redes para recopilar métricas de red susceptivas de ser utilizadas para el aseguramiento de las Slices de red, (ii) la orquestación de redes basadas en el paradigma SDN, y (iii) la virtualización avanzada de componentes mediante el uso de la tecnología serverless.
En el primer caso, relativo a la monitorización de Network Slices, se ha diseñado una plataforma de monitorización distribuida y adaptable a múltiples entornos y usuarios, estableciendo un sistema jerárquico de captura y agregación de datos de monitorización para su posterior análisis, procesado y visualización.
Esta arquitectura define bloques genéricos que se pueden implementar posteriormente con diferentes tecnologías. Parte, en primer lugar, de un módulo de recolección de datos de los diferentes componentes desplegados en una red 5G, contando los terminales, antenas, VNFs, etc., que permite transformar los datos heterogéneos capturados en cada equipo en un formato homogéneo, siguiendo un modelo de datos concreto, que es consumido por la plataforma de distribución de datos de monitorización superior.
Al ser un sistema jerárquico de distribución de datos, esto permite abarcar múltiples entornos, pudiendo conectar fácilmente nuevas infraestructuras de red a monitorizar con tal de incluir los componentes de recolección de datos y de agregación y conectarlos al sistema jerárquico. Esto es útil de cara a pensar en escenarios más flexibles y en redes más allá de 5G, conocido como Beyond 5G. El nivel más alto de esta jerarquía ofrece los datos a las herramientas de procesamiento y visualización de datos antes comentadas.
Además, este diseño de plataforma es perfectamente compatible con otros módulos de valor añadido, como herramientas de inteligencia artificial y aprendizaje automático para la gestión de estos datos de monitorización y su aplicación para tomar decisiones inteligentes sobre ciertos sistemas 5G. Esta integración, en cuanto a aspectos de arquitectura, se ha abordado también en el presente trabajo, mostrando cómo la arquitectura de monitorización puede interactuar con una plataforma de inteligencia artificial que ofrezca las capacidades comentadas anteriormente.
Esta plataforma general se ha implementado siguiendo paradigmas y tecnologías ya presentes en diferentes recomendaciones de organismos de estandarización como el 3GPP. En concreto, se ha seguido el paradigma de publicación-suscripción, haciendo uso de Apache Kafka, para desplegar esta arquitectura distribuida. Gracias a este paradigma, los componentes de recolección de datos publicarían los datos de monitorización en Kafka, y las entidades interesadas en estos datos (herramientas de procesamiento y visualización de datos) se suscribirían a estos datos, siendo entregados automáticamente por Kafka. Para estas funcionalidades de valor añadido de procesamiento y visualización, se ha hecho uso de Elastic Stack.
Finalmente, esta plataforma, basada en Kafka y en Elastic Stack, ha sido validada para cargas de tráfico que pueden presentarse en escenarios reales de redes 5G y más allá. En concreto, haciendo uso de Sangrenel, una herramienta para pruebas de carga de Kafka, se han medido parámetros como la latencia, el porcentaje de paquetes recibidos y el consumo de CPU de las máquinas implicadas en el escenario.
Estas medidas se han realizado para diferentes escenarios de redes 5G posibles, diferenciando entre pruebas con una única métrica monitorizada, que sirvió para establecer ciertos parámetros de configuración de Sangrenel, y pruebas con múltiples métricas monitorizadas (las cuales, agrupadas, constituyen una cierta tasa de transferencia a procesar por la plataforma de monitorización), extrayendo conclusiones interesantes como que métricas del mismo tamaño no varían en cuanto a resultados de rendimiento, que la latencia o el porcentaje de paquetes recibidos no varían si modifico la tasa que recibe el sistema de monitorización o el número de métricas monitorizadas (manteniendo el otro parámetro constante), o que si ambos parámetros varían, el rendimiento de la plataforma empieza a empeorar cuando se llega a un cierto límite software definido por la tecnología Kafka, momento en el cual satura el sistema.
También, tratando de abordar el análisis de escenarios Beyond 5G, se ha evaluado el impacto de la reducción de la CPU asignada a las máquinas del escenario, comprobando que el rendimiento ofrecido puede ser compatible con la cantidad de tráfico esperable en este tipo de entornos, a la vez que se ha demostrado la escalabilidad del sistema en el caso de disponer de múltiples entornos monitorizados.
En el segundo caso, de la misma forma que en redes fijas las tecnologías de virtualización (NFV) se pueden combinar con las de softwarización (SDN) para conseguir un mayor nivel de flexibilidad, este trabajo propone una tecnología de automatización y orquestación de la red gracias al desacoplamiento de la red de control, permitiendo a una entidad centralizada conectar las distintas funciones de red para crear cadenas de funciones que formen un servicio. Para ello, se ha hecho uso del paradigma SD-WAN, haciendo uso de herramientas open-source para constituir un único producto con posibilidades de comercialización futura.
Como principales aportaciones al estado del arte, se ha mostrado el modelo de infraestructura de red aplicado por esta solución, definiendo diferentes entidades lógicas (sedes, switches, puertos de switches, redes, túneles, etc.) y la relación entre ellas para explicar cómo esta solución de orquestación modelaría una red gestionada.
Esto, a su vez, tiene un impacto en la arquitectura desarrollada para esta plataforma, que cuenta con un núcleo central de orquestación que implementa este modelo de red, alimentado por una serie de descriptores que permiten definir la red a gestionar, e interactuando con controladores de red SDN, basados en ONOS, que se encargarán de implementar las políticas correspondientes a la información proporcionada por los descriptores.
La forma de procesar la información por parte del orquestador se basa en un modelo intent-based; es decir, el sistema tratará de implementar todas las políticas necesarias para hacer cumplir las condiciones definidas en el orquestador, y controlará el ciclo de vida de estas políticas para reaccionar frente a posibles errores en la red, aplicando reconfiguraciones en caso necesario.
En el trabajo realizado, aparte de explicar todos los módulos que componen el módulo de orquestación y las aplicaciones desarrolladas para el controlador ONOS, se explica la gestión de estados seguida por el orquestador de red para asegurar la consecución del modelo intent-based propuesto. Este mecanismo se ha probado en un escenario basado en contenedores, para demostrar la escalabilidad de la plataforma cuando el número de sedes SDN crece linealmente. Así, con una prueba de carga desde 1 a 10 sedes SDN controladas por el orquestador de red, se pudo comprobar que la dependencia del número de sedes y el tiempo de despliegue de las configuraciones intent-based sigue un modelo lineal y no exponencial, por lo que el tiempo de despliegue está acotado y es previsible ante despliegues masivos.
Aparte de esto, también se han descrito con detalle dos casos de uso concretos de esta plataforma; (i) el primero, la interconexión con redes tradicionales que usan protocolos como OSPF, BGP, etc., para lo cual se ha integrado Quagga en los switches SDN frontera con dichas redes, integrando la configuración necesaria en las aplicaciones de ONOS y el orquestador para interpretar los mensajes manejados por Quagga y aplicar, consecuentemente, las configuraciones correspondientes. Y (ii) el segundo caso, es un escenario de balanceo de carga entre switches SDN conectados por múltiples enlaces, para lo cual se usan protocolos de monitorización como sFlow para controlar el tráfico manejado por puerto en cada segundo, para así cambiar las reglas de reenvío de paquetes para maximizar el uso de enlaces redundantes. Ambos escenarios se han probado también en un escenario de pruebas, demostrando las capacidades anteriores.
Finalmente, sobre el caso de nuevas técnicas de virtualización, se encuadran todas las investigaciones relativas a la integración del paradigma serverless en la plataforma de monitorización, a modo de ejemplo práctico para ver las implicaciones que suponen pasar a usar este paradigma.
Para ello, se ha realizado el rediseño completo de la plataforma de monitorización, basada originalmente en aplicaciones y bloques monolíticos, difícilmente distribuibles. Este rediseño se ha realizado en dos pasos: (i) en primera instancia, se desacoplaron ciertas funciones que podían ser implementadas en módulos separados; por ejemplo, los referentes a la creación, borrado, listado, etc. de topics de Kafka, y se llevaron a una arquitectura basada en microservicios, donde todos estos bloques de funciones elementales se comunican a través de interfaces REST. Posteriormente, (ii) este diseño basado en microservicios se tradujo en un diseño puramente serverless, utilizando una plataforma serverless (OpenFaaS) por debajo encargada de gestionar el ciclo de vida de estas funciones elementales, de manera que dichos bloques sólo se ejecutarían cuando se requieren, por tanto no consumirían recursos de cómputo, red, etc. en otros momentos.
Además de realizar este diseño y mostrar las interacciones entre componentes, que se complican en el segundo escenario basado en serverless porque se requiere que todas las peticiones pasen por la plataforma serverless para lanzar las funciones correspondientes, se ha demostrado su funcionamiento en un entorno de pruebas, comprobando que el flujo de trabajo definido es correcto. En cuanto a implicaciones de rendimiento, a pesar de que se complican las interacciones entre componentes, es evidente que se logra un mejor consumo en el segundo escenario, ya que las funciones serverless, cuando no se usan, no están instanciadas, por lo que no están consumiendo recursos, cosa que sí pasaba en el escenario tradicional y en el basado en microservicios.
Aparte de realizar esta transformación, también se ha procedido a tomar medidas del rendimiento de dicha plataforma utilizando diferentes técnicas de virtualización; como el uso directo de servidores físicos (no hay virtualización), máquinas virtuales, contenedores con/sin orquestación (haciendo uso de Docker para desplegar los contenedores y Kubernetes para la orquestación) o el uso de herramientas serverless (Kata Containers), combinadas con otras tecnologías analizadas en el estado del arte (como Firecracker). Esto ha servido para posicionar, desde el punto de vista del rendimiento, a las tecnologías serverless estudiadas, comparándolas con herramientas de virtualización más “tradicionales”.
De esta forma, se han evaluado las mismas métricas de rendimiento que se evaluaron para el análisis de rendimiento de la plataforma de monitorización, de cara a tener resultados comparables entre las diferentes plataformas. Una vez ejecutadas las pruebas con diferentes tasas recibidas para la plataforma de monitorización instanciada con diferentes técnicas de virtualización, se detectaron tres grupos de resultados claramente diferenciados. En primer lugar, (i) el uso de servidores físicos y el despliegue de contenedores sobre servidores físicos ofrecieron los mejores resultados en términos de latencia y porcentaje de paquetes recibidos, demostrando que los contenedores son tecnologías ya maduras y que pueden utilizarse perfectamente en entornos de producción.
En segundo lugar, (ii) se cuenta con la plataforma de monitorización basada en máquinas virtuales, que ofrecía un orden de magnitud mayor en términos de latencia (de milisegundos a décimas de milisegundos) y de porcentaje de paquetes recibidos (del 80% al 30% en el peor caso) que en el primer grupo comentado anteriormente. Esto es debido, probablemente, a que las máquinas virtuales no tienen acceso directo a los recursos del servidor sobre el que se despliegan, cosa que sí ocurre en el primer caso. Igualmente, son una tecnología también madura y que ofrece un rendimiento aceptable para las cargas probadas.
Y en tercera posición, (iii) aparecen las tecnologías serverless probadas, cuyo rendimiento es el peor de todos los probados, con un orden mayor de latencia que el caso de máquinas virtuales (centenas de milisegundos) y con un rendimiento que puede llegar al 10% de paquetes recibidos en el peor caso. Esto permite decir que estas tecnologías no están todavía lo suficientemente maduras como para ser usadas en entornos de producción de este tipo, si bien no se puede extrapolar más allá puesto que los parámetros utilizados en estas pruebas no implican que estas tecnologías funcionen en otros entornos. Además, el uso de estas tecnologías soluciona problemas existentes en las tecnologías de contenedores, como puede ser la gestión de la seguridad, por lo que, realmente, están añadiendo valor a esta tecnología, aparte de posibilitar despliegues más ligeros y con un consumo menor de recursos.
Estos tres casos de arquitecturas cloudificadas, en su conjunto, permiten a su vez el desarrollo de un sistema inteligente, utilizando mecanismos innovadores de virtualización de servidores, capaz de recabar métricas de rendimiento de la red para su aplicación posterior en mecanismos de orquestación de redes, con funciones que pueden ir desde mecanismos de encaminamiento de tráfico hasta la aplicación de políticas personalizadas de red, todas basadas en las métricas recolectadas. Dicho sistema es la continuación lógica de los trabajos realizados en esta tesis doctoral, la cual se limitará al análisis en detalle de cada uno de los tres aspectos mencionados anteriormente por separado.
