1. Introduction
Le protocole central (IP) d'Internet connaît un succès sans précédent. Alors que l'utilisation d'identifiants IPv4 et le manque de sécurité ont simplifié l'ajout d'appareils à Internet à ses débuts, ils se sont transformés en lacunes à mesure que le réseau évolue et que la sécurité devient une préoccupation majeure. Dans l'Internet d'aujourd'hui, les adresses IPv4 sont rares en raison de la quasi-épuisement de l'espace d'adressage de 32 bits, et de nombreux réseaux doivent recourir à l'utilisation d'adresses privées et de boîtes de médiation de traduction d'adresses réseau (NAT) [1]. Les problèmes de sécurité ont également conduit à la prolifération de boîtes de médiation de pare-feu, tandis que le besoin d'authentification, de confidentialité et d'intégrité a conduit à l'apparition de protocoles de couche transport (par exemple TLS [2], [3]). En conséquence, les applications distribuées qui s'exécutent sur Internet doivent souvent gérer des appareils sans adresses IPv4 publiques qui se trouvent derrière divers boîtiers de médiation NAT et pare-feu et doivent créer des sessions de transport sécurisées pour la communication. Bien que ces problèmes soient relativement faciles à gérer avec les applications client-serveur, ils constituent un fardeau pour les applications où une communication peer-to-peer est nécessaire.
Les applications distribuées émergentes dans l’informatique Edge/Fog [4], [5] sont sur le point de bénéficier de la capacité de l’IoT et des nœuds Edge à communiquer de manière peer-to-peer. Cependant, les défis de connectivité décrits ci-dessus deviennent un fardeau croissant pour le développement de middleware et d'applications à mesure qu'ils passent du cloud vers la périphérie [6], y compris la sécurité et la confidentialité [7]. Bien que le protocole IPv6 ultérieur offre un espace d'adressage plus grand et des fonctionnalités de sécurité intégrées, il n'est toujours pas largement déployé malgré des décennies depuis sa sortie. Une approche pour relever ces défis qui ne nécessite pas de changement fondamental des protocoles Internet consiste à créer des réseaux superposés [8], [9] qui tunnelisent le trafic sur l'infrastructure existante. Associées à la virtualisation du réseau, les superpositions offrent la possibilité de prendre en charge les middlewares et les applications existants, tout en les protégeant des complexités dues à l'adressage privé, à la traduction d'adresses réseau et aux politiques de pare-feu.
Cet article décrit la conception et la mise en œuvre d'IP-over-P2P (IPOP [10]-[15]), un réseau privé virtuel superposé qui prend en charge le tunneling du trafic de couche 2 (Ethernet) et supérieur (y compris IPv4) à travers des réseaux peer-to-peer. -tunnels de pairs. IPOP expose les points de terminaison d'interface réseau virtuelle qui s'intègrent aux systèmes d'exploitation existants, gère automatiquement la traversée NAT entre pairs avec des adresses IP privées, auto-organise des topologies de superposition évolutives et prend en charge le cryptage des liens peer-to-peer et permet la programmation définie par logiciel de la commutation. règles. IPOP fournit un substrat de virtualisation de réseau sur lequel les ressources IoT, Edge et Cloud computing géographiquement distribuées peuvent être regroupées logiquement pour faciliter la conception d'applications de Fog Computing. Cet article décrit l'évolution de la conception et de la mise en œuvre open source d'IPOP au cours de plusieurs itérations du projet.
L'avènement de la virtualisation et du cloud computing a fondamentalement modifié la manière dont les applications et services distribués sont déployés et gérés. Avec la prolifération de l'IoT et des appareils mobiles, les systèmes virtualisés similaires à ceux proposés par les fournisseurs de cloud sont de plus en plus nécessaires géographiquement à proximité de la périphérie du réseau [4]. Les applications sur les ressources en périphérie peuvent effectuer des opérations sur de gros volumes de données produites par des capteurs (par exemple, des flux de caméra haute définition en temps réel) à proximité d'appareils IoT pour des applications sensibles à la latence et gourmandes en bande passante – un modèle appelé brouillard informatique [5 ]. Non seulement les performances sont importantes, mais un réseau fiable est également essentiel pour garantir la confidentialité et l'intégrité au niveau de la couche réseau sur toutes les ressources participantes (par exemple, l'IoT, les machines virtuelles cloud et les conteneurs dans les ressources périphériques [16]).
Bien que les systèmes de réseaux virtuels définis par logiciel existent dans des centres de données cloud à grande échelle [17] – au cœur d'Internet et sous une seule entité administrative – ils ne sont pas adaptés aux futures applications distribuées couvrant les ressources de pointe. De telles applications Fog sont distribuées sur plusieurs fournisseurs et réseaux périphériques, soulevant des problèmes de sécurité et de confidentialité plus complexes que dans les environnements cloud [6]. Contrairement à un cloud, les réseaux virtuels de périphérie nécessitent de traverser plusieurs environnements administratifs (éventuellement NATés [7]) entre différents fournisseurs et de garantir la confidentialité et l'intégrité des données dans les communications. Bien qu'il existe des technologies de sécurité réseau au niveau de la couche de transport (par exemple TLS, DTLS) et de tunneling VPN (par exemple IPSEC), elles ne sont pas facilement applicables aux systèmes où l'appartenance aux ressources est dynamique et où la plupart des appareils sont limités par des boîtiers de médiation NAT/pare-feu. De plus, les efforts associés au développement ou au portage d’applications pour garantir la confidentialité et l’intégrité des communications entraînent des coûts importants.
Pour accomplir ses fonctionnalités requises, une application Fog nécessite la capacité de déployer, d'agréger et de traiter les données des capteurs en périphérie et des ressources cloud de manière dynamique. Il doit également prendre en charge les changements dynamiques dans l'adhésion des appareils participants au fil du temps, dans la mesure où les appareils peuvent être mobiles (par exemple, les caméras vidéo des smartphones et des véhicules). Fondamentalement, le réseau reliant les ressources IoT, Edge et Cloud doit fournir une communication fiable et transparente à travers un ensemble de ressources mobiles dynamiques, hétérogènes.
La version actuelle d'IPOP implémente un logiciel hybride de superposition/réseau défini par logiciel (SDN [18]) qui est nouveau dans la façon dont il prend en charge le regroupement/l'agrégation dynamique de périphériques de périphérie et de cloud dans un réseau privé virtuel digne de confiance qui exploite le réseau social en ligne (OSN). ) interfaces pour l'auto-configuration. Les sections suivantes décrivent les concepts fondamentaux de la conception et l'évolution de la mise en œuvre menant à sa forme actuelle.
2. Abstractions et architecture de base
L'abstraction principale exposée par IPOP à un système informatique qui l'utilise est celle d'un réseau virtuel. Le 1\(^{\mathrm{st}}\) la génération du projet a exposé l'abstraction d'un réseau virtuel de couche 3 (IP) [10]-[12], tandis que le 3\(^{\mathrm{rd}}\) 4\(^{\mathrm{th}}\) Les générations exposent l'abstraction au niveau de la couche 2 (Ethernet) [13], [14]. Dans les deux cas, l'abstraction est exposée via une interface réseau virtuelle (VNIC), telle que le pseudo-périphérique TAP disponible dans les noyaux Linux et Windows, à partir de laquelle les trames/paquets envoyés et reçus sont interceptés. Les nœuds IPOP sont implémentés en tant que processus dans l'espace utilisateur qui s'exécute dans chaque nœud connecté à la superposition ; ce processus lit/écrit à partir du périphérique TAP, à l'aide de l'interface d'appel système, comme illustré sur la figure 1.
Les nœuds IPOP forment des liens virtuels entre eux, chaque lien virtuel étant un tunnel Internet qui transporte des trames/paquets de réseau virtuels cryptés et encapsulés via un protocole de transport – généralement UDP, qui se prête mieux à la traversée NAT que TCP.
Chaque nœud IPOP dans une superposition est identifié de manière unique par un identifiant de nœud (par exemple A, B, ..., F) sur la figure 1. L'ensemble des liens virtuels entre les nœuds IPOP forme une topologie. Bien que différentes topologies de superposition aient été implémentées dans les versions IPOP au fil du temps, une topologie P2P structurée est une caractéristique de la conception depuis sa création. Dans cette topologie, les nœuds forment un anneau logique, avec des liens successeurs classés par leurs ID de nœud et des liens de raccourci à travers l'anneau, suivant un algorithme P2P structuré pour la construction de topologie et le routage basé sur des identifiants tels que Chord [19] ou Symphony [20]. .
3. Conception P2P entièrement décentralisée
La solution 1\(^{\mathrm{st}}\) La génération d'IPOP [10] a été entièrement décentralisée, suivant une conception P2P structurée utilisant la bibliothèque Brunet [21] et un protocole basé sur Symphony. Deux motivations principales pour cette approche étaient d'éviter toute dépendance externe et tout point de défaillance unique. Chaque nœud a implémenté la fonctionnalité pour 1) découvrir d'autres nœuds au moyen d'un fichier de liste de pairs, 2) amorcer en contactant les nœuds de la liste de pairs et en les utilisant pour envoyer des messages aux voisins gauche et droit du pair qui rejoint, 3) fournir un support pour la découverte. du point de terminaison IP:port public d'un nœud, et 4) transférer les messages selon un algorithme de routage glouton.
Cette implémentation a fourni un réseau virtuel de couche 3 pour le protocole IPv4. Il n’y avait ni cryptage ni authentification des nœuds dans la superposition. Les adresses IP ont été attribuées aux nœuds en exploitant un magasin de clés/valeurs de table de hachage distribuée (DHT [19]) qui a également été implémenté par les nœuds IPOP. Le DHT a utilisé une clé composée, comprenant un espace de noms de réseau virtuel et une adresse IP virtuelle pour mapper l'ID IPOP du nœud. Cela a permis à plusieurs réseaux virtuels de partager une seule superposition sans collision de sous-réseaux privés. Les nœuds IPOP comprenaient également une implémentation d'un serveur DHCP au niveau utilisateur qui distribuait des adresses IP en attribuant aléatoirement une adresse dans un espace de noms de réseau virtuel déclaré et en insérant le mappage dans le DHT [22].
Bien que cette mise en œuvre se soit avérée utile dans de nombreux scénarios et résistante aux échecs et aux désabonnements, elle présentait plusieurs lacunes. Premièrement, la conception monolithique a conduit à un nœud complexe qui implémentait plusieurs modules pour la découverte et l'amorçage, le DHT, le routage par superposition, la traversée NAT, l'attribution/le mappage d'adresses IP, ainsi que les liaisons d'interface réseau virtuelle. Deuxièmement, l’utilisation d’une conception monolithique implémentée sous la forme d’une application écrite en C# rendait difficile l’incorporation de normes et de fonctionnalités dans des bibliothèques écrites pour différents langages dans un seul processus. En particulier, les protocoles ICE, STUN et TURN [23], [24] pour la traversée NAT n'étaient pas pris en charge, ainsi que la sécurité de la couche transport. Troisièmement, la conception ne prévoyait pas de mécanisme permettant d’authentifier les pairs dans la superposition. Quatrièmement, les règles de transfert de paquets et de manipulation des en-têtes, telles que le mappage IP, ont été implémentées dans le nœud monolithique, empêchant ainsi leur modification sans investissement important dans le code. Ces lacunes ont été progressivement corrigées dans les mises en œuvre ultérieures de l'IPOP, comme décrit dans les sections suivantes.
4. Découplage de la découverte des points de terminaison de la superposition
Pour aborder les complexités de l'adhésion à la superposition, de la découverte des points de terminaison et des liens d'amorçage - qui découlent de sa conception initiale - le 2\(^{\mathrm{nd}}\) La génération IPOP [12] a introduit un processus de signalisation dépendant des réseaux sociaux en ligne (OSN). Chaque hôte d'une superposition est représenté et identifié par une identité OSN (ONSI) qui existe sur un serveur OSN. L'ONSI conserve la notion de réseau social (c'est-à-dire sa liste privée d'amis) qui correspond aux hôtes pairs qui participent à sa superposition.
En utilisant un service de messagerie instantanée conforme à XMPP [25], les problèmes d'adhésion superposée et d'accréditation sont traités en externe par un service qui suit une norme largement utilisée et qui prend en charge l'authentification des comptes d'utilisateurs et l'établissement de relations de confiance entre les utilisateurs. De plus, un service publié élimine le besoin de connaître au préalable les nœuds en ligne pour rejoindre la superposition. La messagerie instantanée permet d'échanger des données d'amorçage utilisées à l'appui d'autres normes établies, par exemple ICE, STUN et TURN. Collectivement, ces modifications dissocient la découverte des points de terminaison et l’amorçage de la connexion de la superposition.
Alors qu'avant cette approche, toute personne disposant du logiciel pouvait rejoindre la superposition globale unique pour tous les participants, les OSN fournissaient désormais le mécanisme nécessaire pour restreindre les participants d'une superposition, puis définir plusieurs superpositions distinctes. Un ONSI est protégé par des informations d'identification qui nécessitent que chaque identité s'authentifie auprès d'un serveur (ou fédération) OSN centralisé avant d'utiliser ses services. Une fois authentifié, l'OSNI découvre sa liste d'amis qu'il interprète comme une indication de connaissance directe et de confiance mutuelle. Les amis sont donc utilisés pour identifier les points de terminaison du réseau éligibles pour participer au réseau superposé. À cet égard, le réseau superposé est la réalisation des relations sociales d'un individu. La vision des relations sociales dans cette approche est prise au sens large : d'une part, elles peuvent être mappées à des ressources appartenant à plusieurs individus connectés par un réseau social, tandis que d'autre part, elles peuvent être mappées à des ressources gérées par un seul (ou fédéré) domaine administratif avec des relations de confiance capturant l'adhésion dans une superposition.
Lorsqu'un OSNI se connecte, un message de présence est diffusé à tous ses amis disponibles. Cette conscience de présence est utilisée pour déclencher le processus de négociation des liens entre pairs. L'établissement de liens homologues à l'aide d'ICE nécessite que chaque nœud découvre et partage les données des points de terminaison avec son homologue, ce qui doit se produire avant qu'un canal de communication entre les homologues ne soit établi. La fonction de messagerie instantanée de l'OSN est utilisée pour échanger des messages indiquant l'intention de créer un canal P2P ainsi que pour échanger les données d'amorçage nécessaires entre pairs. Ces données incluent l'UUID homologue, les empreintes digitales du certificat et les points de terminaison de l'adresse réseau qui seront finalement utilisés pour créer toutes les installations du tunnel.
5. Découplage du contrôle du chemin de données
Une autre amélioration introduite dans 2\(^{\mathrm{nd}}\) La génération IPOP était la séparation des préoccupations entre le contrôle et le chemin de données. Plutôt que le processus monolithique de sa mise en œuvre initiale, à partir de [12], l'IPOP a adopté une conception modulaire inspirée du SDN des composants du contrôleur et du chemin de données.
Le chemin de données IPOP (Tincan) s'appuie sur WebRTC [26], [27] pour créer ses liens de communication. WebRTC est un standard ouvert et un effort de l'industrie visant à permettre une communication multimédia directe et en temps réel entre les navigateurs. Tincan utilise les bibliothèques C++ natives WebRTC pour les canaux de données qui constituent le lien virtuel entre pairs. Ces liens virtuels utilisent des connexions directes, réflexives ou relais. Une connexion directe se produit lorsque deux nœuds ont des points de terminaison routables utilisant leur adresse IP locale (par exemple au sein d'un réseau local) ; les connexions réflexives se produisent lorsque les nœuds se trouvent derrière des NAT de type cône qui se prêtent à une traversée basée sur STUN ; les connexions relais se produisent lorsqu'un serveur intermédiaire est nécessaire pour échanger des messages. Tincan gère également l'interaction IO entre la VNIC et le lien virtuel. Les trames Ethernet lues à partir de la VNIC sont cryptées à l'aide de DTLS, encapsulées sous forme de charge utile d'un datagramme IP et transmises sur la liaison. À l’inverse, les messages entrants sont débarrassés des en-têtes UDP, déchiffrés et écrits sur la VNIC.
La solution 3\(^{\mathrm{rd}}\) Le contrôleur IPOP de génération utilise un cadre modulaire qui sépare le cadre d'application des modules qui implémentent des fonctionnalités spécifiques [14]. La structure du contrôleur charge et initialise une liste paramétrée de modules au démarrage, fournissant ainsi un service de messagerie asynchrone basé sur des tâches pour les communications inter-modules. L’abstraction Controller Brokered Task (CBT) est utilisée à cette fin ; il s'agit d'une structure autonome qui décrit entièrement la tâche tout au long de sa durée de vie, y compris tous les détails relatifs à sa demande et à sa réponse. Un CBT est créé par un module, soumis au framework et livré à la file d'attente de travail des modules destinataires. Lorsque la tâche demandée est terminée, le CBT est renvoyé à l'initiateur via le framework.
Un module de contrôle est un composant ayant un rôle spécifique à l'application au sein du contrôleur IPOP. En implémentant une interface définie par un framework, les modules peuvent être chargés et initialisés, envoyés des CBT pour traitement et invoqués à intervalles périodiques. Des modules peuvent être créés dans n'importe quel but pour étendre les capacités du contrôleur IPOP. Quelques modules de base incluent la signalisation, la négociation et la création de liens, la définition de la topologie et les rapports d'état.
Le module de signalisation exploite XMPP pour annoncer la présence, indiquer l'intention et échanger des données d'amorçage de connexion. Lors de la connexion et à intervalles périodiques, un nœud diffuse un message de présence à tous les pairs de sa liste d'amis indiquant sa disponibilité pour un canal de communication. Ce module traite les requêtes qui nécessitent une communication homologue sur la bande XMMP.
Le module de gestion des liens gère les tunnels entre pairs, reflétant la notion de couche liaison entre deux appareils en réseau. Il crée, entretient et détruit des tunnels en tant que service pour d'autres modules et utilise le module de signal pour indiquer l'intention de créer un lien ainsi que pour échanger les données d'amorçage du lien. De plus, il suit la VNIC et la liaison pour chaque tunnel et demande au chemin de données de les créer – en coordonnant en tant qu'intermédiaire la prise de contact d'échange CAS entre les plans de données local et homologue.
Le module de topologie détermine l'emplacement des tunnels et leur durée. Il utilise les services de gestion de liens pour la création de tunnels individuels et orchestre la participation du nœud local à la construction de la structure globale. L'implémentation de 4ème génération est une topologie P2P structurée basée sur un anneau successeur avec des chemins de raccourci.
La surveillance de l'état de la superposition est réalisée par un travail coopératif entre les module de reporting et l'autre contrôleur. Les modules participants soumettent périodiquement leur état respectif au module de reporting qui regroupe les données dans une représentation à l'échelle du nœud. Les données des nœuds sont envoyées à un service Web collecteur central qui regroupe les données des nœuds dans une vue globale englobant toutes les superpositions signalées et leurs nœuds respectifs.
6. Commutation définie par logiciel
Dans sa 4\(^{\mathrm{th}}\) génération, IPOP est passé d'un réseau virtuel de couche 3 à un réseau virtuel de couche 2 et a implémenté un contrôleur OpenFlow SDN. Cela permet à IPOP de prendre en charge des protocoles de diffusion/multidiffusion autres qu'IP (par exemple ARP), des adresses IP relocalisables et une plus grande variété d'applications. De plus, la prise en charge de l'API OpenFlow et des commutateurs logiciels basés sur SDN ouvre la superposition virtualisée à une variété d'implémentations de réseau possibles.
IPOP virtualise un domaine de diffusion de couche 2 via le périphérique TAP du système local ou un pont logiciel OpenFlow, et en tunnelant les trames Ethernet. La structure en anneau avec des liens de raccourci fournit plusieurs chemins redondants entre les commutateurs réseau dans la superposition. S'ils sont utilisés, ces liens fournissent des chemins alternatifs pour éviter les goulots d'étranglement des E/S et la résilience contre les pannes de liaison. Cependant, la commutation Ethernet typique ne prend pas en charge une topologie avec des cycles, et une défaillance du réseau due à des tempêtes de diffusion se produit si les cycles ne sont pas désactivés. Des approches telles que le Spanning Tree Protocol (STP) sont utilisées dans les réseaux Ethernet locaux pour désactiver sélectivement les liaisons et construire un arbre couvrant sans cycle. Malheureusement, cette approche ignore les liens fonctionnels qui pourraient autrement être utilisés comme chemins alternatifs entre des paires d'hôtes communicants. Pour résoudre les problèmes liés aux chemins cycliques tout en conservant les avantages fonctionnels des liaisons multiples, un protocole de commutation compatible OpenFlow, appelé Bounded Flooding, a été conçu et implémenté pour les topologies P2P structurées dans IPOP.
Chaque nœud IPOP instancie deux composants de contrôleur : un contrôleur IPOP et un module de contrôleur OpenFlow – produisant un système décentralisé. Le contrôleur IPOP crée et maintient la topologie tandis que le contrôleur OpenFlow programme les règles de commutation. La fonctionnalité du contrôleur OpenFlow dépend de la topologie et s'appuie sur les informations structurelles interrogées auprès du contrôleur IPOP, telles que la liste de contiguïté du nœud. Il est conçu pour être évolutif depuis des superpositions avec deux nœuds jusqu'à des milliers de nœuds.
La topologie IPOP est un anneau de successeurs avec des identifiants croissants dans le sens des aiguilles d'une montre et des arcs de liens de raccourci. Chaque nœud de commutation exécutant IPOP se voit attribuer un UUID, et chaque nœud a la responsabilité d'identifier son voisin le plus proche (le prochain UUID plus grand) et de construire un lien successeur entre eux ; un nœud peut sélectionner plus d'un successeur pour sa résilience contre les interruptions dues au désabonnement. Ce processus se poursuit avec chaque nœud jusqu'à ce que l'anneau soit terminé. Le nombre de nœuds dans la superposition est proportionnel au nombre moyen de sauts de commutation pour transmettre les trames dans la superposition et est ensuite utilisé comme mesure de la latence perçue dans la communication. Même si un réseau complet fournirait un coût de commutation constant, cela est irréalisable pour des superpositions comportant plus de dizaines de nœuds. Pour une superposition avec n nœuds, chaque nouveau nœud ajoute \(\left (n-1\right )\) bords pour un total \(n(n-1)/2\) bords. Comme chaque tunnel entraîne un coût de communication continu tout au long de sa durée de vie, cette approche n'est pas adaptée à mesure que les données de maintenance commencent à saturer le réseau.
Des liens de raccourci peuvent être utilisés pour limiter la latence moyenne, et en utilisant \(\mathit{\log }_{2} \left (n\right )\) les liens par nœud fournissent une limite équivalente [19]. Pour choisir un homologue approprié pour les liens de raccourci, l'algorithme de sélection Symphony Long Distance Links [20] est utilisé. La superposition est paramétrée pour régler les compromis entre le degré de nœud et la latence, et chaque nœud peut être configuré indépendamment.
Les données de topologie fournies par le contrôleur IPOP sont utilisées pour faire la distinction entre les ponts homologues et les périphériques feuilles directement connectés, et pour associer les périphériques feuilles à leur pont racine respectif. La connaissance du pont racine d'un périphérique est nécessaire pour créer des tunnels à la demande qui constituent un mécanisme permettant d'éliminer les sauts de commutation supplémentaires entre des périphériques feuilles communiquant activement.
Le contrôleur OpenFlow implémente le nouveau protocole d'inondation limitée, qui est fondamental pour construire sa table d'apprentissage (un mappage de l'adresse MAC source observée et des ports d'entrée associés) et par la suite pour programmer les règles de flux du plan de données. Chaque fois qu'une diffusion est nécessaire, un Flooding Route and Bound (FRB) est utilisé pour inonder avidement tous ses ports homologues, c'est-à-dire les ports de sortie qui se connectent à un autre pont. FRB est un protocole de couche Ethernet personnalisé implémenté et utilisé par la commutation IPOP SDN pour effectuer des diffusions de couche liaison dans des structures à commutation cyclique dynamique. Le FRB préfixe la diffusion originale avec un en-tête décrivant le pont racine et la limite du message. Le pont racine est le commutateur qui gère le périphérique qui a lancé la diffusion. La limite d'inondation est un intervalle fermé-ouvert \([i,j)\), en précisant le destinataire i, et le nœud le plus éloigné j, le message doit être transmis. Les destinataires sont des pairs adjacents et chaque limite peut potentiellement différer. À la réception d'un FRB, un nœud délivrera la charge utile sur ses ports feuilles gérés, déterminera si des ponts homologues adjacents se trouvent dans la limite du message, recalculera et mettra à jour la limite si nécessaire, et retransmettra le message. La retransmission d'un FRB s'effectue dans le sens des aiguilles d'une montre autour de l'anneau sur les bords successeurs et raccourcis. Cette approche garantit que les diffusions ne sont jamais dupliquées, sont diffusées sur tous les appareils de la superposition et finissent par se terminer. Au fur et à mesure que les FRB se propagent dans la superposition, ils sont suivis au niveau de chaque nœud et utilisés pour mettre à jour sa table d'apprentissage locale. Ces informations fournissent collectivement une route de retour à travers la superposition jusqu'à l'initiateur FRB. De plus, un FRB est utilisé pour échanger les périphériques feuilles gérés contre un commutateur avec son homologue.
7. Discussion
7.1 Travaux connexes
Deux approches liées aux réseaux superposés virtualisés sont VIOLIN [28] et VNET/P [29]. VIOLIN utilise un modèle virtualisé couche 2/couche 3 (Ethernet/IP) et tous les composants – vHost, vNic, vSwitch et vRouter – sont virtualisés. L'objectif de VIOLIN est d'isoler le vHost au sein de la superposition de l'Internet public. Cette approche permet d'orchestrer l'ensemble du réseau par logiciel, mais elle ne dispose d'aucun mécanisme d'identification des pairs, d'authentification de l'adhésion à la superposition, de planification topologique ou de traversée NAT – tous ces éléments étant nécessaires à la gestion dynamique. De plus, en l'absence de routes de commutation programmables, une commutation standard de couche 2 (apprentissage MAC) est implicite ; de plus, les routes IP doivent être configurées manuellement sur chaque vHost. En comparaison, il est moins évolutif car chaque domaine de couche 2 doit être un arbre couvrant, ce qui entraîne des goulots d'étranglement au niveau des liens de superposition à fort conflit. La spécification manuelle de la topologie, des règles de commutation et de routage entraîne des délais de déploiement et de reconfiguration plus longs. Bien que les canaux de communication soient cryptés, n'importe quel hôte disposant de la liste de pairs superposés peut se joindre.
VNET/P présente un réseau de couche 2 adapté aux charges de travail HPC étroitement couplées. Il implémente son noyau de commutation dans l'hyperviseur Palacios et un pont de tunneling dans le noyau hôte. La topologie de superposition, les nœuds et les routes de commutation sont définis dans un fichier de configuration statique qui est généré et validé par un outil de gestion centralisé distinct avec une vue globale du réseau. La configuration doit être régénérée pour refléter toute modification et réappliquée aux hôtes concernés. VNET/P prend également en charge les canaux de communication cryptés mais aucune méthode d'authentification pour l'adhésion par les pairs. Ces propriétés entraînent des superpositions moins évolutives, ouvertes à tout hôte disposant de la liste d'homologues, et des temps de réponse accrus aux modifications apportées à la superposition par rapport à Bounded Flood.
7.2 Architecture P2P
Bien que les schémas P2P non structurés et structurés aient leurs avantages et inconvénients respectifs [30], les propriétés P2P structurées inhérentes à Symphony sont particulièrement bénéfiques pour l'IPOP. Plus précisément, il s'agit de la décentralisation, de la topologie, des paramètres du système, des performances et de l'état du routage et de la résilience. Étant décentralisé, le système est hautement évolutif et prend en charge de très grands réseaux. Sa topologie est simple à créer et à maintenir dans des déploiements réalistes, même dans des systèmes à taux de désabonnement fréquent où les nœuds ont une durée de vie courte. Les paramètres système, ceux qui influencent de manière significative les caractéristiques du système, sont principalement le nombre de nœuds dans l'overlay et le nombre de liens par nœud, k. De plus, chaque nœud du système peut être configuré indépendamment. Les coûts de routage et d'état sont limités en fonction des paramètres du système et à des limites qui se prêtent à des déploiements à grande échelle. Le coût du routage est pour Symphony \(1/k log(n)\), et son état varie selon k. Il s’agit d’un système résilient tel que la défaillance d’un nœud n’entraînera pas de défaillance durable à l’échelle du réseau. De plus, la superposition peut tolérer jusqu'à f échecs de nœuds sans partitionnement à l'aide de \(s=f\) liens successeurs par nœud.
8. Exemples de cas d'utilisation
PerSoNet [31] s'appuie sur la fonctionnalité virtualisée de couche 2 fournie par IPOP pour créer un réseau VPN à deux couches défini par logiciel pour une collaboration communautaire à la périphérie. La couche personnelle connecte les appareils détenus et gérés par une personne exposant la sémantique OSI Layer-2. Au-dessus, la connectivité entre les appareils appartenant à différents pairs est assurée en interconnectant les réseaux personnels des individus via des passerelles programmables SDN pour créer un réseau superposé de couche communautaire avec la sémantique OSI Layer-3. PerSoNet résume les complexités impliquées dans la gestion de l'adressage de la couche IP, la gestion des noms d'appareils, le contrôle d'accès et la connectivité en combinant l'interception et le traitement des requêtes DNS ainsi que la programmation réactive de passerelles définies par logiciel pour effectuer la traduction et la commutation d'adresses.
GRAPPIN est une collaboration interdisciplinaire entre informaticiens et modélisateurs de lacs associés à deux réseaux internationaux, GLEON (Global Lake Ecological Observatory Network) et PRAGMA (Pacific Rim Applications and Grid Middleware Assembly). Le principal produit logiciel de la collaboration GRAPLE est GRAPLEr [32]. Bien qu'il soit relativement facile d'exécuter une simulation de modèle de lac sur un ordinateur personnel, il est plus difficile d'exécuter plusieurs simulations, ce qui nécessite des ressources informatiques et humaines supplémentaires. Pour surmonter cette contrainte, GRAPLer, en tant que système informatique distribué, intègre et applique le réseau virtuel de superposition IPOP pour prendre en charge le calcul à haut débit et les technologies de services Web. En utilisant IPOP comme substrat de réseau virtuel, GRAPLEr est capable de réutiliser des logiciels existants non modifiés, y compris le planificateur de tâches HTCondor, et de permettre un ajout simple de ressources via Internet au pool HTCondor. GRAPLer permet de soumettre des centaines ou des milliers de simulations de modèle général de lac (GLM), d'exécuter efficacement ces simulations de modèle de lac et de récupérer les résultats du modèle.
Banc d'essai de réseautage expérimental PRAGMA (PRAGMA-ENT) est un banc d'essai international SDN conçu pour offrir aux chercheurs une totale liberté d'accès aux ressources du réseau pour développer, expérimenter et évaluer de nouvelles idées sans interférer avec un réseau de production. PRAGMA-ENT connecte les commutateurs compatibles OpenFlow dans différentes institutions sur des réseaux à haut débit et construit un banc d'essai de réseau à grande échelle basé sur OpenFlow. Dans ce scénario de cas d'utilisation, IPOP a été utilisé pour étendre le banc d'essai avec une superposition définie par logiciel, afin d'activer les sites qui ne disposent pas de commutateurs compatibles OpenFlow ni de connexion directe au backbone de PRAGMA-ENT. Grâce à IPOP, chaque utilisateur final peut déployer un réseau d'accès entre ses ressources et le point de terminaison PRAGMA-ENT le plus proche. Cette approche fonctionne efficacement pour les utilisateurs finaux qui ont simplement besoin de connecter temporairement leurs ressources à PRAGMA-ENT pour leurs expériences.
9.Conclusion
Nous avons retracé l'évolution d'IPOP depuis ses origines P2P à Brunet jusqu'à sa mise en œuvre hybride actuelle, montrant comment les besoins spécifiques d'un système réel ont entraîné des changements de conception pragmatiques à chaque étape. Ces changements permettent à l'IPOP de combler une lacune dans les technologies émergentes et d'intégrer de manière transparente les applications existantes. Nous avons également illustré des systèmes du monde réel qui utilisent les capacités d'IPOP, démontrant ainsi ses applications pratiques.
La génération 1 a virtualisé un réseau de couche 3 grâce à l'intégration d'hôtes VNIC et au tunneling des paquets IP au sein d'UDP/IP. Il s'agissait d'une superposition entièrement décentralisée, utilisant la bibliothèque Brunet. L'architecture reflétait un processus monolithique qui incorporait tous les services d'amorçage et de transfert de paquets, ce qui rendait difficile l'interopérabilité avec les normes ouvertes. La superposition globale utilisait des identifiants d'espace de noms et un magasin DHT pour fournir une portée au sous-réseau IP. Rejoindre la superposition nécessitait une liste de pairs et utilisait des liens de superposition pour transporter les messages d'amorçage, et il n'y avait aucune prise en charge de l'authentification ou du cryptage.
La génération 2 a introduit les OSN pour découpler la découverte des points de terminaison de la superposition et a introduit un modèle client-serveur pour l'amorçage. Bien qu'il ne s'agisse plus d'un modèle P2P pur, l'utilisation d'un serveur OSN publié et de relations amicales a facilité les superpositions indépendantes, simplifié le démarrage et renforcé l'authentification pour l'adhésion. Le processus monolithique a été séparé en un plan de contrôle et de données et des normes telles que ICE, STUN, TURN ont été adoptées. Quitter la bibliothèque Brunet signifiait perdre la structure Symphony ; pour tenir compte de cela, des liens ont été créés avec tous les amis et un mappage IP effectué entre eux. Une approche inspirée du SDN a été adoptée, qui divise l'IPOP en processus de contrôleur et de plan de données. Cependant, la granularité grossière des composants architecturaux rendait toujours difficile la maintenance et les améliorations du code.
La génération 3 a résolu les problèmes architecturaux en introduisant le cadre d'application du contrôleur. Le contrôleur utilisait des composants modulaires axés sur la topologie, la gestion des liaisons et la signalisation. Les améliorations apportées au plan de données ont pris en charge plusieurs superpositions de couche 2 simultanées et isolées au sein d'un seul processus.
La génération 4 a réintroduit la topologie en anneau structuré Symphony, implémentée dans un module contrôleur IPOP. Pour fournir les routes de commutation pour la topologie spécialisée, un module Ryu/OpenFlow implémentant Bounded Flood est utilisé. Les algorithmes pour la topologie et les règles de commutation ont été conçus pour être paramétrés et évolutifs pour fonctionner sur des réseaux allant de deux nœuds à des centaines de nœuds.
Références
[1] P. Srisuresh and K. Egevang, “Traditional IP network address translator (traditional NAT),” 2000. [Online]. Available: https://www.rfc-editor.org/info/rfc3022. [Accessed: 13-Jun-2019].
URL
[2] E. Rescorla, “The transport layer security (TLS) protocol version 1.3,” 2018. [Online]. Available: https://www.rfc-editor.org/info/rfc8446. [Accessed: 13-Jun-2019].
URL
[3] E. Rescorla and N. Modadugu, “Datagram transport layer security version 1.2,” 2012. [Online]. Available: https://www.rfc-editor.org/info/rfc6347. [Accessed: 13-Jun-2019].
URL
[4] A. Yousefpour, C. Fung, T. Nguyen, K. Kadiyala, F. Jalali, A. Niakanlahiji, J. Kong, and J.P. Jue, “All one needs to know about fog computing and related edge computing paradigms: A complete survey,” J. Syst. Architect., vol.98, pp.289–330, Feb. 2019.
CrossRef
[5] N. Bessis and C. Dobre, eds., Big Data and Internet of Things: A Roadmap for Smart Environments, vol.546, Springer International Publishing, Cham, 2014.
CrossRef
[6] H. Chang, A. Hari, S. Mukherjee, and T.V. Lakshman, “Bringing the cloud to the edge,” 2014 IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), pp.346–351, 2014.
CrossRef
[7] Y. Guan, J. Shao, G. Wei, and M. Xie, “Data security and privacy in fog computing,” IEEE Netw., vol.32, no.5, pp.106–111, Sept. 2018.
CrossRef
[8] D. Andersen, H. Balakrishnan, F. Kaashoek, and R. Morris, “Resilient overlay networks,” Proc. Eighteenth ACM Symposium on Operating Systems Principles, pp.131–145, New York, NY, USA, 2001.
CrossRef
[9] H. Eriksson, “MBONE: The multicast backbone,” Commun. ACM, vol.37, no.8, pp.54–60, Aug. 1994.
CrossRef
[10] A. Ganguly, A. Agrawal, P.O. Boykin, and R. Figueiredo, “IP over P2P: Enabling self-configuring virtual IP networks for grid computing,” Proc. 20th IEEE International Parallel Distributed Processing Symposium, p.10, 2006.
CrossRef
[11] D.I. Wolinsky, Y. Liu, P.S. Juste, G. Venkatasubramanian, and R. Figueiredo, “On the design of scalable, self-configuring virtual networks,” Proc. Conference on High Performance Computing Networking, Storage and Analysis, pp.1–12, 2009.
CrossRef
[12] P.S. Juste, K. Jeong, H. Eom, C. Baker, and R. Figueiredo, “TinCan: User-defined P2P virtual network overlays for ad-hoc collaboration,” EAI Endorsed Trans. Collab. Comput., vol.1, no.2, p.15, Oct. 2014.
CrossRef
[13] K. Subratie and R. Figueiredo, “Towards island networks: SDN-enabled virtual private networks with peer-to-peer overlay links for edge computing,” Internet and Distributed Computing Systems, pp.122–133, 2018.
CrossRef
[14] K. Subratie, S. Aditya, S. Sabogal, T. Theegala, and R. Figueiredo, “Towards dynamic, isolated work-groups for distributed iot and cloud systems with peer-to-peer virtual private networks,” Sensors to Cloud Architectures Workshop (SCAW-2017), Austin, Texas, USA, 2017.
[15] ACIS, “IP Over P2P Virtual Private Network,” IPOP VPN, 2006. [Online]. Available: http://ipop-project.org/. [Accessed: 20-Mar-2015].
URL
[16] C. Pahl, S. Helmer, L. Miori, J. Sanin, and B. Lee, “A container-based edge cloud PaaS architecture based on raspberry Pi clusters,” 2016 IEEE 4th International Conference on Future Internet of Things and Cloud Workshops (FiCloudW), pp.117–124, 2016.
CrossRef
[17] C. Chen, C. Liu, P. Liu, B.T. Loo, and L. Ding, “A scalable multi-datacenter layer-2 network architecture,” Proc. 1st ACM SIGCOMM Symposium on Software Defined Networking Research, pp.8:1–8:12, New York, NY, USA, 2015.
CrossRef
[18] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner, “OpenFlow: Enabling innovation in campus networks,” SIGCOMM Comput. Commun. Rev., vol.38, no.2, pp.69–74, March 2008.
CrossRef
[19] I. Stoica, R. Morris, D. Liben-Nowell, D.R. Karger, M.F. Kaashoek, F. Dabek, and H. Balakrishnan, “Chord: A scalable peer-to-peer lookup protocol for internet applications,” IEEE/ACM Trans Netw., vol.11, no.1, pp.17–32, Feb. 2003.
CrossRef
[20] G.S. Manku, M. Bawa, and P. Raghavan, “Symphony: Distributed hashing in a small world,” Proc. 4th Conference on USENIX Symposium on Internet Technologies and Systems, vol.4, p.10, Berkeley, CA, USA, 2003.
[21] P.O. Boykin, J.S.A. Bridgewater, J.S. Kong, K.M. Lozev, B.A. Rezaei, and V.P. Roychowdhury, “A symphony conducted by Brunet,” ArXiv:0709.4048 Cs, Sept. 2007.
URL
[22] A. Ganguly, D. Wolinsky, P.O. Boykin, and R. Figueiredo, “Decentralized dynamic host configuration in wide-area overlays of virtual workstations,” 2007 IEEE International Parallel and Distributed Processing Symposium, pp.1–8, 2007.
CrossRef
[23] J. Rosenberg, “Interactive connectivity establishment (ICE): A protocol for network address translator (NAT) traversal for offer/answer protocols,” 2010. [Online]. Available: https://www.rfc-editor.org/rfc/rfc5245.txt
URL
[24] R. Mahy, P. Matthews, and J. Rosenberg, “Traversal using relays around NAT (TURN): Relay extensions to session traversal utilities for NAT (STUN),” 2010. [Online]. Available: https://www.rfc-editor.org/info/rfc5766. [Accessed: 13-Jun-2019].
URL
[25] E.P. Saint-Andre, “Extensible messaging and presence protocol (XMPP): Core,” 2004. [Online]. Available: https://www.rfc-editor.org/info/rfc3920. [Accessed: 13-Jun-2019].
URL
[26] S. Loreto and S.P. Romano, Real-Time Communication with WebRTC: Peer-to-Peer in the Browser, O’Reilly Media, 2014.
[27] “WebRTC 1.0: Real-time Communication Between Browsers.” [Online]. Available: https://w3c.github.io/webrtc-pc/. [Accessed: 29-Jun-2018].
URL
[28] X. Jiang and D. Xu, “VIOLIN: Virtual internetworking on overlay infrastructure,” Parallel and Distributed Processing and Applications, pp.937–946, 2005.
CrossRef
[29] L. Xia, Z. Cui, J.R. Lange, Y. Tang, P.A. Dinda, and P.G. Bridges, “VNET/P: Bridging the cloud and high performance computing through fast overlay networking,” Proc. 21st International Symposium on High-Performance Parallel and Distributed Computing, pp.259–270, New York, NY, USA, 2012.
CrossRef
[30] E.K. Lua, J. Crowcroft, M. Pias, R. Sharma, and S. Lim, “A survey and comparison of peer-to-peer overlay network schemes,” IEEE Commun. Surveys Tuts., vol.7, no.2, pp.72–93, Second Quarter 2005.
CrossRef
[31] S. Aditya, K. Subratie, and R.J. Figueiredo, “PerSoNet: Software-defined overlay virtual networks spanning personal devices across social network users,” 2018 IEEE International Conference on Cloud Computing Technology and Science (CloudCom), pp.171–180, 2018.
CrossRef
[32] K.C. Subratie, S. Aditya, S. Mahesula, R. Figueiredo, C.C. Carey, and P.C. Hanson, “GRAPLEr: A distributed collaborative environment for lake ecosystem modeling that integrates overlay networks, high-throughput computing, and WEB services,” Concurr. Comput. Pract. Exp., vol.29, no.13, p.e4139, 2017.
CrossRef