Université de Kinshasa: Faculté Des Sciences

Université de Kinshasa
Faculté des Sciences
Département des Mathématiques et Informatique

B.P.190 KINSHASA XI
MISE EN PLACE D’UNE SOLUTION SDN POUR LA

GESTION DU RESEAU :
« Application de Gestion de Load-Balancing »
Rédigé par :
MUKADI NTUMBA Chaco
Mémoire présenté et défendu en vue de

l’obtention du titre de Licencié en
Sciences.
Groupe : Informatique
Option : Gestion
Directeur
Professeur MBUYI MUKENDI Eugène
Année universitaire 2017-2018

ii
Epigraphe
« (…) Et les gagnants seront ceux qui arriveront à restructurer la

manière dont l’information circule au sein de leurs
organisations »
William Henry Bill Gates
Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.

iii
Dédicace
Je dédie ce modeste travail aux êtres les plus chers de ma vie :
-A mes très chers parents, André MUKADI et Théthé TSHIBOLA qui ont attendu, et espérer
ma réussite, ont toujours veillé sur moi avec beaucoup d’amour et de patience,
-A mes très chers frères et sœurs, Raphael, Lydie, Anne, Christian, Aimée, Divine, Grace.
- A tous ceux qui me sont chers et proche.
- A tous ceux qui ont semé en moi à tout point de vue
- A tous ceux que j’aime et ceux qui m’aiment.
- A tous ceux qui me connaissent de prêt ou de loin
Je dédie ce travail.
Toutes ces valeurs m’ont donné confiance et espoir pour continuer les études et pour
préparer ce travail.
Chaco MUKADI NTUMBA

iv
Remerciements
Je tiens à remercie le Dieu tout puissant de m’avoir accordé la santé et la volonté pour
accomplir ce travail.
Je tiens à remercier : tous ceux qui de près ou de loin, ont contribué à l’élaboration de ce
modeste travail.
Mes remerciements s’adressent essentiellement à mon directeur le professeur MBUYI

MUKENDI pour sa disponibilité et orientations.
Mes remerciements aussi à mon co-directeur le chef des travaux KABAMBA Richard pour
son encadrement et à Mr. Jean Claude MUDILU.
Je remercie également tout le personnel de l’entreprise Tendaji-Technologies;
Mon chef Renato NSUMBU et sans oublier Mr BOHARI Souleymane qui m’ont soutenu
énormément par des explications et des tests du logiciels.
Je remercie mes amis et proches de lutte, notamment : Edouard TSHONGA et Christian
MAZAMBA
Je remercie toutes les personnes qui, d’une quelconque manière, m’ont apporté leur amitié,
leur attention, leurs encouragements, leur appui et leur assistance pour que je puisse mener à
terme ce travail : Nathan NGALAMULUME, Yves KATANGA, Kelvi KANGA, Isaac NZOVU,
Josué NZABA, Grazzy MAYAMBALA, Olivia MABULU, Clarisse NTUMBA et Isaac
MUZIGWA
Je suis honoré par la présence de membres du jury d’avoir accepté ce Travail en espérant
qu’ils trouveront dans ce projet de quoi être satisfait.
Et auront la gratitude de l’enrichir avec leurs critiques et correct.
Que tous trouvent ici l’expression de ma franche et profonde reconnaissance !
Chaco MUKADI NTUMBA

v
Liste des Abréviations et Acronymes
API : Application Programming Interface

ASIC : Application Specific Integrated Circuit
CLI : Command Line Interface
HP : Hewlett Packard
HTTP : HyperText Transfer Protocol
Iaas : Infrastructure as a Service
IP : Internet Protocol
JDK : Java Development Kit
KVM : Kernel-based Virtual Machine
NAT : Network Address Translation
NIST : National Institute of Standards and Technology
ONF : Open Networking Foundation
OSI : Open Systems Interconnection
PaaS : Platform as a Service
QoS : Qualité de Service
RDP : Remote Desktop Protocol
SaaS : Software as a Service
SDN : Software Defined Network
TCP : Transmission Control Protocol
TLS : Transport Layer Security

vi
Liste des Figures
Figure I.1 : Architecture Réseau classique………………………..…………………...8

Figure I.2 : La virtualisation des systèmes………………………………….………......9
Figure I.3 : Informatique du Nuage……………………………………………...........12
Figure II.1 : Architecture SDN……………………………………………...……………16
Figure II.2 : Réseau traditionnel et SDN….……………………………...……………16
Figure II.3 : Diagramme de flux des messages OpenFlow………...………….......20
Figure II.4 : Table de flux des messages OpenFlow……………………...………....21
Figure II.5 : Schématisation d’un modèle de flux OpenFlow…………..…………21
Figure III.1 : Schéma d’un réseau SDN simple……………………….…………..…..30
Figure III.2 : Différents types de topologie réseau.………………………….….…..32
Figure IV.1 : Architecture de l’application…………………………………..…….…36
Figure IV.2 : Topologie du scénario…………………………………………..……..…41
Figure IV.3 : Fichier topomemo.py…………………………………………………….42
Figure IV.4 : Topologie du lancement de topomemo.py……………………...…43
Figure IV.5 : Exécution de la commande Help………..……………………...….…43
Figure IV.6 : Sortie des commandes net et dump……...…………………………..44
Figure IV.7 : Démarrage de l’équilibreur de charge et des servers………...…..45
Figure IV.8 : Démarrage des servers……………………………………………….….45
Figure IV.9 : Affichage des requêtes au niveau des serveurs……………… . ….45
Figure IV.10 : Requêtes des 3 premiers clients………………………………….…...46
Figure IV.11 : Requêtes des 3 derniers clients…………………………… ……..…..47

vii
Liste des Tableaux
Tableau II.1 : Résumer des caractéristiques des contrôleurs…………………..…27

1
0. INTRODUCTION GENERALE
Avec l’avènement des innovations technologiques récentes

telles que la virtualisation des systèmes, le cloud computing et le Big
Data, les limites actuelles des architectures réseaux deviennent de plus
en plus problématiques pour les opérateurs et les administrateurs
réseaux.
Durant ces dernières années, les réseaux informatiques

classiques ont connu de grands défis qui résultent principalement des
applications modernes déployées sur ces réseaux.
En effet, l’apparition du Big Data qui nécessite un traitement

distribué et l’adoption de l’infonuagique par plusieurs entreprises ont
induit le besoin d’avoir des réseaux dynamiques qui offrent la possibilité
de s’adapter rapidement aux changements des requis.
À titre d’exemple, les usagers de l’infonuagique peuvent

demander de nouvelles ressources selon leurs besoins et peuvent
changer les politiques de gestion (exp : liste de contrôle d’accès,
bande passante...) des infrastructures allouées. Dans d’autres mesures,
les infrastructures de calcul et stockage distribués des données massives
(Big Data) peuvent évoluer rapidement en adoptant de nouveaux
clusters qui peuvent contenir des milliers de serveurs et de
commutateurs.
Ces évolutions nécessitent généralement une mise à jour

des infrastructures concernées. Toutefois, la mise à jour des réseaux
classiques (ou traditionnels) est réalisée en configurant manuellement
chaque équipement ce qui peut produire plusieurs erreurs et
incohérences. De plus, ces configurations prennent beaucoup de
temps ce qui ne permet pas de faire face à l’expansion rapide du
monde des technologies d’information.
C’est dans ce contexte qu’est apparu le paradigme des

réseaux définis par logiciels en acronyme (SDN) qui permet
principalement de s’adapter à la nature dynamique des applications
susmentionnées.
En effet, SDN permet principalement de centraliser la

logique déterminant les politiques de gestion d’un réseau dans une ou
plusieurs unités appelées contrôleurs. Ces contrôleurs communiquent
avec le reste des équipements du réseau via des interfaces ouvertes.

2
De ce fait, la définition d’une politique de gestion d’un

réseau revient à écrire des programmes et les déployer dans les
contrôleurs. Dans la plupart des cas, ces programmes seront compilés,
en tenant compte de la topologie et des ressources disponibles, afin de
générer les configurations nécessaires à chaque équipement du réseau
pour mettre en œuvre les politiques désirées.
L’architecture SDN a été adoptée par plusieurs grandes

entreprises et universités à savoir, Google et Stanford. D’autre part, les
fabricants des équipements pour les réseaux tels que Cisco, HP et
Juniper offrent désormais des solutions SDN qui permettent de gérer les
centres de données.
Dans le cadre de ce travail, nous comparons les

caractéristiques des différents contrôleurs utilisés dans la mise en place
d’un réseau défini par les logiciels. Notamment, Pox, Nox, Floodlight et
Opendaylight. Au terme des analyses, les résultats prouvent l’efficacité
du contrôleur POX.
En vue de concilier la théorie à la pratique, nous avons

également développé une application de gestion de LOAD
BALANCING (Répartition de Charge) dans un environnement SDN.

3
0.1 PROBLEMATIQUE
Depuis des années, il est communément admis que les

architectures IP traditionnelles présentent, d’une part, particularité
complexes dans sa configuration, à cause de la nature distribuée des
protocoles réseaux et, d’autre part, la difficulté à son évolution, en
raison du fort couplage qui existe entre le plan de contrôle et le plan
de données des équipements d’interconnexion existants. Ce qui
engendre des contraintes importantes sur le déploiement des
applications réseaux.
Pour pallier à cette instabilité, l’intégration des

fonctionnalités relatives à l’interopérabilité des composants devient un
préalable de la conception d’infrastructures réseau.
Les principaux domaines d’innovation au cours des

dernières années sont à chercher du côté du contrôle centralisé, de la
programmabilité, et de la virtualisation. Ces innovations sont
regroupées sous l’appellation commune de SDN (ou software-defined
network) et visent à résoudre les problèmes que les entreprises
rencontrent avec leurs réseaux en leur fournissant une solution de
gestion (soit des Vlans, des Serveurs, etc) centralisée au niveau d’un
contrôleur.
Notre préoccupation se résumera au tour des questions

suivantes :
-En quoi le SDN est-il une meilleure solution pour la gestion actuelle du
réseau ?
-En quoi la répartition de charge dans un SDN est-elle meilleure que
dans un réseau traditionnel (ou classique) ?
0.2 HYPOTHESES DU TRAVAIL
Une hypothèse est selon le dictionnaire Robert Méthodique,

une proposition relative à l’expression des phénomènes naturels et qui
doit être vérifié par des faits.
A ces préoccupations exprimées sous forme des questions

au niveau de la problématique, nous avons proposé la mise en place
d’une solution SDN pour la gestion des réseaux en mettant en place
une application de répartition de charge qui serait une solution pour la
gestion des serveurs et assurer la haute disponibilité sans interruption
des services au niveau des serveurs.
4
0.3 CHOIX ET INTERET DU SUJET

0.3.1 CHOIX
Il convient de souligner que le choix d’un sujet est fonction

de plusieurs facteurs notamment les motivations personnelles, les
enseignements reçus et la filière choisie.
Cependant notre choix est poussé par le souci de savoir

comment mettre en place une solution SDN et répartir les charges au
sein d’un réseau définis par le logiciel.
0.3.2 INTERET
En sus des différentes motivations qui nous ont poussés à

exploiter des solutions, ce travail vise également à des personnels et
collectifs. Personnel, dans la mesure où nous serons le premier à le
capitaliser, et collectif puisqu’il révèle un caractère à profiter à
l’ensemble de la société. Ces intérêts sont notamment :
- Montrer l’importance actuelle du réseau définis par le logiciel
pour la gestion actuelle du réseau.
- Déterminer les points essentiels en montrant les outils et la

procédure à suivre pour mettre en place un réseau définis par le
logiciel.
- Montrer le rôle et l’importance de Load-Balancing (répartition des

charges) dans un réseau définis par le logiciel.
0.4 DELIMITATION DU SUJET
Selon Madeleine GRAWITZ, « Limiter son sujet, c’est

déterminer ce que l’on retient mais c’est aussi d’écarter un certain
nombre de problème ».
Pour mieux mener un travail de recherche, il faut qu’il soit
limité dans le temps, dans l’espace et dans le domaine.
La mise en place d’une solution SDN (software defined
network) pour la gestion du réseau, application du Load-Balancing
(répartiteur des charges).
En ce qui concerne notre travail, nous nous sommes limité
dans le temps et dans l’espace, étant donné que nous n’avions pas de

5
temps ni de moyens matériels suffisants pour effectuer une étude

couvrant toutes les fonctionnalités du Réseau définis par le logiciel
(Software defined network-SDN).
Nous nous sommes limités seulement au Load-Balancing qui
est une répartition des charges.
Du point de vue temporel, ce travail est effectué d’une
période allant de Février 2018 et Avril 2019.
Du point de vue spatial, nous nous sommes limités à parler
uniquement d’une fonctionnalité du réseau définis par le logiciel, SDN
en sigle qui est la gestion de Load-Balancing.
0.5 DIFFICULTES RENCONTREES
En effectuant nos recherches pour l’élaboration de notre travail de fin

d’étude, nous nous sommes buté à certaines difficultés :
- La recherche documentaire a été compliquée car nous n’avons

pas pu avoir des documents suffisant pour l’enrichissement de ce
sujet. Cela se justifie par le manque des moyens suffisants pour
l’accession à des bibliothèques dans des conditions normales ;
- L’auto formation des nouveaux cours et logiciels non familier.
0.6 SUBDIVISION DU TRAVAIL
Hormis l’introduction et la conclusion générale, ce présent

travail est organisé en quatre chapitres qui sont subdivisé en deux
parties.
La première partie, L’état des technologies de réseaux, qui

comprend deux chapitres. Ces chapitres, Fonctionnement des bases
de réseaux informatique et Réseau programmable : SDN, présentent
respectivement un aperçu sur les technologies actuelles des réseaux et
les détails relatifs à la technologie du SDN.
S’agissant de la seconde partie, Mise en place d’une

solution SDN, elle comprend le troisième et quatrième chapitre. Ces
derniers sont organisés comme suit : Le contrôleur SDN : POX, pour le
troisième chapitre dans lequel les différentes démarches à suivre pour
déployer un réseau SDN avec contrôleur POX sont abordées, et
l’Implémentation d’une application SDN : gestion de LOAD-BALANCING
comme quatrième chapitre, qualifié comme pratique.
6
PARTIE I :
L’ETAT DES TECHNOLOGIES DE RESEAUX

7
CHAPITRE I : FONCTIONNEMENT DE BASE DE

RESEAUX INFORMATIQUE
[1] [6] [10]
I.1 INTRODUCTION
Vu le cout d’exploitation des réseaux à grande échelle,

c’est ce qui continue à pousser aux fournisseurs des services de toujours
rechercher d’autres moyens pour réduire leur capital et les couts
opérationnels.
Ceci s’explique par l’explosion des différentes technologies,

tel que la virtualisation des serveurs, du stockage, ou encore des postes
de travail et l'apparition de l'informatique en nuage, mais avec toutes
ces innovations, nous rencontrons toujours les problèmes de
l’incapacité à faire évoluer les réseaux physiques aussi vite que les
montées en charge, ou encore une limitation dans le déploiement
automatique des ressources dans des environnements multi-clients.
Ce premier chapitre défini d’abord le réseau ensuite

présente l’architecture du réseau classique ainsi que les technologies
des réseaux utilisées actuellement tel que l'informatique en nuage, la
virtualisation, le cloud et le besoin du réseau programmable.
I.2 DEFINITION DU RESEAU
Un réseau est principalement défini par un ensemble

d’équipements qui sont connectés entre eux par des liens. Chaque lien
du réseau permet de passer une quantité spécifique de donnée
pendant une période bien définie.
I.3 ARCHITECTURE DU RESEAU CLASSIQUE
Le schéma ci-dessous décrit l’Etat de l’Art actuel d’une

architecture Réseau. Chaque nœud du réseau (Switch, Routeur) est un
boitier propriétaire. Il intègre deux fonctions (plans) principales : la
fonction Control (plan de contrôle) et la fonction Data Plane (plan de
données).
 Le plan de Control est l’intelligence du boitier, il lui permet de

déterminer les destinations que les paquets doivent atteindre. En
quelque sorte le plan de contrôle permet de prendre les décisions
de transmission.
8
Il comprend des mécanismes de transmission d'itinéraire de

couche 2 et 3, notamment la table de voisinage et la table
topologique (protocole de routage), la table de routage, etc.
 Le plan de données est la capacité de traitement du boitier, il lui

permet de faire transiter les paquets à très grande vitesse vers leur
destinataire. Le plan de données de chaque périphérique permet
de transmettre les flux de trafic. Les routeurs et les commutateurs
utilisent les informations du plan de contrôle pour transmettre le
trafic entrant vers l'interface de sortie appropriée.
Figure I.1: Architecture Réseau « classique »
Le point essentiel est que les applications ne dialoguent pas

avec le réseau, une médiation humaine est nécessaire.
I.4 LA VIRTUALISATION
La virtualisation est un ensemble de techniques matérielles

et/ou logicielles qui permettent de faire fonctionner sur une même
machine, plusieurs systèmes d’exploitation et/ou plusieurs applications,
séparément les uns des autres, comme s’ils fonctionnaient sur des
machines physiques distinctes.
On parle de :
Machine hôte = machine exécutant les différents systèmes
virtuels.
Machine invitée = machine virtuelle s'exécutant dans

l'environnement de virtualisation.

9
La virtualisation dépasse ces limites en permettant

d’exécuter simultanément plusieurs systèmes d’exploitation et plusieurs
applications sur le même ordinateur, ce qui accroît l’utilisation et la
flexibilité du matériel.
Ce concept couvre différents aspects, on peut ainsi

virtualiser les serveurs, le stockage, les applications (simplification de
l'administration) ou encore le poste client.
Figure I.2 : La virtualisation des systèmes
A ce stade, la virtualisation et l'informatique en nuage, ces

deux sujets vont de pair, les avantages de la virtualisation prennent tout
leur sens à l'échelle de l'informatique en nuage.
I.5 LE CLOUD COMPUTING (L’INFORMATIQUE EN NUAGE)
I.5.1 Définition
L’informatique en nuage ou Cloud Computing est un

concept où les ressources informatiques sont virtualisées et
dynamiquement élastiques (provisionnement et déprovisionnement
automatique).
Ces ressources sont fournies comme un service à travers

Internet, de manière transparente pour les utilisateurs.

10
I.5.2 Modèles de services
Les services cloud sont disponibles sous diverses options,

selon les besoins des clients. Dans la publication spéciale 800-145, le
NIST (National Institute of Standards and Technology) définit les
trois principaux services cloud suivants : Software as a
Service (SaaS), Platform as a Service (PaaS), Infrastructure as a
Service (IaaS).
Ces trois modèles de service doivent être déployés sur des

infrastructures qui possèdent les cinq caractéristiques essentielles citées
plus bas pour être considérées comme du Cloud Computing.
I.5.2.1 Software as a Service (SaaS) : Logiciel en tant que Service
Les applications sont mises à la disposition des utilisateurs via

le web. Ce modèle de service est caractérisé par l’utilisation d’une
application partagée qui fonctionne sur une infrastructure Cloud.
L’utilisateur accède à l’application par le réseau au travers

de divers types de terminaux (souvent via un navigateur web).
L’administrateur de l’application ne gère pas et ne contrôle pas
l’infrastructure sous-jacente (réseaux, serveurs, applications, stockage).
Il ne contrôle pas les fonctions de l’application à l’exception d’un
paramétrage de quelques fonctions utilisateurs limitées.
I.5.2.2 Platform as a Service (PaaS) : Plate-forme en tant que Service
Représente les outils et les services utilisés pour fournir les

applications.
L’utilisateur a la possibilité de créer et de déployer sur une

infrastructure Cloud PaaS ses propres applications en utilisant les
langages et les outils du fournisseur. L’utilisateur ne gère pas ou ne
contrôle pas l’infrastructure Cloud sous-jacente (réseaux, serveurs,
stockage) mais l’utilisateur contrôle l’application déployée et sa
configuration.
I.5.2.3 Infrastructure as a Service (IaaS) : Infrastructure en tant que Service
Représente le matériel et les logiciels utilisés pour les

serveurs, le stockage, les réseaux et les systèmes d’exploitation.

11
L’utilisateur loue des moyens de calcul et de stockage, des

capacités réseau et d’autres ressources indispensables (partage de
charge, pare-feu, cache).
L’utilisateur a la possibilité de déployer n’importe quel type

de logiciel incluant les systèmes d’exploitation.
L’utilisateur ne gère pas ou ne contrôle pas l’infrastructure

Cloud sous-jacente mais il a le contrôle sur les systèmes d’exploitation,
le stockage et les applications. Il peut aussi choisir les caractéristiques
principales des équipements réseau comme le partage de charge, les
pare-feu, etc.
I.5.3 Caractéristiques du cloud
Le cloud présente les caractéristiques suivantes :
 Self-service à la demande (Accès aux services par l’utilisateur à la

demande): un utilisateur peut allouer des ressources sans interaction
humaine avec le fournisseur.
 Accès réseau élargi (Accès réseau large bande): les ressources sont
accessibles via le réseau par des systèmes hétérogènes (clients
légers, clients lourds, etc.).
 Partage de ressources (Réservoir de ressources (non localisées)): les

ressources sont dynamiquement affectées, libérées puis réaffectées
à différents utilisateurs. L'utilisateur n'a pas besoin de connaître la
localisation (pays, région, centre de donnée) des ressources.
 Élasticité (Redimensionnement rapide): La mise en ligne d’une

nouvelle instance d’un serveur est réalisée en quelques minutes,
l’arrêt et le redémarrage en quelques secondes. Toutes ces
opérations peuvent s’effectuer automatiquement par des scripts. Ces
mécanismes de gestion permettent de bénéficier pleinement de la
facturation à l’usage en adaptant la puissance de calcul au trafic
instantané.
 Facturation à l’usage: Il n’y a généralement pas de coût de mise en

service (c’est l’utilisateur qui réalise les opérations).
La facturation est calculée en fonction de la durée et de la quantité de

ressources utilisées. Une unité de traitement stoppée n’est pas facturée.

12
Figure I.3 : Informatique du Nuage
I.6 UN BESOIN DU RESEAU PROGRAMMABLE
Dans l’architecture du réseau classique présenté ci-haut,

nous avons pu voir que les applications ne dialoguent pas avec le
réseau, une médiation humaine est nécessaire.
Dans ces conditions, le Réseau devient le maillon faible des

infrastructures IT. L’intervention humaine pour sa programmation fait
perdre un temps précieux, sans compter les risques d’erreurs. Ajouter à
cela que l’homme ne peut évidemment pas être aussi réactif qu’une
machine pour gérer les montées en charge soudaines.
Alors, avec toutes ces difficultés, ça nous montrent qu'il faut

trouver une solution d'automatisation adaptée aux défis de réseau,
c'est le réseau programmable.

13
I.7 CONCLUSION
Pour cela nous nous posons cette question : Est-ce que

l'informatique en nuage, la virtualisation et le cloud computing
résolvent toutes les problématiques? Non, car il reste la problématique
d'appliquer des règles réseau, d’où la sécurité n’est qu'un aspect parmi
d’autres, notamment des règles de QoS, de routage et de load-
balancing. C’est pourquoi le marché planche sur SDN.
Alors dans le chapitre suivant, nous discuterons en premier

lieu sur la technologie SDN, puis nous traiteront les différents
composants d'un réseau SDN.

14
CHAPITRE II : LE RESEAU PROGRMMABLE : SDN

[1] [2] [3] [4] [5] [7] [8] [9] [15] [16]
II.1 INTRODUCTION
Les infrastructures réseau courantes utilisent généralement

des équipements (commutateurs, routeurs. . .) dont la configuration
dépend des fabricants. Une fois déployées, il s’avère difficile de faire
évoluer ces infrastructures en adoptant de nouveaux protocoles ou en
ajoutant et supprimant des équipements.
De ce fait émerge l’idée des réseaux définis par logiciels

(SDN).
L’idée de SDN est de rendre le réseau programmable, c’est-

à-dire de permettre aux applications d’interagir directement avec les
réseaux, avec une coopération à double sens : l’application informe le
réseau du comportement désiré, le réseau informe les applications de
ses capacités. Le tout permettant d’établir un service avec des
conditions définies a priori.
Par conséquent, SDN sépare le plan de données et le plan

de contrôle. Le plan de données définit les équipements du réseau et
les connexions entre eux tandis que le plan de contrôle définit le
comportement de ce réseau.
II.2 DEFINITION
SDN signifie littéralement Software Defined Networking,

c’est-à-dire le réseau défini par logiciel. On comprend donc
immédiatement que le sujet est vaste et qu’il va être difficile d’avoir
une définition unique.
Le SDN désigne, comme son nom l’indique, le fait de piloter

une infrastructure réseau par un logiciel.
Autrement nous pouvons définir le SDN comme une

architecture qui découplait les fonctions de contrôle et de transfert des
données du réseau afin d’avoir une infrastructure physique
complètement exempte de tout service réseau.

15
Dans ce modèle, les équipements réseau se contentent

d’implémenter des règles, injectées par les applications, de traitement
des flux de données.
Plus besoin d’avoir sur ces équipements de protocoles de

routage : une entité intelligente, appelée « contrôleur » voit le réseau
dans sa globalité et injecte directement les règles de traitement des
données sur chaque équipement.
Le SDN est donc reconnue aujourd’hui comme une

architecture permettant d’ouvrir le réseau aux applications. Cela
intègre les deux volets suivants :
 Permettre aux applications de programmer le réseau afin d’en

accélérer le déploiement ;
 Permettre au réseau de mieux identifier les applications

transportées pour mieux les gérer (qualité de service, sécurité,
ingénierie de trafic...).
II. 3 ARCHITECTURE
La Figure II.1 présente une vue logique de l’architecture

typique d’un réseau SDN.
- La couche « Plan de données » est composée principalement des

équipements d’acheminement (commutateurs, routeurs...).
- La couche « Plan de contrôle » est constituée principalement d’un

contrôleur SDN qui permet d’héberger la logique de contrôle du
réseau. Ce contrôleur met en œuvre cette logique en accédant
au plan des données à travers une interface unifiée appelée
‘south-bound’.
- D’autre part, la couche « Application » représente les

programmes qui définissent la logique de contrôle du réseau. Ces
programmes sont construits moyennant une interface de
programmation appelée ‘north-bound’ et offerte par le
contrôleur. Une application de contrôle pourrait, par exemple,
définir la politique de routage ou la façon de gérer la qualité de
service (QOS) dans un réseau SDN.

16
Figure II.1 : Architecture SDN
Ci-dessous une figure comparative entre le réseau

traditionnel et le SDN :
Figure II.2 : Réseau traditionnel et SDN

17
II. 4 AVANTAGES
Offrant un réseau qui peut dynamiquement s'adapter afin

de répondre aux divers besoins des entreprises et la centralisation du
plan de contôle, SDN fournit également les avantages suivants:
II.4.1 Réduction des dépenses d'investissement
SDN limite potentiellement la nécessité d'acheter des

équipements hardware (matériels) réseau basés sur des ASICs via un
modèle « pay-as-you-grow » (payer à la croissance).
II.4.2 Réseaux programmables
Avec SDN, il est plus simple de modifier les stratégies réseau

car il suffit de changer une politique de haut niveau et non de multiples
règles dans divers équipements de réseau.
De plus, la centralisation de la logique dans un tel contrôleur

entièrement personnalisé avec des connaissances globales et une
puissance de calcul élevée, simplifient le développement des fonctions
plus sophistiquées. Cette aptitude à programmer le réseau est l'élément
clé du SDN.
II.4.3 Livrer agilité et la flexibilité
SDN aide les organisations à déployer rapidement de

nouvelles applications, les services et l'infrastructure de répondre
rapidement à l'évolution des objectifs et objectifs d'affaires.
Il apporte également une grande flexibilité dans la gestion

du réseau. Il devient facile de rediriger le trafic, d'inspecter des flux
particuliers, de tester de nouvelles stratégies ou de découvrir des flux
inattendus.
II.4.4 Routage
SDN peut également être utilisé pour gérer les informations

de routage de manière centralisée en déléguant le routage et en
utilisant une interface pour le contrôleur.

18
II.4.5 Politique unifiée
Avec son contrôleur, SDN garantit également un politique

réseau unifié et à jour, puisque le contrôleur est responsable de l'ajout
de règles dans les commutateurs, il n'y a aucun risque qu'un
administrateur de réseau ait oublié un commutateur ou installé des
règles incohérentes entre les dispositifs.
En effet, l'administrateur va simplement spécifier une

nouvelle règle et le contrôleur adaptera la configuration pour envoyer
des règles cohérentes dans chaque dispositif pertinent.
II.4.6 Simplification matérielle
SDN a tendance d'utiliser des technologies standard et de

base pour contrôler les équipements du réseau, tandis que la puissance
de calcul n'est requise qu'au niveau du contrôleur. Ainsi, les
équipements de réseau deviendront des produits à bas prix offrant des
interfaces standard.
II.4.7 Activer l'innovation
SDN permet aux organisations de créer de nouveaux types

d'applications, des services et des modèles d'affaires qui peuvent offrir
de nouvelles sources de revenus et plus de valeur à partir du réseau.
II. 5 LE PROTOCOLE OPENFLOW DANS L’ARCHITECTURE SDN
Le protocole d’injection de règles SDN le plus connu est

OpenFlow, c’est aussi ça que nous allons utiliser dans le cadre de notre
travail.
II.5.1 Introduction
Dans le fonctionnement actuel des réseaux IP, chaque

équipement de réseau (routeur IP, commutateur Ethernet, Firewall,
load-balancer, système de détection d’intrusion, NAT, etc.) exécute ses
fonctions du plan de contrôle et du plan de données.
SDN (Software Defined Network) propose de créer un point

central qui gère le plan de contrôle, tandis que les
commutateurs/routeurs physiques n’ont plus à prendre en charge que
le plan de données. Pour ce faire, l’Open Networking Foundation (ONF)
a publié OpenFlow.
19
Il s’ agit d’un protocole standard utilisé par le contrôleur

pour transmettre au commutateur des instructions qui permettent de
programmer leur plan de données et d’obtenir des informations de ces
commutateurs afin que le contrôleur puisse disposer d’une vue globale
logique (abstraction) du réseau physique.
OpenFlow est un protocole de lien entre le plan de contrôle

et le plan de données. L’échange de messages se fait au cours d’une
session TCP établie via le port 6633 du serveur contrôleur.
Cette vue est utilisée pour toutes les décisions que doit
prendre le plan de contrôle (routage, filtrage de trafic, partage de
charge, traduction d’adresse, etc).
II.5.2 La genèse d’OpenFlow
L’histoire d ’OpenFlow est intéressante et permet de mieux

comprendre son rôle fondamental dans la conception de
l’architecture SDN (Software Defined Network) et la virtualisation des
fonctions réseau.
OpenFlow a été initié comme un projet à l’université de

Stanford lorsqu’un groupe de chercheurs exploraient la manière de
tester de nouveaux protocoles dans le monde IP (créer un réseau
expérimental confondu avec le réseau de production) mais sans
arrêter le trafic du réseau de production lors des tests.
C’est dans cet environnement que les chercheurs à

Stanford ont trouvé un moyen de séparer le trafic de recherche du
trafic du réseau de production qui utilise le même réseau IP.
OpenFlow est donc un protocole ouvert (open protocol) qui

permet aux administrateurs de réseau de programmer les tables de flux
(flow tables) dans leurs différents commutateurs, chacun avec son
ensemble de fonctionnalités et caractéristiques de flux, c’est ça qui a
était le résultat de l’équipe de recherche à Stanford.
II.5.3 Structure d’un commutateur OpenFlow
Les commutateurs Ethernet et les routeurs les plus modernes

contiennent des tables de flux qui sont utilisées pour effectuer des
fonctions de transfert indiquées dans les entêtes de paquets.

20
Les principales fonctions des commutateurs sont les

suivantes :
 Fonction de support du contrôle (Control support function) :

Interagit avec la couche contrôle SDN afin de supporter la
programmabilité via les interfaces ressource-contrôle.
Le commutateur communique avec le contrôleur et le

contrôleur gère le commutateur avec le protocole OpenFlow.
OpenFlow peut être utilisé aussi bien pour du contrôle que pour de la
gestion.
 Fonction d’acheminement des données (Data forwarding

function) : Accepte les flux de données entrants provenant
d’autres équipements de réseau et des systèmes de terminaison
et les relaie sur un chemin de commutation qui a été calculé et
établi à partir des règles définies par les applications SDN, passées
au contrôleur et redescendues au commutateur.
À l'aide de la table de flux, une des actions suivantes est exécutée :
A. Relayer le paquet sur un port de sortie,

B. Supprimer le paquet,
C. Passer le paquet au contrôleur. Le paquet est encapsulé dans
un message OpenFlow PACKET_IN.
Figure II.3 : Diagramme de flux des messages OpenFlow
II.5.4 Table de flux
Chaque table de flux du commutateur contient un

ensemble d’entrées de flux qui présentent les règles d’acheminement
des paquets. Chacune est structurée comme suit :
21
Figure II.7 : Table de flux des messages OpenFlow
 Champ de correspondance (Match fields) : qui définissent le

modèle du flux de paquets à travers l'instanciation des champs
d'en-tête allant de la couche Ethernet à la couche Transport.
 Compteurs (Counters) : des compteurs sur les paquets servent

essentiellement à garder des statistiques sur les flux pour ensuite
décider si une entrée de flux est active ou non.
 Instructions (Actions) : Actions à appliquer aux paquets qui

correspondent à l’entrée de flux.
Figure II.5 : Schématisation d’un modèle de flux OpenFlow
II.5.5 Messages OpenFlow
Les messages OpenFlow entre le contrôleur et le

commutateur sont transmis via un canal sécurisé, implanté via une
connexion TLS sur TCP. Le commutateur initie la connexion TLS lorsqu’il
connaît l’adresse IP du contrôleur. Chaque message entre le
commutateur et le contrôleur commence avec l’en-tête OpenFlow.
Cet en-tête spécifie le numéro de version OpenFlow, le type

de message, la longueur de message, et l’identificateur de transaction
du message.
Il existe trois catégories de message : symétrique, contrôleur-

commutateur et asynchrone.
22
II.5.5.1 Messages symétriques
Les messages symétriques peuvent être émis indifféremment

par le contrôleur ou le commutateur sans avoir été sollicité par l’autre
entité. Par exemple, on trouve les messages HELLO qui sont échangés
une fois que le canal sécurisé a été établi.
Les messages ECHO sont utilisés par n’importe quelle entité

(contrôleur, commutateur) pendant le fonctionnement du canal pour
s’assurer que la connexion est toujours en vie et afin de mesurer la
latence et le débit courants de la connexion. Chaque message
ECHO_REQUEST doit être acquitté par un message ECHO_REPLY.
II.5.5.2 Messages asynchrones
Les messages asynchrones sont émis par le commutateur au

contrôleur sans que le commutateur ait été sollicité par le contrôleur.
Par exemple, on peut citer le message PACKET_IN qui est

utilisé par le commutateur pour passer les paquets de données au
contrôleur pour leur prise en charge (lorsqu’aucune entrée de flux ne
correspond au paquet entrant ou lorsque l’action de l’entrée
correspondante spécifie que le paquet doit être relayé au contrôleur).
Si le commutateur dispose d'une mémoire suffisante pour

mémoriser les paquets qui sont envoyés au contrôleur, les messages
PACKET-IN contiennent une partie de l’en-tête (par défaut 128 octets),
les commutateurs qui ne supportent pas de mémorisation interne (ou
ne disposant plus de mémoire) émettent le paquet entier au contrôleur
dans le message PACKET-IN.
Le commutateur peut informer le contrôleur qu’une entrée

de flux a été supprimée de la table de flux via le message
FLOW_REMOVED. Cela survient lorsqu’aucun paquet entrant n’a de
correspondance avec cette entrée pendant un temporisateur spécifié
par le contrôleur lors de la création de cette entrée au niveau de la
table de flux du commutateur.
Le message PORT_STATUS est utilisé afin de communiquer un

changement d’état du port (le lien est hors service). Finalement le
commutateur utilise le message ERROR pour notifier des erreurs au
contrôleur.

23
II.5.5.3 Messages contrôleur-commutateur
Les messages contrôleur-commutateur représentent la

catégorie la plus importante de messages OpenFlow. Ils peuvent être
représentés en cinq sous-catégories : switch configuration, command
from controller, statistics, queue configuration, et barrier.
a. Les messages switch configuration consistent en un message

unidirectionnel et deux paires de messages requête-réponse.
- Le contrôleur émet le message unidirectionnel SET_CONFIG afin

de positionner les paramètres de configuration du commutateur.
- Le contrôleur utilise la paire de message FEATURES_REQUEST et

FEATURES_REPLY afin d’interroger le commutateur au sujet des
fonctionnalités (notamment optionnelles) qu’il supporte.
- La paire de message GET_CONFIG_REQUEST et

GET_CONFIG_REPLY est utilisée afin d’obtenir la configuration du
commutateur.
b. Les messages command from controller sont au nombre de 3.

PACKET-OUT est analogue à PACKET_IN mentionné précédemment.
- Le contrôleur utilise PACKET_OUT afin d’émettre des paquets de

données au commutateur pour leur acheminement via le plan
usager (Plan de données).
- Le contrôleur modifie les entrées de flux existantes dans le

commutateur via le message FLOW_MOD.
- PORT_MOD est utilisé pour modifier l’état d’un port OpenFlow.
c. Des statistiques sont obtenues du commutateur par le contrôleur via

la paire de message STATS_REQUEST et STATS_REPLY.
d. La configuration de files d’attente associées à un port n’est pas

spécifiée par OpenFlow. Un autre protocole de configuration doit être
utilisé pour ce faire. Toutefois le contrôleur peut interroger le
commutateur via QUEUE_GET_CONFIG_REQUEST acquitté par
QUEUE_GET_CONFIG_REPLY pour apprendre quelle est la configuration
des files d’attente associées à un port afin de pourvoir acheminer des
paquets sur des file d’attente spécifiques et ainsi fournir à ces paquets
un niveau de QoS désiré.
24
e. Le message BARRIER_REQUEST est utilisé par le contrôleur pour

s’assurer que tous les messages OpenFlow émis par le contrôleur et qui
ont précédé cette requête ont été reçus et traités par le commutateur.
II.6 QUELQUES CONTROLEURS SDN
Le contrôleur est, quant à lui, piloté par le besoin des

applications. On dit que le contrôleur fournit une abstraction du plan
de transport aux applications.
La notion d’abstraction signifie que le contrôleur offre des

interfaces programmables aux applications réseaux (les interfaces sont
nommées API) et le contrôleur se charge de piloter le plan de données
en injectant des règles d’acheminement spécifiques répondant aux
besoins des applications sans que les applications connaissent ces
règles.
La couche d’abstraction du contrôleur comporte

une interface de programmation (interface Nord) qui fournit des
fonctions génériques et banalisées de manipulation du réseau de
transport en cachant les détails techniques des entités du réseau. Ceci
permet à une application d’informer le contrôleur des besoins de
traitement de flux de manière générale en faisant abstraction des
détails technique du matériel.
Le contrôleur SDN fournit une API aux « applications SDN »

qui inclut cette vue globale. Ces applications implémentent, via le
contrôleur, des services tels que le routage de flux, la mise en œuvre de
politiques de QoS pour les flux, la sécurité de bout en bout des flux, le
filtrage de flux, etc. Cette approche permet une mise en œuvre flexible
et rapide de nouvelles applications réseau qui émule les « appliances »
réseau.
Le contrôleur SDN permet d’implémenter un changement

sur le réseau en traduisant une demande globale en une suite
d’opérations sur les équipements réseau (ajouts d’états Openflow,
configuration en CLI…), les ordres sont donnés au contrôleur par une
application via une API dite « Northbound » ou nord. Le contrôleur
communique avec les équipements via une ou plusieurs API dites «
Southbound » ou sud. Openflow se positionne comme une API sud
agissant directement sur le plan de données.

25
Plusieurs contrôleurs ont été développés, dont la majorité

sont open source et supportent le protocole OpenFlow. Ces contrôleurs
diffèrent par leurs langages de programmation, la version d’OpenFlow
supportée, les techniques utilisées comme le multi-threading et les
performances comme le débit.
Nous présentons ci-dessous une liste non exhaustive des

contrôleurs SDN:
II.6.1 NOX
Le premier contrôleur disponible au public écrit en langage

C, l’utilisation d’un seul thread dans son cœur limite son déploiement.
Plusieurs dérivations du NOX ont été proposées plus tard, notamment le
Nox dans sa version multithread appelée NOX-MT, le QNOX, NOX
supportant la qualité de service (QoS), FortNOX, une extension du NOX
implémentant un analyseur de détection des conflits dans les règles de
flux causées par les applications, et enfin, le contrôleur POX, un
contrôleur basé sur NOX en langage python, dont le but est d’améliorer
les performances du contrôleur original NOX.
II.6.2 POX
POX est le plus jeune frère de NOX. C'est un contrôleur

open-source écrit en Python, et comme NOX, fournit un cadre pour le
développement et le test d'un contrôleur OpenFlow.
II.6.3 MAESTRO
Utilise la technologie du multithreading pour effectuer le

parallélisme au bas niveau, en gardant un modèle simple de
programmation pour les développeurs d’applications. Il atteint ses
performances à travers la distribution des tâches du cœur aux threads
disponibles et la minimisation de la mémoire consommée.
II.6.4 BEACON
Développé en java par l’université de Stanford, il est aussi

basé sur les technologies de multithreads et est multiplateforme. Son
architecture modulaire permet au gestionnaire d’exécuter uniquement
les services désirés.

26
II.6.5 SNAC
Utilise une application web pour gérer les règles du réseau.

Un langage de définition des règles flexibles et des interfaces faciles à
utiliser ont été intégrés pour configurer les équipements réseaux et
contrôler leurs évènements.
II.6.6 MCNETTLE
C’est un contrôleur SDN programmé par Nettle, qui est un

DSL (Domain Specific Language) intégré dans Haskell, et permet la
programmation des réseaux en utilisant OpenFlow. McNettle opère
dans des serveurs multi-cœurs qui partagent leur mémoire pour
atteindre une visibilité globale, une haute performance et une faible
latence.
II.6.7 RISE
Conçu pour les expérimentations des réseaux à grande

échelle, RISE est un contrôleur basé sur Trema. Ce dernier est un
Framework programmé en Ruby et C. Trema fournit un environnement
intégré de test et de débogage, incluant un ensemble d’outils pour le
développement.
II.6.8 RYU
Est un Framework développé en Python. Il permet la

séparation entre les domaines sans utiliser de VLAN. Il supporte jusqu’à
la dernière version d’OpenFlow 1.5.
II.6.9 FLOODLIGHT
Floodlight est un contrôleur open-source OpenFlow basé sur

Java, pris en charge par BigSwitch Networks. Il est sous licence Apache.
II.6.10 OPENDALIGHT
OpenDaylight est un projet de la Fondation Linux pris en

charge par l'industrie. C'est Un framework open source pour faciliter
l'accès au logiciel de définition de réseau (SDN). Comme Floodlight, il
peut également être Considéré comme une solution complète.
27
II.7 CHOIX DU CONTROLEUR
Par la suite plusieurs contrôleurs ont été proposés pour

améliorer les performances et la scalabilité (adaptation au
changement) du réseau.
Les performances des contrôleurs SDN sont caractérisées

par le débit, qui est la quantité de flux traités par seconde et la latence,
qui est le temps d’installation d’une nouvelle règle, etc.
Voici ci-dessous une table non exhaustive des

caractéristiques des contrôleurs SDN:
Caractéristiques FLOODLIGHT OPENDAYLIGH NOX POX

T
Développé par Big Switch Linux Nicira Nicira
Networks Foundation
Ecrit en Langage Java Java C++/Pytho Python
n
Langages Java, Python Java C++, etc Python
supportés
Open source Oui Oui Oui Oui
Interface Oui Oui Non Oui
utilisateur
Virtualisation Mininet, Mininet, Mininet, Mininet,
OpenVswitch OpenVswitch OpenVswit OpenVswit
ch ch
Interface southbound southbound southboun southboun
(OpenFlow), (OpenFlow et d d
northbound autres (OpenFlow (OpenFlow
(Java, REST) protocoles), ), ),
northbound northboun
(Java RPC) d
Plateforme Linux, Mac, Linux, Windows Linux Linux
Windows
Documentation Un peu difficile Un peu difficile Difficile à Facile à
à trouver à trouver trouver trouver
Northbound API OpenFlow Open Flow, - OpenFlow
BGP-LS,
Apprentissage Difficile Difficile Moyen Facile
Distribué Oui Oui Non Non
Installation Difficile Moyen Moyen Facile
Tableau II.1 : Résumer des caractéristiques des contrôleurs

28
Le Tableau II.1 ci-dessus résume les caractéristiques des

contrôleurs SDN les plus connus.
Selon les résultats, nous avons remarqué que plusieurs

contrôleurs ont des problèmes du côté de l’apprentissage, de
l’installation, du langage supporté et de la documentation. Suite à ces
résultats de simulation, nous avons opté pour le choix du contrôleur POX
pour réaliser notre simulation SDN ainsi que l'application.
II.8 CONCLUSION
Cette première partie a été consacrée aux bases théoriques

des réseaux définis par logiciels (SDN). Tout au long de son
développement, nous avons présenté notamment les avantages des
réseaux définis par logiciels (SDN) avant de traiter les composants
essentiels de cette solution pour leur adaptation au contexte de notre
travail.
Il sied de relever la fonction relative à la « programmabilité »

présente un avantage majeur dans la mesure où elle facilite à
l’administrateur de contrôler tous les nœuds réseau au même moment.

29
PARTIE II :
MISE EN PLACE D’UNE SOLUTION SDN

30
CHAPITRE III : LE CONTROLEUR SDN : POX

[1] [11] [15] [16]
III.1 INTRODUCTION
Le réseau programmable, sépare la partie contrôle de la

partie infrastructure du réseau qui traite et achemine les données.
Autrement dit, l’application indique au contrôleur SDN ses

prérequis, et le contrôleur relaie la demande a une infrastructure qui
n’a plus besoin d’être homogène, ainsi, c’est le contrôleur qui devient
le véritable cerveau du réseau.
Ci-dessous nous avons une figure qui illustre le routage d’un

paquet entre deux réseaux qui ne sont pas dans un même site (réseaux
distants) via une
implémentation de SDN avec le protocole OpenFlow. Les routeurs
discriminent les paquets et
déterminent leur interface de sortie, mais ce comportement découle
de règles émises par le
contrôleur. Le routeur qui réceptionne le paquet de l’envoi (1) signale
l’évènement au
contrôleur et reçoit en retour des règles au cours d’un échange (2), afin
de décider du transfert
(3) vers le routeur suivant approprié.
Figure III.1 : Schéma d’un réseau SDN simple
Avec le SDN, les administrateurs gère aisément et à faible

coût le réseau, puisqu’ils n’ont
à gérer que les paramètres et les règles, uniquement au niveau du
contrôleur central, et non
plus au niveau de chaque équipement.

31
Ce chapitre représente la première contribution de notre

travail, nous commençons d'abord par une présentation de Mininet et
open Vswitch, puis nous parlerons du contrôleur POX ainsi que ses
fonctionnalités.
III.2 MININET
Mininet est un émulateur de réseau, il permet de créer une

topologie réseau qui se compose d'un ensemble de hosts, de switchs,
de contrôleurs et liens virtuels. Il fournit la capacité de créer des hôtes,
les commutateurs et contrôleurs via :
 Ligne de commande,
 Interface interactive,
 Script Python.
III.2.1 Configuration utilisée
Afin de bien visualiser le fonctionnement du SDN, nous avons

choisi d'utiliser une machine virtuelle téléchargée depuis :
https://github.com/mininet/mininet/releases/download/2.2.2/mininet-
2.2.2-170321-ubuntu- 14.04.4-server-amd64.zip et accessible via
VirtualBox, elle utilise le système d'exploitation Linux (Ubuntu-14.04.4).
III.2.2 Fonctionnement de base du Mininet
Mininet permet avec un simple jeu de commande de

réaliser des réseaux virtuels en utilisant la commande mn.
III.2.2.1 Création d'une topologie avec la ligne de commande
Mininet fournit, en plus de la topologie « minimal », la

topologie « single », « linear » et « tree » comme montre dans la figure 8.
Pour charger l’une de ces topologies, on utilise l’option «--
topo», par exemple : $ sudo mn –topo single. « single » tout court
donne la même topologie que minimal, c’est-à-dire créer un hôte relie
avec un switch, mais on peut ajouter également comme argument un
chiffre, qui indique le nombre d'hôtes à créer.
$ sudo mn –topo single, 4
Si nous souhaitons personnaliser une topologie déjà créée, nous
appliquons une des commandes citées ci-dessous :

32
- Ajouter un switch : self.addSwitch(‘s1’)

- Ajouter un hôte : self.addHost(‘h1’)
- Ajouter un lien : self.addLink(h1,s1)
Figure III.2 : Différents types de topologie réseau
Apres la configuration, nous devons tester si les paquets sont

routes correctement avec la commande ping qui est un bon moyen
pour vérifier la connectivité :
Mininet> h1 ping -c h2 ou bien Mininet> pingall

et pour analyser les règles insérées dans chaque commutateur, nous
utilisons la commande dpctl: Mininet> dpctl dump-flows, et d'une façon
générale, pour accéder a toutes les commandes utilisées sous Mininet,
il suffit de taper :
Mininet> help
III.2.2.2 Topologies personnalisées
Si nous souhaitons travailler avec une topologie autre que

tree, linear ou simple, et même sans la ligne de commande, il faut créer
une topologie personnalisée à l’aide des scripts Python. Par exemple, si
on veut créer 2 hôtes h1 et h2, les deux sont connectes a un switch s1.
Voici le script Python à écrire :

33
class Test_Topo(Topo):
def __init__(self):
"Create P2P topology"
# Initialize topology
Topo.__init__(self)
# Add hosts and switches
h1 = self.addHost('h1')
h2 = self.addHost('h2')
s1 = self.addSwitch('s1')
# Add links
self.addLink(h1,s1)
self.addLink(h2,s1)
topos = { 'toptest': (lambda: Test_Topo()) }
Apres, nous sauvegardons le code dans un fichier

toptest.py, et nous executons la commande suivante:
$ sudo mn --custom /chemin/vers/toptest.py --topo toptest
III.3 Open vSwitch
Open vSwitch est bien adapte pour fonctionner comme un

commutateur virtuel dans les environnements Virtuels. En plus, il
supporte plusieurs technologies de virtualisation basées sur Linux, y
compris Xen, KVM et VirtualBox.
Open vSwitch est donc une implémentation logicielle d’un

switch Ethernet. Concrètement il est constitué d’un service (ovs-
vswitchd) et d’un module kernel (openvswitch_mod).
Le service permet de commuter effectivement les paquets

vers les bons ports virtuels, alors que le module kernel permet de
capturer le trafic provenant des interfaces réseau.
Pour fonctionner comme n’importe quel switch, Open

vSwitch utilise la notion de ports. Chaque port est constitué d’une ou
plusieurs interfaces, qui correspondent à des interfaces du système hôte
(logiques ou physiques).
IIII.3.1 Interagir avec Open vSwitch
 Pour connaitre l’état global d’un switch : ovs-vsctl show

 La création d’un switch se fait par la commande :
ovs-vsctl add-br <nom du virtuel switch>

34
 Pour ajouter un flux directement dans la table de flux sans avoir

utiliser un controleur, nous utilisons la commande : dpctl
mininet> dpctl add-flow in_port=1,actions=output:2

mininet> dpctl add-flow in_port=2,actions=output:1
Cette commande permet de transférer les paquets arrivant à port1 vers

port 2 et vice versa.
 Pour vérifier le contenu de la table de flux : $ dpctl dump-flows
III.4 CONTROLEUR POX
Dans les SDN, le plan de contrôle est place dans un

contrôleur centralise qui a une visibilité sur l’ensemble du réseau, y
compris les hôtes qui s’y connectent, les applications qui disent aux
contrôleurs comment programmer le réseau utilisent des interfaces de
programmation « NorthBound » tandis que les API et protocoles utilises
par le contrôleur pour communiquer avec les équipements du réseau
sont dits « SouthBound ».
L'une des conceptions de POX est facile à installer et à

exécuter. Cependant, surtout si cela vous intéresse vraiment. Les
commutateurs OpenFlow POX et logiciels sont préinstallés et prêts à
fonctionner.
Il peut également fonctionner comme un commutateur SDN

ou un système d'exploitation réseau. POX est très facile à installer et à
tester depuis la source.
a. Fonctionnalité de base du contrôleur POX
POX est une plate-forme de développement open source

pour les applications de contrôle de réseau défini par logiciel (SDN),
telles que les contrôleurs OpenFlow SDN. POX, qui permet un
développement et un prototypage rapides, est de plus en plus utilisé
par NOX, un projet jumeau.
Il a pour mission :
● Installer / Supprimer les règles de transfert sur les commutateurs

● Découverte de la topologie : besoin de savoir à quoi ressemble
le réseau (Link Layer Discovery Protocol (LLDP)).
● Statistiques : besoin de savoir ce qui se passe dans le réseau.

35
III.5 CONCLUSION
Outre les concepts se rapportant à la démarche

d’implémentation évoqués au chapitre suivant, au présent chapitre
nous avons présenté Mininet qui fait office d’émulateur réseau. Cet
outil permet de créer une topologie réseau qui se compose d'un
ensemble de hosts, de switchs, de contrôleurs et liens virtuels.
En vue de concilier cette théorie à la pratique, nous avons

évoqué le Open vswitch qui est un commutateur Virtuel avant de
boucler par le contrôleur POX ainsi que ses différentes fonctionnalités
de base.

36
CHAPITRE IV :
L’IMPLEMENTATION D’UNE
APPLICATION SDN
« GESTION DU LOAD-BALANCING »
[12] [13] [14] [16]
IV.1 INTRODUCTION
Au cours de ce chapitre, nous allons implémenter une

application de gestion de load-balancing (répartition de charge) au
sein d’une entité qui a deux départements, ces derniers ont chacun 3
clients qui veulent accéder aux serveurs http et nous allons répartir les
charges entre nos trois serveurs de telle sorte qu’il ait un équilibre entre
eux. Et à la fin de l’implémentation, chaque serveur recevra le même
nombre de requêtes que les autres venant des clients, c’est ce qui fera
qu’il ait l’équilibre entre les serveurs.
La version Ubuntu-14.04.4 du système d'exploitation Linux a

été choisie comme environnement du travail pour ces fins.
Ci-dessous l’architecture utilisée pour l’implémentation de

notre application :
Figure IV.1 : Architecture de l’application

37
IV.2 LOAD-BALANCING
Load-balancing : littéralement "répartition de charge" ou

"équilibrage de charge".
D’un côté un serveur. De l’autre un poste client. Entre les

deux, tout un ensemble d’équipements reliés entre eux pour permettre
aux informations de circuler de l’un à l’autre : le réseau.
Simple dans son concept, le réseau est plus complexe qu’il

n’y paraît. De nombreux éléments le composent, regroupés en
"couches" dans le modèle OSI, sur lequel repose le fonctionnement
d’un réseau informatique.
Chaque composant participe, à sa manière, au bon

déroulement des opérations de circulation des informations.
Une solution de load balancing peut intervenir à deux

niveaux du modèle OSI:
Niveaux 3/4 : Réseau et transport (protocole TCP/ IP) ;

consiste à travailler sur les paquets réseau en agissant sur leur routage
(TCP/IP). Le répartiteur de niveau 3/4 intervient donc à l’ouverture de la
connexion TCP puis aiguille les paquets en fonction des algorithmes
retenus.
Niveau 7 : Applications (protocole HTTP, RDP…) : le
répartiteur de charge ne se contente plus d’aiguiller "aveuglément" les
requêtes. Il analyse le contenu de chaque requête HTTP, RDP ou autre
pour décider du routage.
IV.3 INTERET DU LOAD-BALANCING
Pourtant, dans sa définition fonctionnelle, un répartiteur,

quel qu’il soit, assumera au moins deux missions principales :
l’équilibrage de charge entre les serveurs et la surveillance de ces
derniers.
a) Equilibrer dynamiquement la charge sur les serveurs
En pratique, le répartiteur s’appuie sur des algorithmes de

répartition. Il en existe de nombreux qui répondent à des critères bien
différents : les durées de sessions, les variations de charge, les capacités
de serveurs, etc.
38
b) Surveiller l’état des serveurs
C’est l’un des aspects les plus complexes de la répartition

de charge. Mais néanmoins indispensable : en cas de défaillance de
l’un des serveurs, toutes les requêtes seront réparties automatiquement
entre les autres serveurs de la ferme. Et ceci, de façon totalement
transparente pour l’utilisateur. On parle alors de haute disponibilité
applicative.
IV.4 DIFFICULTES DU LOAD-BALANCING DANS RESEAUX TRADITIONNELS
Les équilibreurs de charge actuellement disponibles

contiennent peu d'algorithmes pouvant être utilisés. Les administrateurs
réseau ne peuvent pas créer leurs propres algorithmes car les
équilibreurs de charge traditionnels sont verrouillés par le fournisseur et
non programmables.
Ces équilibreurs de charge traditionnels sont exorbitants et

peu flexibles au changement.
Étant donné que les équilibreurs de charge traditionnels sont

verrouillés par le fournisseur, les administrateurs réseau ne sont pas en
mesure de créer leurs propres algorithmes en raison de leur nature non
programmable.
IV.5 LE SDN, POUR UNE GESTION SIMPLE DU LOAD-BALANCING
Les équilibreurs de charge SDN sont programmables et vous

permettent de concevoir et de mettre en œuvre votre propre stratégie
d'équilibrage de charge.
Les autres avantages de l'équilibreur de charge SDN sont

que nous n'avons pas besoin de matériel dédié.
Le périphérique silicium muet peut être converti en un

puissant équilibreur de charge par l’application construite sur le
contrôleur, sans nécessiter d’administration de réseau.
Dans le cas d’équilibreurs de charge SDN, les programmeurs

ont la possibilité de construire et de concevoir leur propre stratégie
d’équilibrage de charge, ce qui rend l’équilibreur de charge SDN
programmable et flexible.

39
Il transmet la demande du client aux serveurs principaux et

obtient les réponses des serveurs, qu'il répond au client.
Il aide également les clients à se connecter directement aux

serveurs principaux, ce qui sécurise la structure du réseau interne et
empêche toute attaque sur le réseau.
IV.6 CHOIX DU TYPE D’EQUILIBREUR DE CHARGE
Pour planifier efficacement le routage des demandes d'un

client vers les serveurs respectifs de manière optimisée, plusieurs
stratégies d'équilibrage de charge sont utilisées, qui sont les suivantes:
 STRATÉGIE ALÉATOIRE: à partir d'une liste de serveurs actifs, l'équilibreur

de charge choisira au hasard un serveur pour l'envoi de la demande.
Cette politique a de gros frais généraux.
 ROUND-ROBIN: chaque serveur reçoit la requête de manière

circulaire. Les requêtes sont allouées à divers serveurs en direct sur une
base de tourniquet.
 WEIGHTED ROUND-ROBIN: chaque serveur reçoit la demande du client

en fonction de critères définis par l'administrateur du site. Dans un autre
monde, une pondération statique est attribuée à chaque serveur dans
la stratégie WRR (pondéré). Nous spécifions généralement des poids
proportionnellement aux capacités réelles. Ainsi, par exemple, si la
capacité du serveur 1 est 5 fois supérieure à celle du serveur 2, nous
pouvons attribuer un poids de 5 au serveur 1 et un poids de 1 au serveur
2.
Dans le cas de notre travail nous avons utilisé la stratégie de

l’algorithme "Round Robin", le premier client à se connecter est envoyé
au premier serveur, le deuxième client au deuxième serveur, le
troisième client au troisième serveur et ainsi de suite.
IV.7 IMPLEMENTATION D’UNE APPLICATION DE GESTION DU LOAD-

BALANCING
De nos jours, nos réseaux doivent gérer une grande quantité

de trafic et servir des milliers de clients. Il est très difficile pour un seul
serveur de gérer une telle charge. La solution consiste à utiliser plusieurs
serveurs avec l'équilibreur de charge faisant office de serveur frontal.

40
Les clients enverront les demandes à l'équilibreur de charge.

L'équilibreur de charge transmettra les demandes du client à différents
serveurs en fonction de la stratégie d'équilibrage de la charge.
Les principales démarches de notre travail sont les suivantes:
- Mettre en place d'une topologie à l'aide d'un outil d'émulation

basé sur Mininet, et d'un contrôleur POX.
- Conception et développement d’une application d’équilibrage

des charges (Load-Balancing) pour une gestion simple des
serveurs.
a. Mise en place d’une topologie à l'aide du Mininet
Scénario : Ici, nous allons utilisé une topologie réseau qui a 3 servers
HTTP (server1, server2 et server3) et 6 hosts clients (Client1, Client2,
Client3, Client4, Client5 et Client7), tous sont connectés via un Switch
Openflow, et ce dernier est connecté au Contrôleur POX, comme
indiqué dans la figure IV.2 ci-dessous.
- Client1 envoi sa demande au contrôleur qui joue le rôle de

l’équilibreur de charge, et ce dernier transmet sa demande au
server1,

server2,

server3,
- Ainsi de suite pour le reste des clients.

41
Figure IV.2 : Topologie du scénario
Nous avons créé notre topologie, nous avons utilisé un fichier python :
topomemo.py que nous avons créé, puis nous avons fait appel à ce
fichier à travers la ligne de commande ci-après :

42
Figure IV.3 : Fichier topomemo.py

43
Figure IV.4 : Topologie du lancement de topomemo.py
Après avoir créé la topologie, nous pouvons la tester en

exécutant des différentes commandes, nous pouvons utiliser la
commande help pour avoir cette liste de commandes, comme montre
la figure ci-dessous :
Figure IV.5 : Exécution de la commande Help
Par exemple, la figure ci-dessous nous affiche la sortie de la commande

dump (la configuration de la topologie) ainsi que la sortie de la
commande net (qui nous montre les liens entre hôtes et switch) :

44
Figure IV.6 : Sortie des commandes net et dump
b. Contrôleur POX
Pré-requis :
 Pour étudier et tester un réseau SDN, nous avons utilisé une

machine Linux (Ubuntu 14.03), et installé les outils de
développement JDK et éclipse.
 Puis, nous avons téléchargé et installé POX.
Exécution du POX :
Pour démarrer POX, nous exécutons le fichier pox.py avec la

commande suivante: ./pox.py forwarding.l2_learning
Démarrage de notre équilibreur des charges et des servers au niveau du

contrôleur
La figure ci-dessous nous montre comment notre équilibreur

des charges est démarré avec nos 3 serveurs (server1, server2 et
server3) :

45
Les résultats de la commande est :
Figure IV.7 : Démarrage de l’équilibreur de charge et des servers
Démarrage des serveurs web HTTP au niveau des servers
Les serveurs sont démarrés au moyen de cette commande :

python –m SimpleHTTPServer 80 et nous pouvons l’arrêter via : Ctrl+C
Figure IV.8 : Démarrage des serveurs
Envoi des requêtes aux serveurs par les clients
Cette figure nous montre comment les requêtes sont

redirigées via des différents serveurs par notre serveur Load Balancer.
Figure IV.9 : Affichage des requêtes au niveau des serveurs

46
Ci-dessous nous montre comment les requêtes des clients

arrivent aux différents serveurs par l’équilibrage des charges. Le premier
client envoi sa requête au contrôleur (Load Balancer) à l’aide de la
commande curl suivi de l’adresse IP du contrôleur, et ce dernier
redirige la requête au premier serveur, le deuxième vers le deuxième
server, ainsi des suites pour les autres clients.
Figure IV.10 : Requêtes des 3 premiers clients

47
Figure IV.11 : Requêtes des 3 derniers clients
IV.8 CONCLUSION
Tout au long de ce chapitre, nous avons exploité

l’émulateur Mininet, le contrôleur POX et le protocole OpenFlow. Notre
contribution principale est le développement d’une application
d’équilibrage de charge (Load Balancing) dans un environnement
SDN. Notre application donne la possibilité de gérer, créer, de modifier
et aussi de visualiser un équilibrage des charges.
En fournissant une topologie réseau, notre l’administrateur

réseau peut surveiller facilement pour les flows qui va vers nos serveurs
web http à l’aide du contrôleur.
Actuellement, l'équilibrage de charge est un concept très

important dans les datacenters où une haute disponibilité et des
performances sont requises.

48
CONCLUSION GENERALE
Grâce à la solution SDN, les réseaux sont maintenant

programmables, et la mise à disposition d’interfaces de programmation
d’applications permettra de programmer les équipements du réseau
en utilisant différents langages.
Dans ce travail, nous avons présenté une technologie dans

le domaine des réseaux : SDN qui consistait à mettre en œuvre et à
étudier l'équilibrage de la charge des serveurs dans l'environnement de
réseau défini par logiciel (SDN) à l'aide de règles récurrentes et
aléatoires. Les règles d'équilibrage de la charge sont exécutées sur le
contrôleur SDN.
Le contrôleur Open Source POX Controller utilisé a permis de

fournir l’interface North Bound pour la mise en œuvre des règles
d’équilibrage de la charge, ainsi que l’interface South pour la
communication avec les commutateurs OpenFlow. L'ensemble du
centre de données est émulé dans la plate-forme Mininet.
Au cours des simulations, nous avons découvert en quoi le

réseau défini par logiciel est différent du réseau traditionnel par sa
facon de gérer le réseau au travers d'un côntroleur et enfin une
meilleure appréhension de de POX, Mininet et OpenFlow vSwitch a été
obtenue.
Ce travail nous a également permis de comprendre les

fonctionnalités de base du réseau actuel, et la manière dont ces
dernières sont simplifiées à l’aide du réseau définis par les logiciels.
Ainsi, pouvoir proposer des équipements ou technologies

basées sur SDN devient une priorité et nous citons quelques
rapprochement ou rachat de petites startups spécialisées dans le SDN
par les grands acteurs des réseaux et du logiciel : Oracle rachetant la
startup Xsigo qui offre des services réseaux basés sur le SDN, Juniper
s’alliant à la société Contrail, Cisco se rapprochant de la société
Insiemi. Des acteurs comme HP se sont intéressés très tôt au SDN et se
positionnent aujourd’hui parmi les leaders du marché.

49
Bibliographie
[1] Bouida Hafida, « Etude et mise en œuvre d’une solution SDN », Mémoire de
Master, Université Abou Bakr Belkaid-Tlemcen, Année universitaire 2016-2017.
[2] Enric Caceres, « Le Protocole OpenFlow dans l’Architecture SDN », EFORT

2016.
[3] Fouad BENAMRANE, « Etude des Performances des Architectures du Plan

de Contrôle des Réseaux SDN », Thèse de doctorat, Université Mohammed V,
Soutenue le 18 Janvier 2017.
[4] Samy ZEMMOURI, «Modèle de routage écoénergétique dans les réseaux

définis par logiciel », Mémoire de Master, école de technologie supérieure
université du québec, soutenue le 1 juin 2017.
[5] Shiva Rowshanrad, Vajihe Abdi et Manijeh Kechtgari, « Performance

evaluation of SDN Controllers », Université de technologie Shiraz, Iran, IIUM, 2
Novembre 2016.

50
Webographie
[6] Le nuage informatique : https://www.figer.com/Publications/nuage.htm
[7] L’architecture SDN : https://www.supinfo.com/articles/single/1080-sdn-software-

defined-networking-architecture
[8] Le principe du SDN dans une architecture réseau classique :

http://blogs.univ-poitiers.fr/f-launay/2018/01/15/principe-du-sdn-dans-une-
architecture-reseau-classique/
[9] SDN, principes et fonctionnement : https://blog.wescale.fr/2018/03/01/sdn-

principes-et-fonctionnement/
[10] Introduction à la virtualisation :

https://www.google.cd/url?sa=i&source=images&cd=&cad=rja&uact=8&ved=2ahU
KEwikpu2d9dXeAhUmz4UKHc_2AzQQjRx6BAgBEAU&url=https%3A%2F%2Fwww.sebasti
en-han.fr%2Fblog%2F2011%2F04%2F12%2Fintroduction-a-la-
virtualisation%2F&psig=AOvVaw1XxRLRFZ62OdN0IFxowIXq&ust=1542354468552014
[11] Définition du POX : https://searchnetworking.techtarget.com/definition/POX
[12] Haute disponibilité des serveurs : https://www.jscape.com/blog/active-

active-vs-active-passive-high-availability-cluster
[13] Haute disponibilité des serveurs :

https://www.jscape.com/blog/bid/86515/How-to-Setup-High-Availability-File-Transfer-
Servers
[14] Utilisation d’équilibreur des charges dans le contrôleur POX :

https://angel.co/projects/193862-load-balancing-in-sdn-using-pox-controller
[15] Caractéristique des contrôleurs :

https://www.researchgate.net/publication/3E8W6mVzyQgNxhj6uNkBTc4NbkUc1Kh1r
sSDN_controllers_POX_Floodlight_and_Opendaylight
[16] Architecture de l’application : https://www.draw.io/

51
Table des matières
0. INTRODUCTION GENERALE ........................................................ Erreur ! Signet non défini.1

0.1 PROBLEMATIQUE ..................................................................................................................... 3
0.2 HYPOTHESES DU TRAVAIL ..................................................................................................... 3
0.3 CHOIX ET INTERET DU SUJET ............................................................................................. 4
0.4 DELIMITATION DU SUJET ....................................................................................................... 4
0.5 DIFFICULTES RENCONTREES .................................................................................................. 5
0.6 SUBDIVISION DU TRAVAIL ...................................................................................................... 5
PARTIE I : L’Etat des technologies de réseaux ............................................................................... 6
CHAPITRE I : FONCTIONNEMENT DE BASE DE RESEAUX INFORMATIQUE ...... 7
I.1 INTRODUCTION ......................................................................................................................... 7
I.2 DEFINITION DU RESEAU............................................................................................................ 7
I.3 ARCHITECTURE DU RESEAU CLASSIQUE .............................................................................. 7
I.4 LA VIRTUALISATION ................................................................................................................. 8
I.5 LE CLOUD COMPUTING (L’INFORMATIQUE EN NUAGE) .............................................. 9
I.5.1 Définition .............................................................................................................................. 9
I.5.2 Modèles de services ...................................................................................................... 10
I.5.3 Caractéristiques du cloud ........................................................................................... 11
I.6 UN BESOIN DU RESEAU PROGRAMMABLE ....................................................................... 12
I.7 CONCLUSION .......................................................................................................................... 13
CHAPITRE II : LE RESEAU PROGRMMABLE : SDN ........................................................ 14
II.1 INTRODUCTION ...................................................................................................................... 14
II.2 DEFINITION ............................................................................................................................... 14
II. 3 ARCHITECTURE ...................................................................................................................... 15
II. 4 AVANTAGES........................................................................................................................... 17
II. 5 LE PROTOCOLE OPENFLOW DANS L’ARCHITECTURE SDN ......................................... 18
II.5.1 Introduction ..................................................................................................................... 18
II.5.2 La genèse d’OpenFlow ............................................................................................... 19
II.5.3 Structure d’un commutateur OpenFlow ................................................................ 19
II.5.4 Table de flux ..................................................................................................................... 20
II.5.5 Messages OpenFlow .................................................................................................... 21
II.6 QUELQUES CONTROLEURS SDN ......................................................................................... 24
II.6.1 NOX .................................................................................................................................... 25
II.6.2 POX .................................................................................................................................... 25
52
II.6.3 MAESTRO .......................................................................................................................... 25

II.6.4 BEACON ........................................................................................................................... 25
II.6.5 SNAC ................................................................................................................................. 26
II.6.6 MCNETTLE ......................................................................................................................... 26
II.6.7 RISE ..................................................................................................................................... 26
II.6.8 RYU ..................................................................................................................................... 26
II.6.9 FLOODLIGHT .................................................................................................................... 26
II.6.10 OPENDALIGHT............................................................................................................... 26
II.7 CHOIX DU CONTROLEUR ..................................................................................................... 27
II.8 CONCLUSION ......................................................................................................................... 28
PARTIE II : Mise en place d’une solution SDN .............................................................................. 29
CHAPITRE III : LE CONTROLEUR SDN : POX .................................................................. 30
III.1 INTRODUCTION ...................................................................................................................... 30
III.2 MININET ................................................................................................................................... 31
III.3 Open vSwitch........................................................................................................................ 33
III.4 CONTROLEUR POX ............................................................................................................... 34
III.5 CONCLUSION ........................................................................................................................ 35
CHAPITRE IV : L’IMPLEMENTATION D’UNE APPLICATION SDN ............................. 36
IV.1 INTRODUCTION .................................................................................................................... 36
IV.2 LOAD-BALANCING.............................................................................................................. 37
IV.3 INTERET DU LOAD-BALANCING ........................................................................................ 37
IV.4 DIFFICULTES DU LOAD-BALANCING DANS RX TRADITIONNELS ................................ 38
IV.5 LE SDN, POUR UNE GESTION SIMPLE DU LOAD-BALANCING ................................... 38
IV.6 CHOIX DU TYPE D’EQUILIBREUR DE CHARGE ............................................................... 39
IV.7 IMPLEMENTATION D’UNE APPLICATION DE GESTION DU LOAD-BALANCING ...... 39
IV.8 CONCLUSION ........................................................................................................................ 47
V. CONCLUSION GENERALE ..................................................................................................... 48
Bibliographie ................................................................................................................................... 49
Webographie .................................................................................................................................... 50

Université de Kinshasa: Faculté Des Sciences

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Université de Kinshasa: Faculté Des Sciences

Загружено:

Авторское право:

Доступные форматы

Université de Kinshasa

Faculté des Sciences

Département des Mathématiques et Informatique

MISE EN PLACE D’UNE SOLUTION SDN POUR LA

Mémoire présenté et défendu en vue de

Année universitaire 2017-2018

« (…) Et les gagnants seront ceux qui arriveront à restructurer la

William Henry Bill Gates

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.

- A tous ceux qui me sont chers et proche.

- A tous ceux qui ont semé en moi à tout point de vue

- A tous ceux que j’aime et ceux qui m’aiment.

- A tous ceux qui me connaissent de prêt ou de loin

Chaco MUKADI NTUMBA

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.

Mes remerciements s’adressent essentiellement à mon directeur le professeur MBUYI

Je remercie également tout le personnel de l’entreprise Tendaji-Technologies;

Et auront la gratitude de l’enrichir avec leurs critiques et correct.

Que tous trouvent ici l’expression de ma franche et profonde reconnaissance !

Chaco MUKADI NTUMBA

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.

Liste des Abréviations et Acronymes

API : Application Programming Interface

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.

Liste des Figures

Figure I.1 : Architecture Réseau classique………………………..…………………...8

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.

Liste des Tableaux

Tableau II.1 : Résumer des caractéristiques des contrôleurs…………………..…27

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.

Avec l’avènement des innovations technologiques récentes

Durant ces dernières années, les réseaux informatiques

En effet, l’apparition du Big Data qui nécessite un traitement

À titre d’exemple, les usagers de l’infonuagique peuvent

Ces évolutions nécessitent généralement une mise à jour

C’est dans ce contexte qu’est apparu le paradigme des

En effet, SDN permet principalement de centraliser la

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.

De ce fait, la définition d’une politique de gestion d’un

L’architecture SDN a été adoptée par plusieurs grandes

Dans le cadre de ce travail, nous comparons les

En vue de concilier la théorie à la pratique, nous avons

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.

Depuis des années, il est communément admis que les

Pour pallier à cette instabilité, l’intégration des

Les principaux domaines d’innovation au cours des

Notre préoccupation se résumera au tour des questions

0.2 HYPOTHESES DU TRAVAIL

Une hypothèse est selon le dictionnaire Robert Méthodique,

A ces préoccupations exprimées sous forme des questions

0.3 CHOIX ET INTERET DU SUJET

Il convient de souligner que le choix d’un sujet est fonction

Cependant notre choix est poussé par le souci de savoir

En sus des différentes motivations qui nous ont poussés à

- Déterminer les points essentiels en montrant les outils et la

- Montrer le rôle et l’importance de Load-Balancing (répartition des

0.4 DELIMITATION DU SUJET

Selon Madeleine GRAWITZ, « Limiter son sujet, c’est

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.

temps ni de moyens matériels suffisants pour effectuer une étude

0.5 DIFFICULTES RENCONTREES

En effectuant nos recherches pour l’élaboration de notre travail de fin

- La recherche documentaire a été compliquée car nous n’avons