Software Defined Network

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique
Université Tunis El Manar

Ecole Nationale d’Ingénieurs de Tunis
Département Technologies de l’Information et de la Communication
Projet de Fin d’Année

(2ème Année)
présenté par
Oumaima NIJAOUI & Rania BOUGHANMI

2AINFO1
Plan de contrôle SDN distribué

pour l’Internet des Objets
soutenu le 11/05/2022 devant le Jury composé de :
Rapporteur Mr Lazhar FEKIH

Examinateur Mr Riadh BEN ABDALLAH
Encadrant Mme Meriem KASSAR
Année Universitaire
2021-2022
Signatures
Encadrant ENIT
Vu le 09/05/22
Remerciements
Au terme de ce travail, nous adressons tout d’abord nos vifs remerciements
aux membres du jury pour avoir bien voulu examiner et évalué ce travail.
Ensuite, nous tenons à exprimer notre profonde gratitude à notre chère

professeur et encadrante Mme. Meriem Kassar pour son suivi et pour son
énorme soutien qu’elle n’a cessé de nous prodiguer tout au long de la période
du projet.
Nous tenons à remercier également notre chère Mme Intidhar Bedhief pour
le temps qu’elle nous a consacré et pour les précieuses informations qu’elle nous
a prodiguées avec intérêt et compréhension.
Mes remerciements vont à tout le personnel que nous avons contacté durant
la période de réalisation de ce travail au sein de l’École Nationale d’Ingénieurs
de Tunis.
Enfin, nos remerciements à tous ceux qui ont contribué de prés ou de loin
au bon déroulement de ce projet.
Plan de contrôle SDN distribué pour l’Internet des
Objets
Résumé : Les réseaux IP actuels deviennent de plus en plus complexes
et difficiles à gérer à cause de leur intégration verticale vu que les plans de
contrôle et de données sont regroupés. Le concept des réseaux SDN (Software-
Defined Networking) consiste à briser l’intégration verticale, à séparer le plan
de contrôle du réseau du plan de données, à promouvoir le contrôle centralisé
du réseau et à introduire sa programmabilité. Dans ce document, nous pré-
sentons d’abord le réseau traditionnel, son architecture puis nous décrivons
la naissance de SDN en étudiant son architecture, ses avantages et ses diffé-
rents cas d’utilisation. Enfin, nous proposons une topologie pour montrer les
meilleures pratiques du SDN dans le domaine de l’IoT (Internet of Things),
puis nous passons à la partie d’automatisation, où nous utilisons les outils de
DevOps tels que Docker et Kubernetes pour répondre à une certaine problé-
matique qui peut apparaître lors de l’envoi de paquets entre les hôtes et aussi
pour contrôler le trafic.
Mots clés : SDN, IoT, Distributed control plan, Mininet, Ryu, OpenFlow,
OVSwitch, Kubernetes, Docker, iPerf, Wireshark
Distributed SDN control plan for Internet of Things
Abstract : Current IP networks are becoming more and more complex and
difficult to manage because of their vertical integration which means control
and data plans are grouped together. The concept of SDN (Software-Defined
Networking) networks is to break down this vertical integration, separates its
network control logic from the underlying hardware, promote centralized net-
work control and introduce network programmability. In this document, we
first present the traditional network, its architecture and then we describe the
emergence of SDN by studying its architecture, advantages and different use
cases.
Finally, we propose a topology to show the best practice of SDN in IoT (In-
ternet of Things), and then we switch to the automatisation part, in which
we use the tools of DevOps such as Docker and Kubernetes to facilitate some
issues that can occur during sending packets between hosts and also to control
the traffic.
Keywords : SDN, IoT, Distributed control plan, Mininet, Ryu, Open-

Flow, OVSwitch, Kubernetes, Docker, iPerf, Wireshark
Table des matières
Liste des figures vi
Liste des acronymes ix
Introduction générale 1
1 Software-Defined Networking (SDN) & Internet of Things

(IoT) 3
1.1 Présentation du concept SDN . . . . . . . . . . . . . . . . . . 4
1.1.1 Le réseau traditionnel . . . . . . . . . . . . . . . . . . 4
1.1.2 L’évolution vers le réseau SDN . . . . . . . . . . . . . . 5
1.2 Principe du SDN . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 L’architecture SDN . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Le contrôleur SDN . . . . . . . . . . . . . . . . . . . . 9
1.2.3 Les interfaces de communication . . . . . . . . . . . . . 10
1.3 Avantages du SDN . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4 Protocole OpenFlow . . . . . . . . . . . . . . . . . . . . . . . 14
1.4.1 Architecture du protocole OpenFlow . . . . . . . . . . 14
1.4.2 Messages OpenFlow . . . . . . . . . . . . . . . . . . . 17
1.5 Orchestration : comparaison entre différents orchestrateurs . . 18
1.6 Cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.6.1 Réseau de campus et d’entreprise . . . . . . . . . . . . 22
1.6.2 Centre de données . . . . . . . . . . . . . . . . . . . . 22
1.7 Internet of Things . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.7.1 IoT et ses Caractéristiques . . . . . . . . . . . . . . . . 23
1.7.2 Protocoles de l’IoT . . . . . . . . . . . . . . . . . . . . 24
1.7.3 SDN et son évolution dans les réseaux sans fil et IoT . 26
1.7.4 Architecture SDN pour l’IoT . . . . . . . . . . . . . . . 27
1.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2 Mise en place de l’environnement SDN 29

2.1 MiniNet : Émulateur réseau . . . . . . . . . . . . . . . . . . . 30
2.1.1 Ligne de commande MiniNet . . . . . . . . . . . . . . . 30
2.1.2 Différentes architectures de Mininet . . . . . . . . . . . 32
2.1.3 Topologies personnalisées . . . . . . . . . . . . . . . . . 34
2.2 Open vSwitch . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.3 Ryu, contrôleur SDN . . . . . . . . . . . . . . . . . . . . . . . 39
TABLE DES MATIÈRES
2.3.1 Comparaison entre un contrôleur centralisé et un contrô-

leur distribué . . . . . . . . . . . . . . . . . . . . . . . 39
2.3.2 Création d’une topologie avec MiniNet . . . . . . . . . 42
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3 Mise en pratique & Comparaison 48

3.1 Différence entre la conteneurisation et la virtualisation . . . . 49
3.1.1 Virtualisation : Machine Virtuelle . . . . . . . . . . . . 50
3.1.2 Conteneurisation : Docker . . . . . . . . . . . . . . . . 51
3.2 Mise en pratique : virtualisation vs dockerisation . . . . . . . . 53
3.2.1 Virtualisation . . . . . . . . . . . . . . . . . . . . . . . 53
3.2.2 Dockerisation . . . . . . . . . . . . . . . . . . . . . . . 56
3.3 Mise en pratique : contrôle centralisé vs contrôle distribué . . 59
3.3.1 Topologie personnalisée . . . . . . . . . . . . . . . . . . 59
3.3.2 Contrôle centralisé . . . . . . . . . . . . . . . . . . . . 60
3.3.3 Contrôle Distribué . . . . . . . . . . . . . . . . . . . . 61
3.4 Évaluation des performances . . . . . . . . . . . . . . . . . . . 61
3.4.1 Débit TCP . . . . . . . . . . . . . . . . . . . . . . . . 61
3.4.2 Débit UDP . . . . . . . . . . . . . . . . . . . . . . . . 62
3.5 Orchestration : Kubernetes . . . . . . . . . . . . . . . . . . . . 64
3.5.1 Définition : . . . . . . . . . . . . . . . . . . . . . . . . 64
3.5.2 Installation du kubernetes : . . . . . . . . . . . . . . . 64
3.5.3 Architecture : . . . . . . . . . . . . . . . . . . . . . . . 65
3.5.4 Les Concepts . . . . . . . . . . . . . . . . . . . . . . . 68
3.5.5 Les commandes du kubernetes : . . . . . . . . . . . . . 72
3.5.6 Les fichiers YAML : . . . . . . . . . . . . . . . . . . . . 73
3.5.7 Implémentations . . . . . . . . . . . . . . . . . . . . . 75
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Conclusion Générale 82
Bibliographie 83
vi
Table des figures
1.1 Architecture du réseau traditionnel vs SDN . . . . . . . . . . . 5

1.2 Couche Infrastructure de l’architecture SDN . . . . . . . . . . 7
1.3 Couche Contrôle de l’architecture SDN . . . . . . . . . . . . . 7
1.4 Couche application de l’architecture SDN . . . . . . . . . . . 8
1.5 Commutateur SDN . . . . . . . . . . . . . . . . . . . . . . . 9
1.6 Contrôleur SDN . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.7 Processus de communication entre le commutateur et le contrô-
leur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.8 Communication entre la couche des application et le contrôleur 12
1.9 Communication entre contrôleurs . . . . . . . . . . . . . . . . 13
1.10 L’architecture d’OpenFlow dans SDN. . . . . . . . . . . . . . 15
1.11 Entête du table de flux dans OpenFlow. . . . . . . . . . . . . 15
1.12 Table de flux . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.13 Les messages OpenFlow . . . . . . . . . . . . . . . . . . . . . 18
1.14 Le service Kubernetes expose la logique du ou des conteneurs
d’un pod au réseau. . . . . . . . . . . . . . . . . . . . . . . . . 19
1.15 L’Architecture de Docker Swarm . . . . . . . . . . . . . . . . 21
1.16 Domaines d’utilisation de l’IOT . . . . . . . . . . . . . . . . . 24
1.17 Structure de SDN avec IoT . . . . . . . . . . . . . . . . . . . . 28
2.1 Mininet SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.2 Topologie single . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3 Topologie lineaire . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.4 Topologie en arbre . . . . . . . . . . . . . . . . . . . . . . . . 33
2.5 Représentation graphique de topologies mininet . . . . . . . . 34
2.6 Topologie personnalisée . . . . . . . . . . . . . . . . . . . . . . 34
2.7 Commandes CLI pour une exécuter une topologie personalisée 35
2.8 Commandes CLI pour afficher les commandes de Mininet. . . 35
2.9 Commandes CLI pour afficher les noeuds de Mininet . . . . . 36
2.10 Commandes CLI pour afficher les liens de Mininet . . . . . . . 36
2.11 Commandes CLI pour afficher toute les informations sur les
noeuds de Mininet. . . . . . . . . . . . . . . . . . . . . . . . . 36
2.12 Commandes CLI pour tester la connectivité entre h1 et h2. . . 37
2.13 Commandes CLI pour tester la connéctivité entre tous les noeuds
de Mininet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.14 Commandes CLI pour quitter le Mininet. . . . . . . . . . . . . 37
2.15 Open vSwitch . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
TABLE DES FIGURES
2.16 Contrôleur RYU . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.17 Contrôleur Centralisé . . . . . . . . . . . . . . . . . . . . . . . 40
2.18 Contrôleur Distribué . . . . . . . . . . . . . . . . . . . . . . . 41
2.19 Miniedit un simple éditeur graphique pour Mininet . . . . . . 42
2.20 L’interface de MiniEdit . . . . . . . . . . . . . . . . . . . . . 43
2.21 Ajouter des hôtes, des commutateurs et des contrôleurs . . . . 43
2.22 Connecter les nœuds ensemble . . . . . . . . . . . . . . . . . . 44
2.23 Modifier chaque contrôleur pour qu’il utilise un numéro de port
unique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.24 Paramètres par défaut des préférences MiniEdit . . . . . . . . 45
2.25 Définir l’option CLI . . . . . . . . . . . . . . . . . . . . . . . . 46
2.26 La console MiniEdit affiche l’invite Mininet . . . . . . . . . . . 46
2.27 Fenêtre Résumé OVS. . . . . . . . . . . . . . . . . . . . . . . 47
3.1 Container Vs Virtuel machine . . . . . . . . . . . . . . . . . . 49

3.2 Virtualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3 conteneurisation . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.4 Virtualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.5 Pulling the Controller’s image from Docker Hub . . . . . . . . 56
3.6 Vérification de l’existence de l’image tirer du Docker Hub . . . 57
3.7 Lister Les images existants sur notre machine . . . . . . . . . 58
3.8 Shell dans le container du Mininet . . . . . . . . . . . . . . . . 58
3.9 New Controller image pushed to Docker Hub . . . . . . . . . . 59
3.10 Utilisation d’un seul contrôleur . . . . . . . . . . . . . . . . . 60
3.11 Contrôle distribué . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.12 Architecture du kubernetes . . . . . . . . . . . . . . . . . . . 65
3.13 Le noeud maître . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.14 Les noeuds escalves . . . . . . . . . . . . . . . . . . . . . . . 67
3.15 Concept du Kubernetes . . . . . . . . . . . . . . . . . . . . . 68
3.16 Architecture des noeuds Kubernetes . . . . . . . . . . . . . . . 69
3.17 Architecture d’un pod du Kubernetes . . . . . . . . . . . . . . 70
3.18 Kubernetes Volumes persistants, réclamations et classes de sto-
ckage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.19 la deploiement de Ryu sous Kubernetes . . . . . . . . . . . . . 75
3.20 Le pod de Ryu en exécution . . . . . . . . . . . . . . . . . . . 75
3.21 la Config Map de Ryu sous Kubernetes . . . . . . . . . . . . . 75
3.22 Les propriétés du controleur Ryu . . . . . . . . . . . . . . . . 76
3.23 Exécution de la commande pingall . . . . . . . . . . . . . . . . 76
3.24 L’exécution du deux Contrôleurs RYU sous Kubernetes . . . 77
3.25 L’existence de deux pods du RYU en état dans le dashboard
du kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . 77
viii
TABLE DES FIGURES
3.26 Le Débit de collectivité entre RYU et Mininet . . . . . . . . . 77

3.27 Yaml file pour définir le CPU et le taux d’occupation de mé-
moire du pod . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.28 Installation du metrics server pour l’autoscaling . . . . . . . . 79
3.29 L’ajout/La génération d’un Pod automatiquement du yaml file 79
3.30 la mise à jour du nombre de replicas du RYU(ajout) . . . . . 79
3.31 La mise a jour du nombre du replicas du RYU (suppression) . 80
3.32 Architecture globale . . . . . . . . . . . . . . . . . . . . . . . 81
ix
Liste des acronymes
6LoWPan IPv6 Over Low-PowerWireless Personal Area Networks
API Application Programming Interface
BD Bases de Données
CLI CommandLLineInterface
CNCF CloudNativeComputingFoundation
CoAP Constrained Application Protocol
HPA HorizontalPod Autoscaler
IP Internet Protocol
KVM Kernel-baseVirtualMachine
MEMS MicroElectroMechanical Systems
NFC NearFieldCommunication
NOS NetworkOpertatingSystem
NTT NipponTelegraphTelephon
OS OperatingSystem
OVS OpenVSwitch
QoS QualityOverService
REST Representational State Transfer
RFID RadioFrequencyIDidentification
SDN Software Defined Networking
SD-WAN Software Defined WAN
TCP Transmission Control Protocol
TI TechnologieInformation
UDP User Datagram Protocol
VM Virtual Machine
VoIP VoiceOverIP
WAN Wide Area Network
WSN WirelessSensorNetwork
Introduction générale
La technologie de la communication se développe si rapidement que les
nouvelles tendances peuvent être trouvées dans les archives en une période
très courte. La conception traditionnelle de l’architecture des réseaux dépend
des protocoles de contrôle de la distribution et du réseau de transport exé-
cutés dans les routeurs et les commutateurs qui transmettent les paquets.
Cette intégration entre le plan de contrôle et le plan de données rend difficile
la gestion des réseaux. L’émergence de nouveaux services et applications en
ligne, tant dans les terminaux fixes que dans les appareils mobiles, a fait des
réseaux de communication un point stratégique dans les entreprises, les ins-
titutions et les foyers. L’évolution continue de ces services et la croissance de
l’information circulant sur l’Internet, apportent des défis imprévus aux déve-
loppeurs et aux entreprises. Les progrès des systèmes micro-électromécaniques
(MEMS) favorisent le développement de dispositifs qui enregistrent, traitent
et envoient automatiquement des informations via le réseau. Ce type de dispo-
sitif, composé principalement de capteurs et d’actionneurs (RFID, dispositifs
Bluetooth, réseaux de capteurs sans fil (WSN), systèmes intégrés et com-
munication en champ proche (NFC)), est à l’origine de nouvelles idées, de
nouveaux concepts et de nouveaux paradigmes tels que l’Internet des objets
(IoT, Internet of Things).
L’Internet des Objets est un concept qui a évolué rapidement durant ces
dernières années. Il crée une révolution dans le domaine des technologies de
la communication. L’IoT permet de connecter des dispositifs intelligents hété-
rogènes à travers des technologies de communication hétérogènes. La notion
d’hétérogénéité dans l’IoT est le facteur le plus important et le plus influant
dans le progrès et développement des applications IoT. Néanmoins, il repré-
sente aussi un défi majeur en terme de développement des applications, la
gestion et le contrôle du réseau.
Le principal domaine d’innovation de ces dernières années a été de re-
chercher du contrôle centralisé, de la programmabilité et les aspects de vir-
tualisation. C’est dans ce contexte qu’a émergé l’idée du Software Defined
Networking (SDN), ou réseau défini à base de logiciels, destiné à résoudre les
problèmes que l’entreprise rencontre dans le réseau. SDN est un paradigme
réseau séparant le plan de contrôle du plan de données. Cette séparation four-
nit un niveau d’abstraction aux fonctionnalités des équipements réseau afin de
pouvoir les gérer de manière globale. En effet, elle élimine la rigidité de l’archi-
tecture traditionnelle du réseau et la rend plus flexible. Ainsi, l’IoT requiert un
niveau d’abstraction et d’automatisation que SDN peut lui fournir. SDN peut
concerner une gestion et un contrôle centralisé de l’acheminement des paquets
au sein du réseau et peut présenter une architecture distribuée dans laquelle
la prise de décision quant au routage des paquets dépend de l’ensemble des
éléments du réseau. Plus adaptée à l’IoT, à l’instar du modèle centralisé, la
technologie SDN distribuée admet la nécessité de collecter des informations
sur l’état du réseau, et de les rassembler à un emplacement central depuis
lequel les éléments du réseau peuvent être contrôlés en vue, par exemple, de
gérer les performances. Le défi auquel se heurte la technologie SDN distribuée
est qu’elle doit prouver qu’elle est en mesure de proposer un contrôle du trafic
et de la connectivité à la hauteur de ce que les technologies SDN centralisées
offrent. Notre objectif est de non seulement rendre le plan de contrôle distri-
bué, mais aussi d’automatiser le processus de transfert de paquets ainsi que
la résolution des problèmes d’équilibrage de charge qui se manifeste dans l’ac-
tion que si les capacités (CPU et mémoire) du contrôleur sont saturées, notre
orchestrateur (Kubernetes) crée des replicas (Pods supplémentaires) qui vont
s’occuper du contrôle du flux puis ils vont être automatiquement supprimés.
Le présent rapport est organisé en trois chapitres. Le premier chapitre dé-
taille le contexte général de notre projet en présentant le concept de l’IoT,
du SDN, leurs avantages et leurs défis, et enfin la technologie des dockers. Le
troisième chapitre décrit l’environnement de MiniNet, sa ligne de commande
ainsi que les différentes topologies existantes dans cet émulateur. Ce dernier
parle aussi du commutateur OVS et ses différents composants. Finalement,
on mentionne le contrôleur SDN, Ryu, son architecture et nous expliquerons
la différence entre le contrôle centralisé et le contrôle distribué. Dans le der-
nier chapitre, nous décrivons notre proposition et son implémentation et nous
évaluons ses performances sous l’émulateur MiniNet.
2
Chapitre 1
Software-Defined Networking
(SDN) & Internet of Things (IoT)
1.1 Présentation du concept SDN
Introduction
Le Software-Defined Networking (SDN) est un nouveau paradigme d’archi-
tecture réseau dont le plan de contrôle est totalement découplé du plan de don-
nées. Le terme SDN peut être traduit par "réseau défini par le logiciel".Cette
séparation permet de déployer des plans de contrôle sur des plateformes avec
des capacités plus importantes que les commutateurs réseau traditionnels [13].
Au final, cette abstraction adopte une API réseau standard, une évolution des
services réseau à forte valeur ajoutée sur des fonctionnalités spécifiques aux
constructeurs d’appareils [10].
1.1 Présentation du concept SDN

Dans cette partie, nous introduisons le concept du SDN en donnant l’évo-
lution du réseau traditionnel vers un réseau SDN.
1.1.1 Le réseau traditionnel

En tant que combinaison de plan de données et de plan de contrôle, un
réseau peut être décrit par : le plan de données effectuera le travail de trans-
fert de l’information conformément aux informations de routage tandis que
le plan de contrôle déterminera le trafic réseau et les décisions de contrôle
nécessaires pour obtenir les données des utilisateurs à la cible appropriée [6].
Dans le réseau traditionnel, comme le montre la Figure 1.1, nous pouvons voir
tout cela dans un seul dispositif (ex. routeurs). Il y a certains types de dis-
positifs matériels dans les réseaux traditionnels ; principalement les routeurs,
les commutateurs et les pare-feu. Tous ces dispositifs ont tendance à impli-
quer une interconnexion matérielle qui se déplace l’information à travers eux,
et les composants logiciels sont personnalisés pour contrôler le mouvement
des données via du matériel basé sur les règles et règlements de mouvement
des données (exp. zones de circulation énormes avec beaucoup de véhicules
se déplaçant chaque jour, sans ponts) [6]. La principale limitation du réseau
traditionnel est que l’administrateur doit se connecter à un système individuel
pour l’interaction afin de configurer et de contrôler les fonctionnalités prêtes à
l’emploi pilotées par des périphériques matériels qui nécessitent des modifica-
tions de configuration, rendre la tâche compliquée et exigeante en ressources.
Néanmoins, le nombre croissant d’innovations qui utilisent les concepts de
virtualisation, d’informatique en nuage et de technologies sans fil génère des
environnements plus complexes et difficiles dans lesquels les réseaux doivent
mieux soutenir et s’adapter à ces environnements, et traiter leurs transactions
exigeantes en temps réel [6].
4
1.2 Principe du SDN
1.1.2 L’évolution vers le réseau SDN

Le but de la mise en réseau définie par logiciel était d’isoler les plans de
contrôle des périphériques réseau et les plans de données, comme le montre
la Figure 1.1. Le plan de contrôle fait des choix quant à la façon dont les
paquets qu’il reçoit doivent être envoyés et le plan de données transfère litté-
ralement les paquets à travers le système et les transmet via le réseau. SDN
suggère que le plan de contrôle soit centralisé afin de maintenir et de modifier
la configuration du réseau de manière innovante et adaptable [22]. Si un ad-
ministrateur réseau doit fournir une capacité accrue ou modifier les règles ou
les règlements existants sur le mouvement des données, il n’a pas besoin de
communiquer avec plusieurs appareils et d’apporter des changements manuels
[28]. La modification doit être effectuée de manière dynamique pour leur per-
mettre de former et de changer le réseau très facilement et rapidement. Il ya
un effort avec SDN pour essayer de freiner cela en utilisant certains principes
ouverts comme OpenFlow(OpenFlow est un protocole de communication qui
donne accès au plan de transmission d’un commutateur réseau ou d’un routeur
sur le réseau). [28]
Figure 1.1 – Architecture du réseau traditionnel vs SDN
1.2 Principe du SDN

1.2.1 L’architecture SDN
La mise en réseau définie par logiciel (SDN) est un paradigme récent,
offrant divers avantages par rapport aux réseaux traditionnels. Cela fait du
SDN l’une des solutions clés pour le système cellulaire de cinquième génération
(5G). L’utilisation d’un contrôleur centralisé unique pour les réseaux SDN pose
de nombreux problèmes concernant l’évolutivité, la fiabilité et d’autres per-
formances liées au système, en particulier pour les réseaux à grande échelle.
Un seul contrôleur représente le problème du goulot d’étranglement. Ainsi,
5
1.2 Principe du SDN
l’emploi de contrôleurs distribués servira de solution vitale [21]. La tendance

récente dans les réseaux SDN est le déploiement de contrôleurs répartis ; ce-
pendant, il y a quelques problèmes liés à cette structure. Le principal problème
avec les contrôleurs répartis est de savoir comment équilibrer la charge entre
ces contrôleurs. Dans ce travail, nous fournirons un algorithme de clustering
dynamique pour équilibrer la charge entre les contrôleurs distribués dans le
réseau SDN. Le système utilise deux niveaux de contrôleurs, soit des contrô-
leurs répartis et un contrôleur principal. Un contrôleur maître gère et effectue
le regroupement des contrôleurs distribués. La décision de la reconstruction
des clusters relève de la responsabilité du contrôleur principal, en fonction de
la charge de travail des contrôleurs répartis. Les résultats de la simulation
prouvent que l’algorithme proposé est plus efficace pour équilibrer la charge
entre les contrôleurs que les techniques de groupement statique existantes.[21]
Globalement un réseau est dit SDN en considération des 5 caractéristiques
suivantes :
- Séparation du plan de données et du plan de contrôle.
- Périphériques simplifiés.
- Contrôle centralisé.
- Automatisation du réseau et virtualisation.
- Open source.
Le réseau SDN est composé de 3 couches communiquant entre elles par le
biais d’interfaces APIs. De la plus basse à la plus haute, nous avons :
a - La couche infrastructure
Composé du divers périphériques réseau à la fois physique et virtuel (voir
Figure 1.2), le principal devoir du plan de données est la transmission. Dans
les réseaux traditionnels précédents, le plan de contrôle et le plan de données
étaient dans le même équipement [7]. Mais avec SDN, les périphériques réseau
n’ont que le plan de données. Ainsi, le rôle principal de ces dispositifs de réseau
c’est la transmission des données. Cela fournit un mécanisme de transmission
très efficace [12].
b - La couche contrôle
Le contrôleur est le centre de l’architecture SDN et le plus important des
composants d’architecture SDN (voir Figure 1.3). En d’autres termes, Le
contrôleur SDN est le cerveau du système. Le contrôle de tous les périphé-
riques de plan de données est effectué via SDN Controller [7]. Il contrôle
également les applications à la couche d’application. Le contrôleur SDN com-
munique et contrôle ces couches supérieure et inférieure avec les API via les
interfaces.
6
1.2 Principe du SDN
Figure 1.2 – Couche Infrastructure de l’architecture SDN
Figure 1.3 – Couche Contrôle de l’architecture SDN
c - La couche application
Les applications et services qui utilisent les services du plan de contrôle
et/ou de gestion forment le plan d’application (voir Figure1.4). En outre,
les services résidant dans le plan d’application peuvent fournir des services
à d’autres services et applications qui résident dans le plan d’application via
7
1.2 Principe du SDN
l’interface de service. Des exemples d’applications incluent la découverte de

topologie de réseau, l’approvisionnement de réseau, la réservation de chemin,
etc.
Figure 1.4 – Couche application de l’architecture SDN
Les commutateurs SDN Un commutateur SDN est essentiel pour la com-

mutation de la technologie SDN, et la formation SDN Cisco peut vous ap-
prendre comment cette technologie fonctionne. Lorsqu’un commutateur SDN
acquiert un paquet de données dont le flux n’est pas connu, il communique
avec le contrôleur SDN, connu sous le nom de serveur, pour obtenir des ins-
tructions sur ce qu’il faut faire avec le paquet de données. C’est le port de
transfert et de sortie.[15] Avoir un serveur central qui connaît la disposition
du réseau et peut prendre toutes les décisions de commutation et construire les
chemins nous donne de nouvelles capacités. Les avantages des commutateurs
SDN sont énumérés ci-dessous [7] :
1. Le contrôleur SDN peut acheminer du trafic non critique sur des routes
plus longues qui ne sont pas entièrement utilisées.
2. Le contrôleur SDN pourrait envoyer le couple initial de paquets à un
pare-feu, et une fois que le pare-feu est satisfait/accepte le flux, le contrôleur
8
1.2 Principe du SDN
SDN peut contourner le pare-feu, ce qui supprime la charge du micrologiciel

et permet aux datacenters multi-gigabit d’être pare-feu.[15]
3. Le contrôleur SDN peut facilement implémenter l’équilibrage de charge
également à des débits de données élevés en dirigeant simplement différents
flux vers différents hôtes, en ne faisant que la configuration du flux initial.[15]
4. Le trafic peut être isolé sans avoir besoin de vlan, il peut simplement refuser
certaines connexions.
5. Configurer un réseau TAP/Sniffer facilement pour n’importe quel port ou
même un trafic spécifique en programmant le réseau pour envoyer un flux
dupliqué à un dispositif de surveillance du réseau.[15]
6. Il permet le développement de nouveaux services et idées tout en logiciel
sur le contrôleur SDN. OpenFlow-Actions.
Figure 1.5 – Commutateur SDN
1.2.2 Le contrôleur SDN

Les contrôleurs SDN (aussi appelés plateformes de contrôleurs SDN) dans
un réseau défini par logiciel (SDN) sont appelés les « cerveaux » du réseau.
Le contrôleur SDN est et l’application agissant comme un point de contrôle
centralisé dans le réseau SDN (voir Figure 1.6) Il gère également le contrôle
de flux vers les commutateurs / routeurs. Les applications et la logique mé-
tier via l’API en direction nord pour Le déploiement de réseaux intelligents
est également géré par un contrôleur. Récemment, les organisations déploient
plus de réseaux SDN, les contrôleurs sont chargés de fédérer entre les domaines
de contrôleur SDN, l’utilisation d’interfaces d’applications communes, y com-
pris OpenFlow et open virtual switch database (OVSDB). Diverses tâches de
réseau et de plate-forme de contrôleur SDN sont effectuées par un ensemble
de modules « enfichables » [11]. Les tâches comprennent l’étude des disposi-
tifs dans les réseaux, la recherche des capacités des dispositifs et la collecte
de statistiques réseau, etc. Des capacités plus avancées peuvent être prises en
9
1.2 Principe du SDN
charge en fournissant des extensions avec plus de fonctionnalités y compris des

algorithmes de routage pour effectuer des analyses et orchestrer de nouvelles
règles dans l’ensemble du réseau [11].
Figure 1.6 – Contrôleur SDN
1.2.3 Les interfaces de communication

Les interfaces de communication ou les API permettent au contrôleur d’in-
teragir avec les autres couches du réseau SDN. On leur affecté la notation
Nord/Sud/Est/Ouest selon la position de la couche avec laquelle communique
le contrôleur dans la hiérarchie de l’architecture. Pour communiquer avec une
couche basse , l’interface Sud est le plus utilisée. [25] Inversement pour les
couches hautes c’est une interface Nord et la communication entre différents
contrôleurs se fait via les interfaces Est/Ouest[25].
L’interface SUD Dans SDN, les interfaces en direction sud sont la spécifi-
cation de protocole OpenFlow qui permet la communication entre les contrô-
leurs et les commutateurs et d’autres nœuds réseau, qui est avec les compo-
sants de niveau inférieur. Cela permet au routeur d’identifier la topologie du
réseau, de déterminer les flux réseau et de mettre en œuvre la requête qui lui
est envoyée via des interfaces en direction nord [25].
Les API Southbound et notament le protocole OpenFlow permettent à
l’utilisateur de mieux contrôler le réseau et favorisent le niveau d’efficacité
du contrôleur SDN pour évoluer en fonction des demandes et des besoins
en temps réel. En outre, l’interface est une norme de l’industrie qui justifie
10
1.2 Principe du SDN
l’approche idéale que le contrôleur SDN devrait communiquer avec le plan

de transmission pour modifier les réseaux qui lui permettrait de se déplacer
progressivement avec les besoins de l’entreprise en progression. La figure 1.7
illustre le type de messages transitant par l’interface sud (Openflow), lors de
l’instauration d’une nouvelle règle sur un switch [25].
Figure 1.7 – Processus de communication entre le commutateur et le contrô-

leur
L’interface NORD Au contraire de l’API sud, les interfaces Nord (North-

bound) permettent la communication entre les composants de niveau supérieur
(voir Figure 1.8). Alors que les réseaux traditionnels utilisent un pare-feu ou
un équilibreur de charge pour contrôler le comportement du plan de données,
SDN installe des applications qui utilisent le contrôleur et ces applications
communiquent avec le contrôleur via son interface en direction nord [25]. Les
experts affirment qu’il serait plutôt difficile d’améliorer l’infrastructure du ré-
seau, car sans une interface nord, les applications du réseau devront provenir
directement des fournisseurs d’équipement, ce qui peut compliquer l’évolu-
tion. En outre, l’API nord permet aux opérateurs de réseau d’innover ou de
personnaliser les contrôles réseau et le traitement de cette tâche ne nécessite
pas d’expertise.[25]
Les API Nord sont utilisées dans différents secteurs verticaux qui com-
prennent les secteurs sans but lucratif, les établissements d’enseignement, les
11
1.3 Avantages du SDN
entreprises ,etc .[25]
Figure 1.8 – Communication entre la couche des application et le contrôleur
L’interface EST/OUEST C’est l’interface qui permet aux contrôleurs de

partager une vue commune et d’échanger des informations sur le réseau (voir
Figure 1.9). Cette interface est gérée de manière à ce que les contrôleurs du
SDN interagissent entre eux pour partager des informations. En général, nous
pouvons considérer cette interface comme un canal permettant la communica-
tion entre les différents contrôleurs d’un réseau de plusieurs domaines, chacun
disposant d’un contrôleur [25]. Ainsi, le contrôleur peut transmettre des in-
formations sur l’état du réseau et influencer les décisions de routage. Cette
interface est-ouest peut être utilisée pour améliorer entre différents domaines
du réseau SDN et donc l’évolutivité et l’interopérabilité pour les déploiements
SDN.

Parmi les avantages de SDN, nous citons [10] :
a- Approvisionnement en réseau :
SDN offre une connaissance consolidée de l’ensemble réseau, permettant la
centralisation des gestion et provisionnement.
12
Figure 1.9 – Communication entre contrôleurs
b-Meilleure gestion d’entreprise :

Des réseaux d’entreprise sont nécessaires pour construire sur demande les ma-
chines virtuelles et les technologies émergentes pour répondre aux nouvelles
exigences de l’analyse des données massives. En utilisant l’approche SDN,
les administrateurs informatiques peuvent interagir avec configuration réseau
sans affecter le réseau.
c- Amélioration de la sécurité et diminution des dépenses de fonctionnement :
Dans le SDN, les politiques d’information et de protection peuvent être régu-
lièrement contrôlé et communiqué au sein de l’organisation pour améliorer la
sécurité. Il utilise et optimise le matériel banalisé, ce qui simplifie encore plus
le processus. SDN utilise la même infrastructure à diverses fins pour éliminer
les dépenses en capital. Il est tout en raison de contrôleur SDN-centric, qui
permet de déployer le même matériel avec beaucoup d’effet.
d- Abstraction et automatisation du cloud :
L’entreprise peut également unifier les ressources du cloud facilement en ex-
traire des ressources infonuagiques à l’aide d’un RPS. L’alternance des ré-
ponses automatisées dans le nuage peut également être fait avec SDN. Dans
des environnements comme entreprise-large SD-WAN met en réseau le pro-
cessus fonctionne particulièrement bien.
13
1.4 Protocole OpenFlow

Open Flow est le standard API ouvert le plus largement établi pour les
SDN. Il fournit une spécification commune pour la mise en œuvre de dispo-
sitifs de transmission à flux ouvert et pour le canal de communication entre
les dispositifs de données et de plan de contrôle (par exemple commutateurs
et contrôleurs). [8] Le protocole OpenFlow fournit trois sources d’information
pour les systèmes d’exploitation réseau. Tout d’abord, les messages basés sur
les événements sont envoyés par des périphériques de transfert au contrôleur
lorsqu’un lien ou un changement de port est produit. Deuxièmement, les sta-
tistiques de flux sont générées par les dispositifs de transfert et collectées par
le contrôleur. Troisièmement, les messages de paquets entrants sont envoyés
par les dispositifs de réacheminement au contrôleur lorsqu’il ne sait pas quoi
faire avec un nouveau flux entrant ou parce qu’il y a une action explicite «
envoyer au contrôleur » dans l’entrée correspondante du tableau de flux. Ces
canaux d’information sont le moyen essentiel de fournir des informations sur
le niveau de flux au système d’exploitation du réseau.
1.4.1 Architecture du protocole OpenFlow

Le protocole OpenFlow (OF) est une norme dans l’architecture de réseau
défini par logiciel (SDN). Ce protocole définit la communication entre un
contrôleur SDN et le périphérique/agent réseau.
1.4.1.1 Table de flux

La table de flux est extrêmement simple dans le protocole OpenFlow.
Chaque entrée de la table de flux correspond au tuple suivant : Les tables
de flux ressemblent à la table MAC/CAM d’un commutateur traditionnel qui
stocke les adresses matérielles des hôtes. Les tables de flux stockent des en-
trées de flux ou des flux qui indiquent au commutateur SDN quoi faire avec
un paquet lorsqu’il arrive sur un port entrant.
Le commutateur correspondra à des paramètres spécifiques tels que l’adresse

IP, le numéro de port, l’adresse MAC, l’ID de VLAN, etc., sélectionnera l’en-
trée de flux la mieux adaptée dans le tableau et exécutera l’action associée à
cette entrée. Les actions peuvent consister à supprimer le paquet, à le trans-
férer vers un port différent, à inonder le paquet ou à l’envoyer au contrôleur
pour une inspection plus approfondie.
Si un commutateur n’a pas d’entrée pour un paquet, le commutateur peut
14
Figure 1.10 – L’architecture d’OpenFlow dans SDN.
Figure 1.11 – Entête du table de flux dans OpenFlow.
15
avoir une entrée par défaut ou une entrée « TABLE MISS ». Cette entrée a
la priorité la plus basse et les actions peuvent consister soit à supprimer le
paquet, soit à l’envoyer au contrôleur.
Champs de correspondance (Match Fields) Les champs de correspon-

dance sont utilisés pour trouver l’entrée correspondant au paquet, c’est-à-dire
pour l’identification du trafic. Celle-ci peut être effectuée sur la base d’une
grande quantité d’informations contenues dans l’en-tête du paquet, allant de
la couche 1 à la couche 4 du modèle OSI . La figure ci-dessous montre Certains
champs fournis par le protocole et à partir des dernières versions, il y avait
ajout d’autres possibilités d’identification telles que les champs IPV6 et les
étiquettes MPLS
Compteurs Servent essentiellement à garder des statistiques sur les flux

pour ensuite décider si une entrée de flux est active ou non . Pour chaque
table, chaque flux , chaque port, des compteurs de statistiques sont maintenus
Actions Représentent l’ensemble des instructions OpenFlow qui servent à

modifier le traitement que va subir le paquet. Les instructions supportées sont :
1. Apply-Actions : Pour appliquer les actions sur le paquet immédiatement.
2. Clear-Actions : Pour supprimer une liste des actions du paquet.
3. Write-Actions : Ajouter une liste d’actions au paquet.
4. Write-Metadata : Ajouter des données utiles pour le séquencement entre
les tables OpenFlow.
5. Goto-Table : Indique que le paquet doit être acheminé vers une table d’in-
dice supérieur.
Figure 1.12 – Table de flux
16
1.4.2 Messages OpenFlow

Le protocole OpenFlow prend en charge trois types de messages, contrôleur-
Commutateur, asynchrone et symétrique, chacun avec plusieurs sous-types.
Les messages contrôleur à commutateur sont lancés par le contrôleur et utili-
sés pour gérer ou inspecter directement l’état du commutateur. Les messages
asynchrones sont initiés par le commutateur , ils sont utilisés pour mettre
à jour le contrôleur des événements réseau et des changements à l’état du
commutateur. les messages Symétrique sont initiés par le commutateur ou le
contrôleur et ils sont envoyés sans sollicitation. Les types différentes types des
messages utilisés par OpenFlow sont décrits ci-dessous : [14]
1.4.2.1 Messages contrôleur-commutateur

Messages de contrôleur à commutateur et lancés par le contrôleur et uti-
lisés pour gérer ou inspecter directement le commutateur. Ces messages com-
prennent [14] :
- Caractéristiques : le commutateur doit demander l’identité .
- Configuration : définir et interroger les paramètres de configuration .
- Modification d’état : également appelé « flow mod », utilisé pour ajouter,
supprimer et modifier des entrées de flux/groupe.
- Lecture : obtenir des statistiques.
- Sorties de paquets : le contrôleur envoie un message au commutateur, soit
l’ID du paquet complet ou de la mémoire tampon.
- Obstacle : Les messages de demande ou de réponse sont utilisés par le contrô-
leur pour s’assurer que les dépendances des messages ont été respectées et
reçoivent une notification.
- demande de rôle : définit le rôle de son canal OpenFlow.
- Configuration asynchrone : définit un filtre supplémentaire sur le message
asynchrone qu’il souhaite recevoir sur le canal OpenFlow.[14]
1.4.2.2 Messages asynchrones

Les messages asynchrones sont initiés par le commutateur et utilisés pour
mettre à jour le contrôleur des événements réseau et des changements à l’état
du commutateur. Ces messages comprennent :
- Mise en paquet :transférer le contrôle d’un paquet au contrôleur
- Débit retiré : informer le contrôleur que le débit a été supprimé
- État du port : informer le contrôleur que l’interrupteur est tombé en panne
- Erreur : informer le contrôleur des problèmes
17
1.5 Orchestration : comparaison entre différents orchestrateurs
1.4.2.3 Messages symétriques

Les messages symétriques sont lancés par le commutateur ou le contrôleur
et envoyés sans sollicitation. Ces messages comprennent :[14]
- Hello : introduction ou maintien des messages échangés entre le commu-
tateur et le contrôleur
- Écho : envoyé par le commutateur ou le contrôleur, ils vérifient la vivacité
de la connexion et servent à mesurer la latence ou la bande passante .
- Experimenter : un moyen standard pour les commutateurs OpenFlow d’offrir
des fonctionnalités supplémentaires dans l’espace de type message OpenFlow.
Figure 1.13 – Les messages OpenFlow
1.5 Orchestration : comparaison entre différents

orchestrateurs
Kubernetes est une technologie d’orchestration de conteneurs. Sous Ku-
bernetes, la logique d’une application web est segmentée en conteneurs. Les
conteneurs sont organisés en une abstraction appelée pod (voir Figure 1.14).
Un pod peut avoir un ou plusieurs conteneurs. La logique d’un pod est exposée
au réseau par le biais d’une autre abstraction Kubernetes appelée service (voir
Figure 1.14). En bref, le réseau connaît les services Kubernetes et un service
connaît le(s) pod(s) qui contient(nt) sa logique. Dans chaque pod se trouvent
un ou plusieurs conteneurs qui réalisent la logique du pod en question [26].
Sous Kubernetes, les conteneurs, les pods et les services sont hébergés dans
un ensemble d’un ou plusieurs ordinateurs, réels ou virtuels. Dans le jargon
de Kubernetes, un ordinateur est appelé un nœud. Kubernetes fonctionne sur
18
Figure 1.14 – Le service Kubernetes expose la logique du ou des conteneurs

d’un pod au réseau.
un certain nombre de nœuds. La collection de nœuds est appelée un cluster

[26].
Les pods et les conteneurs associés à un service peuvent être hébergés sur
un certain nombre de machines. Kubernetes dispose également de fonctions
de mise à l’échelle et de tolérance aux pannes qui lui permettent de créer au-
tomatiquement plus de pods au moment de l’exécution pour répondre à une
demande accrue sans perte de service. En outre, si un pod échoue, Kubernetes
le reconstitue automatiquement. Docker Compose prend en charge les redé-
marrages automatiques en cas de défaillance, mais n’est pas destiné à prendre
en charge l’auto-scaling.
Ce qu’il faut comprendre de la différence entre Docker Compose et Kuber-

netes, c’est qu’alors que sous Docker Compose, un conteneur et son service
et réseau correspondant s’exécutent sur une seule machine, sous Kubernetes,
les conteneurs sont organisés selon une abstraction appelée pod. Un pod peut
être utilisé par un ou plusieurs services et les pods associés à un seul service
sont généralement répartis sur un certain nombre de machines.
Docker Compose Docker Compose est une technologie d’orchestration de

conteneurs destinée à exécuter un certain nombre de conteneurs sur une seule
machine hôte. Les développeurs créent un fichier Docker-Compose qui décrit
les images de conteneurs et la configuration permettant de constituer le Do-
cker Compose. Le nom par défaut de ce fichier est docker-compose.yml.
Listing ci-dessous montre un exemple de fichier docker-compose.yml.
19
1 version : “3.9”
2 services :
3 web :
4 build : .
5 ports :
6 – “5000 :5000”
7 networks :
8 – mynetwork
9 redis :
10 image : “redis :alpine”
11 networks :
12 – mynetwork
13 networks :
14 mynetwork :
listing 1 : a docker-compose file that publishes two services, web

and redis
L’une des caractéristiques intéressantes de Docker Compose est qu’il per-

met aux développeurs d’exposer un conteneur en tant que service et d’orga-
niser ce(s) service(s) sous un réseau. Cela permet à un certain nombre de
conteneurs de fonctionner sur l’hôte tout en étant organisés et isolés en fonc-
tion du réseau sous lequel le conteneur donné est exécuté.
Comme vous pouvez le voir dans le Listing 1 ci-dessus, docker-compose.yml dé-
clare un réseau nommé mynetwork à la ligne 14. Le fichier docker-compose.yml
déclare également deux services, web, à la ligne 3 et redis à la ligne 9. Ces
services s’exécutent sous le réseau, monréseau comme déclaré aux lignes 8 et
12, respectivement. Ces deux services sont isolés sous monservice. Cependant,
comme le service web expose le port 5000 à la ligne 6, les utilisateurs peuvent
accéder au conteneur du service web via le port 5000.
L’une des fonctionnalités supplémentaires de Docker Compose est qu’il

peut créer des conteneurs en utilisant des images de conteneurs qui sont hé-
bergées sur un dépôt de conteneurs tel que DockerHub. De plus, Docker Com-
pose peut créer des conteneurs à partir d’un Dockerfile stocké sur la machine
hôte. Dans le Listing 1 ci-dessus, remarquez à la ligne 10 que le service redis
utilise une image de conteneur, redis :alpine, hébergée sur Docker Hub. Ce-
pendant, le service web construit son conteneur à partir du Dockerfile local
selon l’attribut build, tel que défini à la ligne 4.
La chose importante à comprendre au sujet de Docker Compose est qu’il vous
20
permet d’exécuter de nombreux conteneurs sur un seul hôte en tant que ser-
vices distincts et chaque service peut être configuré pour fonctionner sur un
ou plusieurs services sur un réseau Docker Compose particulier. Kubernetes,
quant à lui, est destiné à exécuter des conteneurs en tant que service sur une
ou plusieurs machines, virtuelles ou réelles.
Docker Swarm Docker swarm est un outil d’orchestration de conteneurs, ce

qui signifie qu’il permet à l’utilisateur de gérer plusieurs conteneurs déployés
sur plusieurs machines hôtes.
Docker swarm est un groupe de machines physiques ou virtuelles qui exécutent
l’application Docker et qui ont été configurées pour se réunir en un cluster.
Une fois qu’un groupe de machines a été réuni en cluster, vous pouvez toujours
exécuter les commandes Docker auxquelles vous êtes habitué, mais elles seront
désormais exécutées par les machines de votre cluster. Les activités du cluster
sont contrôlées par un gestionnaire de swarm, et les machines qui ont rejoint
le cluster sont appelées des nœuds.
La différence entre Docker Swarm et Docker Compose est que Compose est
utilisé pour configurer plusieurs conteneurs dans le même hôte. Docker Swarm
est différent en ce sens qu’il s’agit d’un outil d’orchestration de conteneurs.
Cela signifie que Docker Swarm vous permet de connecter des conteneurs à
plusieurs hôtes, comme Kubernetes.
Figure 1.15 – L’Architecture de Docker Swarm
21
1.6 Cas d’utilisation
1.6 Cas d’utilisation

1.6.1 Réseau de campus et d’entreprise
Au cours des dernières années, les perceptions des gens ont fondamentale-
ment changé envers les Équipements de travail utilisés dans les entreprises et
campus universitaires. Chaque employé et étudiant utilise son propre matériel
dans son environnement de travail sous le nom de BYOD (Bring Your Own
Device)
Cela nous pousse à repenser le réseau et à lui apporter de la flexibilité qui sans
elle, les administrateurs réseau peuvent rapidement être étonnés de la quantité
de trafic à gérer. L’un de ses avantages de SDN est l’automatisation et La pro-
grammation du réseau qui semble facilement capable de résoudre les lacunes
de plus en plus complexes. Outre la virtualisation, l’une des applications les
plus intéressantes pour le campus est la programmation d’applications sen-
sibles au réseau (Application aware routing).
Ce nombre d’applications s’exécutant sur les machines des utilisateurs est
considérable (réseau médias sociaux, streaming audio et vidéo...), ce qui en-
traîne dans la plupart des cas une surcharge sur le réseau et peut conduire à
des problèmes dans les applications destinées aux entreprises ou les applica-
tions Académiques. Le SDN permet de gérer ces applications en introduisant
des priorités pour différentes applications et en installant des équilibreurs de
charge, en éliminant toute sorte d’embouteillage , un environnement pour les
professionnels et les étudiants pour profiter d’un travail fluide.
1.6.2 Centre de données

Le SDN peut également être utilisé pour remplacer l’infrastructure câblée
des réseaux de centres de données. Actuellement, des chercheurs de l’Uni-
versité de l’Illinois essaient d’utiliser des commutateurs SDN pour tester un
nouveau réseau qui a été déployé pour un centre de données. Les chercheurs
ont la capacité d’assurer la mise à l’échelle de la bande passante entre les ser-
veurs ; bien sûr, cela aurait pu être réalisé autrement, mais pas avant d’avoir
engagé trop de coûts matériels. 13 commutateurs Pica8 ont été installés et
se composent d’environ 670 ports. Une fois que les réseaux de données seront
exploités plus fréquemment par des logiciels, les vitesses d’accès deviendront
probablement beaucoup plus élevées car l’équilibrage de charge et la mise à
l’échelle de la bande passante seront assurés.
22
1.7 Internet of Things

L’Internet des objets (IOT) offre une multitude de possibilités pour au-
tomatiser les processus d’affaires, améliorer les soins de santé et fournir une
meilleure compréhension des décisions d’affaires. De nombreuses entreprises
lancent des flottes de dispositifs IoT dans le but de collecter des données per-
tinentes et de mieux gérer leurs processus, mais deux défis majeurs posent un
problème pour l’expansion de l’IoT [16] :
Les problèmes de sécurité deviennent plus complexes avec l’IOT, car il y
a tellement de points d’accès pour les pirates. En outre, l’entreprise peut avoir
de la difficulté à identifier chacun des nombreux services cloud auxquels un
appareil se connecte dans ses transmissions.
La connectivité réseau est nécessaire pour que chacun des appareils puisse
se connecter aux ressources informatiques de manière efficace.
Ces défis interdépendants peuvent être relevés grâce à un réseau défini par
logiciel (SDN). L’utilisation croissante de l’IOT coïncide avec l’objectif et la
charge de travail du SDN , ce qui permet à chacun de devenir une ressource
efficiente et efficace.[16]
1.7.1 IoT et ses Caractéristiques

Les objets physiques courants peuvent communiquer virtuellement avec
la technologie IOT, ce qui leur permet d’être conscients des événements qui
se produisent à distance ou de réagir à un événement qu’ils ne peuvent pas
détecter physiquement. Comparé aux appareils mobiles personnels, l’IoT a
une puissance de traitement, un stockage et une mémoire volatile limités. Par
conséquent, il peut être nécessaire de se connecter à une plate-forme Cloud ou
à une plate-forme Fog pour un traitement ultérieur des données. Trois com-
posants principaux permettent les fonctions IoT :
1- Matériel : le réseau d’objets ou de dispositifs connectés et intégrés de

capteurs ;
2- Logiciel : programme utilisé pour la collecte de données, le stockage, le
transport, le traitement, les instructions des dispositifs ;
3- Communication de données : protocoles et technologies d’échange de
données.[16]
23
Figure 1.16 – Domaines d’utilisation de l’IOT
Il n’existe actuellement aucune norme reconnue pour l’architecture ou la

conception des réseaux IoT. Le réseau de l’Internet des objets peut être séparé
en quatre couches principales en fonction du flux de données et des diverses
fonctionnalités [16] :
1. Couche perception/détection - comprend les nœuds et les réseaux de
perception.
2. Couche réseau/transport - comporte plusieurs sous-couches comme le
réseau d’accès, le réseau central et le réseau local
3. Couche de service/gestion - c’est là que les données sont traitées et
analysées, tandis que la couche d’application/interface est là où les données
sont recueillies.
4. Couche application/interface - L’information traitée est consommée et
présentée dans les applications opérationnelles
1.7.2 Protocoles de l’IoT

L’utilisation de la technologie IP est à la base de l’Internet des objets(IOT).
IP permet l’interopérabilité du système. Cette fonctionnalité peut ne pas sem-
bler importante aujourd’hui, mais à mesure que l’Internet des objets se déve-
24
loppe, l’interopérabilité des systèmes deviendra une fonctionnalité importante

génératrice de revenus. Ethernet/Wifi et 6LoWPAN reposent tous deux for-
tement sur IPv4 et IPv6.
Protocoles IP utilisés par l’IoT De nombreux experts considèrent les

appareils IoT comme des systèmes contraints, car ils pensent que les appareils
IoT doivent être aussi bon marché que possible et utiliser le plus petit MCU
disponible, tout en exécutant la pile de communication. Actuellement, l’adap-
tation d’Internet à l’IoT est l’une des principales priorités de la plupart des
organismes internationaux de normalisation. Si votre système ne nécessite pas
la fonctionnalité de TCP et peut utiliser la fonctionnalité plus limitée d’UDP.
C’est pourquoi 6LoWPAN (pour WSN) et CoAP (Lightweight Internet Pro-
tocol) contribuent au monde de l’IoT.
CoAP Bien que les appareils IoT puissent utiliser l’infrastructure Web,
celle-ci est trop lourde pour la plupart des applications IoT. En juillet 2013,
l’IETF a publié le protocole d’application contrainte (CoAP) pour les nœuds
et les réseaux (LLN) à faible puissance et avec perte (contraints). CoAP,
comme HTTP, est un protocole REST.
CoAP est sémantiquement cohérent avec HTTP et a même un mappage

un à un avec l’envoi et la réception HTTP. L’équipement réseau est limité par
de petits microcontrôleurs avec une petite quantité de mémoire flash et de
RAM, tandis que la limitation des réseaux locaux (par exemple 6LoWPAN)
est due à des taux d’erreur de paquets élevés et à un faible débit (dizaines
de kilobits par seconde). CoAP peut être un bon protocole pour les appareils
alimentés par batterie ou à récupération d’énergie.
Fonctionnalités de CoAP :
-CoAP utilise UDP Comme CoAP utilise UDP, certaines fonctions de TCP
sont répliquées directement dans CoAP. Par exemple, CoAP fait la distinction
entre les messages acquittables (nécessitant un acquittement) et les messages
non acquittables.
Les requêtes et les réponses sont échangées de manière asynchrone via

des messages CoAP (contrairement à HTTP, en utilisant une connexion TCP
existante).
Toutes les en-têtes, méthodes et codes d’état sont codés en binaire, ce qui
25
réduit la surcharge du débit du protocole. Cependant, cela nécessite l’utilisa-

tion d’un analyseur de protocole pour résoudre les problèmes de réseau.
CoAP répond pleinement aux besoins d’un protocole extrêmement léger

avec des propriétés de connexion persistantes [16].
1.7.3 SDN et son évolution dans les réseaux sans fil et

IoT
L’émergence de nouveaux services et applications en ligne, tant dans les
terminaux fixes que dans les appareils mobiles, a fait des réseaux de commu-
nication un point stratégique dans les entreprises, les institutions et les foyers.
L’évolution continue de ces services et la croissance de l’information circulant
sur Internet, apportent des défis imprévus aux développeurs et aux entreprises.
Les progrès dans les systèmes micro-électromécaniques (MEMS) augmentent
le développement de dispositifs qui enregistrent, traitent et envoient auto-
matiquement des informations par le réseau. Ce type de dispositif, composé
principalement de capteurs et d’actionneurs (RFID, dispositifs Bluetooth, ré-
seaux de capteurs sans fil (WSN), systèmes embarqués et communication en
champ proche (NFC)), a mené à l’origine de nouvelles idées, concepts et pa-
radigmes tels que l’Internet des objets (IoT) [9].
Cet appareil utilise différentes façons de se connecter au réseau, y compris

l’infrastructure réseau traditionnelle. À l’heure actuelle, il y a 9 milliards d’ap-
pareils connectés et un nombre de 24 milliards est prévu pour 2020 [13]. Cet
appareil utilise différentes façons de se connecter au réseau, y compris l’infra-
structure réseau traditionnelle. Cependant, les équipements traditionnels et
les protocoles réseau ne sont pas conçus pour supporter le haut niveau d’évo-
lutivité, de trafic et de mobilité. Les architectures actuelles sont inefficaces et
ont des limites importantes pour satisfaire ces nouvelles exigences.
L’infrastructure responsable de la transmission de l’information provenant

des dispositifs IoT (routeurs, commutateurs, réseaux 3G et 4G et points d’ac-
cès) devrait être adaptée aux nouveaux services post-PC (VoIP, virtualisation
des capteurs, QoS, cloud computing et applications IoT) tout en assurant la
sécurité, la stabilité, le taux élevé et la disponibilité, entre autres.
Software Defined Networking (SDN) est une architecture de réseau qui éli-
mine la rigidité présente dans les réseaux traditionnels. Sa structure permet
au comportement du réseau d’être plus flexible et adaptable aux besoins de
chaque organisation, campus, ou groupe d’utilisateurs. En outre, sa concep-
tion centralisée permet de recueillir des informations importantes sur le ré-
26
seau et de les utiliser pour améliorer et adapter leurs politiques de manière

dynamique. Le développement de ces dernières années a donné naissance à
de nouveaux concepts, tels que le système d’exploitation réseau (NOS) "NOS
tente d’émuler les progrès des systèmes informatiques" . Dans ce document,
l’évolution des principales NOS est également analysée. Avec cet outil, il est
possible de tester le concept SDN dans plusieurs projets (Home Networking,
Data centers, Security, Virtualization, Multimedia, entre autres). De même,
SDN a conduit à la conception de modèles qui intègrent et atteignent finale-
ment la convergence d’architectures communément séparées (Wifi-4G-LTE).
Cependant, ces opportunités sont encore loin d’être mises en œuvre globale-
ment dans la production.[9]
1.7.4 Architecture SDN pour l’IoT

Dans l’IoT avec structure SDN, le contrôleur SDN permet de séparer le ré-
seau en sous-réseaux isolés. De plus, le contrôleur SDN communique avec l’ap-
plication IoT à l’aide d’une interface de programmation d’application (API)
unique appelée « API en direction nord ». Ce dernier analyse le trafic réseau
et prend des mesures en fonction des règles qui ont été précisées [9].
Le contrôleur, d’autre part, communique avec les commutateurs réseau en
utilisant une autre API (appelée "Southbound API") en fonction des règles
configurées. Dans l’ensemble, la combinaison IoT-SDN améliore les opérations
et la sécurité de l’IoT en permettant un contrôle complet et à distance de la
configuration du réseau sans avoir besoin de contacts directs avec les dispositifs
IoT [9].
SDN est implémenté via le protocole Openflow. Le commutateur SDN uti-
lise une table de flux, qui est similaire à la table de routage utilisée par les
routeurs traditionnels. Cependant, il soutient le chaînage et permet l’appa-
riement d’une plus grande variété de domaines, chaque flux ayant son propre
ensemble d’actions. Quand un paquet arrive à un commutateur, il est comparé
à la table de flux ; si une correspondance est détectée, les actions pertinentes
sont exécutées. Si aucune correspondance n’est identifiée, comme on s’y at-
tend avec un périphérique nouvellement inséré, le paquet reçu est transféré
au contrôleur SDN via l’API Southbound.[8] Le contrôleur inspecte alors le
paquet et prend les mesures appropriées. Il peut créer un nouveau flux sur le
commutateur pour permettre aux paquets suivants d’être routés sans l’inter-
vention du contrôleur. L’application SDN sera notifiée via l’API Northbound
[8].
27
1.8 Conclusion
Figure 1.17 – Structure de SDN avec IoT
1.8 Conclusion
Dans cette première partie, nous avons présenté une base théorique sur les
réseaux définis par logiciels(SDN) avec son architecture et ses avantages , puis
abordé les composants essentiels de cette solution afin d’appliquer ses concepts
à notre contexte. Au cours des dernières années, l’Internet des objets (IOT)
est devenu une partie intégrante de nos activités quotidiennes. Il y a une de-
mande importante pour fournir au monde davantage d’appareils intelligents.
À mesure que de plus en plus d’appareils seront connectés à Internet, il y aura
une demande croissante en matière de sécurité de l’information puisque des
renseignements sensibles peuvent être interceptés. Nous avons étudié l’intégra-
tion de SDN avec IoT pour améliorer la sécurité du système. Nous examinons
ensuite le SDN en tant que nouvelle technologie de réseau et la structure com-
binée de l’IoT et du SDN. Avec la mise en œuvre et les tests, nous avons
démontré qu’il est possible de protéger les appareils IoT qui ne peuvent utili-
ser HTTP qu’en raison de contraintes de ressources sans modifier le modèle de
modification des appareils. Dans les prochains chapitres, nous nous focalisons
sur la mise en place de l’environnement SDN et la mise en pratique de notre
solution de plan de contrôle distribué.
28
Chapitre 2
Mise en place de l’environnement
SDN
2.1 MiniNet : Émulateur réseau
Introduction
Après que nous nous sommes familiarisés avec les bases du SDN, nous al-
lons maintenant nous concentrer sur sa mise en œuvre dans le cas d’un réseau
IoT. L’objectif est de comprendre ce que signifient ces changements de para-
digme pour la conception et l’administration des réseaux. Nous examinons,
entre autres, les méthodes d’interaction avec les éléments qui interféreraient
avec la solution proposée. .

C’est un émulateur de réseau qui fait un système d’hôtes virtuels, de com-
mutateurs, de contrôleurs et de connexions. Mininet a exécuté la programma-
tion standard Linux organisée, et ses commutateurs renforcés pour profondé-
ment adaptable de direction personnalisée et la technologie SDN. Qui peut
facilement se connecter avec le système par le logiciel CLI (Command Line
Interface) et API (interface de programme d’application). Mininet est utilisé
généralement en vue de :
- rapide pour commencer un système simple,
- prenant en charge les topologies personnalisées et l’envoi de paquets,
- l’exécution de véritables projets accessibles sur Linux, sur PC, serveurs, ma-
chines virtuelles,
- ayant la capacité de partage et de recréation,
- simple à utiliser, étant dans un état d’avancement open source et dynamique.
Mininet utilise la virtualisation basée sur processus pour émuler des entités sur
un seul noyau OS en exécutant un vrai code, y compris les applications réseau
standard, le noyau OS réel et la pile réseau. Par conséquent, un projet qui
fonctionne correctement dans Mininet peut généralement passer directement
à des réseaux pratiques composés de dispositifs matériels réels. Le code qui
doit être développé dans Mininet, peut également fonctionner dans un réseau
réel sans aucune modification. Il prend en charge les réseaux à grande échelle
contenant un grand nombre d’hôtes virtuels et de commutateurs.[20]
2.1.1 Ligne de commande MiniNet

Grâce à la commande mn et les différentes options offertes par l’émula-
teur, il est possible de réaliser plusieurs formes de topologies :
- L’option –topo permet de créer trois types de topologies : Tree(Arbre), Li-
near(linéaire) et single(topologie centralisé d’un seul switch) .
- L’option pour connecter le contrôleur à notre topologie est la suivante –
controller, et si le contrôleur est distant on ajoute –controller=remote,
30
Figure 2.1 – Mininet SDN
ip= 172.17.0.4.
- D’autres options disponibles sur Mininet –switch pour choisir un modéle
de switch supporté par l’emulateur.
Après insertion de la commande "mn" suivie d’options désirées et création de
la topologie on accède à la ligne de commande Mininet identifiable par l’ex-
pression mininet > au début de chaque ligne( Hors CLI les commandes sont
précédées du symbole comme toute plateforme sous linux). Les principales
commandes de CLI sont :
- mininet > ping Pour tester la connectivité entre les différents périphériques
, aussi la commande mininet>iperf permet de mesurer la bande passante
entre les hôtes .
- mininet > net pour afficher toutes les liaisons de réseau.
- mininet>dump pour afficher toute les informations liées aux noeuds du
réseau.
- mininet > xterm h1 ouvre un terminal xterm pour chaque hôte (dans
cette exemple cette commande ouvre terminal pour hôte h1) et on peut exé-
cuter divers programme sur les différents hôtes [19].
31
2.1.2 Différentes architectures de Mininet

Dans Mininet nous avons différentes topologies comme minimal, simple(single),
linéaire, topologie arborescente(Tree), etc.
Minimal : C’est la topologie la plus basique avec deux hôtes et un com-
mutateur. Pour exécuter la topologie minimale nous lançons simplement la
commande suivante dans le fenêtre de terminal Sudo mn –topo minimal
[20]
single : C’est la topologie simple avec un commutateur et N hôtes. Pour exé-
cuter cette topologie nous exécuter la commande suivante dans la fenêtre du
terminal, c-à-d. Sudo mn – topo single,3.
Figure 2.2 – Topologie single
linear : C’est le lien entre les N hôtes et les N commutateurs . Nous pou-
vons exécuter cette topologie en écrivant la commande suivante dans fenêtre
de terminal, c-à-d. Sudo mn –topo linear,3.
Tree : Une topologie arborescente est un multi-niveau topologie avec N
32
Figure 2.3 – Topologie lineaire
niveaux et deux hôtes par commutateur. Pour exécuter cette topologie, nous
pouvons utiliser ce qui suit dans la fenêtre du terminal, c-à-d. Sudo mn – topo
tree,3
Figure 2.4 – Topologie en arbre
33
Figure 2.5 – Représentation graphique de topologies mininet
2.1.3 Topologies personnalisées

Si on veut travailler avec une topologie autre que Linear, Single ou Tree,
il faut créer une topologie personnalisée en Python. Par exemple, si on veut
créer 4 hôtes h1,h2 connecté avec un switch S1, S2 voici le script à
Figure 2.6 – Topologie personnalisée
Après, on sauvegarde le code dans un fichier lab1.py, et nous exécutons
34
la commande suivante : sudo mn –custom /chemin/vers/lab1.py –topo

mytopo
Figure 2.7 – Commandes CLI pour une exécuter une topologie personalisée
Afficher les commandes CLI Mininet :
Figure 2.8 – Commandes CLI pour afficher les commandes de Mininet.
35
Pour afficher les noeuds :
Figure 2.9 – Commandes CLI pour afficher les noeuds de Mininet
Afficher les liens :
Figure 2.10 – Commandes CLI pour afficher les liens de Mininet
Pour afficher tous les informations sur les noeuds :
Figure 2.11 – Commandes CLI pour afficher toute les informations sur les
noeuds de Mininet.
Exécuter une commande sur un process hôte :
Teste la connectivité entre les hôtes :
Pour quitter mininet :
36
Figure 2.12 – Commandes CLI pour tester la connectivité entre h1 et h2.
Figure 2.13 – Commandes CLI pour tester la connéctivité entre tous les
noeuds de Mininet
Figure 2.14 – Commandes CLI pour quitter le Mininet.
37
2.2 Open vSwitch
2.2 Open vSwitch

OpenvSwitch, parfois abrégé en OVS, est dit aussi un commutateur Open-
Flow open source qui fonctionne comme un commutateur virtuel dans les
environnements virtualisés tels que KVM. Il est également utilisé comme logi-
Figure 2.15 – Open vSwitch
ciel multicouche pour interconnecter des périphériques virtuels dans le même

hôte ou entre différents hôtes. Actuellement, OpenvSwitch peut fonctionner
sur n’importe quelle plate-forme de virtualisation basée sur Linux, notam-
ment : KVM, VirtualBox, Xen, Xen Cloud Platform, XenServer.[4] OpenvS-
witch comporte huit éléments principaux : ovs-vswitchd, le module du noyau
Linux, ovsdb-server, ovs-dpctl, ovs-vsctl, ovs-appctl, ovs-ofctl et ovs-pki. Ovs-
vswitchd est un démon qui implémente le commutateur. Le module du noyau
Linux est destiné à la commutation basée sur les flux. Ovsdb-server est un
serveur de base de données léger. Ovs-dpctl est un outil de configuration du
module du noyau du commutateur. Ovs-appctl est un utilitaire qui envoie des
commandes à l’exécution de démons Open vSwitch. Ovs-ofctl est un utilitaire
pour contrôler les fonctionnalités OpenFlow d’OVS. Ovs-pki est un utilitaire
de création et de gestion de l’infrastructure à clé publique.[3]
38
2.3 Ryu, contrôleur SDN

Ryu Controller est un contrôleur de réseau ouvert et défini par logiciel
(SDN) conçu pour augmenter l’agilité du réseau en le rendant facile à gérer
et à adapter la façon dont le trafic est géré. En général, le contrôleur SDN est
le cerveau de l’environnement SDN, communiquant des informations vers les
commutateurs et les routeurs avec les API en direction sud, et jusqu’aux ap-
plications et la logique d’affaires avec les API en direction nord. Le contrôleur
Ryu est pris en charge par NTT et est également déployé dans les centres de
données cloud NTT. Le contrôleur Ryu fournit des composants logiciels, avec
Figure 2.16 – Contrôleur RYU
des interfaces de programme d’application (API) bien définies, qui permettent

aux développeurs de créer facilement de nouvelles applications de gestion et
de contrôle de réseau. Cette approche aide les organisations à personnaliser
les déploiements pour répondre à leurs besoins spécifiques ; les développeurs
peuvent rapidement et facilement modifier les composants existants ou mettre
en œuvre les leurs pour s’assurer que le réseau sous-jacent peut répondre aux
demandes changeantes de leurs applications.[5]
2.3.1 Comparaison entre un contrôleur centralisé et un

contrôleur distribué
Software Defined Networking (SDN) découple les plans de données et de
contrôle pour simplifier la procédure de gestion. Les fonctions du plan de
contrôle SDN consistent à gérer le réseau global via une vue globale du réseau,
à définir des stratégies pour les flux entrants et à appliquer ces stratégies à
l’aide d’un environnement de contrôleur centralisé ou distribué.
39
2.3.1.1 Contrôleur centralisé

Un plan de contrôle physiquement centralisé composé d’un contrôleur
unique pour l’ensemble du réseau ,est un choix de conception théoriquement
parfait en termes de simplicité. Cependant, un seul système de contrôle peut
ne pas suivre la croissance du réseau. Il est susceptible de devenir submergé
(bouton du contrôleur) tout en traitant un nombre croissant de demandes et
en luttant simultanément pour atteindre les mêmes performances Garantir.
Le contrôleur NOX est considéré comme le premier contrôleur SDN ; il est
entièrement programmable. Mais il présente de nombreuses limites telles que
l’évolutivité, la fiabilité et la flexibilité pour gérer le grand nombre de flux
entrants. Il ne prend en charge que l’architecture centralisée en raison de ses
limites. De plus, le contrôleur NOX prend en charge la granularité de contrôle
du trafic entrant en utilisant le principe basé sur le flux. De la même manière,
Ethane est le premier modèle d’architecture de réseau construit à l’Université
de Stanford qui prend en charge les contrôleurs centralisés pour définir, appli-
quer et mettre en œuvre la stratégie à l’aide d’un système d’exploitation réseau
unique (NOS). Floodlight est un autre contrôleur centralisé commun basé sur
Figure 2.17 – Contrôleur Centralisé
Java et développé par Big Switch Networks. Il existe de nombreux problèmes

liés au contrôleur de projecteur. Ainsi, une nouvelle version de Floodlight a
été conçue et publiée pour surmonter ces problèmes tels que SEFloodlight . De
plus, une étude a analysé les problèmes des contrôleurs centralisés en termes
de perspectives de sécurité. Nicira Networks a développé un contrôleur SDN
amélioré connu sous le nom de NOX-MT pour améliorer les performances du
contrôleur NOX.
40
2.3.1.2 Contrôleur distribué

Pour résoudre les problèmes liés aux contrôleurs SDN centralisés uniques,
des contrôleurs distribués ont donc été placés pour résoudre les problèmes évi-
dents tels que le point de défaillance unique et l’évolutivité. Les contrôleurs
distribués sont divisés en architecture plate et hiérarchique. Dans lequel l’ar-
chitecture plate divise les zones du réseau et un seul contrôleur gère chaque
zone, cet aspect résout les problèmes de goulot d’étranglement puisque chaque
contrôleur gère la seule petite quantité de trafic et assure éventuellement la
disponibilité. HyperFlow est un contrôleur distribué qui résout le problème du
point de défaillance unique et de la résilience. Il gère la tolérance aux pannes
en utilisant une technique de détection.
De même, ONOS se concentre sur la tolérance aux pannes pour assurer la
Figure 2.18 – Contrôleur Distribué
continuité du réseau. La connexion de chaque commutateur openflow à de

nombreux contrôleurs est la force de l’architecture ONOS. D’autre part, l’or-
ganisation de l’architecture hiérarchique au plan de contrôle permet d’obtenir
de meilleures performances et évolutivité. Nous expliquerons les comparaisons
entre les contrôleurs SDN centralisés et distribués uniques en utilisant une ap-
plication d’équilibrage de charge avec plusieurs algorithmes à savoir Aléatoire,
Round Robin et Round Robin pondéré, en termes de temps de réponse et de
nombre de transactions.
Les contrôleurs distribués offrent de meilleures performances que les centralisé
en termes de temps de réponse, de taux de transactions et d’évolutivité.
Ainsi, l’utilisation de contrôleurs distribués serait une bonne option, mais elle
ne nécessite que la redondance ou le concept (deux de tout). L’architecture des
41
contrôleurs distribués assure une tolérance aux pannes qui garantit à son tour
la disponibilité du réseau. De plus, la mise à l’échelle du réseau nécessite un
tel type de contrôleurs distribués pour prendre en charge la grande quantité
de trafics entrants et obtenir également un nombre élevé de transactions.[24]
2.3.2 Création d’une topologie avec MiniNet

Nous avons exécuté diverses topologies sur Mininet. Quand nous utilisons
toute la topologie, il crée hôte et commutateurs. Par exemple : Si nous utilisons
la topologie linéaire, c-à-d Sudo mn –topo linear, 4.Cette topologie crée 4
hôtes (h1, h2, h3, h4) et 4 commutateurs (s1, s2, s3, s4). Lorsque nous utilisons
l’instruction pingall dans Mininet, elle vérifie la connexion entre chaque hôte
créé. Lorsque nous faisons pingall entre les hôtes dans le réseau, le flux de
paquets a lieu ; cela signifie qu’il existe une possibilité d’accessibilité entre les
hôtes. Par conséquent, nous pensons que s’il y a une connectivité entre les
hôtes, il y a aussi des chances d’envoyer des fichiers entre les hôtes avec le
réseau Mininet. Pour que cela arrive vraiment (i.e. l’envoi de fichiers entre les
hôtes), nous avons utilisé la commande wget fonctionnalité de Linux dans
Mininet. Nous pouvons utiliser n’importe lequel de topologie.
Figure 2.19 – Miniedit un simple éditeur graphique pour Mininet
2.3.2.1 Création d’une topologie personnalisée en utilisant l’inter-

face MiniEdit
Le simulateur de réseau Mininet inclut MiniEdit, un simple éditeur gra-
phique pour Mininet.
42
Figure 2.20 – L’interface de MiniEdit
MiniEdit est un outil expérimental créé pour démontrer comment Mininet

peut être étendu. Démarrer MiniEdit Le script MiniEdit se trouve dans le
dossier des exemples de Mininet. Pour exécuter MiniEdit, exécutez la com-
mande :
sudo /mininet/examples/miniedit.py
MiniEdit a une interface utilisateur simple qui présente un canevas avec

une rangée d’icônes d’outils sur le côté gauche de la fenêtre et une barre de
menus en haut de la fenêtre.
Figure 2.21 – Ajouter des hôtes, des commutateurs et des contrôleurs
43
Nous allons d’abord ajouter quelques hôtes au scénario de réseau. Cliquez

sur l’icône Hôte, puis déplacez le pointeur vers l’emplacement sur le canevas
MiniEdit où vous souhaitez que l’hôte apparaisse, puis cliquez à nouveau. Une
icône d’hôte apparaîtra sur le canevas. Tant que l’outil Hôte est actif, vous
pouvez ajouter d’autres hôtes. Continuez à cliquer à chaque endroit du canevas
où vous souhaitez qu’un hôte apparaisse. Dans cet exemple, nous ajouterons
dix hôtes.
Figure 2.22 – Connecter les nœuds ensemble
Ajoutez huit commutateurs et trois contrôleurs en utilisant la même mé-

thode : Cliquez sur l’outil Commutateur et ajoutez des commutateurs, puis
cliquez sur l’outil Contrôleur et ajoutez des contrôleurs.
Figure 2.23 – Modifier chaque contrôleur pour qu’il utilise un numéro de

port unique
44
Ensuite, ajoutez des liens entre les nœuds sur le canevas. Cliquez sur l’outil
NetLink, puis cliquez sur un nœud et faites glisser le lien vers un autre nœud.
Par exemple : connectez un hôte à un commutateur ou un commutateur à
un autre commutateur. Connectez chaque hôte à au moins un commutateur.
Connectez les commutateurs ensemble pour créer un réseau. Ensuite, connec-
tez chaque commutateur à l’un des contrôleurs.
Votre réseau terminé devrait être similaire au réseau affiché dans la cap-
ture d’écran ci-dessous :
Figure 2.24 – Paramètres par défaut des préférences MiniEdit
-Configurer les contrôleurs :

Modifiez chaque contrôleur afin qu’il utilise un numéro de port unique Nous
avons trois contrôleurs. Dans cet exemple de base, nous utiliserons le contrô-
leur de référence OpenFlow par défaut intégré à Mininet. Cependant, nous
devons configurer chaque contrôleur afin qu’il utilise un port différent. Cliquez
avec le bouton droit sur chaque contrôleur et sélectionnez Propriétés dans le
menu qui s’affiche. Le numéro de port par défaut pour chaque contrôleur est
6633. Modifiez-le afin que les numéros de port utilisés par les contrôleurs c0,
c1 et c2 soient respectivement 6633, 6634 et 6635.
45
Figure 2.25 – Définir l’option CLI
-Définir les préférences de MiniEdit :
Figure 2.26 – La console MiniEdit affiche l’invite Mininet
Définissez l’option Démarrer CLI Par défaut, la fenêtre de la console Mi-

niEdit ne permet pas à l’utilisateur d’accéder à l’interface de ligne de com-
mande Mininet.
Si vous souhaitez pouvoir utiliser la CLI Mininet lorsqu’une simulation est

en cours d’exécution, cochez la case Start CLI. Vous pouvez également définir
la version d’OpenFlow que vous utiliserez.
-Enregistrement des préférences : Les préférences MiniEdit sont enregistrées
dans le fichier de topologie MiniEdit pour chaque scénario, vous pouvez donc
46
2.4 Conclusion
avoir des préférences différentes pour chaque scénario enregistré. Enregistrer

la configuration
Figure 2.27 – Fenêtre Résumé OVS.
2.4 Conclusion
Dans ce chapitre, nous avons examiné les outils qui seront utilisés pour
compléter le scénario sur lequel le prochain chapitre se concentrera. Nous
avons recherché et testé chaque élément de l’architecture pour montrer les
différentes fonctionnalités mais plus précisément pour démontrer sa fiabilité
et son efficacité. Dans le prochain chapitre, on va realiser le reste du travail
sur le dashboard de kubernetes à l’aide des YAML file et Kubectl.
47
Chapitre 3
Mise en pratique & Comparaison
3.1 Différence entre la conteneurisation et la virtualisation
Introduction
Dans ce chapitre, nous présentons notre contribution principale qui dans la
programmation et l’administration d’un réseau de type SDN et la proposition
d’une solution de routage sensible aux réseaux d’autre part. L’objectif est
d’expliquer comment administrer un réseau et évaluer les fonctionnalités et
la performance de routage offertes par le SDN . Pour cela nous avons pris un
orchestrateur Kubernetes pour faire equilibrer les charges sur le controlleur
SDN (RYU dans notre cas ).
3.1 Différence entre la conteneurisation et la vir-

tualisation
Les conteneurs et les machines virtuelles sont les deux approches les plus
populaires pour mettre en place une infrastructure logicielle pour votre orga-
nisation.[27]
Figure 3.1 – Container Vs Virtuel machine
Les conteneurs sont maintenant un acteur majeur dans le développement

cloud natif. Combinés à des machines virtuelles (VM) ou utilisés individuelle-
ment, ils offrent d’innombrables avantages pour votre système informatique.
De nombreuses entreprises peinent à comprendre la différence entre conte-
neurisation et virtualisation. Ils diffèrent en capacités, mais sont similaires
à certains égards. Les deux améliorent l’efficacité, introduisent la flexibilité,
fournissent l’évolutivité et optimisent le cycle de vie de développement[27].
Vous pouvez utiliser la conteneurisation et la virtualisation ensemble pour

améliorer l’efficacité de votre équipe informatique et répondre aux besoins de
49
l’entreprise. Cependant, ils peuvent aussi être déroutants pour les nouveaux
utilisateurs des outils de virtualisation.
3.1.1 Virtualisation : Machine Virtuelle

La virtualisation désigne le processus consistant à utiliser un logiciel pour
créer une ressource virtuelle qui fonctionne sur une couche distincte du ma-
tériel physique. Le cas d’utilisation le plus courant de la virtualisation est le
cloud computing. Vous pouvez exécuter plusieurs VM sur un ordinateur grâce
à la virtualisation. Ces VM sont des systèmes indépendants mais partagent
la même infrastructure informatique physique et sont gérées par l’hypervi-
seur[27].
La virtualisation a pris une importance considérable dans le domaine récent
des logiciels. Le marché mondial de la virtualisation des applications devrait
être évalué à 5,76 milliards de dollars d’ici 2026. En effet, la virtualisation
permet aux utilisateurs d’accéder aux applications et aux fonctionnalités sans
les installer sur l’ordinateur.[27]
Cette technologie basée sur le cloud permet d’économiser de l’argent, du
temps et de l’espace de stockage tout en offrant toutes les capacités de cloud
computing. Les grandes entreprises et les petites entreprises en profitent. Voici
certains des avantages de la virtualisation [27] :
- Disponibilité de toutes les ressources du système d’exploitation pour les

applications
- Fonctionnalité bien établie
- Meilleurs outils et contrôles de sécurité
- Outils de gestion robustes
- Économies de coûts et haute efficacité Charge de travail centralisée sans frais
généraux
50
Figure 3.2 – Virtualisation
3.1.2 Conteneurisation : Docker

Comme mentionné précédemment, la conteneurisation est le processus
d’empaquetage de chaque composant nécessaire pour exécuter une application
ou un microservice, y compris les bibliothèques associées. Chaque conteneur
se compose de codes, de dépendances et du système d’exploitation lui-même
de la machine mère. Il permet aux applications de fonctionner de la même
manière sur plusieurs plates-formes.[23]
La conteneurisation est une forme de virtualisation du système d’exploita-

tion qui exploite les fonctionnalités du système d’exploitation hôte pour isoler
les processus et contrôler leur accès à la mémoire, à l’espace disque et aux
processeurs.
51
L’avènement de la conteneurisation a commencé avec Docker, une plate-

forme open-source pour construire, déployer et gérer des applications conte-
neurisées.[23] Avec son introduction en 2013, la technologie des conteneurs et
l’écosystème ont énormément évolué.
Figure 3.3 – conteneurisation
Voici quelques avantages de la conteneurisation :

- Réduction de l’occupation des ressources de gestion des IT
- Exigences de petite taille
- Moins de code pour migrer, transférer ou télécharger les charges de travail.
La conteneurisation fonctionne en partageant le noyau du système d’exploi-
tation hôte avec d’autres conteneurs en tant que ressource en lecture seule.
Vous pouvez déployer plusieurs conteneurs sur un seul serveur ou une seule
52
3.2 Mise en pratique : virtualisation vs dockerisation
machine virtuelle car ils sont légers et évolutifs.

De cette façon, vous ne maintenez qu’un seul OS et ne consacrez pas un serveur
entier à une seule application. La conteneurisation est la réponse à plusieurs
problèmes DevOps. C’est pourquoi plusieurs entreprises adoptent cette ap-
proche pour migrer les services gérés vers le cloud.
Les conteneurs vous permettent de décomposer les applications en leurs plus
petits composants ou microservices. Ces services sont développés et déployés
indépendamment, éliminant une unité monolithique.[27]
3.2 Mise en pratique : virtualisation vs docke-

risation
3.2.1 Virtualisation
Figure 3.4 – Virtualisation
Pour installer Mininet sur une machine virtuelle il faut d’abord mettre à
jour la VM via la commande :
sudo apt-get update

sudo apt-get upgrade
sudo apt-get dist-upgrade
Puis installer les logiciels requis comme Git : sudo apt-get install git
installer mininet avec l’option ‘-n’ pour installer les dépendances MiniNet et
les fichiers de base. L’option ‘-a’ installe tous les paquets, cependant, ceux-ci
ont été installés sur Ubuntu indépendamment . [1]
53
Ceci installe la dernière version de contrôleur Ryu :
Le répertoire d’accueil de l’application ryu est :
Testez le logiciel installé. Ouvrez trois terminaux. Exécutez également Wi-

reshark pour surveiller l’interface de bouclage. Dans le terminal numéro 1,
lancez le gestionnaire Ryu pour un simple commutateur.[1]
Dans le terminal numéro 2, exécutez le réseau Mininet pour interagir avec le

contrôleur Ryu sur l’adresse IP de bouclage au port par défaut 6653.[1]
54
Lorsque la topologie mininet est terminée à l’aide de la commande ‘quit’,

il est nécessaire de nettoyer, en particulier si elle s’est écrasée ou si le terminal
est fermé. Le nettoyage supprime les tunnels, les chemins de données kernal
ou OvS qui restent après que mininet a quitté, ces derniers peuvent laisser un
impact sur le fonctionnement futur de l’émulateur.
55
3.2.2 Dockerisation
Pour commencer, on prépare nos deux conteneurs contenant chacune l’image
de Mininet et l’image du contrôleur(RYU dans notre cas). On tire ces images
a partir du Docker hub.[1]
Figure 3.5 – Pulling the Controller’s image from Docker Hub
56
Pour vérifier que nos images est sur notre machine, on utilise la commande :
Docker images
Figure 3.6 – Vérification de l’existence de l’image tirer du Docker Hub
Pour la création des deux conteneurs on utilise les deux commandes suivantes :
— docker run -it –rm –privileged -e DISPLAY -v /tmp/.X11-

unix :/tmp/.X11-unix -v /lib/modules :/lib/modules iwa-
seyusuke/mininet
— docker run -it –rm osrg/ryu /bin/bash
Après avoir créer nos deux conteneurs on vérifie leur existence en tapant la
commande suivante :
Docker ps -a
Cette commande permet de lister toutes les conteneurs dans les deux états
possibles : Running or Exited avec toutes les autres informations necessaires.
57
Figure 3.7 – Lister Les images existants sur notre machine
Pour ouvrir le Shell dans nos conteneurs on utilise la commande suivante :
Docker exec -it -ID du conteneur- bash
Figure 3.8 – Shell dans le container du Mininet
Et maintenant, on exécute les commandes nécessaires pour la création de

la topologie et le test du Ping.
Après avoir apporter des modification dans nos conteneurs, et pour pouvoir
sauvegarder leur état on exécute la commande suivante :
docker commit idContainer newName Ceci permet de créer une nouvelle
image qu’on peut l’exporter vers Docker Hub
58
3.3 Mise en pratique : contrôle centralisé vs contrôle distribué
Figure 3.9 – New Controller image pushed to Docker Hub
3.3 Mise en pratique : contrôle centralisé vs contrôle

distribué
3.3.1 Topologie personnalisée
59
3.3 Mise en pratique : contrôle centralisé vs contrôle distribué
3.3.2 Contrôle centralisé

On exécute la commande Python Topologie.py pour fonctionner la to-
pologie sur Mininet.
Puis la commande ryu-manager ryu.app.simple switch 13 pour visualiser
les paquets entre les hosts.
Figure 3.10 – Utilisation d’un seul contrôleur
60
3.4 Évaluation des performances
3.3.3 Contrôle Distribué

De même que le contrôle centralisé, seulement on utilise deux contrôleurs.
Figure 3.11 – Contrôle distribué

3.4.1 Débit TCP
On utilise iperf pour faire une évaluation de base de la performance sur
mininet . En outre, on va utiliser un script shell simple pour obtenir les résul-
tats de l’évaluation, puis utiliser gnuplot pour dessiner le graphique[17].
1- Creation d’une topologie :
Sudo mn —topo [single, linear,tree],[no-hosts]
2- utiliser xterm pour ouvrir des fenêtres pour h1 et h2 :
Xterm h1 h2
3- Fonctionner le serveur TCP sur h2 et puis h1 :
Iperf -s -p 5566 -i 1 > result
Iperf -c 10.0.0.2 -p 5566 -t 15
61
4- Collecter les données pour le plotting dans le fichier new-

result :
Cat result | grep sec | head -15 | tr - " " | awk ’print 4,8 > new-result
5- Dessiner le graphe : En utilisant Gnuplot :
gnuplot
Gnuplot > plot “newresult” title “donner un nom à votre courbe” with linespoints
Maintenant on va tester le TCP des différentes topologies avec iperf :[28]
Single Linear Tree
sudo mn –topo single,2 sudo mn –topo linear,2 sudo mn –topo tree, 2
Evaluation de debit TCP sur les différentes topologies sur une machine
virtuel et un conteneur
3.4.2 Débit UDP

1- Création d’une topologie :
Sudo mn —topo [single, linear, tree],[no-hosts]

2- utiliser xterm pour ouvrir des fenêtres pour h1 et h2 :[18]
Xterm h1 h2
3- Suivre les packets envoyés et reçus :
h2 : tcpdump -i h2-eth0 -nn -v -tt "src host 10.0.0.1 and dst host 10.0.0.1">rec
h1 : tcpdump -i h1-eth0 -nn -v -tt "src host 10.0.0.2 and dst host 10.0.0.2">sent
5- Utiliser iperf dans h1 et h2 :
62
Iperf -s -i 1 -u > result
Iperf -c 10.0.0.2 -u -b 100k -t 10

5- Collecter les données pour le plotting dans le fichier newresult :
[29]
grep -V ARP sent | grep IP | awk ’print 8,1 | tr "," " " >sent1
grep -V ARP received | grep IP | awk ’print 8,1 | tr "," " " > rec1
6-Sort :
sort received1 > receivedsorted
sort sent1 > sentsorted
join sentsort receivedsort > combine
6- Dessiner le graphe :
En utilisant Gnuplot :
Gnuplot
Gnuplot > plot “newresult” title “Nom du courbe” with linespoints.
Maintenant on va visualiser le débit UDP des différentes topologies avec Iperf

[18] :
Single Linear Tree
sudo mn –topo single,2 sudo mn –topo linear,2 sudo mn –topo tree, 2
Evaluation de debit UDP sur les différentes topologies sur une machine
virtuel et un conteneur [18]
63
3.5 Orchestration : Kubernetes

3.5.1 Définition :
Kubernetes est un outil de gestion de conteneurs open source hébergé
par Cloud Native Computing Foundation (CNCF). Ceci est également connu
comme la version améliorée de Borg qui a été développé par Google pour gé-
rer à la fois les processus de longue durée et les travaux par lots, qui a été
auparavant géré par des systèmes séparés.
Kubernetes est livré avec une capacité d’automatiser le déploiement, l’échelle

de l’application et les opérations des conteneurs d’application à travers les
grappes. Il est capable de créer une infrastructure centrée sur les conteneurs.
Voici quelques-unes des caractéristiques importantes de Kubernetes.
- Poursuivre le développement, l’intégration et le déploiement.
- Infrastructure conteneurisée
- Gestion axée sur les applications
- Infrastructure à évolutivité automatique

- Uniformité de l’environnement dans les essais de développement et la pro-
duction.
- Infrastructure faiblement couplée, où chaque composant peut agir comme

une unité séparée
- Plus grande densité d’utilisation des ressources
- Infrastructure prévisible qui sera créée.
L’un des composants clés de Kubernetes est, il peut exécuter des appli-
cations sur des grappes d’infrastructures de machines physiques et virtuelles.
Il a également la capacité d’exécuter des applications sur le cloud. Il aide à
passer d’une infrastructure centrée sur l’hôte à une infrastructure centrée sur
les conteneurs.
3.5.2 Installation du kubernetes :

Pour installer Kubernetes, on doit, au premier lieu, avoir Docker sur notre
machine.
64
3.5.3 Architecture :
Kubernetes suit l’architecture maître-esclave. L’architecture Kubernetes a
un nœud maître et des nœuds esclave (worker node).
Le nœud maître comporte divers composants, tels que :
1- ETCD
2- Controller Manager
3- Scheduler
4- API Server
5- Kubectl
Et le nœud esclave (worker node) a trois composants :
1- kubelet
2- kube-proxy
3- Pods
Figure 3.12 – Architecture du kubernetes
Master : Le nœud maître est le composant le plus vital de l’architecture

Kubernetes. Il est le point d’entrée de toutes les tâches administratives. Il y
a toujours un nœud à vérifier pour la tolérance aux pannes[2].
65
Figure 3.13 – Le noeud maître
1. ETCD
Ce composant stocke les détails de configuration et les valeurs essentielles.
Il communique avec tous les autres composants pour recevoir les commandes
pour effectuer une action. Gère les règles du réseau et l’activité post-transmission.[2]
2. Controller Manager
- Un démon (serveur) qui fonctionne en boucle continue et est responsable

de la collecte des informations et de leur envoi au serveur API. Fonctionne
pour obtenir l’ensemble partagé de clusters et les changer à l’état souhaité du
serveur.
- Les contrôleurs clés sont les contrôleurs de réplication, le contrôleur end-
point, les contrôleurs d’espace de noms et les contrôleurs de compte de service.
3. Le planificateur
- Le planificateur assigne les tâches aux nœuds esclaves
- Il est chargé de distribuer la charge de travail et de stocker les informations
sur l’utilisation des ressources sur chaque nœud
- Fait le suivi de l’utilisation de la charge de travail sur les grappes et place la
charge de travail sur les ressources disponibles.
4. API Server
- Kubernetes utilise le serveur API pour effectuer toutes les opérations sur le
66
cluster
- Il s’agit d’une entité de gestion centrale qui reçoit toutes les demandes de
modification REST, en tant que client du cluster
- Met en œuvre une interface qui permet à différents outils et bibliothèques
de communiquer efficacement
5. Kubectl
- Kubectl contrôle le cluster manager de Kubernetes
Noeud Esclave :
Un nœud esclave est un serveur virtuel ou physique qui exécute les applica-
tions et est contrôlé par un noeud maître. Les pods sont planifiées sur les
nœuds esclave , qui possèdent des outils nécessaires pour les exécuter et faire
connecter. Les pods sont des ensemble de conteneurs Et pour accéder aux
applications depuis le monde extérieur, il est nécessaire de se connecter à des
noeuds esclave et non des noeuds maîtres .
Le nœud esclave (Worker node) possède les composants suivants [2] :
Figure 3.14 – Les noeuds escalves
1.Pod
Une gousse est un ou plusieurs conteneurs contrôlés comme une seule appli-
cation. Il encapsule les conteneurs d’application, les ressources de stockage et
est étiqueté par un identifiant de réseau unique et d’autres configurations qui
régulent le fonctionnement des conteneurs.
3. Kubelet
- Service chargé de la transmission des informations à destination et en pro-
venance du service de plan de contrôle
- Il récupère la configuration d’un pod à partir du serveur API et s’assure que
67
les conteneurs fonctionnent efficacement

- Le processus kubelet est responsable du maintien de l’état des travaux et du
serveur de noeuds
4. Kubernetes Proxy
- Sert d’équilibreur de charge et de proxy réseau pour effectuer le service sur
un nœud travailleur unique
- Gérer les unités sur les nœuds, les volumes, les secrets, la création de nou-
veaux conteneurs, les bilans de santé, etc.
- Un service proxy qui s’exécute sur chaque nœud et qui met les services à la
disposition de l’hôte externe.
3.5.4 Les Concepts

Cette section intitulée Concepts va nous aider à découvrir les parties du
système Kubernetes et les abstractions utilisées par Kubernetes pour repré-
senter notre cluster, et nous aider à mieux comprendre le fonctionnement de
Kubernetes.
Les concepts de Kubernetes :
Figure 3.15 – Concept du Kubernetes
— L’architecture du Cluster :
Gérés par le plan de contrôle, les nœuds de cluster sont des machines qui
exécutent des conteneurs. Chaque nœud exécute un agent pour com-
muniquer avec le plan de contrôle, le kubelet, le contrôleur principal de
Kubernetes. Chaque nœud exécute également un moteur d’exécution de
68
conteneur, tel que Docker ou rkt(Rocket). Le nœud exécute également

des composants supplémentaires pour la surveillance, la journalisation,
la découverte de services et des extras facultatifs.
Voici quelques composants de cluster Kubernetes :
Nœud :
Un cluster Kubernetes doit avoir au moins un nœud de calcul, bien

qu’il puisse en avoir plusieurs, selon le besoin de capacité. Les pods
sont orchestrés et planifiés pour s’exécuter sur des nœuds, donc davan-
tage de nœuds sont nécessaires pour augmenter la capacité du cluster.
Les nœuds connectent les applications et les ressources réseau, de cal-
cul et de stockage et ils peuvent être des machines virtuelles[2].
Figure 3.16 – Architecture des noeuds Kubernetes
Service Kubelet :
Chaque nœud de calcul comprend un kubelet, un agent qui commu-
nique avec le plan de contrôle pour s’assurer que les conteneurs d’un
pod sont en cours d’exécution. Lorsque le plan de contrôle nécessite
qu’une action spécifique se produise dans un nœud, le kubelet reçoit les
spécifications du pod via le serveur d’API et exécute l’action. Il s’assure
ensuite que les conteneurs associés sont sains et en cours d’exécution.
Service proxy Kube :
Chaque nœud de calcul contient un proxy réseau appelé kube-proxy
69
qui facilite les services de mise en réseau Kubernetes. Le kube-proxy

transfère le trafic lui-même ou s’appuie sur la couche de filtrage de pa-
quets du système d’exploitation pour gérer les communications réseau
à la fois à l’extérieur et à l’intérieur du cluster.
Pods :
Un pod représente une instance unique d’une application et l’unité la
plus simple du modèle d’objet Kubernetes. Cependant, les pods sont
centraux et cruciaux pour Kubernetes. Chaque pod est composé d’un
conteneur couplés dans une série qui vont logiquement ensemble, ainsi
que de règles qui contrôlent le fonctionnement des conteneurs.
Figure 3.17 – Architecture d’un pod du Kubernetes
Images de conteneurs :
Une image de conteneur est un paquet logiciel prêt à l’emploi, conte-

nant tout ce qui est nécessaire pour exécuter une application : le code
et tout environnement d’exécution dont il a besoin, les bibliothèques
d’application et système, et les valeurs par défaut pour tous les para-
mètres essentiels.
70
— Le stockage :
Kubernetes utilise le concept de volumes. À la base, un volume n’est

qu’un répertoire, contenant éventuellement des données, accessible à
un pod. La façon dont ce répertoire est créé, le support qui le soutient
et son contenu sont déterminés par le type de volume particulier utilisé.
Kubernetes a un certain nombre de types de stockage, et ceux-ci peuvent

être mélangés et assortis dans un pod (voir l’illustration ci-dessus). Le
stockage dans un pod peut être consommé par n’importe quel conte-
neur du pod. Le stockage survit aux redémarrages du pod, mais ce qui
se passe après la suppression du pod dépend du type de stockage spé-
cifique.
Il existe quelques types spéciaux pour montrer le stockage de fichiers

et des blocs sur un pod , comme configMap et Secrets, utilisés pour in-
jecter des informations stockées dans Kubernetes dans le pod ou emp-
tyDir, couramment utilisé comme espace de travail[2].
Figure 3.18 – Kubernetes Volumes persistants, réclamations et classes de

stockage
Les volumes persistants (PV) sont liés à une ressource de stockage exis-
tante et sont généralement provisionnés par un administrateur. Ce sont
des objets à l’échelle du cluster liés au fournisseur de stockage de sau-
vegarde qui rendent ces ressources disponibles pour la consommation.
Pour chaque pod, un PersistentVolumeClaim effectue une demande de

consommation de stockage dans un espace de noms. Selon l’utilisation
71
actuelle du PV, il peut avoir différentes phases ou états : disponible,

lié (indisponible pour les autres), libéré (nécessite une intervention ma-
nuelle) et en échec (Kubernetes n’a pas pu récupérer le PV)[2].
Enfin, les StorageClasses sont une couche d’abstraction pour différen-
cier la qualité du stockage sous-jacent. Ils peuvent être utilisés pour
séparer différentes caractéristiques, telles que les performances. Les
classes de stockage ne sont pas différentes des étiquettes ; les opéra-
teurs les utilisent pour décrire différents types de stockage, afin que le
stockage puisse être dynamiquement provisionné en fonction des de-
mandes entrantes des pods. Ils sont utilisés conjointement avec Per-
sistentVolumeClaims, qui permet aux pods de demander dynamique-
ment un nouveau stockage. Ce type d’allocation de stockage dynamique
est couramment utilisé lorsque le stockage est un service, comme dans
les fournisseurs de cloud public ou les systèmes de stockage comme
CEPH.[2]
3.5.5 Les commandes du kubernetes :

1- Disposition physique :
kubectl version : Interroger la version serveur/client utilisée

kubectl config view : Obtenir des informations de configuration
kubectl get nodes -w : Surveiller les nœuds en continu
kubectl describe node123 : Obtenez des informations sur ’node123’
2- Vue d’ensemble de l’abstraction :
kubectl get pods : Liste des pods

kubectl describe pod nginx-hl2nb : Obtenez des informations sur pod ’nginx-
hl2nb’
kubectl get svc : Services de liste
kubectl delete pod nginx-hl2nb : Détruire/supprimer une ressource
kubectl exec nginx-hl2nb /bin/sh -c NAME-OF-CONTAINER : débuger le
conteneur NAME-OF-CONTAINER.
kubectl logs -f nginx-hl2nb -c "NAME-OF-CONTAINER " : Voir les logs de
NAME-OF-CONTAINER
3- Détails de l’abstraction :
kubectl run ubuntu –image=ubuntu : Pour lancer un pod et créer implici-

tement un RC
kubectl create -f my-service.yaml : Pour créer un service à partir d’un fichier
72
YAML
kubectl apply -f deployment/pod.yaml : Pour créer un pod ou deployment à
partir d’un fichier YAML .
3.5.6 Les fichiers YAML :

Pour la réalisation de notre objectif, qui s’illustre dans le contrôle auto-
matisé du traffic, l’autoscalling ainsi que la résolution des problèmes qui vont
apparaître sur le réseau en cas de panne soit dans un contrôleur ou un host.
apiVersion : apps/v1
kind : Deployment
metadata :
name : ryu-deployment
labels :
app : ryu
spec :
replicas : 1
selector :
matchLabels :
app : ryu
template :
metadata :
labels :
app : ryu
spec :
containers :
- name : ryu
image : osrg/ryu :latest
command : ["/bin/sh","-c"]
args : ["cd ryu/ryu/app ;ryu run
simples witch1 3.pyguit opology/guit opology.py
observe links verbose”]
resources :
requests :
cpu : 0.5
limits :
cpu : 1
Fichier YAML : Deployment de RYU
73
apiVersion : autoscaling/v1
kind : HorizontalPodAutoscaler
metadata :
spec :
scaleTargetRef :
apiVersion : apps/v1
kind : Deployment
minReplicas : 1
maxReplicas : 10
targetCPUUtilizationPercentage : 50
Fichier YAML : Autoscaler (HPA) de RYU
kind : Service
apiVersion : v1
metadata :
name : ryu-controller-service
spec :
selector :
app : ryu
type : NodePort
ports :
- protocol : TCP
port : 6653
targetPort : 6653
Fichier YAML : service du contrôleur Ryu
74
3.5.7 Implémentations
Figure 3.19 – la deploiement de Ryu sous Kubernetes
Figure 3.20 – Le pod de Ryu en exécution
Figure 3.21 – la Config Map de Ryu sous Kubernetes
75
Figure 3.22 – Les propriétés du controleur Ryu
Figure 3.23 – Exécution de la commande pingall
Les courbes
Ci-dessus, on a montré l’exécution du contrôleur Ryu, l’émulateur Mininet

et containernet sous Kubernetes, il nous reste que de résoudre le problème de
Ryu, puis le connecter avec Mininet et on sera capable de voir le traffic entre
les différentes machines(hôtes) en utilisant Wireshark ou Iperf comme on a
fait déjà dans le chapitre 3 dans Docker et VM.
76
Figure 3.24 – L’exécution du deux Contrôleurs RYU sous Kubernetes
Cette image montre l’exécution de deux contrôleurs RYU sous kubernetes

Chacune dans un pod et le Mininet situé dans un docker container a l’extérieur
de kubernetes .
Figure 3.25 – L’existence de deux pods du RYU en état dans le dashboard

du kubernetes
Figure 3.26 – Le Débit de collectivité entre RYU et Mininet
Cette imprime d’écran(4.28) montre le débit des paquets transfères entre le

RYU et le mininet , en effet , la couleur rouge indique l’erreur ou bien les
paquets non transmit.
77
Les figures ci-dessous montre le processus de l’opération de la mise à

l’échelle automatique et de l’équilibrage de charge du traffic echangées entre
le Mininet et le contrôleur RYU avec l’ajout et/ou la suppression des repli-
cas(pods supplémentaires) même ajout et/ou suppression des nodes au cas où
le cas actuelle de trafic pour notre architecture dépasse ses limites (le maxi-
mum) que ce soit dans le CPU ou bien dans le taux d’occupation de mémoire
.
en effet, l’opération de le mise à l’échelle et l’équilibrage de charge sur kuber-
netes se fait en utilisant un HPA (Horizontal pod autoscaler) qui détecte le
changement de CPU/mémoire par le billet de service "Metrics Server " qui est
le responsable de comptage et la comparaison entre l’état actuelle du pod et
la limite max/min d’occupation, et selon l’état trouvé il décide soit d’ajouter
des replicas(pods) ou de les supprimer.
Figure 3.27 – Yaml file pour définir le CPU et le taux d’occupation de

mémoire du pod
78
Figure 3.28 – Installation du metrics server pour l’autoscaling
Figure 3.29 – L’ajout/La génération d’un Pod automatiquement du yaml

file
Figure 3.30 – la mise à jour du nombre de replicas du RYU(ajout)
79
3.6 Conclusion
Figure 3.31 – La mise a jour du nombre du replicas du RYU (suppression)
3.6 Conclusion
Dans ce chapitre, nous avons exploité mininet, RYU, Kubernetes, Docker,
containeret et OpenFlow. Notre contribution est fournit une interface interac-
tive qui nous permet de gérer, créer, modifier et également visualiser le réseau.
Il offre une convivialité flexible pour les administrateurs réseau. En fournissant
une vue topologique distincte pour chaque réseau, les administrateurs réseau
peuvent facilement surveiller plusieurs réseaux VLAN en temps réel.
80
3.6 Conclusion
Figure 3.32 – Architecture globale
81
Conclusion Générale
Dans ce rapport, nous avons présenté une architecture basée sur SDN-
Docker pour remettre en question l’hétérogénéité du réseau et des appareils.
Nos expériences prouvent la faisabilité de notre architecture et l’établissement
de communication entre les appareils intelligents grâce à un réseau SDN. Néan-
moins, l’architecture doit être expérimentée avec différents contrôleurs SDN
centralisés et distribués. Dans un proche avenir, nous allons tester l’archi-
tecture avec différents réseaux hétérogènes qui peuvent exister dans un en-
vironnement smart domestique comme Ethernet, WiFi et Bluetooth. Dans
les prochains travaux, nous mettrons en œuvre notre architecture avec divers
contrôleurs SDN tels que Floodlight, POX et ONOS et comparerons leurs per-
formances. Nous avons également l’intention d’utiliser un plus grand nombre
d’appareils de connexion sur lesquels les applications seront mises en œuvre
par l’intermédiaire de Dockers.
Notre objectif est d’automatiser le réseau par le concept du DevOps . En
effet, DevOps peut être utilisé pour configurer un plan de contrôle distribué,
comme IS-IS, sur tous les périphériques réseau, et aussi pour configurer un
contrôleur centralisé qui peut annuler les décisions locales du protocole de
routage de distribution pour l’ingénierie du trafic.
En effet, l’automatisation ouvre tellement de nouvelles perspectives, qui
est le pouvoir d’augmenter l’agilité, la sécurité ou même les capacités en inté-
grant de nouvelles solutions logicielles comme jamais auparavant.
Ainsi, le SDN va changer le quotidien des administrateurs qui sont moins

concernés par les opérations répétitives et fastidieuses, qui se consacrent à
des tâches qui apportent plus de valeur à l’entreprise. Notre approche est
d’abord de déployer le contrôleur Ryu, le connecter avec l’émulateur Mininet
qui, avec lequel on a interagit avec SDN en simulant notre topologie. Ensuite,
de faire l’équilibrage de charge du traffic transmis au cas de panne ou d’echec
d’un contrôleur en utilisant la propriété d’autoscaling de kubernetes sur les
contrôleurs RYU.
Ce projet nous a donné l’opportunité d’explorer un réseau basé sur SDN
avec un panneau de contrôle centralisé et distribué qui est aussi capables de
prendre en charge une grande partie de ces tâches fastidieuses. L’automatisa-
tion fournie par Kubernetes est la meilleure que nous avons vue dans notre
projet .
Notre perspective est de tester le fonctionnent des différents types de
contrôleurs (centralisés/distribués) comme ONOS, Floodlight et POX avec
kubernetes et de comparer leurs performances.
Bibliographie
[1] Containernet, 2022. (Cité en pages 53, 54 et 56.)
[2] Kubernetes orchestration, 2022. (Cité en pages 65, 66, 67, 69, 71 et 72.)
[3] Open vswitch manual, 2022. (Cité en page 38.)
[4] Openvswitch vs openflow : What are they, what’s their relationship ?,
2022. (Cité en page 38.)
[5] What’s ryu ?, 2022. (Cité en page 39.)
[6] Himanshu Arora. Software defined networking (sdn) - architecture and
role of openflow, 2022. (Cité en page 4.)
[7] Himanshu Arora. Software defined networking (sdn) - architecture and
role of openflow, 2022. (Cité en pages 6 et 8.)
[8] Nada Chendeb, Nazim Agoulmine, and Mohammad El-Assaad. Inspi-
ring from sdn to efficiently deploy iot applications in the cloud/fog/iot
ecosystem. In 8th International Workshop on ADVANCEs in ICT In-
frastructures and Services (ADVANCE 2020), pages 1–8, 2020. (Cité en
page 27.)
[9] Ihssane Choukri, Mohammed Ouzzif, and Khalid Bouragba. Software
defined networking (sdn) : Etat de l’art. In Colloque sur les Objets et
systèmes Connectés, 2019. (Cité en pages 26 et 27.)
[10] cisco. Software-defined networking, 2022. (Cité en pages 4 et 12.)
[11] Abhishek De. Software defined networking, 2022. (Cité en pages 9 et 10.)
[12] Alexis de Talhouët. The evolution of software defined networking, 2022.
(Cité en page 6.)
[13] IBM Cloud Education. What is software-defined networking (sdn) ?,
2022. (Cité en pages 4 et 26.)
[14] Hewlett Packard Enterprise. Openflow messages, 2022. (Cité en pages 17
et 18.)
[15] Chris Francis. Sdn switch vs. non-sdn switch, 2022. (Cité en pages 8
et 9.)
[16] futura. Internet des objets : qu’est-ce que c’est ?, 2022. (Cité en pages 23,
24 et 26.)
[17] Chih-Heng Ke. How to use iperf over mininet ?, 2022. (Cité en page 61.)
[18] Chih-Heng Ke. Performance measurement (get the packet delay), 2022.
(Cité en pages 62 et 63.)
BIBLIOGRAPHIE
[19] Deepak Kumar and Manu Sood. Software defined networks (sdn) : ex-
perimentation with mininet topologies. Indian Journal of Science and
Technology, 9(32), 2016. (Cité en page 31.)
[20] Mininet. Mininet overview, 2022. (Cité en pages 30 et 32.)
[21] Benoit Petit. Sdn : principes et fonctionnement, 2022. (Cité en page 6.)
[22] procica. Les réseaux sdn - software defined network, 2022. (Cité en
page 5.)
[23] rohnux2 6. Containerizationusingdocker, 2022. (Citenpages 51et 52.)
[24] Yassine Sabri, Najib El Kamoun, and Fatima Lakrami. A survey : Centrali-
zed, decentralized, and distributed control scheme in smart grid systems. In
2019 7th Mediterranean Congress of Telecommunications (CMT), pages 1–11.
IEEE, 2019. (Cité en page 42.)
[25] sanwal55. Sdn northbound interfaces (nbi) and southbound interfaces (sbi),
2022. (Cité en pages 10, 11 et 12.)
[26] stackoverflow. What’s the difference between docker compose and kuber-
netes ?, 2022. (Cité en pages 18 et 19.)
[27] Aaron Strong. Containerization vs. virtualization : What’s the difference ?,
2022. (Cité en pages 49, 50 et 53.)
[28] vmware. Software-defined networking, 2022. (Cité en page 5.)
84
BIBLIOGRAPHIE
85

Software Defined Network

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Software Defined Network

Transféré par

Droits d'auteur :

Formats disponibles

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Université Tunis El Manar

Département Technologies de l’Information et de la Communication

Projet de Fin d’Année

Oumaima NIJAOUI & Rania BOUGHANMI

Plan de contrôle SDN distribué

soutenu le 11/05/2022 devant le Jury composé de :

Rapporteur Mr Lazhar FEKIH

Ensuite, nous tenons à exprimer notre profonde gratitude à notre chère

Keywords : SDN, IoT, Distributed control plan, Mininet, Ryu, Open-

Liste des figures vi

Liste des acronymes ix

1 Software-Defined Networking (SDN) & Internet of Things

2 Mise en place de l’environnement SDN 29

2.3.1 Comparaison entre un contrôleur centralisé et un contrô-

3 Mise en pratique & Comparaison 48

1.1 Architecture du réseau traditionnel vs SDN . . . . . . . . . . . 5

2.1 Mininet SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.16 Contrôleur RYU . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.1 Container Vs Virtuel machine . . . . . . . . . . . . . . . . . . 49

3.26 Le Débit de collectivité entre RYU et Mininet . . . . . . . . . 77

1.1 Présentation du concept SDN

1.1.1 Le réseau traditionnel

1.1.2 L’évolution vers le réseau SDN

Figure 1.1 – Architecture du réseau traditionnel vs SDN

1.2 Principe du SDN

l’emploi de contrôleurs distribués servira de solution vitale [21]. La tendance

Figure 1.2 – Couche Infrastructure de l’architecture SDN

Figure 1.3 – Couche Contrôle de l’architecture SDN

l’interface de service. Des exemples d’applications incluent la découverte de

Figure 1.4 – Couche application de l’architecture SDN

Les commutateurs SDN Un commutateur SDN est essentiel pour la com-

SDN peut contourner le pare-feu, ce qui supprime la charge du micrologiciel

Figure 1.5 – Commutateur SDN

1.2.2 Le contrôleur SDN

charge en fournissant des extensions avec plus de fonctionnalités y compris des

Figure 1.6 – Contrôleur SDN

1.2.3 Les interfaces de communication

l’approche idéale que le contrôleur SDN devrait communiquer avec le plan

Figure 1.7 – Processus de communication entre le commutateur et le contrô-

L’interface NORD Au contraire de l’API sud, les interfaces Nord (North-

entreprises ,etc .[25]

Figure 1.8 – Communication entre la couche des application et le contrôleur

L’interface EST/OUEST C’est l’interface qui permet aux contrôleurs de

1.3 Avantages du SDN

Figure 1.9 – Communication entre contrôleurs

b-Meilleure gestion d’entreprise :

1.4 Protocole OpenFlow

1.4.1 Architecture du protocole OpenFlow

1.4.1.1 Table de flux

Le commutateur correspondra à des paramètres spécifiques tels que l’adresse

Si un commutateur n’a pas d’entrée pour un paquet, le commutateur peut

Figure 1.10 – L’architecture d’OpenFlow dans SDN.

Figure 1.11 – Entête du table de flux dans OpenFlow.

Champs de correspondance (Match Fields) Les champs de correspon-

Compteurs Servent essentiellement à garder des statistiques sur les flux

Actions Représentent l’ensemble des instructions OpenFlow qui servent à

Figure 1.12 – Table de flux

1.4.2 Messages OpenFlow

1.4.2.1 Messages contrôleur-commutateur

1.4.2.2 Messages asynchrones

1.4.2.3 Messages symétriques

Figure 1.13 – Les messages OpenFlow

1.5 Orchestration : comparaison entre diﬀérents