Soutenance mémoire
Toutefois, afin de continuer son succès, Internet doit relever le défi de traiter des volumes de plus en plus gigantesques de trafic dus à : une explosion du nombre de terminaux mobiles, une utilisation massive des réseaux sociaux et de nouvelles tendances des technologies de l’information comme le cloud computing, le big data, et l’internet des objets qui sont génératrices de gros volumes de données. Le problème pour relever ce défi dans l’avenir, est qu’il est très difficile d’innover et d’apporter des changements au réseau Internet actuel tant sur le plan des protocoles que de l’infrastructure physique. D’ailleurs, son architecture fondamentale n’a connu aucun progrès significatif en presque trois décennies.
La migration des équipements réseau d’IPv4 vers IPv6 a commencé depuis une dizaine d’années et est toujours en cours. Selon [1], le design, l’évaluation et le déploiement d’un nouveau protocole de routage peuvent prendre entre 5 à 10 années. Une des raisons de cette difficulté d’innover réside dans l’architecture des réseaux actuels où le plan de contrôle et le plan de données coexistent dans chaque équipement réseau. Ce problème du couplage du plan de contrôle et du plan de données dans les équipements réseaux, rend les opérations de configuration et de gestion complexes. En effet, les administrateurs réseaux doivent configurer et gérer séparément chaque équipement, ce qui augmente le risque d’erreurs. Et selon nos études, les facteurs humains sont signalés comme étant responsables de 50 à 80 % des interruptions de service et pannes de périphériques réseaux.
C’est dans ce contexte qu’a apparu le concept des réseaux définis par logiciels (Software Defined Networking ou SDN). Ces changements dans l’infrastructure réseau ont pour conséquence de simplifier des équipements et de les rendre indépendants des fabricants. Il est en outre envisageable d’utiliser le SDN avec différentes approches, afin d’améliorer les performances des réseaux, par exemple l’utilisation de Machine Learning avec SDN permet de fournir plus d’intelligence aux réseaux, et cela grâce aux capacités du SDN. En outre, l’utilisation du concept SDN dans le réseau peut fournir des services innovants, notamment le routage multidiffusion, la sécurité, le contrôle d’accès, la gestion de la bande passante, l’ingénierie de trafic, la QoS, l’efficacité énergétique et diverses formes de gestion des stratégies.
Software-Defined Networking (SDN)
Définition
Selon l’ONF (Open Network Fundation) (un consortium d’entreprises à but non lucratif fondé en 2011 pour promouvoir SDN et normaliser ses protocoles) SDN est une architecture qui sépare le plan de contrôle du plan de données, et unifie les plans de contrôle dans un software de contrôle externe appelé Contrôleur, pour gérer plusieurs éléments du plan de données via des APIs (Application Programming Interface). En d’autres termes, on peut dire qu’une architecture réseau suit le paradigme SDN si elle vérifie les points suivants :
▪ Le plan de contrôle est complètement découplé du plan de données, cette séparation est matérialisée à travers la définition d’une interface de programmation (Southbound API)
▪ Toute l’intelligence du réseau est externalisée dans un point logiquement centralisé appelé contrôleur SDN, ce dernier offre une vue globale sur toute l’infrastructure physique.
▪ Le contrôleur SDN est un composant programmable qui expose une API (NorthboundAPI) pour spécifier des applications de contrôle.
Différence entre un réseau SDN et un réseau traditionnel
Traditionnellement, un réseau informatique est composé d’équipements réseau interconnectés tels que des switchs et des routeurs. Dans chaque équipement, nous trouvons un mécanisme de transmission dans la couche de transmission et un plan de contrôle qui incorpore le système d’exploitation et les applications. Dans ce modèle, les équipements réseau sont fermés et nous n’avons aucune possibilité d’ajouter une nouvelle application. De plus, avec cette approche traditionnelle de gestion des réseaux, chaque équipement doit être configuré indépendamment. Ce qui est non seulement lourd et fastidieux, mais induit aussi le risque de ne pas avoir l’uniformité dans les configurations. D’où le SDN pour permettre la centralisation des configurations.
Architecture SDN
L’architecture SDN est constituée de trois couches à savoir la couche infrastructure, la couche de contrôle et la couche application. Ces différentes couches se communiquent via les interfaces Southbound, Northbound et East-Westbound APIs comme l’indique la figure 3 Nous décrivons dans la suite ces couches ainsi que les interfaces de communication entre les couches. La couche la plus basse est la couche de transmission, aussi appelée plan de données. Elle contient les équipements de transmission (FEs : Forwarding Element) tels que les switchs physiques et virtuels. Son rôle principal est de transmettre les données, surveiller les informations locales et collecter les statistiques. La couche de contrôle, également appelée plan de contrôle, est constituée d’un ou de plusieurs logiciels de contrôle (Contrôleurs), ces contrôleurs utilisent des interfaces Sud ouvertes pour contrôler le comportement des FEs et communiquent via des APIs Nord avec la couche supérieure pour superviser et gérer le réseau. La couche d’application héberge les applications qui peuvent introduire de nouvelles fonctionnalités réseau, comme la sécurité, la configuration dynamique et la gestion. La couche d’application exploite la vue globale et distante du réseau offerte par le plan de contrôle pour fournir des directives appropriées à la couche de contrôle.
Les interfaces de communications
Le contrôleur interagit avec les autres couches à travers les interfaces Sud et Nord et avec les autres contrôleurs à travers une interface Est-Ouest.
Le Southbound API
L’interface entre la couche infrastructure et la couche de contrôle est appelée Southbound API ou interfaces Sud. Les Southbound APIs représentent les interfaces de communication, qui permettent au contrôleur SDN d’interagir avec les équipements de la couche d’infrastructure, tel que les switches, et les routeurs. OpenFlow est le Southbound API le plus souvent utilisé dans l’architecture SDN permettant la programmation du plan de données. Bien qu’OpenFlow est le Southbound API le plus utilisé et même le standard de facto, il y a aussi plusieurs autres Southbound API pour gérer les communications entre ces deux niveaux de l’architecture SDN, tels que Forwarding and Contrôle Element Separation (ForCES) [13] et OpFlex..
Le Northbound API
L’interface entre la couche de contrôle et la couche application est le Northbound API ou l’interface nord qui est une des abstractions clés de l’environnement SDN. Il fournit généralement une liste des fonctions réseaux de base associées au fournisseur, qui est ensuite utilisées pour configurer un équipement spécifique à l’utilisateur, et le contrôleur l’interprète dans un langage que chaque équipement réseau peut comprendre. Au moment de la rédaction de ce mémoire, il n’existe aucun standard intervenant entre la couche de contrôle et celle d’application du côté d’ONF ou d’autres organisations. C’est pourquoi ONF a créé un groupe de travail pour élaborer un protocole standard sur cette interface. Il existe actuellement plusieurs types de contrôleurs SDN qui offrent une grande variété de Northbound API. Les Northbound API peuvent être classées principalement en trois catégories, à savoir les API REST (REpresentational State Transfer) [16], les API ad hoc spécialisées et les langages de programmation tels que Procera [17], Frenetic [18]. L’API REST est le plus utilisé car il fournit une intégration simple et permet une interaction minimale entre un client et un serveur. L’API REST est l’œuvre de Roy Thomas Fielding qui a aussi participé à la définition du protocole HTTP.
|
Table des matières
Introduction générale
Chapitre 1 : Cadre théorique et méthodologique
1.1 Introduction générale
1.2 Contexte
1.3 Problématique
1.4 Objectifs
1.4.1 Objectif général
1.4.2 Objectifs spécifiques
Chapitre 2: Software Defined Networking (SDN): Etat de L’art
2.1 Introduction
2.2 Software-Defined Networking (SDN)
2.2.1 Définition
2.3 Différence entre un réseau SDN et un réseau traditionnel
2.4 Architecture SDN
2.5 Les interfaces de communications
2.5.1 Le Southbound API
2.5.2 Le Northbound API
2.5.3 Le East Westbound API
2.6 La couche de contrôle
2.7 Le protocole OpenFlow
2.8 L’architecture du protocole OpenFlow
2.9 Fonctionnement du protocole OpenFlow
2.10 Quelques contrôleurs OpenFlow
2.10.1 NOX
2.10.2 OpenDayLight
2.10.3 Floodlight
2.10.4 POX
2.10.5 ONOS
2.11 Architecture initiale (mono contrôleur)
2.12 Architecture multi contrôleur
2.12.1 Architecture logiquement centralisée
2.12.2 Architecture logiquement distribuée
2.13 Avantages et inconvénients de SDN
2.13.1 Avantages
2.13.2 Inconvénient
Chapitre 3 : Etudes des différentes solutions existantes sur le problème de placement du contrôleur (CPP)
3.1 Introduction
3.2 Pourquoi le problème de placement des contrôleurs
3.3 Formulation du problème
3.4 Les impacts du CPP sur les performances
3.4.1 La Latence
3.4.2 Fiabilité
3.4.3 Le Coût
3.4.4 Multi-Objects
3.5 Etude des différentes solutions existantes
3.5.1 Solution 1 : Sallahi et M.St-Hilaire
3.6 ABCP : Approche basée sur le cluster de la densité
3.6.1 Calcule de la densité
3.6.2 Trouver le commutateur le plus proche avec une densité plus élevée
3.6.3 regroupements (clustering)
3.6.4 Emplacement du Controleur
3.6 Tableau comparatif des différentes solutions liées aux problème de placement du contrôleur
3.8 Conclusion
Chapitre 4 : Mise en œuvre de la solution basée sur la méthode de cluster des contrôleurs SDN
4.1 Introduction
4.2 Etude comparative des outils de simulations
4.3 Présentation de l’émulateur de réseau mininet
4.3.1 Configuration utilisée
4.3.2 Création d’une topologie avec la ligne de commande
4.4 Architecture Utilisée
4.4 Prérequis ou Méthode d’implémentation
4.5 Installation des prérequis
4.5.1 Installation de mininet
4.5.2 Installation d’OpenDayLight
4.6 Création du cluster composé de trois contrôleurs OpenDayLight
4.6.1 Présentation du clustering
4.6.2 Configuration du cluster
4.7 Création de la topologie et analyse des résultats
4.8 Interprétation des résultats
4.9 Conclusion
Conclusion générale
BIBLIOGRAPHIE
WEBOGRAPHIE
