El objetivo del protocolo descrito es apoyar la incorporación flexible de infraestructuras de experimentación 5G en un ecosistema NFV multisitio, a través de una arquitectura de red superpuesta basada en VPN. Además, el protocolo define cómo validar la efectividad de la integración, incluida una implementación de servicio vertical en varios sitios con vehículos aéreos pequeños con capacidad NFV.
La virtualización de funciones de red (NFV) ha sido considerada como uno de los habilitadores clave para la5ª generación de redes móviles, o 5G. Este paradigma permite reducir la dependencia de hardware especializado para desplegar telecomunicaciones y servicios verticales. Para ello, se apoya en técnicas de virtualización para softwarize las funciones de red, simplificando su desarrollo y reduciendo el tiempo y los costes de despliegue. En este contexto, la Universidad Carlos III de Madrid, Telefónica e IMDEA Networks Institute han desarrollado un ecosistema NFV dentro de 5TONIC, un centro de innovación de red abierta centrado en las tecnologías 5G, que permite la creación de escenarios de experimentación complejos y cercanos a la realidad a través de un conjunto distribuido de infraestructuras NFV, que pueden ser puestos a disposición por los grupos de interés en diferentes ubicaciones geográficas. Este artículo presenta el protocolo que se ha definido para incorporar nuevos sitios NFV remotos en el ecosistema NFV multisitio basado en 5TONIC, describiendo los requisitos tanto para las infraestructuras existentes como para las recién incorporadas, su conectividad a través de una arquitectura de red superpuesta y los pasos necesarios para la inclusión de nuevos sitios. El protocolo se ejemplifica a través de la incorporación de un sitio externo al ecosistema 5TONIC NFV. Posteriormente, el protocolo detalla los pasos de verificación necesarios para validar una integración exitosa del sitio. Estos incluyen el despliegue de un servicio vertical de múltiples sitios utilizando una infraestructura NFV remota con pequeños vehículos aéreos no tripulados (SUAV). Esto sirve para mostrar el potencial del protocolo para permitir escenarios de experimentación distribuida.
La introducción de la quinta generación de redes móviles (5G) ha supuesto revolucionar la industria de las telecomunicaciones desde principios de la década, obligando a los operadores de telecomunicaciones a abordar las especificaciones mucho más exigentes de los nuevos servicios y aplicaciones de redes desarrollados bajo el paraguas 5G1,2 . Estas nuevas especificaciones incluyen, entre otras, aumentos de la velocidad de datos, mejoras en la latencia de transmisión inalámbrica y reducción de los costos operativos. Entre las tecnologías que constituyen las bases de las mejoras para esta nueva generación, Network Functions Virtualization3 (NFV) se ha convertido en uno de sus facilitadores clave. NFV proporciona la capacidad de softwarize funciones de red, tradicionalmente retransmitiendo en hardware especializado, mediante el uso de equipos físicos de propósito genérico en su lugar, como computadoras servidor en un centro de datos. Con este nuevo paradigma, los operadores de telecomunicaciones y las industrias verticales pueden implementar funciones y servicios de red como un conjunto de componentes de software, y ahorrar costos tanto en la implementación como en el mantenimiento del servicio, además de facilitar una elasticidad de infraestructura de red mucho mayor. Este enfoque alivia o elimina la necesidad de utilizar dispositivos dedicados (y generalmente más complejos y menos reutilizables) para la mayoría de las funciones específicas de red y verticales, y admite un grado mucho mayor y más denso de automatización operativa, lo que reduce los costos de implementación y mantenimiento.
Teniendo en cuenta todas las ventajas que un entorno NFV es capaz de proporcionar, es natural que un gran número de partes interesadas relevantes del sector de las telecomunicaciones hayan participado cada vez más en la prueba de nuevas ideas de servicios en entornos NFV. En este contexto, Telefónica e IMDEA Networks Institute han creado 5TONIC4,un laboratorio abierto de investigación e innovación centrado en las tecnologías 5G. Con sede en Madrid (España), este laboratorio cuenta con una amplia gama de tecnologías disponibles para investigadores y socios para impulsar el desarrollo y validación de servicios 5G. En particular, este laboratorio tiene una plataforma NFV experimental donde los desarrolladores pueden implementar y probar sus nuevas aplicaciones y servicios basados en NFV en un ecosistema NFV compatible con ETSI5. Por lo tanto, las conclusiones experimentales sobre las opciones de diseño y las propuestas tecnológicas se pueden derivar en un entorno realista y mucho más flexible que las redes de producción. Esta plataforma ha sido diseñada para soportar actividades de experimentación en múltiples sitios externos, que pueden estar interconectados de manera flexible a 5TONIC utilizando un protocolo bien definido.
La solución técnica adoptada para el ecosistema 5TONIC NFV considera la utilización de un único orquestador NFV, implementado utilizando el software Open Source MANO (OSM) alojado en ETSI6. Este es el elemento encargado de gestionar y coordinar el ciclo de vida de los Servicios de Red (NS). Estos servicios se pueden construir como una composición de Virtualized Network/Vertical Functions (VNF), que se puede implementar en cualquiera de los sitios integrados en la plataforma NFV. El diseño del ecosistema 5TONIC NFV se ha realizado en el contexto del proyecto H2020 5GINFIRE7,8,donde la plataforma se utilizó para apoyar la ejecución de más de 25 experimentos, seleccionados a través de un proceso competitivo de convocatoria abierta, a través de ocho infraestructuras experimentales verticales específicas ubicadas en Europa y una en Brasil, esta última conectada a través de un enlace transoceánico. Además, la plataforma se aprovechó para construir un banco de pruebas NFV distribuido a escala nacional, en España, apoyando las actividades de experimentación dentro del proyecto español 5GCity9,10. Más recientemente, se ha integrado un sitio brasileño adicional en la plataforma, para apoyar actividades de demostración conjuntas en el contexto de una cooperación de investigación e innovación establecida entre Brasil y Europa (es decir, el proyecto 5GRANGE11,12). Por último, pero no menos importante, la infraestructura se ha utilizado para apoyar experimentos de terceros en el ámbito del proyecto 5G-VINNI13,14. La distribución geográfica de la plataforma NFV se puede ver en la Figura 1.
Las organizaciones interesadas que alojan su propia infraestructura NFV pueden conectarse de manera flexible al ecosistema 5TONIC NFV, sujeto a la aprobación de la Junta Directiva de 5TONIC, convertirse en proveedores de bancos de pruebas dentro del ecosistema distribuido y participar en actividades conjuntas de experimentación y demostración. Para ello, deben contar con un VIM (Virtual Infrastructure Manager) compatible con la pila de software OSM. El orquestador 5TONIC NFV es capaz de interactuar con los VIMs en los sitios involucrados en una implementación de servicio determinada, coordinando la asignación y configuración de los recursos informáticos, de almacenamiento y de red necesarios para la creación de instancias e interconexión de los VNF que componen un servicio de red, y controlando su ciclo de vida, desde su incorporación hasta su desmantelamiento final.
Para gestionar el intercambio de control y el tráfico de datos dentro de todos los sitios interconectados, el ecosistema 5TONIC NFV hace uso de una arquitectura de red superpuesta basada en Redes Privadas Virtuales (VPN). Este enfoque proporciona acceso seguro basado en PKI a los sitios externos que están integrados en el ecosistema 5TONIC, lo que permite el intercambio de información de control NFV entre la pila de software OSM y los diferentes VIM distribuidos en los bancos de pruebas, así como el intercambio de información que se requiere para administrar y configurar todos los VNF. Además, esta red superpuesta admite la difusión del tráfico de datos entre VNF que se implementan en diferentes sitios.
En este contexto, este documento detalla el protocolo diseñado para incorporar un sitio externo a un ecosistema NFV. El protocolo asume que el ecosistema está gobernado por un único orquestador NFV, instalado en un sitio central, y los sitios externos cuentan con una solución VIM compatible con la pila de software de orchestrator. El protocolo propuesto permite incrementar la cartera de recursos del ecosistema experimental, con la incorporación flexible de sitios NFV e infraestructuras verticales específicas. Esto permite la creación de una plataforma MANO distribuida capaz de probar y validar nuevos servicios verticales y de red en múltiples sitios, bajo el control de un solo orquestador NFV. Con el fin de ilustrar el funcionamiento interno del protocolo, el proceso se ejemplificará agregando un sitio NFV externo al ecosistema actual de 5TONIC NFV, describiendo los componentes necesarios en el sitio externo y 5TONIC, así como todos los pasos a seguir durante el proceso de integración. La Figura 2 proporciona una visión general del objetivo de la integración, con el nuevo banco de pruebas basado en NFV conectado a la plataforma 5TONIC desde donde se pueden desplegar los servicios de red, mediante conexiones VPN entre el sitio central y el resto de las infraestructuras externas.
Además, para mostrar la efectividad del protocolo, se mostrará el despliegue de un servicio vertical simple, utilizando el ecosistema 5TONIC y un sitio externo con pequeños vehículos aéreos no tripulados (SUAV) con capacidad NFV. El diseño del servicio vertical se ha inspirado en un experimento presentado en Vidal et al.9,que se ha simplificado a efectos ilustrativos de este trabajo. La Figura 3 describe el servicio, que tiene como objetivo ayudar a las actividades agrícolas inteligentes en un área remota. El servicio considera un proveedor de servicios de agricultura inteligente que utiliza SUAV para recopilar y difundir los datos producidos por sensores meteorológicos dispersos en un campo de cultivo. Para simplificar, el experimento presentado en el documento considera un solo SUAV y un sensor, capaces de proporcionar mediciones de temperatura, humedad y presión. En el experimento, el sitio NFV externo hospeda un punto de acceso Wi-Fi que se implementa como VNF a través del SUAV. Este VNF ofrece conectividad de acceso a la red al sensor, reenviando los datos detectados hacia una función de puerta de enlace. Este último se despliega como un VNF en un equipo terrestre (una computadora mini-ITX). La difusión de datos del sensor a la función de puerta de enlace sigue un enfoque de publicación/suscripción basado en el protocolo de transporte de telemetría de Message Queue Server (MQTT)15. La función de puerta de enlace procesa y luego difunde los datos hacia un servidor de Internet de las cosas (IoT), que está disponible como VNF en el sitio central del ecosistema NFV, basado en la plataforma de código abierto Mainflux16. Finalmente, el escenario asume un área remota donde la conectividad a Internet es proporcionada por una red de acceso celular no 3GPP. Por lo tanto, el servicio incluye dos VNF adicionales: 1) un enrutador de acceso VNF, que implementa la pila de protocolos de plano de usuario de un equipo de usuario 3GPP conectado a una red de acceso que no es 3GPP17; y 2) una implementación de referencia de una red central 5G, que admita el envío de información entre el enrutador de acceso y los VNF del servidor IoT. Con este propósito, el núcleo 5G VNF proporciona una implementación simplificada del plano de usuario de una función de interfuncionamiento no 3GPP y una función de plano de usuario, según lo definido por 3GPP17.
Finalmente, la Figura 4 representa los procesos más relevantes involucrados durante el desarrollo del protocolo, destacando sus interconexiones lógicas y las entidades encargadas de su ejecución.
Uno de los aspectos más importantes del protocolo descrito anteriormente es su extraordinaria flexibilidad para incorporar nuevas infraestructuras computacionales a un ecosistema NFV, independientemente de su distribución en términos de ubicación geográfica (siempre y cuando el ancho de banda y la latencia de las comunicaciones de red con sitios remotos lo admitan). Esto es posible a través de una arquitectura de red superpuesta basada en VPN, que permite el establecimiento de un enlace virtual para conectar sitios remotos a las instalaciones centrales del ecosistema NFV. Este enfoque permite la provisión de un canal efectivo y seguro para soportar el NFV y las comunicaciones de datos entre los sitios de un ecosistema NFV, reduciendo la probabilidad de que partes externas accedan y/o modifiquen información confidencial sobre los procesos de orquestación de NFV y los datos de los servicios implementados. En este contexto, el protocolo también describe una metodología específica para compartir de forma segura las credenciales de VPN con los sitios externos que permitirán la integración de nuevas infraestructuras. El protocolo ha sido ejemplificado utilizando el ecosistema NFV puesto a disposición en 5TONIC por la Universidad Carlos III de Madrid, Telefónica e IMDEA Networks Institute, aunque es genérico para ser utilizado en otros entornos NFV que cumplan con los requisitos previos mencionados en el paso 1 de este protocolo.
Además, vale la pena enfatizar la utilización exclusiva de herramientas y software de código abierto para la implementación del protocolo. A pesar de las funcionalidades potencialmente beneficiosas que podrían ofrecer las diferentes soluciones propietarias (por ejemplo, Fortinet35), el uso de desarrollos de código abierto ha facilitado la integración de todos los elementos abarcados por el protocolo debido a sus características inherentes, como la rentabilidad, un amplio soporte de software proporcionado por la comunidad de código abierto y un alto nivel de fiabilidad. solo por nombrar algunos de ellos. Además, la utilización de tecnologías de código abierto también puede promover sinergias entre componentes de naturaleza similar. Por ejemplo, para monitorear el estado de la conexión VPN para los clientes que usan la plataforma, el servicio VPN implementado en todo el protocolo podría confiar en la herramienta de monitoreo open-vpn36 (una herramienta de monitoreo basada en Python capaz de interoperar con servidores OpenVPN).
Por otro lado, la especificación del protocolo considera la creación de instancias de servicios de red en diferentes sitios con fines de validación. En este sentido, es importante destacar que el despliegue de servicios en un sitio determinado está sujeto a la disponibilidad de recursos informáticos, de almacenamiento y de red en el sitio, así como de equipos especializados que podrían ser necesarios para realizar el despliegue (por ejemplo, SUAV habilitados para NFV). Esto no es una limitación del protocolo, y debe ser tenido en cuenta por las partes interesadas en reproducir el experimento descrito en este documento.
Además, cabe señalar que el tiempo necesario para llevar a cabo el despliegue de servicios de red depende en gran medida de varios factores, como la ruta de red entre el orquestador y los diferentes VIM, el rendimiento de las comunicaciones de datos entre el VIM y sus nodos computacionales administrados, y también en la naturaleza intrínseca de estos nodos computacionales (no solo por sus recursos informáticos disponibles, pero también las tecnologías incorporadas para llevar a cabo la virtualización de las funciones de red).
Por último, y dado el destacado rendimiento que esta plataforma y su servicio VPN tuvieron en los proyectos europeos y trabajos colaborativos donde se ha utilizado hasta ahora (por ejemplo, 5GINFIRE, 5GRANGE o 5GCity, mencionados en la introducción de este documento), se considerará como un elemento importante en proyectos europeos emergentes donde la Universidad Carlos III de Madrid, Participan Telefónica, e IMDEA Networks Institute, como el Laberinto Horizonte 2020, o proyectos nacionales, como TRUE-5G.
The authors have nothing to disclose.
Este trabajo ha contado con el apoyo parcial del proyecto europeo H2020 LABYRINTH (acuerdo de subvención H2020-MG-2019-TwoStages-861696), y del proyecto TRUE5G (PID2019-108713RB-C52PID2019-108713RB-C52 / AEI / 10.13039/501100011033) financiado por la Agencia Nacional de Investigación. Además, el trabajo de Borja Nogales, Iván Vidal y Diego R. López ha sido parcialmente apoyado por el proyecto europeo H2020 5G-VINNI (acuerdo de subvención número 815279). Por último, los autores agradecen a Alejandro Rodríguez García su apoyo durante la realización de este trabajo.
Bebop 2 | Parrot | UAV used in the experiment to transport the RPis and thus, provide mobility to the compute units of external site. | |
BME280 Sensor | Bosch | Sensor capable of providing readings of the environmental conditions regarding temperature, barometric pressure, and humidity. | |
Commercial Intel Core Mini-ITX Computer | Logic Suppy | Computer server which hosts the OpenStack controller node (being executed as a VM) of the experiment's extternal aite. In addition, another unit of this equipment (along with the RPis) conforms the computational resources of the NFV insfrastrucure included in that site. | |
Iptables | Netfilter – Open source tool | (Software) An open source command line utility for configuring Linux kernel firewall rulset. Source-code available online: https://www.netfilter.org/projects/iptables/ | |
Lithium Battery Pack Expansion Board. Model KY68C-UK | Kuman | Battery-power supply HAT (Hardware Attached on Top) for the UAV computation units composing the NFV infrastructure of the external site. | |
MacBook Pro | Apple | Commodity laptop utilized during the experiment to obtain and gather the results as described in the manuscript. | |
Mainflux | Mainflux Labs – Open source platform | (Software) Open source Internet of Things (IoT) platform used in the experiment for implementing the virtual network function called as IoT Server VNF. In addition, this platform includes an open-source software based on Grafana which allows the visualization and formatting of the metric data. Source code available online: https://www.mainflux.com/ | |
Open Source MANO (OSM) – Release FOUR | ETSI OSM – Open source community | (Software) Management and Orchestration (MANO) software stack of the NFV system configured in the experiment. Source-code available online: https://osm.etsi.org/docs/user-guide/ | |
OpenStack – Release Ocata | OpenStack – Open source community | (Software) Open source software used for setting up both the NFV infrastrucure of the central site and the NFV infrastructure of external site within the experiment. Source-code available online: https://docs.openstack.org/ocata/install-guide-ubuntu | |
OpenVPN – Version 2.3.10 | OpenVPN – Open source community | Open source software implementing the VPN service presented in the experiment for the creation of the overlay network that will enable the operations of the NFV ecosystem (providing connectivity among all the sites comprising the ecosystem). Source-code available online: https://openvpn.net/ | |
Openvpn-monitor | Python – Open source software | (Software) Open source program based on Python code that allows the visualization of the state of the VPN service, as well as the representation of the sites that are connected at every instant. For this purpose, the program check priodically the information provided by the VPN server implemented with OpenVPN. Source-code available online: https://github.com/furlongm/openvpn-monitor | |
Paho-mqtt 1.5.0 | Python – Open source library | (Software) Open source library developed in Python code that enables the trasmission of the data read by the sensor through the use of MQTT standard Source-code available online: https://pypi.org/project/paho-mqtt/ | |
Ping | Debian – Open source tool | (Software) An open source test tool, which verifies the connectivity between two devices connected through a communications network. In addition, this tool allows to assess the network performance since it calculates the Round Trip Time (i.e., the time taken to send and received a data packet from the network). Source-code available online: https://packages.debian.org/es/sid/iputils-ping | |
Power Edge R430 | Dell | High-profile computer server which provides the computational capacity within the central site presented in the experiment. | |
Power Edge R430 | Dell | High-profile computer server in charge of hosting the virtual private network (VPN) service. Note that the computing requirements for provisioning this service are high due to the resource consumption of the encryption operations present in the service. | |
Power Edge R630 | Dell | Equipment used for hosting the virtual machine (VM) on charge of executing the MANO stack. In addition, the OpenStack controller node of the central site is also executed as a VM in this device. Note that the use of this device is not strictly needed. The operations carried out by this device could be done by a lower performance equipment due to the non-high resource specifications of the before mentioned VMs. | |
Raspberry PI. Model 3b | Raspberry Pi Foundation | Selected model of Single Board Computer (SBC ) used for providing the computational capacity to the experiment's external site. In addition, this SBC model is used during the deployment of the included realistic service for interpreting and sending the data collected by a sensor. | |
RPi.bme280 0.2.3 | Python – Open source library | (Software) Open source library developed in Python code that allows to interface the sensor Bosch BME280, and interpret the readings offered by that sensor. Source-code available online: https://pypi.org/project/RPi.bme280/ |