Integratie van 5G-experimenteerinfrastructuren in een multi-site NFV-ecosysteem

Summary

Het doel van het beschreven protocol is om de flexibele integratie van 5G-experimenteerinfrastructuren in een multi-site NFV-ecosysteem te ondersteunen, via een VPN-gebaseerde overlay-netwerkarchitectuur. Bovendien definieert het protocol hoe de effectiviteit van de integratie kan worden gevalideerd, inclusief een verticale service-implementatie op meerdere locaties met kleine luchtvaartuigen die geschikt zijn voor NFV.

Abstract

Network Function Virtualization (NFV) wordt beschouwd als een van de belangrijkste enablers voor de^5e generatie mobiele netwerken, of 5G. Dit paradigma maakt het mogelijk om de afhankelijkheid van gespecialiseerde hardware voor het inzetten van telecommunicatie en verticale diensten te verminderen. Voor dit doel vertrouwt het op virtualisatietechnieken om netwerkfuncties te softwariseren, hun ontwikkeling te vereenvoudigen en de implementatietijd en -kosten te verminderen. In deze context hebben Universidad Carlos III de Madrid, Telefónica en IMDEA Networks Institute een NFV-ecosysteem ontwikkeld binnen 5TONIC, een open netwerkinnovatiecentrum gericht op 5G-technologieën, waardoor complexe, dicht bij de realiteit experimentele scenario's kunnen worden gecreëerd over een gedistribueerde set NFV-infrastructuren, die beschikbaar kunnen worden gesteld door belanghebbenden op verschillende geografische locaties. Dit artikel presenteert het protocol dat is gedefinieerd om nieuwe externe NFV-sites op te nemen in het multi-site NFV-ecosysteem op basis van 5TONIC, en beschrijft de vereisten voor zowel de bestaande als de nieuw opgenomen infrastructuren, hun connectiviteit via een overlay-netwerkarchitectuur en de stappen die nodig zijn voor het opnemen van nieuwe sites. Het protocol wordt geïllustreerd door de integratie van een externe site in het 5TONIC NFV-ecosysteem. Daarna beschrijft het protocol de verificatiestappen die nodig zijn om een succesvolle site-integratie te valideren. Deze omvatten de inzet van een verticale service op meerdere locaties met behulp van een externe NFV-infrastructuur met kleine onbemande luchtvaartuigen (SUAVs). Dit dient om het potentieel van het protocol te laten zien om gedistribueerde experimenteerscenario's mogelijk te maken.

Introduction

De introductie van de vijfde generatie mobiele netwerken (5G) heeft sinds het begin van het decennium een revolutie teweeggebracht in de telecommunicatie-industrie, waardoor telecommunicatie-exploitanten moeten voldoen aan de veel veeleisendere specificaties van de nieuwe netwerkdiensten en -toepassingen die zijn ontwikkeld onder de paraplu van 5G^1,2 . Deze nieuwe specificaties omvatten, maar zijn niet beperkt tot, verhogingen van de gegevenssnelheid, verbeteringen van de latentie van draadloze transmissie en verlaging van de operationele kosten. Onder de technologieën die de basis vormen van de verbeteringen voor deze nieuwe generatie, is Network Functions Virtualization³ (NFV) een van de belangrijkste enablers geworden. NFV biedt de capaciteit om netwerkfuncties te softwariseren, traditioneel door te geven op gespecialiseerde hardware, door in plaats daarvan generieke fysieke apparatuur te gebruiken, zoals servercomputers in een datacenter. Met dit nieuwe paradigma kunnen telecommunicatie-exploitanten en verticale industrieën netwerkfuncties en -diensten inzetten als een set softwarecomponenten en kosten besparen bij zowel service-implementatie als onderhoud, evenals een veel hogere elasticiteit van de netwerkinfrastructuur faciliteren. Deze aanpak verlicht of elimineert de noodzaak om speciale (en meestal complexere en minder herbruikbare) apparaten te gebruiken voor de meeste netwerk- en verticaal-specifieke functies, en ondersteunt een veel hogere en dichtere mate van operationele automatisering, waardoor de implementatie- en onderhoudskosten worden verlaagd.

Rekening houdend met alle voordelen die een NFV-omgeving kan bieden, is het logisch dat een groot aantal relevante belanghebbenden uit de telecommunicatiesector in toenemende mate betrokken zijn bij het testen van nieuwe service-ideeën op NFV-omgevingen. In deze context hebben Telefónica en IMDEA Networks Institute 5TONIC⁴opgericht, een open onderzoeks- en innovatielaboratorium gericht op 5G-technologieën. Dit laboratorium is gevestigd in Madrid (Spanje) en heeft een breed scala aan technologieën beschikbaar voor onderzoekers en partners om de ontwikkeling en validatie van 5G-diensten te stimuleren. In het bijzonder heeft dit laboratorium een experimenteel NFV-platform waar ontwikkelaars hun nieuwe NFV-gebaseerde applicaties en services kunnen implementeren en testen op een ETSI-compatibel NFV-ecosysteem⁵. Zo kunnen experimentele conclusies over ontwerpkeuzes en technologievoorstellen worden afgeleid in een realistische, veel flexibelere omgeving dan productienetwerken. Dit platform is ontworpen om experimenteeractiviteiten op meerdere externe locaties te ondersteunen, die flexibel kunnen worden gekoppeld aan 5TONIC met behulp van een goed gedefinieerd protocol.

De technische oplossing die is aangenomen voor het 5TONIC NFV-ecosysteem houdt rekening met het gebruik van een enkele NFV-orchestrator, geïmplementeerd met behulp van de ETSI-gehoste Open Source MANO (OSM) -software⁶. Dit is het element dat verantwoordelijk is voor het beheer en de coördinatie van de levenscyclus van Network Services (NS). Deze services kunnen worden gebouwd als een samenstelling van gevirtualiseerde netwerk / verticale functies (VNF), die kunnen worden geïmplementeerd op elk van de locaties die zijn geïntegreerd op het NFV-platform. Het ontwerp van het 5TONIC NFV-ecosysteem is gedaan in de context van het H2020 5GINFIRE-project^7,8, waar het platform werd gebruikt om de uitvoering van meer dan 25 experimenten te ondersteunen, geselecteerd via een concurrerend open-call-proces, over acht verticaal-specifieke experimentele infrastructuren in Europa en één in Brazilië, de laatste verbonden via een transoceanische verbinding. Daarnaast werd het platform gebruikt om een gedistribueerd NFV-testbed op nationale schaal te bouwen, in Spanje, ter ondersteuning van experimenteeractiviteiten binnen het Spaanse 5GCity-project^9,10. Meer recentelijk is een extra Braziliaanse site in het platform geïntegreerd om gezamenlijke demonstratieactiviteiten te ondersteunen in het kader van een onderzoeks- en innovatiesamenwerking tussen Brazilië en Europa (d.w.z. het 5GRANGE-project^11,12). Last but not least is de infrastructuur gebruikt om experimenten van derden te ondersteunen in het kader van het 5G-VINNI-project^13,14. De geografische spreiding van het NFV-platform is te zien in figuur 1.

Geïnteresseerde organisaties die hun eigen NFV-infrastructuur hosten, kunnen flexibel verbinding maken met het 5TONIC NFV-ecosysteem, onder voorbehoud van goedkeuring door de 5TONIC Steering Board, testbedproviders worden binnen het gedistribueerde ecosysteem en betrokken zijn bij gezamenlijke experimenten en demonstratieactiviteiten. Daartoe moeten ze beschikken over een VIM (Virtual Infrastructure Manager) die voldoet aan de OSM-softwarestack. De 5TONIC NFV-orchestrator is in staat om te communiceren met de VIMs op de locaties die betrokken zijn bij een bepaalde service-implementatie, de toewijzing en installatie van de computer-, opslag- en netwerkbronnen te coördineren die nodig zijn voor de instantiatie en interconnectie van de VNF's die een netwerkservice samenstellen, en de levenscyclus ervan te beheersen, van de onboarding tot de definitieve ontmanteling.

Om de uitwisseling van controle en dataverkeer binnen alle onderling verbonden sites te beheren, maakt het 5TONIC NFV-ecosysteem gebruik van een overlay-netwerkarchitectuur op basis van Virtual Private Networks (VPN). Deze aanpak biedt veilige PKI-gebaseerde toegang tot de externe sites die zijn geïntegreerd in het 5TONIC-ecosysteem, waardoor de uitwisseling van NFV-besturingsinformatie tussen de OSM-softwarestack en de verschillende VIMs verspreid over de testbedden mogelijk is, evenals de uitwisseling van informatie die nodig is om alle VNF's te beheren en te configureren. Bovendien ondersteunt dit overlay-netwerk de verspreiding van dataverkeer onder VNF's die op verschillende locaties worden ingezet.

In deze context beschrijft dit artikel het protocol dat is ontworpen om een externe site op te nemen in een NFV-ecosysteem. Het protocol gaat ervan uit dat het ecosysteem wordt beheerd door een enkele NFV-orchestrator, geïnstalleerd op een centrale locatie, en externe sites beschikken over een VIM-oplossing die compatibel is met de orchestrator-softwarestack. Het voorgestelde protocol maakt het mogelijk om het portfolio van middelen van het experimentele ecosysteem te vergroten, met de flexibele integratie van NFV-locaties en verticaal-specifieke infrastructuren. Dit maakt het mogelijk om een gedistribueerd MANO-platform te creëren dat in staat is om nieuwe netwerk- en verticale services op meerdere locaties te testen en te valideren, onder de controle van een enkele NFV-orchestrator. Om de interne werking van het protocol te illustreren, zal het proces worden geïllustreerd door een externe NFV-site toe te voegen aan het huidige 5TONIC NFV-ecosysteem, waarbij de benodigde componenten op de externe site en 5TONIC worden beschreven, evenals alle stappen die tijdens het integratieproces moeten worden genomen. Figuur 2 geeft een overzicht van het doel van de integratie, waarbij het nieuwe NFV-gebaseerde testbed is gekoppeld aan het 5TONIC-platform van waaruit netwerkdiensten kunnen worden ingezet, door middel van VPN-verbindingen tussen de centrale site en de rest van de externe infrastructuren.

Om de effectiviteit van het protocol te demonstreren, zal bovendien de inzet van een eenvoudige verticale service worden getoond, met behulp van het 5TONIC-ecosysteem en een externe site met NFV-compatibele kleine onbemande luchtvaartuigen (SUAVs). Het ontwerp van de verticale dienst is geïnspireerd op een experiment gepresenteerd in Vidal et al.⁹, dat is vereenvoudigd voor de illustratieve doeleinden van dit artikel. Figuur 3 schetst de dienst, die gericht is op het ondersteunen van slimme landbouwactiviteiten op een afgelegen gebied. De dienst beschouwt een slimme landbouwdienstverlener die SUAVs gebruikt om de gegevens te verzamelen en te verspreiden die worden geproduceerd door meteorologische sensoren verspreid over een gewasveld. Voor de eenvoud beschouwt het experiment dat in het artikel wordt gepresenteerd een enkele SUAV en een sensor, die in staat zijn om temperatuur-, vochtigheids- en drukmetingen te leveren. In het experiment host de externe NFV-site een Wi-Fi-toegangspunt dat als VNF via de SUAV wordt geïmplementeerd. Deze VNF biedt netwerktoegangsconnectiviteit tot de sensor, waardoor de gedetecteerde gegevens worden doorgestuurd naar een gatewayfunctie. Deze laatste wordt ingezet als VNF op grondapparatuur (een mini-ITX-computer). De verspreiding van gegevens van de sensor naar de gatewayfunctie volgt een Publish/Subscribe-benadering op basis van het Message Queuing Telemetry Transport (MQTT)-protocol^15. De gatewayfunctie verwerkt en verspreidt de gegevens vervolgens naar een Internet-of-things (IoT) server, die als VNF beschikbaar wordt gesteld op de centrale locatie van het NFV ecosysteem, gebaseerd op het Mainflux¹⁶ open-source platform. Ten slotte gaat het scenario uit van een extern gebied waar de internetverbinding wordt geleverd door een mobiel niet-3GPP-toegangsnetwerk. Daarom bevat de service twee extra VNF's: 1) een toegangsrouter VNF, die de user-plane protocolstack implementeert van een 3GPP-gebruikersapparatuur die is aangesloten op een niet-3GPP-toegangsnetwerk¹⁷; en 2) een basisimplementatie van een 5G-kernnetwerk, ter ondersteuning van het doorsturen van informatie tussen de toegangsrouter en de VNF's van de IoT-server. Hiertoe biedt de 5G-kern VNF een vereenvoudigde implementatie van het gebruikersvlak van een niet-3GPP-interworkingfunctie en een gebruikersvlakfunctie, zoals gedefinieerd door 3GPP¹⁷.

Ten slotte geeft figuur 4 de meest relevante processen weer die betrokken zijn bij de ontwikkeling van het protocol, met de nadruk op hun logische interconnecties en de entiteiten die verantwoordelijk zijn voor de uitvoering ervan.

Protocol

1. Terbeschikkingstelling van de centrale locatie van het NFV-ecosysteem (voorafgaande vereisten van het experiment)

1. Wijs een IP-adresruimte toe die door de centrale site moet worden gebruikt. Voor de toepassing van dit protocol wordt de privéadresruimte 10.4.0.0/16 gebruikt.
2. Installeer de MANO-softwarestack (Management and Orchestration) op de centrale site. In het bijzonder maakt het experiment dat in dit protocol wordt uitgevoerd gebruik van de Open Source MANO (OSM) Release SEVEN¹⁸, waarvoor de volgende bronnen nodig zijn: Ubuntu 18.04 als besturingssysteem, 2 Central Processing Units (CPU's), 8 GB Ram (Random-Access Memory), 40 GB harde schijf-schijf en ten minste één netwerkinterface met internettoegang. Volg voor de installatie de instructies die beschikbaar zijn in de OSM Release SEVEN-documentatie¹⁸.
3. Stel een Virtual Infrastructure Manager (VIM) in die compatibel is met OSM op de centrale site. Specifiek gebruikt het experiment OpenStack-release Ocata²⁰, draaiend op een Virtuele Machine (VM) met Ubuntu 16.04 , 4 CPU's, 16 GB RAM en 200 GB harde schijf. De NFV-infrastructuur (NFVI) die door deze VIM wordt afgehandeld, bestaat uit drie servercomputers, elk met Ubuntu 16.04, 8 CPU's, 32 GB RAM en 2 TB opslag. Volg voor de installatie de Ocata-releasedocumentatie²¹.
   1. Implementeer een virtueel netwerk binnen het OpenStack-cloudplatform met behulp van een IP-adresbereik van de adresruimte die is toegewezen in stap 1.1. Dit netwerk, voortaan beheernetwerk genoemd, zal worden gebruikt ter ondersteuning van de uitwisseling van NFV-orkestratie-informatie tussen de OSM en de virtuele netwerkfuncties (VNF's) die op de centrale locatie worden geïnstantieerd.
   2. Configureer een virtueel netwerk (voortaan aangeduid als datanetwerk) ter ondersteuning van inter-site datacommunicatie, tussen de VNF's van de centrale site en andere VNF's die op externe sites worden uitgevoerd. Gebruik hiervoor een IP-adresbereik uit de adresruimte van stap 1.1.
      OPMERKING: De implementatie van de netwerken genoemd in stappen 1.3.1 en 1.3.2 is gedaan met behulp van providernetwerken van OpenStack. Providernetwerken moeten worden aangesloten op de fysieke netwerkinfrastructuur van de centrale site om een passende werking te garanderen.
4. Verbind zowel virtual private networks (d.w.z. het beheer en de datanetwerken), als de VIM- en OSM-machines, met een apparatuur die edge routing-functionaliteiten biedt. Deze router zal dienen als het toegangspunt tot de centrale site van het NFV-ecosysteem.
5. Maak een openbare experimentopslagplaats beschikbaar om alle inhoud te bieden die nodig is om het experiment uit te voeren. In het bijzonder maakt dit protocol gebruik van de openbare repository op²².

2. Configuratie van de virtual private network-service

1. Wijs een IP-adresruimte toe om de juiste werking van het multi-site ecosysteem te ondersteunen, zodat netwerkcommunicatie effectief tussen meerdere sites tot stand kan worden gebracht.
   OPMERKING: Het mogelijk maken van effectieve netwerkcommunicatie tussen meerdere sites vereist een zorgvuldig ontwerp van de IP-adresruimte die moet worden gebruikt door het NFV-ecosysteem, evenals door externe sites die er verbinding mee moeten maken. In het bijzonder mag de adresruimte die is toegewezen voor communicatie tussen locaties niet botsen met de adresruimte die op elke andere locatie al voor andere doeleinden wordt gebruikt.
   1. Wijs een IP-adresruimte toe die door externe sites moet worden gebruikt. Adressen in dit blok worden toegewezen aan NFV-entiteiten (bijvoorbeeld VIMs) en VNF's van de externe site. Om dit protocol te illustreren, wordt de privéadresruimte 10.154.0.0/16 gebruikt.
   2. Wijs een IP-adresruimte toe aan de virtuele koppelingen tussen de externe sites en het NFV-ecosysteem. Deze virtuele koppelingen worden ondersteund door een VPN-service. Om dit protocol te illustreren, wordt het adresbereik 10.154.254.0/24 gebruikt voor deze virtuele koppelingen.
2. Stel een apparatuur in om de VPN-service (Virtual Private Network) (d.w.z. een VPN-server) te leveren. Het experiment maakt met name gebruik van een servercomputer met Ubuntu 16.04 (64-bits variantimage), zes onafhankelijke CPU's, 16 GB RAM, 1 TB opslagschijf en twee netwerkinterfaces.
   1. Configureer een van de netwerkinterfaces van de VPN-server om de ontvangst van verbindingsaanvragen van externe sites via internet mogelijk te maken. Daartoe is het noodzakelijk om een interface van de server te gebruiken die is geconfigureerd met een openbaar IP-adres.
   2. Configureer de koppeling tussen de VPN-server en de edge-router van de centrale site. In het experiment kreeg deze link het adresbereik 10.4.255.0/24 toegewezen. Configureer de juiste netwerkroutes op de VPN-server, zodat het NFV-ecosysteem toegankelijk wordt vanaf externe sites die zijn verbonden met de VPN-service.
3. Installeer de VPN open-source software van het OpenVPN^23-project op de VPN-server. In het bijzonder gebruikt dit experiment de OpenVPN-versie 2.3.10 en de implementatie ervan werd gedaan met het bash-script "openvpn-install.sh", beschikbaar op http://github.com/Nyr/openvpn-install (andere installatieopties worden beschreven in de OpenVPN-documentatie ²⁴). Het bash-script presenteert de alternatieve parameters die zullen resulteren in de configuratie van de VPN-service.
   1. Selecteer het IP-adres om naar VPN-verbindingsverzoeken te luisteren (d.w.z. het openbare IP-adres).
   2. Bepaal welk protocol (UDP of TCP) moet worden gebruikt om de communicatie via de VPN aan te sturen. In dit geval maakt het experiment gebruik van UDP dat het aanbevolen protocol is.
   3. Geef de poort op die de duple bevat (samen met het openbare IP-adres) die wordt gebruikt om de serviceverbindingsaanvragen te ontvangen. Standaard is de toegewezen waarde 1194.
   4. Kies een van de DNS-servers van de lijst die wordt gevraagd door de assistent die de naamomzettingsaanvragen verwerkt die worden uitgevoerd door de clients van de VPN-service.
   5. Druk op een willekeurige toets om het automatische starten van het installatieproces van de VPN-service in te schakelen.
4. Bewerk het configuratiebestand "server.conf" dat zich onder de map "/etc/openvpn/server/" bevindt en voeg de "client-to-client"-instructie toe om de basisinstellingen van stap 2.3 uit te breiden. Zo kunnen verschillende clients die zijn verbonden met de VPN-service elkaar bereiken.
5. Schakel de individuele clientconfiguratie binnen de VPN-instellingen in om de routeringstoewijzingen voor elke client onafhankelijk te kunnen beheren.
   1. Voeg de instructie "client-config-dir ccd" toe en bewerk hetzelfde configuratiebestand als in stap 2.4.
   2. Maak de map "ccd" aan met het commando "mkdir /etc/openvpn/ccd/". Deze map zal dienen tijdens de volgende sectie van het protocol om de bestanden te plaatsen die de routeringsrichtlijnen bevatten die zijn gekoppeld aan de clients die bedoeld zijn om te worden geïntegreerd in het platform.
6. Stel de firewallregels in die nodig zijn om de verbindingen met de service toe te staan en tegelijkertijd de VPN-server te beschermen tegen kwaadaardige aanvallen. Daartoe maakt dit experiment gebruik van iptables²⁵, een opdrachtregelhulpprogramma dat is ontwikkeld om de Linux-kernelfirewall te configureren.
   1. Blokkeer eerst inkomend verkeer naar de VPN-server met het commando "iptables -P INPUT DROP".
   2. Sta de ontvangst van VPN-verbindingsverzoeken toe met de opdrachten "iptables -A INPUT -i -m state --state NEW -p udp --dport 1194 -j ACCEPT" ( de naam is van de VPN-serverinterface met het openbare IP-adres) en "iptables -A INPUT -i tun+ -j ACCEPT".
   3. Sta het doorsturen van verkeer toe tussen de VPN-serverinterfaces (d.w.z. de openbare interface en de virtuele interface die is gemaakt door de VPN-service tun0) om de VPN-server in staat te stellen de serviceverbindingsaanvraag te verwerken. Voer hiervoor het commando "iptables -A FORWARD -i tun+ -o -m state --state RELATED,ESTABLISHED -j ACCEPT && iptables -A FORWARD -i -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT" uit.
   4. Stel de VPN-server in staat om de NAT-mogelijkheid (Network Address Translation) te bieden met als doel internettoegang te bieden aan de centrale site, met als resultaat: "iptables -t nat -A POSTROUTING -s 10.4.0.0/16 -o -j MASQUERADE && iptables -A OUTPUT -o tun+ -j ACCEPT".

3. Integratie van een externe NFV-site

1. Verkrijg een geschikt IP-adresbereik om de site te integreren in het NFV-ecosysteem. Dit adresbereik wordt geleverd door het network operations center van het NFV-ecosysteem. Volgens stap 2.1.1 van dit protocol gebruikt het experiment een bereik van IP-adressen voor de externe site binnen 10.154.0.0/16.
2. Maak en geef de beveiligingsreferenties op om verbinding te maken met het NFV-ecosysteem.
   1. Genereer een VPN-referentie waarmee de nieuwe infrastructuur een beveiligde verbinding met de VPN-server tot stand kan brengen. Voer hiervoor de opdracht "bash openvpn-install.sh" uit op de VPN-server, selecteer de optie "1) Een nieuwe client toevoegen" van de gevraagde lijst en geef de naam op die aan die referentie moet worden gekoppeld, bijvoorbeeld uc3m_infrastructure. Deze stap genereert een bestand met de VPN-inloggegevens (genaamd "uc3m_infrastructure.ovpn" in het voorbeeld).
   2. Maak een tekstbestand in de map "/etc/openvpn/ccd/" van de VPN-server, inclusief de routeringsrichtlijnen (zoals gespecificeerd in de OpenVPN-documentatie ²⁴) die door de VPN-server moeten worden gepusht telkens wanneer een verbinding met de VPN-service tot stand wordt gebracht met behulp van de VPN-inloggegevens.
      OPMERKING: De naam van het tekstbestand moet overeenkomen met de naam die is opgegeven tijdens het maken van de VPN-referentie (bijvoorbeeld uc3m_infrastructure) om een aangepaste configuratie voor elke VPN-client te bieden.
   3. Geef het VPN-referentiebestand aan het technische personeel van de externe site. Dit moet gebeuren via een veilig en betrouwbaar kanaal. In dit experiment wordt een handmatig versleutelingsproces gebruikt. Als u de VPN-referentie wilt versleutelen, voert u de opdracht "7za a -tzip '-p' -mem=AES256 " uit, waarbij u instelt als de gewenste coderingssleutel, als de gekozen naam voor het gecodeerde bestand en als bestandsnaam van het VPN-referentiebestand (bijvoorbeeld: uc3m_infrastructure.ovpn).
   4. Verstrek de gecodeerde inloggegevens aan het technische personeel van de nieuwe site, samen met de sleutel die de decoderingsprocedures mogelijk maakt, via een beveiligd communicatiekanaal.
      OPMERKING: In dit experiment werden de gecodeerde referenties via elektronische e-mail verstrekt, terwijl de decoderingssleutel via een apart kanaal werd verzonden, met behulp van de short message service (SMS), met een offline overeenkomst van het telefoonnummer.
3. Stel de omgeving op de nieuwe site in, om de verbinding met het NFV-ecosysteem tot stand te brengen en om de externe NFVI te kunnen koppelen aan de OSM-stack van de centrale site.
   1. Installeer de VPN-software van OpenVPN²⁴ op een computer om een virtuele koppeling tussen de externe site en de centrale site van het NFV-ecosysteem mogelijk te maken. De computer met de OpenVPN-software zal dienen als een VPN-client of VPN-eindpunt op de externe site. De virtuele koppeling wordt gerealiseerd door middel van een beveiligde VPN-tunnel tussen het VPN-eindpunt en de VPN-server. In het experiment wordt het VPN-eindpunt uitgevoerd op een servercomputer met Ubuntu 18.04, 8 CPU's, 8 GB RAM, 128 GB opslagschijf en 3 GbE-interfaces (één voor verbinding met de VPN-service via internet).
   2. Activeer IP-forwarding in het VPN-eindpunt om netwerkrouteringsmogelijkheden te ondersteunen. Neem daartoe de regel "net.ipv4.ip_forward=1" op in het systeemconfiguratiebestand in het pad "/etc/sysctl.conf" en laad de bijgewerkte configuratie met het commando "sudo sysctl -p".
   3. Decodeer het VPN-referentiebestand met de informatie die is ontvangen in stap 3.2.4 met behulp van de opdracht "7za e ", waarbij de de bestandsnaam is van de gecodeerde VPN-referentie. Geef de decoderingssleutel op wanneer daarom wordt gevraagd door de opdracht.
   4. Start de OpenVPN-software op met het gedecodeerde referentiebestand met behulp van het commando "sudo openvpn --config " ( de bestandsnaam van de VPN-referentie is). Hiermee wordt het VPN-eindpunt geverifieerd bij de VPN-server en ontvangt het automatisch de juiste VPN-configuratieparameters en netwerkroutes. Op deze manier zal het VPN-eindpunt zich gedragen als een edge-router met een virtuele link naar de centrale site van het NFV-ecosysteem.
   5. Controleer de juiste werking van het VPN-eindpunt met behulp van de opdracht ping om de beschikbaarheid van connectiviteit met een van de knooppunten van de centrale site (bijvoorbeeld de OSM-stackapparatuur) te verifiëren.
   6. Selecteer op de nieuwe site een OSM-compatibele VIM om bewerkingen met het MANO-platform mogelijk te maken. Voor dit experiment wordt OpenStack release Ocata gebruikt.
      OPMERKING: OSM Release SEVEN ondersteunt de volgende virtuele infrastructuurbeheerders: OpenStack, OpenVIM²⁶, VMware's vCloud Director²⁷, Amazon Web Service²⁸, Microsoft Azure²⁹en Eclipse fog05³⁰ (zie OSM-documentatie¹⁸ voor specifieke configuratiedetails).
   7. Installeer OpenStack release Ocata²⁰ (zie de gedetailleerde procedures in de release documentatie²¹).
   8. Implementeer de NFV-infrastructuur op de externe site en koppel deze aan de VIM. In het bijzonder maakt dit experiment gebruik van een NFV-infrastructuur bestaande uit drie single board computers (SBC's), elk met een rekencapaciteit van 1 GB RAM, 4 CPU's en een opslagschijf van 32 GB; en een enkele mini-ITX-computer met 8 CPU's, 8 GB RAM en 128 GB voor opslag.
      OPMERKING: De externe site die in dit protocol wordt geïllustreerd, is gebaseerd op een NFV-infrastructuur van NFV-compatibele kleine onbemande luchtvaartuigen (SUAVs). De details die zijn gevolgd om een dergelijke infrastructuur mogelijk te maken, zijn opgenomen in Nogales et al³¹. Stappen 3.3.6 tot en met 3.3.8 zijn optioneel, aangezien er mogelijk al een NFV-infrastructuur bestaat op de externe locatie.
   9. Maak een OpenStack-project om de set computationele bronnen van de externe site op te geven die in het NFV-ecosysteem worden geïntegreerd. Om dit te doen, toegang tot de grafische gebruikersinterface (GUI) van OpenStack, log in op het systeem met de beheerdersreferenties, klik op de knop + Project maken van het tabblad Identiteit -> Projecten en maak een project aan dat het weergegeven formulier invult met de gevraagde informatie.
   10. Maak een geldige gebruiker die het project beheert dat in de vorige stap is gemaakt. Ga hiervoor naar het tabblad Identiteit -> Gebruikers met dezelfde aanmelding als in de vorige stap, klik op + Gebruiker maken en vul de vereiste velden van het weergegeven formulier in (gebruikersnaam en wachtwoord), selecteer het nieuw gemaakte project als het primaire project en kies de beheerdersrol.
   11. Wijzig de beveiligingsregels om VNF-communicatiemachtigingen toe te staan op de nieuwe site (met name SSH- en ICMP-verkeer inschakelen). Ga daartoe naar de OpenStack GUI met de referenties van de gebruiker die in de vorige stap is gemaakt, volg de volgorde: Project -> Network -> Security Groups -> + Add Ruleen selecteer de SSH-optie van de vervolgkeuzelijst Rule. Herhaal het proces, maar selecteer de optie Alle ICMP in het vervolgkeuzemenu.
   12. Download de images van een proefdienst aangeboden door de OSM gemeenschap, de Ping Pong netwerk dienst ("Fedora-x86_64-20-20131211.1-sda-ping" en "Fedora-x86_64-20-2013111.1-sda-pong") van de openbare experiment repository, en upload ze naar de VIM van de externe site. Volg hiervoor de reeks Project -> Compute -> Images -> + Create Imageen maak de afbeeldingen met behulp van het weergegeven formulier en selecteer elk van de afbeeldingen.
   13. Wijs twee IP-adresbereiken toe binnen de adresruimte van de externe site (toegewezen in stap 3.1). Deze bereiken zullen worden gebruikt om het beheer van de VNF's van de externe site te ondersteunen en om respectievelijk inter-site datacommunicatie tussen VNF's mogelijk te maken.
   14. Maak een providernetwerk(control-provider)aan met behulp van de VIM. Dit netwerk ondersteunt NFV-communicatie tussen de OSM-stack op de centrale site en de VNF's die op de nieuwe site worden ingezet voor beheerdoeleinden. Met dit type communicatie kan de OSM-stack ook VNF's configureren na hun implementatie. Om een providernetwerk in OpenStack te maken, volgt u de volgorde Admin -> System -> Networks -> + Create Network en vult u de details van het nieuwe netwerk in met behulp van het geselecteerde IP-adresbereik in de vorige stap.
   15. Maak een tweede providernetwerk(data-provider)aan met behulp van de VIM. Dit netwerk ondersteunt datacommunicatie tussen de VNF's van de site en andere VNF's van het NFV-ecosysteem. Om dit providernetwerk in OpenStack te maken, volgt u de volgorde Admin -> System -> Networks -> + Create Networken vult u de details van het nieuwe netwerk in met behulp van het toegewezen adresbereik.
       OPMERKING: Instructies voor het maken van virtuele netwerken variëren afhankelijk van de VIM-software. Raadpleeg hun respectieve softwaredocumentatie voor meer informatie.
   16. Deel de VIM-gerelateerde informatie (met name de gebruikersnaam/het wachtwoord en het project dat is gemaakt in de stappen 3.3.9 en 3.3.10) met het technisch personeel van de centrale site, om de koppeling van het VIM aan de OSM-softwarestack mogelijk te maken.
4. Koppel de externe NFV-infrastructuur aan de OSM-softwarestack van de centrale site, met behulp van de informatie verkregen uit stap 3.3.16.
   1. Controleer de connectiviteit tussen de OSM-stack van de centrale site en de VIM van de nieuwe site met behulp van de ping-tool.
   2. Als de vorige connectiviteitstest is geslaagd, koppelt u de externe VIM aan de OSM-stack van de centrale site. Gebruik hiervoor de volgende opdracht op de OSM-machine: "osm vim-create --name --user --password --auth_url --tenant --account_type ". In deze opdracht: is de naam die is geselecteerd om de VIM binnen de OSM-stack te identificeren, is de naam van de gebruiker die gemachtigd is om de bronnen van de externe site te verwerken (zie stap 3.3.10), is het wachtwoord van de aangegeven gebruiker, is de link naar de API die beschikbaar wordt gesteld door de VIM om verzoeken van de OSM-stack in te schakelen , is de projectnaam gedefinieerd in stap 3.3.9 en is de gebruikte VIM-software (in dit experiment OpenStack).
5. Controleer de juiste bevestiging van de nieuwe VIM aan de OSM-stack van het NFV-ecosysteem.
   1. Voer het commando "ro_id=$(docker ps | grep osm_ro | cut -d ' -f 1)" om de id te identificeren van de container die de Resource Orchestrator (RO) module in het OSM-systeem implementeert. Deze module is verantwoordelijk voor de interactie met de VIMs om de benodigde middelen te coördineren en toe te wijzen bij de implementatie van volgende netwerkservices.
   2. Open de RO-container met het commando "docker exec -it $ro_id bash". Deze opdracht maakt gebruik van de id die is verkregen bij de uitvoering van de vorige stap.
   3. Controleer of de nieuwe VIM is opgenomen in de lijst met beschikbare datacenters met behulp van het commando "openmano datacenter-list". De nieuwe site moet in de lijst verschijnen met dezelfde naam als de eerder geïntroduceerde site in stap 3.4.2 met de parameter.
   4. Maak een lijst van de afbeeldingen die zijn geüpload naar de VIM van de externe site met de opdracht "openmano vim-image-list --datacenter ". De parameter geeft de naam aan die is geselecteerd om de VIM binnen de OSM-stack te identificeren. Als de uitvoering van deze opdracht succesvol is, is de verbinding met de externe VIM met succes verbroken. Controleer of de pingpongafbeeldingen in de lijst zijn opgenomen.
   5. Maak een lijst van de netwerken die beschikbaar zijn op de nieuwe site met de opdracht "openmano vim-net-list --datacenter ". Controleer of control-provider en data-provider aanwezig zijn.
6. Voer een voorlopige validatie uit van de juiste integratie van de nieuwe site, met behulp van een proefservice die wordt aangeboden door de OSM-gemeenschap (alle inhoud in dit verband is opgenomen in de experimentrepository). Voor dit doel worden de opdrachten in de volgende stappen uitgevoerd in de apparatuur die de OSM-stack host.
   1. Onboard de VNF-descriptoren (VNFD's) naar de OSM-stack met de opdracht "osm vnfd-create " voor elk van de VNF's die de proefservice samenstellen ( komt overeen met de bestandsnaam van het VNFD-pakket).
   2. Onboard de NS-descriptor (NSD) van de proefservice met het commando "osm nsd-create ", waarbij de bestandsnaam van het NSD-pakket aangeeft (in dit experiment ping_pong_ns.tar.gz)."
   3. Start de instantiatie van de Ping Pong Network Service (NS) op de externe en de centrale sites, met behulp van het commando "osm ns-create --ns_name --nsd_name ping_pong_ns --vim_account --config '{vnf: [{member-vnf-index: '2', vim_account: }]}'.". De parameter identificeert de VIM van de externe site binnen de OSM-stack. De optie "--config" geeft aan dat alle VNF's waaruit de service bestaat, moeten worden geïmplementeerd op de externe site die door die VIM wordt afgehandeld, behalve de VNF geïdentificeerd door de index 2 in de NS, die zal worden geïmplementeerd op de centrale site (de VIM van de centrale site is opgegeven in de parameter).
   4. Controleer of de NS is ingezet en de status ervan met het commando "osm ns-list". Als de instantiatie succesvol is, verandert de status in "READY".
   5. Controleer het IP-adres van elk van de twee VNF's met "osm vnf-list" (nodig om achteraf in te loggen op de machines).
   6. Maak verbinding met elke VNF via SSH, met behulp van het commando "ssh fedora@" ( het IP-adres vertegenwoordigt van de VNF om verbinding mee te maken, verkregen in de vorige stap). Introduceer het wachtwoord "fedora" wanneer daarom wordt gevraagd door SSH. Zodra u op beide machines bent ingelogd, controleert u hun interfaces met het commando "ip address show" en verkrijgt u de IP-adressen op hun interfaces die zijn aangesloten op het netwerk van de gegevensprovider (interface eth1 in beide VNF's). Voer vanuit een van de VNF's een ping uit naar de andere VNF met behulp van het externe IP-adres in het netwerk van de gegevensprovider. Als er connectiviteit is, wordt de voorlopige validatietest als succesvol beschouwd.

4. Validatie van het NFV multi-site platform met een realistische verticale service

1. Download de VNF-afbeeldingen uit de openbare opslagplaats en upload ze naar het VIM van hun overeenkomstige site (zie figuur 3), volgens de procedure die wordt beschreven in stap 3.3.12. In het bijzonder zal de externe site het Access Point VNF, Router VNF, MQTT Gateway VNF en Access Router VNFhosten. De centrale site zal de 5G Core VNF en de IoT Server VNFhosten.
2. Onboard de VNFD's en de NSD van de smart farming service naar de OSM stack (alle descriptoren kunnen worden gedownload van de experiment repository).
   1. Onboard de VNFD's naar de OSM-stack en voer het commando "osm vnfd-create " uit voor elk van de VNF's van de netwerkservice. In dit geval komt de parameter overeen met de bestandsnaam van het VNFD-pakket.
   2. Onboard de NSD naar de OSM-stack met het commando "osm nsd-create ", waarbij de bestandsnaam van het NSD-pakket aangeeft (in dit experiment jove_uavs_scenario_nsd.tar.gz).
3. Implementeer de smart farming-netwerkservice. Voer hiervoor de volgende opdracht uit vanuit de OSM-opdrachtregelinterface: osm ns-create --ns_name --nsd_name jove_uavs_scenario_nsd --vim_account --config '{vnf: [ {member-vnf-index: "5", vim_account: }, {member-vnf-index: "6", vim_account: } ], wim_account: False }'.
   OPMERKING: Zoals aangegeven in stap 3.6.3, geven de en parameters aan op welke locaties de VNF's moeten worden ingezet. In het bijzonder zullen alle VNF's die de smart farming-service samenstellen, op de nieuwe externe site worden geplaatst, behalve die met index 5 en 6 (de 5G Core en de IoT-server VNF's) die aan de centrale site zullen worden toegewezen.
4. Controleer of de NS is ingezet, volgens dezelfde procedure als in stap 3.6.4.
5. Toegang tot de IoT-server VNF met het commando "ssh mosquittosubscriber@" en controleer de interface die is geconfigureerd om te communiceren met MQTT Gateway VNF via het commando "ip address show dev eth1". Het IP-adres van de VNF () kan worden verkregen door de "osm vnf-list" in de OSM-opdrachtregel uit te voeren.
6. Na een analoge procedure, toegang tot de MQTT Gateway VNF, en voer de opdracht "sudo python3 publisher_MQTT_GW.py -ma -ba " uit waarbij de wordt verkregen in de vorige stap, en de uitvoeren van de opdracht "ip address show dev eth1" in de MQTT Gateway VNF. Deze stap initialiseert de MQTT Gateway VNF, die gegevens ontvangt die door de sensor zijn gegenereerd met behulp van de MQTT-standaard¹⁵, en deze gegevens verzendt naar de IoT-server VNF met behulp van dezelfde standaard.
7. Bereid een Single Board Computer (SBC) voor die een meteorologische sensor bevestigt en met transceivercapaciteit om sensormetingen naar de MQTT Gateway VNF te verzenden.
   OPMERKING: Om dit protocol te illustreren, is met name een SBC-model gebruikt. Daarom moeten de volgende stappen mogelijk worden aangepast in het geval van het gebruik van een ander SBC-platform.
   1. Sluit (bijvoorbeeld met behulp van tingesoldeerde koperdraden) de bordpennen van de sensor aan op de gpio-pinnen (general-purpose input/output) van de SBC, volgens het configuratieschema van figuur 5.
   2. Schakel de I2C-kernelmodule in de SBC in om te kunnen controleren of de sensor wordt gedetecteerd. Voer hiervoor de opdracht "sudo raspi-config" uit, volg de volgorde Interfacing Options -> I2C -> Yes in het weergegeven menu en start de SBC opnieuw op om de wijzigingen effectief te maken.
   3. Controleer of de sensor is gedetecteerd Het installeren van de software i2c-tools in de SBC en het uitvoeren van het commando "sudo i2cdetect -y 1". Als dat het geval is, moet er een raster verschijnen dat de positie aangeeft waar de sensor wordt gedetecteerd.
   4. Installeer de juiste softwarebibliotheken zodat de SBC de gegevens van de sensor kan lezen en verzenden. Dit experiment maakt met name gebruik van de RPi.bme280^32- en paho-mqtt³³ Python-bibliotheken.
8. Met behulp van de mobiele applicatie van de SUAV, neem het luchtvoertuig dat het access point VNFhost en positioneer het om draadloze dekking te bieden aan de SBC met de sensor.
   OPMERKING: De vlucht van de NFV-compatibele SUAVs is onafhankelijk van het operationele gedrag van de netwerkdienst, die in staat is om te werken ongeacht of de SUAVs vliegen of in een staat van rust zijn om het batterijverbruik te verminderen. Stap 4.8 is dus optioneel.
9. Sluit de SBC die verantwoordelijk is voor het lezen van de gegevens die door de sensor worden verzameld aan op het draadloze Wi-Fi-toegangspunt dat wordt geleverd door het access point VNF). Na een succesvolle aansluiting wordt een draadloos netwerkpad ingeschakeld van de sensor naar de MQTT Gateway VNF.
10. Start de overdracht van gedetecteerde gegevens met de opdracht "python3 /home/ubuntu/sensorDataTransmission.py -a " in de SBC die de sensor bevat ( het IP-adres is dat is verkregen in stap 4.6.).
11. Open de web-GUI die wordt geleverd door de IoT-server VNF om de juiste realtime ontvangst van de gedetecteerde gegevens te controleren. Controleer daartoe het IP-adres van de IoT Server VNF met het commando "osm vnf-list" en typ de volgende Uniform Resource Locator (URL) in een webbrowser: http://:3001, waarbij het IP-adres is van de IoT-server VNF. Klik vervolgens op de knop Sensors Data Collection van het tabblad Home en controleer de realtime update van de grafieken in het dashboard wanneer de gegevens worden ontvangen.
    OPMERKING: Om toegang te krijgen tot de URL die wordt vermeld in stap 4.12, moet het apparaat met de webbrowser die die bron probeert te bereiken, verbonden zijn met het NFV-ecosysteem en IP-connectiviteit hebben met de IoT Server VNF. De VPN-dienst kan ook voor dit doel worden gebruikt.
12. Wacht op een geschikte periode om representatieve resultaten te verkrijgen van de uitvoering van de smart farming-service. Verzamel vervolgens de gegevens die zijn opgeslagen in de IoT-server VNF voor verdere analyse. Gezien het feit dat de sensor in dit experiment elke 5 seconden temperatuur-, vochtigheids- en drukmetingen levert, loopt de service in het experiment gedurende een periode van 10 minuten, wat resulteert in 180 monsters van waargenomen gegevens (60 voor elk meteorologisch waardetype).
13. Open de database van de IoT Server VNF om de gedetecteerde gegevens op te halen voor verdere analyse. Voer hiervoor het commando "id_database=$(sudo docker ps | grep 'influxdb:' | cut -d ' -f 1)" op de IoT Server VNF, en vervolgens "sudo docker exec -it $id_database bash"
14. Exporteer de gegevens naar een CSV-bestand (comma-separated value) met het commando "influx -database 'mainflux' -execute "SELECT * FROM messages WHERE \"name\" = '' " -format csv > /tmp/.csv". Wijzig de parameter om te selecteren welk type gedetecteerde gegevens moet worden geëxporteerd met de "temperatuur", "vochtigheid" of "druk" en stel de parameter in om een naam te kiezen voor het uitvoerbestand dat de resultaten bewaart.
15. Sla de gegevensbestanden op die in de vorige stap zijn gegenereerd voor latere weergave (zie de sectie Representatieve resultaten) en verificatie van de juiste werking van de smart farming-service.

Representative Results

Na het zorgvuldig volgen van het protocol om een nieuwe site op te nemen in het centrale platform en één netwerkservice uit te voeren om de juiste functionaliteit te valideren, toont Figuur 6 een screenshot van de open-vpn-monitor tool. Er kan worden waargenomen hoe de nieuwe site de VPN gebruikt voor al zijn communicatie, en laat zien hoe zijn communicatie de VPN volgt om deze gegevensuitwisseling mogelijk te maken en, als gevolg daarvan, de juiste toevoeging van de nieuwe site aan de VPN-service.

Zoals weergegeven in figuur 3,levert de netwerkservice informatie van een sensor in een externe infrastructuur aan de server op de centrale site. Bovendien toont figuur 7 de succesvolle implementatie van de netwerkservice vanuit de OSM-web-GUI, die laat zien hoe het experiment op de juiste manier kan worden geïnstantieerd in de nieuwe externe infrastructuur van de MANO-stack op de centrale site. Bovendien is de tijd die in het experiment nodig is om de implementatie van de service te voltooien ongeveer acht minuten. Deze waarde, samen met de tijd die nodig is om de servicedescriptoren in het orkestratieplatform aan boord te krijgen (ongeveer 9 seconden, met 1,3 seconden per descriptor, rekening houdend met zowel de NS- als elke VNF-descriptoren), maken het mogelijk om te voldoen aan de Key Performance Indicator (KPI) van 90 minuten voor de tijd voor het maken van de service, zoals aangegeven door de 5G Infrastructure Public Private Partnership³⁴. In deze context omvat het werk gepresenteerd in Vidal et al.⁹ een diepgaande analyse van de tijd voor het maken van diensten met meerdere sites met behulp van het gepresenteerde protocol.

Figuur 8 toont de gegevens die door de sensor zijn verzameld, inclusief de waarden van respectievelijk vochtigheid, temperatuur en druk. Deze monsters komen overeen met alle gegevens die van de sensor naar een externe server in 5TONIC worden verzonden, waar deze waarden in een database worden opgeslagen. Al deze gegevens tonen aan dat het platform in staat is om praktische netwerkdiensten in te zetten na de opname van een nieuwe infrastructuur, evenals om communicatie tussen sites correct mogelijk te maken.

Figuur 1:Distributie van VPN-servicesites. Distributie van de VPN-service via het platform en hun linkconnectiviteit (allemaal via 5TONIC). Klik hier om een grotere versie van deze figuur te bekijken.

Figuur 2. Overzicht van het platform en vpn-dienst. Deze figuur toont alle elementen van het platform: de centrale locatie, samen met de NFV-infrastructuur, de VPN-service en een nieuwe infrastructuur die is samengevoegd met het systeem. Het omvat ook de verbindingen tussen de elementen. Klik hier om een grotere versie van deze figuur te bekijken.

Figuur 3: Overzicht van de netwerkdienst. Het toont de elementen die betrokken zijn bij de netwerkservice, de distributie en de logische en netwerkconnectiviteit. Klik hier om een grotere versie van deze figuur te bekijken.

Figuur 4: Protocolworkflows. Elke kolom vertegenwoordigt een sectie van het protocol, waar elke uitgevoerde actie wordt beschreven, de logische verbinding tussen hen en de component die verantwoordelijk is voor de uitvoering ervan. Klik hier om een grotere versie van deze figuur te bekijken.

Figuur 5: Pin configuratie schema. Diagram dat aangeeft hoe de fysieke verbindingen tussen de boardpennen van de sensoren en de GPIO-pinnen van de SBC waarin die sensor is opgenomen, moeten worden gemaakt. Klik hier om een grotere versie van deze figuur te bekijken.

Figuur 6: OpenVPN-monitor snapshot. De afbeelding laat zien dat de geaggregeerde infrastructuur is verbonden met de VPN-service, inclusief enkele details met betrekking tot de verbinding. Bovendien toont de figuur ook extra verbindingen die behoren tot andere afgelegen infrastructuren. Klik hier om een grotere versie van deze figuur te bekijken.

Afbeelding 7: OSM NS-implementatiestatus. OSM grafische interface, die de succesvolle implementatie van de testnetwerkservice in de externe infrastructuur laat zien. Klik hier om een grotere versie van deze figuur te bekijken.

Figuur 8: Representatieve analyse van de door de sensor verzamelde gegevens. (A) Illustratie van de temperatuurgegevens die periodiek om de 5 seconden door de sensor worden verzameld. (B) Grafische weergave van de vochtigheidsgegevens die elke 5 seconden door de sensor worden verzameld. (C) Visuele weergave van de drukgegevens die elke 5 seconden door de sensor worden verzameld. Klik hier om een grotere versie van deze figuur te bekijken.

Discussion

Een van de belangrijkste aspecten van het eerder beschreven protocol is de uitstekende flexibiliteit om nieuwe computationele infrastructuren op te nemen in een NFV-ecosysteem, ongeacht hun distributie in termen van geografische locatie (zolang bandbreedte en latentie van de netwerkcommunicatie met externe sites dit ondersteunen). Dit is mogelijk via een VPN-gebaseerde overlay-netwerkarchitectuur, waarmee een virtuele koppeling kan worden gemaakt om externe sites te verbinden met de centrale gebouwen van het NFV-ecosysteem. Deze aanpak maakt het mogelijk om een effectief en veilig kanaal te bieden ter ondersteuning van de NFV- en datacommunicatie tussen sites van een NFV-ecosysteem, waardoor de kans wordt verkleind dat externe partijen toegang krijgen tot gevoelige informatie over NFV-orkestratieprocessen en gegevens van geïmplementeerde services en deze wijzigen. In deze context beschrijft het protocol ook een specifieke methodologie om de VPN-inloggegevens veilig te delen met de externe sites die de integratie van nieuwe infrastructuren mogelijk maken. Het protocol is geïllustreerd met behulp van het NFV-ecosysteem dat beschikbaar is gesteld op 5TONIC door Universidad Carlos III de Madrid, Telefónica en IMDEA Networks Institute, hoewel het generiek is om te worden gebruikt in andere NFV-omgevingen die voldoen aan de voorafgaande vereisten die worden vermeld in stap 1 van dit protocol.

Bovendien is het de moeite waard om het exclusieve gebruik van open-source tools en software voor de protocolimplementatie te benadrukken. Ondanks de potentieel voordelige functionaliteiten die kunnen worden geboden door verschillende propriëtaire oplossingen (bijv. Fortinet^35),heeft het gebruik van open-source ontwikkelingen de integratie van alle elementen die door het protocol worden omvat vergemakkelijkt vanwege hun inherente kenmerken zoals kosteneffectiviteit, een uitgebreide softwareondersteuning door de open-sourcegemeenschap en een hoge mate van betrouwbaarheid, om er maar een paar te noemen. Bovendien kan het gebruik van open-sourcetechnologieën ook synergieën tussen componenten van vergelijkbare aard bevorderen. Om bijvoorbeeld de VPN-verbindingsstatus voor de clients die het platform gebruiken te controleren, kan de VPN-service die in het hele protocol is geïmplementeerd, vertrouwen op de open-vpn-monitortool³⁶ (een op python gebaseerde monitoringtool die kan samenwerken met OpenVPN-servers).

Aan de andere kant houdt de protocolspecificatie rekening met het instantiëren van netwerkservices op verschillende sites voor validatiedoeleinden. In dit verband is het belangrijk om te benadrukken dat de implementatie van services op een bepaalde site afhankelijk is van de beschikbaarheid van reken-, opslag- en netwerkbronnen op de site, evenals van gespecialiseerde apparatuur die nodig kan zijn om de implementatie uit te voeren (bijvoorbeeld NFV-compatibele SUAVs). Dit is geen beperking van het protocol en moet in aanmerking worden genomen door belanghebbenden die geïnteresseerd zijn in het reproduceren van het experiment dat in dit artikel wordt beschreven.

Bovendien moet worden opgemerkt dat de tijd die nodig is om de implementatie van netwerkdiensten uit te voeren, sterk afhankelijk is van verschillende factoren, zoals het netwerkpad tussen de orchestrator en de verschillende VIMs, de prestaties van datacommunicatie tussen het VIM en zijn beheerde computationele knooppunten, en ook in de intrinsieke aard van deze computationele knooppunten (niet alleen vanwege hun beschikbare computerbronnen, maar ook de technologieën die zijn opgenomen om de virtualisatie van netwerkfuncties uit te voeren).

Ten slotte, en gezien de uitstekende prestaties die dit platform en zijn VPN-service hadden op de Europese projecten en samenwerkingswerken waar het tot nu toe is gebruikt (bijv. 5GINFIRE, 5GRANGE of 5GCity, genoemd in de inleiding van dit document), zal het worden beschouwd als een belangrijk element in opkomende Europese projecten waar Universidad Carlos III de Madrid, Telefónica en IMDEA Networks Institute nemen deel, zoals het Horizon 2020 LABYRINTH, of nationale projecten, zoals TRUE-5G.

Materials

Name	Company	Catalog Number	Comments
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/