L’objectif du protocole décrit est de prendre en charge l’intégration flexible des infrastructures d’expérimentation 5G dans un écosystème NFV multi-sites, grâce à une architecture réseau superposée basée sur VPN. De plus, le protocole définit comment valider l’efficacité de l’intégration, y compris un déploiement de service vertical multisite avec de petits véhicules aériens compatibles NFV.
La virtualisation des fonctions réseau (NFV) a été considérée comme l’un des principaux catalyseurs de la5e génération de réseaux mobiles, ou 5G. Ce paradigme permet de réduire la dépendance à l’égard de matériel spécialisé pour déployer les télécommunications et les services verticaux. À cette fin, il s’appuie sur des techniques de virtualisation pour faciliter les fonctions réseau, simplifier leur développement et réduire le temps et les coûts de déploiement. Dans ce contexte, l’Universidad Carlos III de Madrid, Telefónica et l’IMDEA Networks Institute ont développé un écosystème NFV au sein de 5TONIC, un centre d’innovation de réseau ouvert axé sur les technologies 5G, permettant la création de scénarios d’expérimentation complexes et proches de la réalité à travers un ensemble distribué d’infrastructures NFV, qui peuvent être mis à disposition par les parties prenantes à différents endroits géographiques. Cet article présente le protocole qui a été défini pour incorporer de nouveaux sites NFV distants dans l’écosystème NFV multi-sites basé sur 5TONIC, décrivant les exigences pour les infrastructures existantes et nouvellement incorporées, leur connectivité via une architecture réseau superposée et les étapes nécessaires à l’inclusion de nouveaux sites. Le protocole est illustré par l’incorporation d’un site externe à l’écosystème NFV 5TONIC. Ensuite, le protocole détaille les étapes de vérification requises pour valider une intégration réussie du site. Il s’agit notamment du déploiement d’un service vertical multisite utilisant une infrastructure NFV distante avec de petits véhicules aériens sans pilote (SUAV). Cela sert à mettre en valeur le potentiel du protocole pour permettre des scénarios d’expérimentation distribués.
L’introduction de la cinquième génération de réseaux mobiles (5G) a impliqué une révolution de l’industrie des télécommunications depuis le début de la décennie, obligeant les opérateurs de télécommunications à répondre aux spécifications beaucoup plus exigeantes des nouveaux services et applications de mise en réseau développés sous l’égide de la 5G1,2 . Ces nouvelles spécifications incluent, sans toutefois s’y limiter, l’augmentation du débit de données, l’amélioration de la latence de transmission sans fil et la réduction des coûts d’exploitation. Parmi les technologies qui constituent les fondements des améliorations de cette nouvelle génération, network functions virtualization3 (NFV) est devenu l’un de ses principaux catalyseurs. NFV fournit la capacité de softwarize les fonctions réseau, traditionnellement relayant sur du matériel spécialisé, en utilisant plutôt des équipements physiques à usage générique, tels que des ordinateurs serveurs dans un centre de données. Avec ce nouveau paradigme, les opérateurs de télécommunications et les industries verticales peuvent déployer des fonctions et des services réseau sous la forme d’un ensemble de composants logiciels, et économiser des coûts à la fois dans le déploiement et la maintenance des services, tout en facilitant une élasticité de l’infrastructure réseau beaucoup plus élevée. Cette approche atténue ou élimine la nécessité d’utiliser des périphériques dédiés (et généralement plus complexes et moins réutilisables) pour la plupart des fonctions spécifiques au réseau et à la verticale, et prend en charge un degré d’automatisation opérationnelle beaucoup plus élevé et plus dense, réduisant ainsi les coûts de déploiement et de maintenance.
Compte tenu de tous les avantages qu’un environnement NFV est en mesure de fournir, il est naturel qu’un grand nombre d’intervenants pertinents du secteur des télécommunications aient été de plus en plus impliqués dans la mise à l’essai de nouvelles idées de services sur les environnements NFV. Dans ce contexte, Telefónica et IMDEA Networks Institute ont créé 5TONIC4, un laboratoire ouvert de recherche et d’innovation axé sur les technologies 5G. Basé à Madrid (Espagne), ce laboratoire dispose d’un large éventail de technologies disponibles pour les chercheurs et les partenaires afin de stimuler le développement et la validation des services 5G. En particulier, ce laboratoire dispose d’une plate-forme NFV expérimentale où les développeurs sont en mesure de déployer et de tester leurs nouvelles applications et services basés sur NFV sur un écosystème NFV conforme à l’ETSI5. Ainsi, des conclusions expérimentales sur les choix de conception et les propositions technologiques peuvent être tirées dans un environnement réaliste beaucoup plus flexible que les réseaux de production. Cette plate-forme a été conçue pour prendre en charge les activités d’expérimentation sur plusieurs sites externes, qui peuvent être interconnectés de manière flexible à 5TONIC à l’aide d’un protocole bien défini.
La solution technique adoptée pour l’écosystème NFV 5TONIC prend en compte l’utilisation d’un seul orchestrateur NFV, implémenté à l’aide du logiciel Open Source MANO (OSM) hébergé par ETSI6. Il s’agit de l’élément chargé de gérer et de coordonner le cycle de vie des services réseau (NS). Ces services peuvent être construits comme une composition de réseau virtualisé / fonctions verticales (VNF), qui peut être déployée sur n’importe lequel des sites intégrés sur la plate-forme NFV. La conception de l’écosystème NFV 5TONIC a été réalisée dans le cadre du projet H2020 5GINFIRE7,8, où la plate-forme a été utilisée pour soutenir l’exécution de plus de 25 expériences, sélectionnées dans le cadre d’un processus concurrentiel d’appel ouvert, sur huit infrastructures expérimentales verticales spécifiques situées en Europe et une au Brésil, cette dernière reliée par un lien transocéanique. En outre, la plate-forme a été exploitée pour construire un banc d’essai NFV distribué à l’échelle nationale, en Espagne, soutenant les activités d’expérimentation dans le cadre du projet espagnol 5GCity9,10. Plus récemment, un site brésilien supplémentaire a été intégré à la plateforme, pour soutenir les activités de démonstration conjointes dans le cadre d’une coopération en matière de recherche et d’innovation établie entre le Brésil et l’Europe (c’est-à-dire le projet 5GRANGE11,12). Enfin, l’infrastructure a été utilisée pour soutenir des expériences tierces dans le cadre du projet 5G-VINNI13,14. La répartition géographique de la plate-forme NFV peut être vue à la figure 1.
Les organisations intéressées hébergeant leur propre infrastructure NFV peuvent se connecter de manière flexible à l’écosystème NFV 5TONIC, sous réserve de l’approbation du comité directeur 5TONIC, devenir des fournisseurs de bancs d’essai au sein de l’écosystème distribué et participer à des activités conjointes d’expérimentation et de démonstration. Pour ce faire, ils doivent disposer d’un VIM (Virtual Infrastructure Manager) conforme à la pile logicielle OSM. L’orchestrateur NFV 5TONIC est capable d’interagir avec les VIM sur les sites impliqués dans le déploiement d’un service donné, en coordonnant l’allocation et la configuration des ressources informatiques, de stockage et de réseau nécessaires à l’instanciation et à l’interconnexion des VNF qui composent un service réseau, et en contrôlant son cycle de vie, de son intégration à sa mise hors service finale.
Afin de gérer l’échange de contrôle et le trafic de données au sein de tous les sites interconnectés, l’écosystème NFV 5TONIC utilise une architecture réseau superposée basée sur des réseaux privés virtuels (VPN). Cette approche fournit un accès sécurisé basé sur PKI aux sites externes intégrés dans l’écosystème 5TONIC, permettant l’échange d’informations de contrôle NFV entre la pile logicielle OSM et les différents VIRTUAL répartis sur les bancs d’essai, ainsi que l’échange d’informations nécessaires à la gestion et à la configuration de tous les VNF. De plus, ce réseau de superposition prend en charge la diffusion du trafic de données entre les VNF déployés sur différents sites.
Dans ce contexte, le présent document détaille le protocole conçu pour intégrer un site externe à un écosystème NFV. Le protocole suppose que l’écosystème est régi par un seul orchestrateur NFV, installé sur un site central, et que les sites externes disposent d’une solution VIM compatible avec la pile logicielle orchestrator. Le protocole proposé permet d’incrémenter le portefeuille de ressources de l’écosystème expérimental, avec l’intégration flexible de sites NFV et d’infrastructures verticales spécifiques. Cela permet la création d’une plate-forme MANO distribuée capable de tester et de valider de nouveaux services réseau et verticaux sur plusieurs sites, sous le contrôle d’un seul orchestrateur NFV. Afin d’illustrer le fonctionnement interne du protocole, le processus sera illustré par l’ajout d’un site NFV externe à l’écosystème NFV 5TONIC actuel, décrivant les composants nécessaires sur le site externe et 5TONIC, ainsi que toutes les étapes à suivre pendant le processus d’intégration. La figure 2 donne un aperçu de l’objectif de l’intégration, avec le nouveau banc d’essai NFV connecté à la plate-forme 5TONIC à partir de laquelle les services réseau peuvent être déployés, au moyen de connexions VPN entre le site central et le reste des infrastructures externes.
En outre, pour démontrer l’efficacité du protocole, le déploiement d’un service vertical simple sera montré, en utilisant l’écosystème 5TONIC et un site externe avec de petits véhicules aériens sans pilote (SAV) compatibles NFV. La conception du service vertical a été inspirée par une expérience présentée dans Vidal et al.9, qui a été simplifiée à des fins d’illustration de cet article. La figure 3 décrit le service, qui vise à aider les activités agricoles intelligentes dans une région éloignée. Le service considère un fournisseur de services agricoles intelligents qui utilise des SAV pour collecter et diffuser les données produites par des capteurs météorologiques dispersés sur un champ de culture. Par souci de simplicité, l’expérience présentée dans l’article considère un seul SUAV et un capteur, capables de fournir des mesures de température, d’humidité et de pression. Dans l’expérience, le site NFV externe héberge un point d’accès Wi-Fi déployé en tant que VNF sur le SUAV. Ce VNF offre une connectivité d’accès réseau au capteur, transférant les données détectées vers une fonction de passerelle. Ce dernier est déployé en tant que VNF sur un équipement au sol (un ordinateur mini-ITX). La diffusion des données du capteur vers la fonction passerelle suit une approche Publish/Subscribe basée sur le protocole MQTT (Message Queuing Telemetry Transport)15. La fonction passerelle traite puis diffuse les données vers un serveur Internet des objets (IoT), qui est mis à disposition en tant que VNF sur le site central de l’écosystème NFV, sur la base de la plate-forme open source Mainflux16. Enfin, le scénario suppose une zone éloignée où la connectivité Internet est fournie par un réseau d’accès cellulaire non 3GPP. Par conséquent, le service comprend deux VNF supplémentaires: 1) un routeur d’accès VNF, qui implémente la pile de protocoles du plan utilisateur d’un équipement utilisateur 3GPP connecté à un réseau d’accès non 3GPP17; et 2) une mise en œuvre de base d’un réseau central 5G, prenant en charge la transmission d’informations entre le routeur d’accès et les VNF du serveur IoT. À cette fin, le VNF de base 5G fournit une implémentation simplifiée du plan utilisateur d’une fonction d’interfonctionnement non 3GPP et d’une fonction de plan utilisateur, telle que définie par 3GPP17.
Enfin, la figure 4 représente les processus les plus pertinents impliqués lors de l’élaboration du protocole, en mettant en évidence leurs interconnexions logiques et les entités chargées de leur exécution.
L’un des aspects les plus importants du protocole décrit précédemment est sa flexibilité exceptionnelle pour intégrer de nouvelles infrastructures de calcul à un écosystème NFV, quelle que soit leur distribution en termes de situation géographique (tant que la bande passante et la latence des communications réseau avec les sites distants le prennent en charge). Cela est possible grâce à une architecture réseau superposée basée sur VPN, qui permet l’établissement d’une liaison virtuelle pour connecter des sites distants aux locaux centraux de l’écosystème NFV. Cette approche permet de fournir un canal efficace et sécurisé pour prendre en charge la NFV et les communications de données entre les sites d’un écosystème NFV, réduisant ainsi la probabilité que des parties externes accèdent et/ou modifient des informations sensibles concernant les processus d’orchestration NFV et les données des services déployés. Dans ce contexte, le protocole décrit également une méthodologie spécifique pour partager en toute sécurité les informations d’identification VPN avec les sites externes qui permettra l’intégration de nouvelles infrastructures. Le protocole a été illustré à l’aide de l’écosystème NFV mis à disposition à 5TONIC par l’Universidad Carlos III de Madrid, Telefónica et IMDEA Networks Institute, bien qu’il soit générique pour être utilisé dans d’autres environnements NFV répondant aux exigences préalables mentionnées à l’étape 1 de ce protocole.
En outre, il convient de souligner l’utilisation exclusive d’outils et de logiciels open source pour la mise en œuvre du protocole. Malgré les fonctionnalités potentiellement bénéfiques qui pourraient être offertes par différentes solutions propriétaires (par exemple, Fortinet35), l’utilisation de développements open source a facilité l’intégration de tous les éléments englobés par le protocole en raison de leurs caractéristiques inhérentes telles que la rentabilité, un support logiciel étendu fourni par la communauté open source et un haut niveau de fiabilité, pour n’en nommer que quelques-uns. En outre, l’utilisation de technologies open source peut également favoriser des synergies entre des composants de nature similaire. Par exemple, afin de surveiller l’état de la connexion VPN pour les clients utilisant la plate-forme, le service VPN implémenté tout au long du protocole pourrait s’appuyer sur l’outil de surveillance open-vpn36 (un outil de surveillance basé sur Python capable d’interagir avec les serveurs OpenVPN).
D’autre part, la spécification de protocole prend en compte l’instanciation de services de mise en réseau sur différents sites à des fins de validation. À cet égard, il est important de souligner que le déploiement de services sur un site donné est subordonné à la disponibilité de ressources de calcul, de stockage et de réseau sur le site, ainsi que d’équipements spécialisés qui pourraient être nécessaires pour effectuer le déploiement (par exemple, des SAV compatibles NFV). Il ne s’agit pas d’une limitation du protocole et devrait être pris en compte par les parties prenantes intéressées à reproduire l’expérience décrite dans le présent document.
En outre, il convient de noter que le temps nécessaire pour effectuer le déploiement des services réseau dépend fortement de plusieurs facteurs tels que le chemin réseau entre l’orchestrateur et les différents VIM, les performances des communications de données entre le VIM et ses nœuds de calcul gérés, ainsi que la nature intrinsèque de ces nœuds de calcul (non seulement en raison de leurs ressources informatiques disponibles, mais aussi les technologies incorporées pour effectuer la virtualisation des fonctions réseau).
Enfin, et compte tenu des performances exceptionnelles que cette plate-forme et son service VPN ont eu sur les projets européens et les travaux collaboratifs où elle a été utilisée jusqu’à présent (par exemple, 5GINFIRE, 5GRANGE ou 5GCity, mentionnée dans l’introduction de ce document), elle sera considérée comme un élément important dans les projets européens émergents où l’Universidad Carlos III de Madrid, Telefónica et IMDEA Networks Institute y participent, comme le LABYRINTH Horizon 2020, ou des projets nationaux, comme TRUE-5G.
The authors have nothing to disclose.
Ce travail a été partiellement soutenu par le projet européen H2020 LABYRINTH (convention de subvention H2020-MG-2019-TwoStages-861696), et par le projet TRUE5G (PID2019-108713RB-C52PID2019-108713RB-C52 / AEI / 10.13039/501100011033) financé par l’Agence nationale espagnole de la recherche. En outre, le travail de Borja Nogales, Ivan Vidal et Diego R. Lopez a été partiellement soutenu par le projet européen H2020 5G-VINNI (accord de subvention numéro 815279). Enfin, les auteurs remercient Alejandro Rodríguez García pour son soutien lors de la réalisation de ce travail.
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/ |