Location à la demande et élastiques de ressources virtuelles 

Télécharger le fichier pdf d’un mémoire de fin d’études

TECHNIQUES DE VIRTUALISATION RESEAU

VIRTUALISATION DES INTERFACES/CARTES RESEAU

La virtualisation des interfaces réseau est une brique de base de la virtualisation des machines. Elle vise à partager une interface réseau entre plusieurs machines virtuelles via des interfaces réseau virtuelles. Plusieurs solutions de virtualisation des interfaces existent et sont poussées par les principaux acteurs industriels de la virtualisation des serveurs (tels que Vmware, Xen, Microsoft, etc.). Elles se distinguent par le niveau de performance et de compatibilité qu’elles permettent et peuvent être classées en deux familles :
• Solutions purement logicielles de virtualisation des interfaces
Elles reposent sur une approche classique dans laquelle l’hyperviseur assure entièrement le rôle d’isolation et de partage de(s) interface(s) physique(s) entre les interfaces virtuelles ainsi que l’acheminement du trafic entre interfaces virtuelles et entre interfaces virtuelles et physiques. Il émule donc le comportement d’un switch auquel sont reliées les interfaces virtuelles et physiques (voir Figure B.2.1) par l’interception et la retraduction des requêtes et commandes d’entrées/sorties ainsi que par des copies de (vers) les zones mémoires des machines virtuelles sources (resp. destinataires). Cela se traduit par un sur-­‐‑débit inhérent à l’activation récurrente de l’hyperviseur pour pouvoir traiter les arrivées/départs de paquets et limite le débit maximal qui peut être atteint [SLF12].
Deux principales approches se distinguent : La première cherche à émuler parfaitement les interfaces physiques ce qui permet d’utiliser au niveau des machines virtuelles les drivers des interfaces physiques sans aucune modification. Le prix à payer se traduit à chaque transmission par une interruption de l’exécution d’une VM pour activer l’hyperviseur qui se charge de la relayer vers l’interface physique. Elle implique également la traversée de deux drivers identiques (de l’interface virtuelle et physique). La deuxième approche nécessite l’emploi d’un driver modifié au niveau des VM qui tient compte du fait que les interfaces sont virtuelles et qui travaille en concert avec l’hyperviseur. Il contrôle notamment plus efficacement le moment où une VM donne la main à l’hyperviseur pour pouvoir relayer ses paquets. Cette activation de l’hyperviseur peut concerner plusieurs transmissions et non pas une seule comme précédemment. Pour des raisons de performances, cette approche, connue sous le nom « para-­‐‑virtualized driver », est la plus courante dans les solutions de virtualisation de machines (Xen, Vmaware et KVM).
• Solutions logicielles assistées par des extensions matérielles pour la virtualisation des interfaces
Ces solutions reposent sur le partitionnement de certaines ressources matérielles (mémoires, files, lignes d’interruptions, etc.) des interfaces réseaux physiques pour permettre aux machines virtuelles d’avoir un accès direct (sans passer systématiquement par l’hyperviseur) au matériel et donc réduire le sur-­‐‑débit des solutions purement logicielles. Elles nécessitent donc des interfaces réseaux avec des spécificités/extensions liées à la virtualisation. Deux principales solutions existent [SLF12] : Virtual Machine Device Queue (VMDQ) [VMDQ09] et Single Root IO virtualization (SR-­‐‑IOV) qui est devenu le standard industriel [SRIOV1]. La première repose sur l’exploitation au niveau de l’interface réseau de plusieurs lignes d’interruptions qui peuvent être associées à des VM différentes notamment pour leur signifier individuellement, sans faire intervenir l’hyperviseur, l’arrivée d’un paquet (la VM étant identifiée sur la base de l’adresse de destination). L’interface est également capable d’effectuer des accès DMA (Direct Memory Access) pour placer le paquet reçu dans la mémoire de la machine hôte. Au traitement de sa demande d’interruption, la VM cède la main à l’hyperviseur pour lui récupérer le paquet. Une interface SR-­‐‑IOV lève cette dernière limite. A l’arrivée d’un paquet, en plus de signifier une demande d’interruption à la VM concernée, elle effectue un accès DMA dans la zone mémoire de celle-­‐‑ci sans intervention de l’hyperviseur.

VIRTUALISATION DES EQUIPEMENTS RESEAU

Plusieurs solutions permettent de faire coexister plusieurs équipements réseaux virtuels sur un même équipement réseau. Elles se distinguent par le modèle d’isolation/partage de ressources adopté ainsi que par les ressources considérées par la virtualisation. Elles exhibent donc des degrés de virtualisation et des niveaux de performances différents. La Figure B.2.2 illustre ce concept de virtualisation d’équipements sur le cas particulier d’un routeur physique qui supporte deux routeurs virtuels RvA et RvB. Chaque routeur virtuel dispose de son propre plan de contrôle avec sa propre instance du protocole de routage, sa propre table de routage/acheminement et son propre plan de données (en charge de l’acheminement des paquets). La représentation des deux routeurs virtuels en deux blocs séparés laisse supposer qu’ils reposent sur des ressources dédiées (CPU et mémoire pour le plan de contrôle, commutation, mémoire, interfaces réseau et liens de transmission pour le plan d’acheminement) obtenus potentiellement par partitionnement. Cet exemple illustre le déploiement d’une solution de virtualisation développée où toutes les ressources physiques sont virtualisées par partitionnement et où chaque équipement virtuel dispose de ses propres instances des fonctions réseau. Toutes les solutions que nous présentons ci-­‐‑après n’exhibent pas ce degré de virtualisation.
Un premier type de solutions de virtualisation des équipements repose sur la virtualisation d’hôtes (ou virtualisation du système opératoire) en permettant de faire coexister plusieurs machines virtuelles (VM) avec leur instance du système opératoire sur le même équipement. Ces VM exécutent ensuite les fonctions réseau assurées par l’équipement virtuel (par exemple : fonctions de routage et fonctions d’acheminement du plan de données). Ces solutions purement logicielles se prêtent bien à des nœuds physiques terminaux où une multitude de solutions de virtualisation d’hôte reconnues existent (VMware, Xen, KVM, etc.). La solution Brocade Vyatta 5400 vrouter [Vrouter14] est un exemple. Elles s’appliquent également à des architectures matérielles plus spécifiques ciblant les équipements réseau avec quelques réserves sur les performances, par exemple les solutions de virtualisation d’Untangle [Untangle12] et Router OS de Mikrotik [RouterOS11].
Un deuxième type de solutions beaucoup plus courant -­‐‑ car disponible sur le marché depuis plusieurs années -­‐‑ se focalise sur la virtualisation d’un élément central des équipements réseau, à savoir la table d’acheminement/routage. Ces solutions connues sous le nom de « Virtual Routing and Forwarding » (VRF) permettent d’offrir plusieurs instances séparées de la table d’acheminement/routage, i.e. le nœud virtuel dispose de sa propre table. Le partage et surtout l’isolation entre nœuds virtuels des ressources nécessaires à l’acheminement et au routage demeurent basiques. D’ailleurs, certaines solutions utilisent un seul processus de routage pour alimenter les différentes tables d’acheminement des nœuds virtuels. D’autres, en revanche, offrent des instances de processus de routage propres à chaque nœud virtuel.
Un dernier type de solutions qui concernent les équipements réseaux les plus performants repose sur une isolation et un partitionnement de ressources par hardware et non par logiciel comme les solutions décrites ci-­‐‑avant [HVR12].

VIRTUALISATION DES LIENS

La virtualisation des liens est une pratique très ancienne et très courante dans les réseaux qu’ils soient informatiques ou de transmission. Pour cette raison, nous ne l’aborderons que de manière très synthétique. Le composant de base de la virtualisation des liens est la virtualisation de la ressource de transmission matérialisée par la capacité de transmission d’un lien physique (i.e. débit). Cette dernière est mise en œuvre par les techniques de multiplexage ou d’accès multiple selon le type de lien considéré (point-­‐‑à-­‐‑point ou multipoints). Selon l’algorithme d’ordonnancement ou la technique d’accès multiple utilisés différents niveaux d’isolation/partitionnement de ressources peuvent être obtenus. La virtualisation des ressources de transmission peut également impliquer l’agrégation de plusieurs liens physiques en un seul lien logique, pratique courante dans un contexte LAN (Local Area Network) avec les techniques d’agrégation des liens Ethernet dont celles basées sur le protocole LACP (Link Aggregation Control Protocol) de l’IEEE.
Un lien virtuel peut reposer sur un voire plusieurs chemins de données (i.e. il peut traverser plusieurs liens physiques interconnectés via des équipements réseau). On parle alors de virtualisation du chemin de données dans la mesure où les éléments des chemins de données (liens physiques et équipements réseau) sont partagés entre plusieurs liens virtuels. La virtualisation du chemin de données repose sur l’une ou l’autre des techniques suivantes :
• Une isolation des liens virtuels basée sur l’intégration de labels dans les paquets qui sont utilisés par les équipements réseau pour l’acheminement. Plusieurs technologies rentrent dans ce cadre : MPLS, ATM et Frame-­‐‑Relay et l’utilisation des labels 802.1Q dans le contexte LAN Ethernet.
• Une isolation basée sur des techniques de tunneling avec l’encapsulation d’un paquet dans un autre, l’en-­‐‑tête externe servant à l’acheminement et comme moyen d’isolation entre liens virtuels. Plusieurs protocoles de tunneling sont utilisés en pratique : IP-­‐‑dans-­‐‑IP, GRE (Generic Routing Encapsulation), tunnels MPLS (i.e. Label Switched Path (LSP)), L2TP (Layer 2 Tunneling Protocol), et plus récemment dans le contexte centre de données : VXLAN (Virtual eXtensible Local Area Networks), NVGRE (Network Virtualization using Generic Routing Encapsulation), STT (Stateless Transport Tunneling Protocol), etc.

ECOSYSTEME DE LA VIRTUALISATION RESEAU

Le concept de virtualisation réseau fait très simplement apparaître deux rôles (chacun en charge d’un certain nombre de fonctionnalités et devant assumer des responsabilités aussi bien technique qu’économiques/d’affaires) : le fournisseur de l’infrastructure physique (ou provider d’infrastructure) et le prestataire de service (provider de service).
Le provider d’infrastructure est responsable de la gestion et l’exploitation de son infrastructure, constituée de ressources physiques telles que les routeurs et les liens qui peuvent être virtualisés en plusieurs ressources virtuelles. Via des interfaces de contrôle offertes à ses clients (dans ce cas de figure, les prestataires de service), il offre la possibilité de mobiliser des ressources virtuelles localisées sur des éléments physiques différents pour leur permettre de constituer et mettre en place un réseau virtuel. Le prestataire de service est également responsable de la configuration, l’exploitation et gestion du réseau virtuel. C’est donc lui qui fixe les fonctions réseau exécutées dans le réseau virtuel. Il est, enfin, responsable de la mise en place des services applicatifs qu’il offre à ses clients. Ce modèle économique à deux rôles est le modèle historique proposé dans [FGR07].
Un second modèle de rôles avec des responsabilités atomiques beaucoup plus fines a été proposé par le projet européen FP7 4WARD [4WARD, SWPF09]. Ce modèle, décrit à Figure B.3.1, introduit quatre rôles différents avec certaines des responsabilités du provider de service renvoyées sur deux nouveaux rôles : le provider de réseaux virtuels et l’opérateur du réseau virtuel. Avec ce nouveau modèle, le provider d’infrastructure détient et gère des ressources réseau physiques qu’il virtualise et met à disposition de providers de réseaux virtuels via une interface de contrôle permettant d’établir des requêtes de ressources virtuelles auprès du provider d’infrastructure. Le provider de réseaux virtuels (VNP-­‐‑Virtual Network Provider) construit un réseau virtuel (ou plus précisément une topologie réseau virtuelle pour insister sur le fait que le réseau virtuel ainsi créé n’est qu’une combinaison de ressources virtuelles élémentaires) en assemblant des ressources virtuelles émanant d’un ou plusieurs providers d’infrastructure. Le réseau virtuel ainsi construit est mis à disposition d’un opérateur de réseau virtuel (VNO-­‐‑Virtual Network Operator) ou d’un autre provider de réseaux virtuels pour construire d’autres réseaux virtuels via une interface de contrôle. Le VNO repose sur la topologie virtuelle construite par le VNP pour mettre en place les fonctionnalités réseau permettant d’offrir le service de connectivité répondant aux besoins du provider de services (en termes de QdS, sécurité, etc.). Sur cette topologie virtuelle et via une interface (par exemple, type console), il instancie une architecture réseau au niveau du réseau virtuel par des opérations d’installation et de configuration puis assure sa gestion. En d’autres termes, le VNO transforme un assemblage de ressources virtuelles (topologie virtuelle) en un réseau virtuel opérationnel répondant aux attentes du provider de service. Le provider de service utilise un réseau virtuel opérationnel et customisé à ses besoins pour offrir ses services applicatifs à ses usagers.
Les deux nouveaux rôles introduits par le modèle 4ward permettent au provider de services de s’affranchir des responsabilités liées à l’assemblage de ressources virtuelles qui peuvent pour des raisons de localisation ou de capacité appartenir à plusieurs providers d’infrastructure. Le rôle du VNP est d’orchestrer les demandes de ressources virtuelles pour le compte du provider de service. Indépendamment de l’origine des ressources virtuelles, il est l’unique interlocuteur pour déployer une topologie virtuelle aussi complexe soit-­‐‑elle. Le VNO permet au provider de service de déléguer ou d‘externaliser l’exploitation et la gestion de son réseau virtuel pour lui permettre de centrer ses responsabilités sur la partie service.
Cette décomposition en rôles permet de délimiter les responsabilités. Un acteur économique peut endosser un rôle ou même combiner plusieurs rôles en même temps. C’est notamment le cas actuellement avec plusieurs prestataires endossant le rôle de provider d’infrastructure et de réseaux virtuels en relations économiques avec des opérateurs virtuels.

EXEMPLES D’APPLICATION DE LA VIRTUALISATION RESEAU

D ‘une manière générale et sans considérer des cas d’application spécifiques, la virtualisation réseau offre un certain nombre d’avantages :
• Pour le provider d’infrastructure, le moyen de mutualiser ses ressources et aller vers une utilisation optimale des ressources. Cela permet de rentabiliser ses coûts d’investissements et d’exploitation. Cet avantage est également valable pour un provider de réseaux virtuels qui à son tour peut partitionner ses ressources virtuelles et les partager entre plusieurs clients.
• Pour un client utilisateur d’un réseau virtuel, les avantages se traduisent par une simplification de la gestion du réseau et également par les possibilités de personnalisation du réseau virtuel qui lui est offert.
Plusieurs applications de la virtualisation réseau existent déjà sur le marché depuis plusieurs années. Nous nous focalisons dans la suite sur les scénarios d’application qui émergent et dont certains sont à l’origine des évolutions récentes de la virtualisation réseau (vers le « tout virtualisé », l’élasticité, etc.).

SUPPORT DE SERVICES DIVERSIFIES / RESEAUX VIRTUELS SPECIFIQUES AUX SERVICES

Il est actuellement admis que les solutions incrémentales bâties sur l’architecture TCP/IP ne peuvent constituer une réponse au support de la multitude et la diversité des services actuels et à venir [ITU12]. Certains services reposeront sur des architectures de communication complétement différentes de l’architecture TCP/IP et devront coexister avec celle-­‐‑ci. La virtualisation réseau joue le rôle d’un catalyseur pour permettre le support efficace de ces architectures et services dans la mesure où elle permet d’instancier plusieurs réseaux virtuels (chacun avec son architecture de communication et offrant un service spécifique) sur une même infrastructure physique. Cela évite la prolifération de réseaux spécialisés avec les coûts d’investissement et d’opération associés.
Plusieurs services actuels avec des besoins très spécifiques et qui ne peuvent se satisfaire des possibilités de l’Internet reposent sur l’utilisation de réseaux overlay applicatifs avec potentiellement des piles protocolaires spécifiques au niveau des routeurs overlay mais reliés via l’Internet avec peu de contrôle sur les liens virtuels qui les relient (se référer à Figure B.1.2) Ce cas d’application se distingue des solutions actuelles par le fait que la virtualisation et les architectures de communication peuvent toucher tous les nœuds réseau et pas uniquement des nœuds d’extrémité (Cela ouvre le champ à plus de possibilités et notamment au niveau des services offerts).

SUPPORT DE RESEAUX PLURI-GENERATIONNELS

Ce scénario est un cas particulier du cas d‘application décrit dans la section précédente. L’idée est de se baser sur la virtualisation réseau pour pouvoir faire cohabiter sur une même infrastructure réseau plusieurs générations ou évolutions d’une même technologie réseau. A titre d’exemple, une même infrastructure réseaux cellulaire (ou une partie de celle-­‐‑ci) peut être utilisée pour supporter en même temps plusieurs des technologies réseaux cellulaires (2G, 3G, 4G, ..) qui se sont multipliées ces dernières années.

MIGRATION DE SERVICES APPLICATIFS

La virtualisation des serveurs et d’hôtes se généralise particulièrement au niveau des centres de données. Certains composants d’une application (notamment des serveurs applicatifs) peuvent résider sur des machines virtuelles ce qui peut permettre d’envisager la possibilité de les faire migrer d’une localisation physique (machine) vers une autre. Cette migration du composant applicatif peut être motivée par des politiques propres au provider de l’application (gestion de ses ressources) et/ou par souci d’améliorer l’expérience utilisateur (Quality of Experience (QoE)) en rapprochant le composant (la machine virtuelle associée) de ce dernier. A titre d’exemple, un provider de jeux en réseau pour usagers mobiles peut décider de faire migrer la localisation d’un serveur de jeu pour se rapprocher d’un groupe d’usagers qui se sont déplacés vers une zone donnée pour suivre un événement sportif, culturel etc. Cette migration permet d’améliorer la qualité de l’accès au service (délais plus faibles) et donc la QoE des usagers et potentiellement réduire les coûts des communications. La flexibilité portée par les évolutions récentes de la virtualisation réseau permet une reconfiguration à la volée du réseau virtuel support du service applicatif pour répondre efficacement, tout en respectant des exigences de performances prédéfinies, à la mobilité de certains composants applicatifs. Cela introduit une certaine flexibilité au niveau des providers de service.

EXPERIMENTATION/TEST A GRANDE ECHELLE SUR RESEAUX OPERATIONNELS

Tester et évaluer un nouveau service réseau ou une nouvelle technologie à large échelle et sur un vrai réseau opérationnel est crucial pour un prestataire de service ou un opérateur réseau. De peur d’affecter le fonctionnement d’un réseau en opération, ces expérimentations s’effectuent à petite échelle sur des plateformes réseau dédiées ce qui peut se révéler ne pas être suffisamment représentatif de la réalité lorsque déployés sur un vrai réseau d’opérateur. La virtualisation réseau peut permettre d’effectuer des expérimentations à grande échelle en déployant un réseau virtuel de grande envergure pour ces fins d’expérimentation sur l’infrastructure physique d’un ou plusieurs réseaux opérationnels [GENI06]. De plus, il est possible de customiser les caractéristiques du réseau virtuel et son déploiement selon les besoins des expérimentations.

LOCATION A LA DEMANDE ET ELASTIQUES DE RESSOURCES VIRTUELLES

Un opérateur détenant des ressources (physiques ou virtuelles) peut louer à la demande et de manière élastique une partition de ses ressources. Cela peut concerner des ressources individuelles ou un assemblage de ressources (topologie virtuelle). La location de ressources est une pratique courante entre opérateurs qu’ils soient virtuels ou pas. Elle concerne très souvent les liens virtuels, ne peut être établi à la demande et n’est pas élastique. Ce scénario d’application cherche à répondre à ces limites en ouvrant les ressources aux équipements réseau, et en permettant que les ressources soient louées à la demande et de manière élastique. Cela inclut par exemple l’établissement à la demande d’un lien avec une de la bande passante élastique (Bandwidth on demand). Ce cas qui relève du « cloud networking » sera repris et détaillé ci-­‐‑après dans la section relative à ce thème.

VIRTUAL NETWORKS AS A SERVICE

Ce cas d’application correspond à la situation où similairement aux usages qui prévalent dans le contexte du « cloud computing » et de l’« IaaS », l’on fournisse à un utilisateur suite à sa demande un réseau virtuel complet répondant exactement à ses besoins qui peuvent évoluer dans le temps. L’usager a la possibilité de configurer, gérer son réseau virtuel pour répondre à ses besoins. Plusieurs sous-­‐‑cas d’application ont été proposés dans ce sens et concernent différents types de réseaux dont les réseaux IP, les réseaux mobiles, etc. Ces cas relèvent du « cloud networking »et seront donc repris et détaillés ci-­‐‑après.

AGREGATION DES ACCES SANS FIL

Le paysage des technologies réseaux d’accès sans-­‐‑fil est très hétérogène. Une multitude de technologies (cellulaire, satellitaire, Wi-­‐‑Fi, WiMAx) -­‐‑ avec des caractéristiques spécifiques (en termes de débit, capacité, couverture, etc.) qui les rendent incontournables -­‐‑ existent et continueront à exister sur le marché. Sur une zone prédéfinie, plusieurs types d’accès sans-­‐‑fil peuvent être offerts. Les zones de couverture de ces différents types d’accès peuvent se recouvrir et/ou se compléter. La virtualisation réseau permet aussi bien le partitionnement de ressources réseau que l’agrégation de ressources. Ce cas d’application repose sur ce dernier principe. L’idée est d’agréger les différents réseaux d’accès disponibles sur une zone donnée en un seul réseau d’accès sans-­‐‑fil virtuel. Du point de vue de l’usager, seul le réseau virtuel est visible avec peu ou pas de connaissance sur la ou les technologies réseaux supports. Si les zones de couverture des réseaux d’accès se complètent, la gestion de la mobilité est alors complétement transparente à l’usager et ce même si elle implique un changement du type de réseau d’accès utilisé (mobilité verticale). Si les zones de couverture se recouvrent, cela donne la liberté à l’opérateur de gérer de manière globale ses ressources (des différents types de réseau) tout en respectant les exigences de ses clients (performances, coût, consommation d’énergie,..).

MIGRATION DES SERVICES ET DES FONCTIONS RESEAU

Un nœud d’un réseau virtuel repose sur des ressources virtuelles et exécute un ensemble de fonctions réseau. La virtualisation réseau ouvre la porte à la possibilité de faire migrer à la volée et de manière transparente certaines fonctionnalités réseau d’un nœud physique à un autre. Couplée à la possibilité de reconfigurer à la volée certains liens et nœuds du réseau, la migration des fonctions réseau vient renforcer plusieurs cas d’application de la virtualisation réseau dont :
• Réseaux éco-­‐‑conscients : un opérateur réseau dispose de nouvelles possibilités de gestion de ses ressources. En heures creuses, Il peut décider d’éteindre/libérer certains nœuds après avoir déplacé et concentré leurs fonctionnalités sur un nombre très réduit de nœuds ;
• Réseaux capables de survivre à des désastres : en situation d’un désastre imminent, il est possible de déclencher la migration des fonctions essentielles d’un réseau vers des zones moins exposées tout en reconfigurant certains liens pour continuer à offrir le plus longtemps possible une connectivité minimale dans les endroits sinistrés ;
• Réseaux « self-­‐‑healing » : en réaction à des défaillances de certains éléments d’un réseau, la migration des fonctions peut être utilisée comme moyen de recouvrement.

SOFTWARE-DEFINED NETWORKING C.1 PRINCIPES GENERAUX

Dans un réseau classique, les fonctions de contrôle du réseau et d’acheminement des données sont effectuées au sein des équipements réseau (tels que les routeurs). Cette architecture monolithique est considérée comme un frein et des efforts ont été faits pour définir des architectures cherchant à introduire plus de flexibilité et de simplicité dans la gestion et le contrôle du réseau. La notion de « ʺSoftware-­‐‑Defined Networking »ʺ (SDN) [SDN12] regroupe les architectures visant à séparer l’ʹacheminement des données et son contrôle, principalement en retirant l’ʹintelligence des équipements réseaux matériels et en la disposant dans des composants logiciels sur des équipements dédiés.
La Figure C.1.1 illustre l’ʹarchitecture SDN et la compare avec l’ʹarchitecture d’ʹun réseau classique. La séparation du plan de données du plan de contrôle permet une visualisation et une gestion plus globale du réseau. Le déploiement de nouveaux protocoles ou de nouvelles applications est alors facilité, l’ʹintelligence du réseau étant logiquement regroupée dans une entité spécifique, appelée le contrôleur SDN. Comme on peut le voir sur la Figure C.1.1, le contrôleur devient le point central de l’ʹarchitecture SDN. La partie supérieure englobe les applications agissant sur le réseau telles que le routage, le contrôle d’ʹaccès, la surveillance du réseau… L’interaction avec le contrôleur se fait via des API et les applications obtiennent ainsi une vision simplifiée du réseau sous-­‐‑jacent. Le plan inférieur est composé d’ʹéléments physiques chargés de l’acheminement des données, typiquement des commutateurs. Le contrôleur situé entre les applications et les équipements physiques peut alors, au travers de différents services, interpréter les consignes des applications et les répercuter sur le réseau. Idéalement, les interfaces Nord (Application-­‐‑Contrôleur) et Sud (Contrôleur-­‐‑Routeur) proposent des API ouvertes afin de permettre une meilleure interopérabilité entre les systèmes et matériels de différents constructeurs (voir Figure C.1.2 -­‐‑ Architecture de SDN vue par l’ONF [ONF 2013a]. Vision classique et haut-­‐‑niveau de l’architecture SDN.qui présente la vision de l’Open Networking Foundation (ONF), principal promoteur des réseaux SDN). Pour l’instant, les efforts des chercheurs et des industriels se sont focalisés sur l’interface Sud car celle-­‐‑ci est indispensable à la programmation du plan de données. Nous verrons par la suite que les approches sont légèrement différentes mais que le principe reste globalement le même. Nous détaillerons deux propositions qui nous semblent les plus abouties : OpenFlow [McKeown 2008] et ForCES [Doria 2010].
Si les travaux relatifs à l’interface Nord ne connaissent pas la popularité des protocoles de l’interface Sud (OpenFlow monopolisant les discussions sur les SDN), le succès futur des SDN passera pourtant par l’existence d’API clairement définies au niveau de l’interface Nord. En effet, ceci est indispensable pour le développement d’applications et, donc, une exploitation optimale des architectures SDN. Nous ferons un point sur les mécanismes actuels et sur les objectifs à respecter.
Bien que prometteuse, l’approche SDN soulève plusieurs problématiques et défis qui font actuellement l’objet de plusieurs travaux de recherche [Nunes 2014]. La centralisation de l’ʹintelligence dans le contrôleur pose le problème du passage à l’ʹéchelle. Un nouveau flux entrant dans un commutateur doit être identifié par son contrôleur pour qu’ʹil puisse établir une règle adéquate. Le nombre de nouveaux flux acceptés par seconde dépend alors directement des performances du contrôleur. Il a été démontré dans [Tootoonchian 2012] sur différents contrôleurs OpenFlow que ceux-­‐‑ci pouvaient traiter plus de 50000 nouveaux flux par seconde dans différents scénarios. Une autre problématique est le placement du contrôleur, que ce soit par rapport au nombre de contrôleurs à utiliser ou à son emplacement dans le réseau physique. Les études menées dans [Phemius 2013] concluent que la bande-­‐‑passante influe sur le nombre de nouveaux flux acceptés ainsi que le taux de pertes en cas de congestion sur le lien. La latence sur le lien contrôleur-­‐‑commutateur va quand-­‐‑à-­‐‑elle influencer directement la latence introduite lors de l’ʹacceptation d’ʹun nouveau flux.
Dans une architecture SDN, les commutateurs sont délestés du contrôle pour se concentrer uniquement sur la transmission des données. Le plan de contrôle de plusieurs commutateurs pouvant être regroupé dans un seul contrôleur, celui-­‐‑ci peut devenir un point faible pour le réseau. Il est donc nécessaire d’ʹavoir une distribution ou une redondance en cas de panne du contrôleur. Pour lutter contre cela, des propositions d’ʹarchitecture logiquement centralisée et physiquement distribuée ont été faites. Par exemple, Onix [Koponen 2010] et Hyperflow [Tootoonchian 2010] permettent d’ʹavoir un plan de contrôle distribué tout en offrant aux applications une vision centralisée du réseau. Des compromis sont alors nécessaires afin de pouvoir offrir cette vue centralisée tout en gardant une certaine réactivité [Levin 2012]. Une approche intéressante est l’ʹutilisation d’ʹune architecture hybride comme Kandoo [Kandoo 2012] qui propose de hiérarchiser les contrôleurs en établissant deux couches: les contrôleurs de la couche inférieure ne sont pas interconnectés et agissent uniquement dans leur domaine local tandis la couche supérieure est un contrôleur logiquement centralisé qui connaît l’ʹétat de la globalité du réseau. Il est ainsi possible de limiter les interventions du contrôleur principal et d’ʹobtenir une meilleure réactivité pour les applications locales.
Les problématiques citées ci-­‐‑dessus sont directement liées à la structure de l’ʹarchitecture SDN. En plus de cela, une solution de SDN doit définir comment sont définies les règles présentes dans les commutateurs: de manière réactive ou de manière proactive. La définition des règles de façon proactive correspond à une architecture classique comme Ethane [Casado 2007] où les commutateurs vont renvoyer les nouveaux flux vers les contrôleurs. Comme expliqué précédemment, cela risque de dégrader les performances du contrôleur suivant le nombre de nouveaux flux par seconde. Afin de définir les règles de manières proactives, DIFANE [Yu 2010] propose qu’ʹau lieu de transmettre les nouveaux flux vers le contrôleur, le routeur de bordure transmette ceux-­‐‑ci vers des routeurs intermédiaires qui contiennent les règles de transmission adéquates. Le contrôleur est alors uniquement en charge de répartir ces règles entre les commutateurs intermédiaires.

L’OPEN NETWORKING FOUNDATION (ONF)

L’Open Networking Foundation (ONF) est une organisation à but non-­‐‑lucratif crée en 2011. Son objectif est de promouvoir les SDN par le développement de standards ouverts. De nombreux acteurs soutiennent cette organisation, notamment Deutsche Telekom, Google, Facebook, Microsoft, … La réalisation la plus notable de cette organisation pour l’instant est le standard OpenFlow qui permet la programmation à distance du plan de données. Néanmoins, tous les groupes de travail actifs au sein de l’ONF ne se focalisent pas sur ce standard :
• « Architecture and Framework » : standardisation des SDN en essayant de définir les problèmes architecturaux liés aux SDN [ONF 2013b].
• « Configuration and Management » : étude des problèmes d’administration et de gestion liés au standard OpenFlow et définit notamment OF-­‐‑CONFIG [ONF 2014].
• « Extensibility » : définition du protocole OpenFlow inclus dans les commutateurs [ONF 2013c] et développement d’extensions pour celui-­‐‑ci.
• « Forwarding Abstraction » : définition d’une couche d’abstraction « Hardware Abstraction Layer » (HAL) pour la prise en charge de commutateurs non-­‐‑OpenFlow.
• « Market Education » : en charge de la promotion des SDN [ONF 2013a] mais aussi de la définition de cas d’étude [ONF 2013d].
• « Migration » : proposition de méthodes pour migrer des réseaux traditionnels vers des SDN basés sur le standard OpenFlow [ONF 2013e].
• « Northbound Interface » : définition des besoins, de l’architecture et d’une implémentation pour les interfaces entre contrôleurs et applications (NBI).
• « Optical Transport » : étude des apports des SDN dans les réseaux optiques et définition d’une architecture.
• « Testing and interoperability » : test et certification des implémentations d’OpenFlow faites par les équipementiers. Organisation de PlugFests.
• « Discussion Groups » : forums discutant des SDN. Réservé aux sociétés membres.
• « Wireless & Mobile » : définition de cas d’études et détermination des besoins protocolaires et architecturaux pour étendre les technologies de l’ONF dans les domaines sans-­‐‑fil et mobiles. Certaines propositions issues de ces groupes sont donc intéressantes pour l’ensemble des solutions SDN, même si celles-­‐‑ci n’utilisent pas le standard OpenFlow. Par exemple, [ONF 2013b] offre la vision de l’ONF des composants constituants une architecture SDN (voir). Ces définitions permettent de mieux appréhender les éléments constituant l’architecture, quels sont leurs rôles et comment ils interagissent. En effet, en plus des couches application, contrôle et données, la Figure C.2.1 illustre les informations qui peuvent circuler entre les plans et quelles actions sont réalisables par les organismes de gestion et d’administration du système.

Table des matières

TERMINOLOGIE ET ABREVIATIONS
A INTRODUCTION
B VIRTUALISATION RESEAU
B.1 Principes généraux
B.2 Techniques de Virtualisation réseau
B.2.1 Virtualisation des interfaces/cartes réseau
B.2.2 Virtualisation des équipements réseau
B.2.3 Virtualisation des liens
B.3 Ecosystème de la virtualisation réseau
B.4 Exemples d’application de la virtualisation réseau
B.4.1 Support de services diversifiés / réseaux virtuels spécifiques aux services
B.4.2 Support de réseaux pluri-générationnels
B.4.3 Expérimentation/test à grande échelle sur réseaux opérationnels
B.4.4 Location à la demande et élastiques de ressources virtuelles
B.4.5 Virtual Networks As A service
B.4.6 Agrégation des accès sans fil
B.4.7 Migration des services et des fonctions réseau
C SOFTWARE-DEFINED NETWORKING
C.1 Principes généraux
C.2 L’Open Networking Foundation (ONF)
C.3 Protocoles et Standards pour l’interface Sud
C.3.1 Le Standard ForCES
C.3.2 Le protocole OpenFlow
C.4 L’interface Nord
C.5 Technologies SDN
C.5.1 Commutateurs matériels OpenFlow
C.5.2 Commutateurs logiciels OpenFlow
C.5.3 Contrôleurs Openflow
C.5.4 Outils d’Emulations et de simulations de réseaux SDN
C.6 Exemples d’application de l’approche « Sofware Defined Networking»
C.6.1 Réseau d’accès sur un campus
C.6.2 Réseau étendu (WAN) entre plusieurs sites
C.6.3 Réseau de fournisseur d’accès
C.6.4 Déploiement de politiques de Qualité de Service
D VIRTUALISATION DES FONCTIONS RESEAU
D.1 Principes généraux
D.2 Exemples d’application de l’approche NFV
D.2.1 Network Function Virtualisation Infrastructure as a Service
D.2.2 Virtual Network Function as a Service (VNFaaS)
D.2.3 Virtual Network Platform as a Service (VNPaaS)
D.2.4 Virtualisation of Mobile Core Network
D.2.5 Chaînage flexible de fonctions réseau
D.3 Technologies NFV
E CLOUD NETWORKING: NETWORK AS A SERVICE
E.1 Principes généraux
E.2 technologies NaaS
E.2.1 OpeStack neutron 56
E.3 Exemples d’application du «Cloud Networking: Network as a Service»
F.1 Introduction
F.2 Modèle de communication de DDS
F.3 QoS dans DDS
F.4 DDS Interoperability Wire Protocol (DDSI)
F.5 Etat des lieux des principaux middlewares DDS
F.5.1 OpenSplice DDS
F.5.2 RTI Connext DDS
F.5.3 OpenDDS
F.5.4 BeeDDS
F.5.5 CoreDX DDS
F.5.6 RTI Connext Micro
F.5.7 OpenSplice DDS Vortex
CONCLUSION
REFERENCES

Télécharger le rapport complet