These Benamrane

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/316620880
Etude des Performances des Architectures du Plan de Contrôle des Réseaux

‘Software-Defined Networks'
Thesis · January 2017

DOI: 10.13140/RG.2.2.33883.57126
CITATIONS READS
2 4,447
3 authors:
Fouad Benamrane Mouad Ben Mamoun

University of Bradford Mohammed V University of Rabat
15 PUBLICATIONS 109 CITATIONS 34 PUBLICATIONS 264 CITATIONS
SEE PROFILE SEE PROFILE
Benaini Redouane
Mohammed V University of Rabat
25 PUBLICATIONS 187 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
Congestion management in overlay networks (OrangeLabs) View project
Design and evaluate the future avionic network based on SDN paradigm View project
All content following this page was uploaded by Fouad Benamrane on 02 May 2017.
The user has requested enhancement of the downloaded file.

N° d’ordre 2951
THÈSE DE DOCTORAT
Présentée par
Fouad BENAMRANE
Discipline : Informatique
Spécialité : Réseaux
Titre :
Etude des Performances des Architectures
du Plan de Contrôle des Réseaux
‘Software-Defined Networks
Soutenue le Mercredi 18 Janvier 2017
Devant le jury
Président :
Mr El Mamoun SOUIDI PES Faculté des Sciences, Université
Mohammed V, Rabat
Examinateurs :
Mr Mostafa BELLAFKIH PES Institut National des Postes et
Télécommunications, Université
Mohammed V, Rabat
Mme Hafssa BENABOUD PH Faculté des Sciences, Université
Mohammed V, Rabat
Mr Farid EL HEBIL PES Institut National des Postes et
Télécommunications, Université
Mohammed V, Rabat
Mr Mouad BEN MAMOUN PES Faculté des Sciences, Université
Mohammed V, Rabat
Mr Redouane BENAINI PH Faculté des Sciences, Université
Mohammed V, Rabat
Faculté des Sciences, 4 Avenue Ibn Battouta B.P. 1014 RP, Rabat – Maroc
Tel +212 (0) 37 77 18 34/35/38, Fax : +212 (0) 37 77 42 61, http://www.fsr.ac.ma
Dédicaces
A mes chers parents

Aucune dédicace ne saurait exprimer mon respect, mon amour éternel et ma considération pour
les sacrifices que vous avez consenti pour mon instruction et mon bien être. Je vous remercie
pour tout le soutien et l’amour que vous me portez depuis mon enfance. Que ce modeste travail
soit l’exaucement de vos vœux tant formulés, le fruit de vos innombrables sacrifices. Puisse Dieu,
le Très Haut, vous accorder santé, bonheur et longue vie.
A mes chers frères
Je ne pourrais d’aucune manière exprimer ma profonde affection et mon Immense gratitude pour
tous les sacrifices consentis, votre aide et votre générosité extrêmes ont été pour moi une source
de courage, de confiance et de patience. Que ALLAH vous protège et vous accorde santé, longue
vie et bonheur.
A toutes mes amies
En souvenir des moments agréables passés ensemble, veuillez trouver dans ce travail l’expression
de ma tendre affection et mes sentiments les plus respectueux avec mes vœux de succès, de
bonheur et de bonne santé.
ii
Avant Propos
Les travaux présentés dans le mémoire ont été effectués au sein du Laboratoire De Recherche en
Informatique (LRI) à la faculté des sciences de Rabat sous la direction du Professeur Mouad BEN
MAMOUN et le co-encadrement du Professeur Redouane BENAINI.
J’adresse tous mes remerciements à mon Directeur de Thèse le Professeur Mouad BEN MAMOUN.
Ces années de travail en commun m’ont beaucoup appris scientifiquement et humainement. Je
souhaite à tous les doctorants d’avoir un directeur de thèse aussi prêt à partager son savoir et
son temps.
Je tiens à exprimer tous mes remerciements au Professeur Redouane BENAINI d’avoir co-encadré
ce travail et d’avoir apporté son expertise et ses conseils à l’orientation de cette thèse.
Je tiens à remercier le président du jury le Professeur El Mamoun SOUIDI, Professeur à la Faculté
des Sciences à Rabat, qui m’a honoré en acceptant d’être président du jury de ma soutenance.
Je tiens également à exprimer ma gratitude Monsieur Mostafa BELLAFKIH, Professeur à l’Institut
National des Postes et Télécommunications à Rabat d’avoir accepté d’être rapporteur et exami-
nateur.
Mes gratitudes vont aussi à Madame Hafssa BENABOUD, Professeure à la Faculté des Sciences
à Rabat d’avoir accepté d’être rapporteur et examinateur.
Je remercie aussi Monsieur Farid EL HEBIL, Professeur à l’Institut National des Postes et Télé-
communications à Rabat, qui a accepté d’être examinateur.
Je tiens également à exprimer ma gratitude à Madame Fouzia OMARY directrice du Laboratoire
de Recherche en Informatique (LRI) de la Faculté des Sciences de Rabat.
Je suis profondément reconnaissant envers Monsieur Francisco Javier ROS MUÑOS, ex-professeur
à l’université de Murcia en Espagne, pour sa collaboration à une partie de cette thèse. Ses conseils
et directives pendant le travail que nous avons réalisé m’ont beaucoup aidé dans cette thèse.
iii
Résumé
Ces dernières années ont été marquées par l’émergence d’un nouveau concept réseau appelé
SDN qui sépare le plan de contrôle (décisions de routage) du plan de données (transmission des
paquets). Différentes architectures du plan de contrôle ont été proposées dans la littérature,
l’analyse des performances de ces architectures est un préalable à leur déploiement dans les
réseaux de production. Notre objectif dans cette thèse est d’analyser la faisabilité et les limites
en terme de performances des différentes architectures proposées pour le plan de contrôle des
réseaux SDN. Après un état de l’art sur les travaux déjà réalisés concernant les performances des
réseaux SDN, nous avons commencé par une étude de cas de l’architecture physiquement central-
isée. Cette étude a confirmé les résultats d’autres travaux sur les limites de cette architecture et la
nécessité d’utiliser plusieurs contrôleurs dans le plan de contrôle. Par la suite, nous avons consid-
éré les cas des plans multi-contrôleurs avec une architecture dite logiquement centralisée. Cette
architecture nécessite une forte synchronisation des données entre les différents contrôleurs
afin de maintenir une vue globale et centralisée du réseau. Ainsi, nous avons analysé le coût
de cette synchronisation inter-controleurs. Les résultats de simulation de plusieurs topologies
WAN réelles montrent la faisabilité de cette architecture en terme de délai de synchronisation.
Toutefois, son déploiement dans des réseaux très larges, en particulier composés de plusieurs
domaines peut être limité par la charge de synchronisation. Enfin, pour les architectures du plan
de contrôle dites logiquement distribuées, nous avons proposé une interface de communication
nommée CIDC qui s’implémente sur chaque contrôleur. Nous avons défini différents modes de
communication et différents services distribués dans cette interface pour améliorer la QoS et la
sécurité des communications entre les contrôleurs. Nous avons implémenté et évalué l’interface
CIDC à travers plusieurs simulations. Les résultats montrent la faisabilité de cette interface en
terme de performances et l’intérêt des modes et services proposés.
Mots-clé:
SDN, OpenFlow, Architectures du plan de contrôle, Évaluation des performances, Interface Est/Ouest.
iv
Abstract
Recent years have been marked by the emergence of a new network concept called SDN that sep-
arates the control plan (routing decision) from the data plane (packet transmission). Different
architectures of the control plan have been proposed in the literature, the analysis of the perfor-
mances of these architectures is a prerequisite for their deployment in the production networks.
Our objective in this thesis is to analyze the feasibility and limitations in terms of performance
of the different architectures proposed for the control plan of the SDN networks. After a state
of the art on the studies already done on the performance of SDN networks, we started with a
case study of the physically centralized architecture. This study confirmed the results of other
study on the limitations of this architecture and the need to use several controllers in the control
plan. Thereafter, we considered the cases of multi-controller plans with a logically centralized
architecture. This architecture requires extensive synchronization of data between the various
controllers in order to maintain a global and centralized view of the network. Thus, we analyzed
the cost of this inter-controller synchronization. The results of simulation of several real WAN
topologies show the feasibility of this architecture in terms of synchronization delay. However,
its deployment in very large networks, in particular composed of several domains, may be lim-
ited by the synchronization overhead. Finally, for the architectures of the so-called logically
distributed control plan, we proposed a communication interface called CIDC which is imple-
mented on each controller. We defined different communication modes and different distributed
services in this interface, to improve the QoS and the security of the communications between
the controllers. We implemented and evaluated the CIDC interface through several simulations.
The results show the feasibility of this interface in terms of performance and the interest of the
offered modes and services.
Keywords:
SDN, OpenFlow, Controle plan architectures, Performance evaluation, East/West interface.
v
Table des matières
1 Introduction générale 1
1.1 Contexte général et objectifs de la thèse . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Organisation du mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Software Defined Networking et OpenFlow 6

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Historique des réseaux SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Software-Defined Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1 Architecture SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2 Interfaces de communications . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.3 Plan de contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.1 Architecture du protocole OpenFlow . . . . . . . . . . . . . . . . . . . . 14
2.4.2 Spécifications d’OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.3 Plan de données OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5 Applications SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5.1 Data center et Cloud computing . . . . . . . . . . . . . . . . . . . . . . 21
2.5.2 Multimédia et QOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5.3 Sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5.4 Réseaux sans fil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3 Performances des réseaux SDN basés sur le protocole OpenFlow 24

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Performances des commutateurs OpenFlow . . . . . . . . . . . . . . . . . . . . . 25
3.2.1 Comparaison avec les commutateurs traditionnels . . . . . . . . . . . . 25
3.2.2 Améliorations logicielles . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.3 Améliorations matérielles . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Performances des contrôleurs OpenFlow . . . . . . . . . . . . . . . . . . . . . . 27
3.3.1 Améliorations basées sur le multithreading . . . . . . . . . . . . . . . . 27
3.3.2 Améliorations basées sur la virtualisation . . . . . . . . . . . . . . . . . 28
3.4 Amélioration des performances en utilisant plusieurs contrôleurs . . . . . . . . 28
3.4.1 Nombre et emplacement des contrôleurs . . . . . . . . . . . . . . . . . . 29
3.4.2 Plan de contrôle logiquement centralisé . . . . . . . . . . . . . . . . . . 30
3.4.3 Plan de contrôle logiquement distribué . . . . . . . . . . . . . . . . . . . 31
3.5 Techniques d’évaluation des performances des réseaux SDN . . . . . . . . . . . 32
3.5.1 Modèles analytiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.5.2 Plateformes d’expérimentation . . . . . . . . . . . . . . . . . . . . . . . 33
3.5.3 Outils de simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4 Évaluation des performances du plan de contrôle physiquement centralisé 36

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Environnement d’évaluation et description des expériences . . . . . . . . . . . . 37
4.2.1 Environnement d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.2 Description des expériences . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3 Résultats de simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.1 Débit du contrôleur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.2 Délai du réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5 Évaluation des performances des architectures du plan de contrôle logiquement cen-

tralisé 43
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2.2 Description des expériences . . . . . . . . . . . . . . . . . . . . . . . . . 45
vii
5.3 Analyse du coût de la synchronisation . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3.1 Métriques de performance . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3.2 Expériences avec 2 contrôleurs . . . . . . . . . . . . . . . . . . . . . . . 50
5.3.3 Expériences avec K>2 contrôleurs . . . . . . . . . . . . . . . . . . . . . . 52
5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6 Implémentation et évaluation d’une interface Est/Ouest pour un plan de contrôle SDN

logiquement distribué 57
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2 Interface de Communication pour le plan de contrôle distribué (CIDC) . . . . . 58
6.2.1 Modes de communication . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.2.2 Conception et architecture de l’interface CIDC . . . . . . . . . . . . . . 59
6.2.3 Fonctionnement de l’interface CIDC . . . . . . . . . . . . . . . . . . . . 62
6.3 Services distribués proposés pour l’interface CIDC . . . . . . . . . . . . . . . . . 63
6.3.1 Cryptage de la communication inter-contrôleurs avec le protocole SSL . 63
6.3.2 Service de Firewall distribué dans l’interface CIDC . . . . . . . . . . . . 65
6.3.3 Service d’équilibrage de charge distribué (routé) . . . . . . . . . . . . . . 67
6.4.2 Description des scénarios . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.4.3 Métriques de performance . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.5 Analyse des résultats de simulation . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.5.1 Analyse du délai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.5.2 Analyse de la charge de communication inter-contrôleurs (ICO) . . . . . 74
6.5.3 Consommation des ressources du système . . . . . . . . . . . . . . . . . 75
6.5.4 Évaluation des services distribués . . . . . . . . . . . . . . . . . . . . . . 77
6.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7 Conclusion générale 81
A Mininet et Iperf 84
A.1 CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
A.2 Code python des topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
viii
A.3 Émulation de topologies réelles . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
A.4 Tests de performances en utilisant l’outil iperf . . . . . . . . . . . . . . . . . . . 87
B Exemples de Contrôleurs SDN 88

B.1 Ryu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
B.2 Opendaylight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
B.3 Floodlight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Liste des Acronymes 91
ix
Liste des figures
2.1 Comparaison entre l’architecture des réseaux traditionnels (a) et celle des réseaux
SDN (b) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Processus de communication entre les commutateurs et le contrôleur . . . . . . 10
2.3 Processus de transmission des paquets avec Openflow 1.0 au sein des commutateurs 15
2.4 Pipeline d’OpenFlow 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Pipeline d’OpenFlow 1.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1 Architecture distribuée des réseaux SDN . . . . . . . . . . . . . . . . . . . . . . 33
4.1 Topologie linéaire gérée par un contrôleur SDN centralisé . . . . . . . . . . . . 38

4.2 Débit en fonction du nombre de switchs . . . . . . . . . . . . . . . . . . . . . . . 40
4.3 Délai en fonction du nombre des commutateurs OVS pour les deux scénarios avec
contrôleur et sans contrôleur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4 Délai en fonction du nombre des commutateurs OVS pour les différents scénarios
(avec contrôleur, sans contrôleur et multiples instances) . . . . . . . . . . . . . . 41
5.1 Environnement d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.2 Topologies des réseaux WAN considérées . . . . . . . . . . . . . . . . . . . . . . 46
5.3 Evaluation de la charge de synchronisation par les topologies avec deux contrôleurs 50
5.4 Evaluation du délai de synchronisation pour les topologies avec deux contrôleurs 54
5.5 Comparaison entre les délais des topologies basées sur deux contrôleurs . . . . 55
5.6 Délai et charge pour k>2 contrôleurs et selon différentes topologies . . . . . . . 56
6.1 Architecture de l’interface CIDC au sein du contrôleur SDN . . . . . . . . . . . 61

6.2 Déroulement de la communication entre les contrôleurs dans l’interface CIDC . 63
6.3 Déroulement du service SSL dans l’interface CIDC . . . . . . . . . . . . . . . . . 64
6.4 Déroulement des services distribués (DFS et DLBS) dans l’interface CIDC . . . . 66
6.5 Topologies des réseaux WAN considérés . . . . . . . . . . . . . . . . . . . . . . 69
6.6 Illustration d’une topologie multi-domaines Claranet_4 dont chaque domaine est
géré par son contrôleur SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.7 Délais des évènements pour ODL et CIDC selon plusieurs topologies . . . . . . 74
6.8 Consommation des ressources systèmes avec la topologie Claranet_4 . . . . . . 77
xi
Liste des tableaux
2.1 Caractéristiques des contrôleurs SDN . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Table de flux de commutateur OpenFlow 1.0 . . . . . . . . . . . . . . . . . . . . 14
2.3 Table de flux pour l’OpenFlow v1.1 . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 Liste des instructions pour la version 1.1 d’OpenFlow . . . . . . . . . . . . . . . 17
2.5 Entrées de la table du groupe pour la version 1.1 ou plus d’OpenFlow . . . . . . 17
2.6 Entrées de la table de mesure OpenFlow 1.3 . . . . . . . . . . . . . . . . . . . . . 18
2.7 Types des commutateurs virtuels et leurs caractéristiques . . . . . . . . . . . . . 20
5.1 Topologies évaluées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.1 Topologies considérées dans les tests . . . . . . . . . . . . . . . . . . . . . . . . 71

6.2 Comparaison de la charge et le nombre de paquets échangés pour plusieurs topolo-
gies multi-domaines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.3 ICO en Mbits/s pour CIDC non sécurisée, sécurisée et Opendaylight . . . . . . . 78
6.4 Evaluation du mode Service et Full pour la topologie Hibernia_3 . . . . . . . . . 79
Chapitre 1
Introduction générale
1.1 Contexte général et objectifs de la thèse
Internet a connu un énorme succès et a transformé le monde en trois décennies seulement en

une société numérique par excellence. Il est devenu un outil universel indispensable pour les
entreprises et la vie quotidienne de milliards d’individus. Toutefois, afin de continuer son succès,
Internet doit relever le défi de traiter des volumes de plus en plus gigantesques de trafic dus à :
une explosion du nombre de terminaux mobiles, une utilisation massive des réseaux sociaux et de
nouvelles tendances des technologies de l’information comme le cloud computing, le big data, et
l’internet des objets qui sont génératrices de gros volumes de données. À titre d’exemples, selon
Cisco Visual Networking Index [54], plus d’un demi-milliard (563 millions) d’appareils mobiles
ont été ajoutés en 2015 et il est prévu que le nombre d’appareils mobiles connectés dépasse le
nombre de personnes sur terre (1,5 appareils mobiles par personne) d’ici 2020. Par ailleurs, les
réseaux sociaux ont également connu une croissance spectaculaire ces dernières années. Par
exemple, Facebook est passé de 1 million d’utilisateurs en décembre 2004 à plus d’1,71 milliard
d’utilisateurs actifs en juillet 2016 [48].
Le problème pour relever ce défi dans l’avenir, est qu’il est très difficile d’innover et d’apporter
des changements au réseau Internet actuel tant sur le plan des protocoles que de l’infrastructure
physique. D’ailleurs, son architecture fondamentale n’a connu aucun progrès significatif en
presque trois décennies. La migration des équipements réseau de IPv4 vers IPv6 a commencé
depuis une dizaine d’années et est toujours en cours. Selon [35], le design, l’évaluation et le
déploiement d’un nouveau protocole de routage peuvent prendre entre 5 à 10 années. Une des
raisons de cette difficulté d’innover réside dans l’architecture des réseaux actuels où le plan de
contrôle et le plan de données coexistent dans chaque équipement réseau. En fait, ceci empêche
un déploiement rapide des nouvelles fonctionnalités réseau parce qu’elles doivent être incor-
porées directement dans l’équipement physique. Or, ceci dépend des cycles de production des
fabricants qui peuvent être très longs. D’autre part, la dépendance aux fabricants augmente les
coûts d’investissement liés aux infrastructures réseaux. Un autre problème du couplage du plan
de contrôle et du plan de données dans les équipements réseaux, ce qui rend les opérations de
configuration et de gestion complexes. En effet, les administrateurs réseaux doivent configurer
et gérer séparément chaque équipement, ce qui augmente le risque d’erreurs. Selon [121], les fac-
teurs humains sont signalés comme étant responsables de 50 à 80 % des interruptions de service
et pannes de périphériques réseaux.
L’objectif principal des réseaux définis par logiciel (SDN, Software Defined Networking) est de
faciliter l’innovation dans les réseaux et de simplifier la gestion et la configuration. Ce nouveau
concept repose sur deux idées :
• Sortir la partie décisionnelle (plan de contrôle) des équipements et la placer vers un seul
point de contrôle appelé le plan de contrôle SDN.
• Programmer les équipements réseaux à travers des API.
Ces changements dans l’infrastructure réseau ont pour conséquence de simplification des équipe-
ments et de les rendre indépendants des fabricants. En d’autres termes, toute la complexité est
incorporée dans le plan de contrôle SDN. Ce plan joue le rôle de médiateur entre les applications
et les équipements, en exposant des Interfaces de Programmation (API) aux applications et en
permettant une programmabilité du réseau. Ainsi, la possibilité de programmer les équipements
permet un déploiement plus rapide de nouveaux protocoles et services puisque ça se fait à la
vitesse de développement de l’application et non au cycle de production des fabricants.
Un autre avantage des réseaux SDN est l’abstraction du réseau, ce qui signifie que le plan de con-
trôle fournit une vue abstraite aux applications. Cela permet de traiter le réseau de façon unifiée
et simplifie la configuration et la gestion. En outre, l’utilisation du concept SDN dans le réseau
peut fournir des services innovants, notamment le routage multidiffusion, la sécurité, le contrôle
d’accès, la gestion de la bande passante, l’ingénierie de trafic, la QoS, l’efficacité énergétique et
diverses formes de gestion des stratégies.
Le SDN présente donc plusieurs avantages, mais le fait de concentrer toute l’intelligence du
réseau dans le plan de contrôle soulève des préoccupations de performance et de scalabilité de ce
plan. Ces préoccupations se posent plus pour l’architecture initiale SDN qui propose d’utiliser
un seul contrôleur, qui devient alors un seul point de défaillance (SPOF) et soulève le manque
d’évolutivité et de performance. Par conséquent, le besoin d’utiliser des contrôleurs multiples
devient une nécessité pour surmonter le problème du SPOF et améliorer les performances. Notre
objectif tout au long de cette thèse est d’étudier et évaluer les performances des différentes archi-
tectures du plan de contrôle, aussi bien dans le cas du contrôleur logiquement ou physiquement
centralisé que dans le cas du contrôleur logiquement distribué. Nos études se sont focalisées sur
les performances et la faisabilité de ces architectures.
2
1.2 Contributions
Cette thèse porte sur les réseaux SDN qui sont un nouveau type de réseau avec une nouvelle
philosophie d’architecture, de nouveaux protocoles et de nouveaux produits. Donc, au début de
notre thèse en 2012, il fallait comprendre et maitriser cette nouvelle architecture. C’est pourquoi
nous avons d’abord commencé nos travaux par une étude bibliographique sur ce nouveau con-
cept, ses avantages, son architecture, son principal protocole OpenFlow et aussi les principaux
contrôleurs disponibles. Nous avons présenté une partie de cette étude dans la 2ème édition des
Journées Doctorales en Systèmes d’Information, Réseaux et Télécommunications ”JDSIRT’13”
[43].
L’architecture initiale et les 1ères implémentations SDN comme NOX [78], POX [106] proposent
un seul contrôleur physique. Nous avons donc commencé par une étude de cas du contrôleur
Ryu [110] avec une topologie linéaire. L’objectif de cette étude était aussi de maitriser les outils
de simulation des topologies comme Mininet [21] et les techniques de mesure de performance.
Ce travail a donné lieu à une publication dans LNCS (Lecture Note in Computer Science) [46].
Par la suite, et avant de réaliser d’autres études de performances, nous voulions connaître les
améliorations qui ont été faites dans les réseaux SDN. Nous avons donc réalisé un état de l’art
sur les performances de l’architecture SDN. Nous avons présenté d’abord les techniques qui ont
été utilisées afin d’améliorer les performances des contrôleurs et des commutateurs OpenFlow.
Nous avons aussi classé les contrôleurs selon le type d’architecture, le langage de programma-
tion et leur capacité. Par la suite, nous avons présenté les différentes architectures du plan de
contrôle construit par plusieurs contrôleurs, notamment les architectures logiquement central-
isées et logiquement distribuées. Cette étude a donné lieu à une publication dans le ‘Journal of
Networks’ [45].
Ensuite, nous avons considéré l’architecture du plan de contrôle logiquement centralisé. Dans
ce type d’architecture, les contrôleurs échangent en permanence leurs états pour synchroniser
la vue du réseau. Cette synchronisation peut poser un problème de consommation de bande
passante et génère un délai supplémentaire dans le réseau tout entier. L’objectif de notre étude
est d’évaluer le coût de synchronisation entre des contrôleurs arrangés sous la forme de cluster.
La simulation a été faite sur des topologies réelles issues des réseaux WAN. Notons que cette
étude a été réalisée en collaboration avec le professeur Francisco Javier Ros Muñoz et a donné
lieu à une publication dans le journal ’International Journal of High Performance Computing and
Networking’ [44].
Enfin, nous avons considéré l’architecture logiquement distribuée, où chaque domaine est con-
trôlé par son contrôleur et la synchronisation entre les contrôleurs n’est nécessaire que dans
le cas où une application nécessite une vue totale sur le réseau. Ces architectures ont été pro-
posées pour étendre SDN aux réseaux WAN multi-domaines. Cette architecture est très récente,
c’est pouquoi nous avons remarqué qu’il existe un manque de mécanisme de communication
3
inter-contrôleur standardisé et implémenté. Nous avons proposé un modèle de communica-
tion inter-contrôleurs pour les plans de contrôle logiquement distribués. Ce modèle est basé
sur une nouvelle interface appelée CIDC qui doit être implémenté dans chaque contrôleur et
fonctionne selon des modes de communication que nous avons définis (Notification, service et
full). En fait, nous avons différencié les modes pour économiser la bande passante, car le rôle et
l’importance de chaque contrôleur dans une architecture multi-domaine diffèrent. Nous avons
présenté l’architecture de l’interface composée de quatre modules (producer, consumer, data up-
dater et data collector), ses avantages en matière de modularité et de performance et une première
simulation (proof-of-concept) dans le journal ’International Journal of Communication Networks
and Distributed Systems’ [41]
Par la suite, nous avons approfondi notre travail en implémentant l’interface CIDC dans le con-
trôleur Floodlight [49], nous avons aussi enrichi l’interface avec des services distribués (SSL, DFS,
DLBS) pour améliorer la sécurité et de qualité de service (Qos) des réseaux distribués. Ainsi, nous
avons présenté les résultats d’une large étude d’évaluation de performance et de consommation
des ressources de notre interface, dont nous avons varié les topologies WAN, les modes de com-
munication, le nombre de domaines, de commutateurs et de contrôleurs. Ce travail a donné lieu
à une publication dans le journal ’Computers & Electrical Engineering’ [40].
1.3 Organisation du mémoire
Le reste de ce mémoire est organisé en six chapitres :

Chapitre 2 : nous consacrons ce chapitre à un état de l’art des réseaux SDN. Nous commençons
par un bref historique des réseaux SDN, puis nous décrivons l’architecture SDN composée des
plans de transmission, de contrôle, et d’application, et les interfaces intermédiaires entre ces
plans. Par la suite, nous présentons l’architecture de l’interface du sud OpenFlow et ses spécifi-
cations. Nous terminons ce chapitre par les applications les plus connues du SDN.
Chapitre 3 : l’objectif de ce chapitre est de présenter un état de l’art sur les performances des
réseaux SDN. Nous décrivant d’abord les travaux qui ont pour but d’améliorer l’architecture in-
terne des commutateurs OpenFlow, puis nous présentons les différentes techniques pour améliorer
les performances d’un contrôleur SDN physiquement centralisé. Par la suite, nous décrivons les
architectures multi-contrôleurs notamment logiquement centralisées et logiquement distribuées.
À la fin de ce chapitre, nous présentons les outils d’émulation et de mesure utiles dans l’expérime-
ntation.
Chapitre 4 : Dans ce chapitre, nous considérons le cas d’un plan de contrôle physiquement
centralisé. Nous présentons une étude de cas en particulier, nous précisons le contrôleur, la
topologie et l’environnement de test considéré. Nous présentons et analysons les résultats de
simulation concernant le débit et le délai.
Chapitre 5 : Dans ce chapitre, nous considérons le cas d’un plan de contrôle logiquement central-
4
isé. Nous présentons l’environnement d’évaluation et description des expériences en particulier,
les topologies WAN, les contrôleurs et les scénarios considérés. Nous décrivons par la suite, les
résultats de simulation en matière du coût de synchronisation entre les contrôleurs logiquement
centralisés sous forme de cluster pour 2 et k>2 contrôleurs.
Chapitre 6 :Dans ce chapitre, nous considérons le cas d’un plan de contrôle logiquement dis-
tribué. Nous présentons notre modèle de communication inter-contrôleur, les modes de com-
munication, l’algorithme de l’interface, puis, nous décrivons nos services distribués et leur algo-
rithme. Par la suite, nous décrivons l’environnement de test, la description des scénarios et les
métriques de performance. Finalement, nous présentons et analysons les résultats de simulation
selon les différentes métriques et modes de communication.
Chapitre 7 : Enfin, nous terminons ce mémoire de thèse par une conclusion générale et des
perspectives des travaux futurs.
5
Chapitre 2
Software Defined Networking et

OpenFlow
2.1 Introduction
Pendant longtemps, les technologies réseau ont évolué à un rythme plus faible par rapport aux
autres technologies de télécommunication. Des équipements de réseau tels que les commuta-
teurs et les routeurs ont été développés par les fabricants avec des plans de contrôle et de données
étroitement couplées. Chaque fournisseur conçoit son propre firmware pour exploiter leur pro-
pre matériel de manière exclusive et privée, le design, l’évaluation et le déploiement d’un nouveau
protocole peuvent prendre entre 5 à 10 années [35]. Cela a ralenti l’avancement des innovations
dans les technologies réseaux et provoque une augmentation considérable de la complexité, des
coûts de gestion et de l’exploitation à chaque fois que de nouveaux services devaient être dé-
ployés dans les réseaux existants. L’existence de ces limitations ont poussé à la collaboration
des chercheurs et des leaders du marché industriel afin de repenser la conception des réseaux
traditionnels.
Récemment, les réseaux programmés par logiciel (SDN, Software-Defined Networking) ont gagné
en popularité dans les milieux industriels et de recherches. SDN n’est pas une proposition révo-
lutionnaire, mais c’est un mélange des propositions antérieures notamment les réseaux pro-
grammables et la séparation du plan de contrôle et de données [80]. C’est le résultat d’un proces-
sus à long terme déclenché par le désir de porter le réseau « out of the box ». L’idée principale
de SDN consiste à déplacer le plan de contrôle à l’extérieur des périphériques réseau et à laisser
seulement laisser le plan de données à l’intérieur. Le plan de contrôle est pris en charge par
une application appelée ”Contrôleur”. Les périphériques réseau deviennent des équipements de
transmission simples qui peuvent être programmés par le contrôleur. Certains des prédécesseurs
du SDN qui prônent la séparation des plans contrôle-données sont 4D [16] et Ethane [71].
Ce chapitre est organisé comme suit : la première section décrit les premiers travaux sur la
programmation du réseau et la séparation des plans de contrôle et de données. La deuxième
section est consacrée à l’architecture du SDN, aux interfaces de communications, et aux con-
trôleurs les plus utilisés. La troisième section présente le protocole OpenFlow, son architecture
et ses différentes versions. La quatrième section explore les applications émergentes basées sur
l’architecture SDN dans le domaine du cloud computing, des centres de données, de la sécurité
et des réseaux sans fil.
2.2 Historique des réseaux SDN
Avant l’apparition des réseaux SDN tels que nous les connaissons aujourd’hui, plusieurs idées et
travaux ont été proposés auparavant, notamment la programmation du réseau et la séparation
des plans de contrôle et de données. Nous donnons dans cette section un bref aperçu de ces
travaux, qui peuvent être considérés comme des ancêtres de SDN.
La première idée de programmation de réseaux a été développée en 1996 sous le nom de « réseaux
actifs » (AN, Active Network) [72]. Ces réseaux injectent des programmes parmi les données du
paquet. Quand un nœud du réseau reçoit ces paquets, il extrait et exécute les programmes à
partir des données du paquet et déclenche par conséquent des actions de transmission, de modi-
fication ou de suppression du paquet. Avec cette approche, de nouveaux mécanismes de services
et de routage du réseau peuvent être implémentés sans modification des équipements de trans-
mission. Plusieurs études ont été menées sur les ANs, en particulier sur les paquets intelligents
[22], ANTS [31] et SwitchWare [33]. Puisque les paquets des ANs peuvent transporter des pro-
grammes malveillants, une alternative aux ANs appelée « réseaux programmables »(PN) [34] a
été proposée en 1999. Les PNs injectent des programmes à l’intérieur des nœuds du réseau. Ces
nœuds exécutent les programmes uniquement après une phase de signalisation et de vérification,
pour renforcer la sécurité. Les ANs et les PNs ont cherché à introduire la programmabilité dans
les réseaux à travers des paquets et des switchs programmables. Ces approches n’ont pas réduit
la complexité de l’infrastructure réseau.
D’autres part, certains projets ont essayé de séparer le plan de contrôle du plan de données pour
simplifier l’architecture réseau et fournir une abstraction sur l’infrastructure physique. Par ex-
emple, le projet de recherche dénommé DCAN (Devolved Control of ATM Networks) [36] de
l’université de Cambridge dont l’objectif était de développer l’infrastructure réseau de manière
à ce que les fonctions de contrôle et de gestion de plusieurs équipements (les switchs ATM dans
le cas du DCAN) soient découplées de l’équipement physique et déléguées aux entités externes
telles que le gestionnaire. Mais DCAN avait besoin d’un protocole de communication entre le
gestionnaire et l’infrastructure réseau. En 1998, le groupe de travail OPENSIGN a commencé une
série d’ateliers dédiés à rendre les réseaux d’ATM, d’Internet, et de mobiles plus ouverts, exten-
sibles, et programmables [37]. OPENSIG établit une distinction entre l’équipement physique qui
transporte les paquets, le système de contrôle et de gestion du réseau. Le cœur de leur proposi-
7
tion était de fournir un accès à l’équipement physique via des interfaces réseaux programmables
et ouvertes, puis de laisser au fournisseur de services le choix de manipuler le réseau en util-
isant des applications intermédiaires. Motivé par ces idées, un groupe de travail de l’IETF (In-
ternet Engineering Task Force) a pu proposer un protocole général de gestion des switchs GSMP
(General Switch Management Protocol) [6]. Un autre projet appelé 4D a été lancé en 2005 [16]
pour séparer les décisions de routage et les protocoles qui gouvernent les interactions entre les
équipements du réseau. Les plans de diffusion et de découverte collectent les informations sur le
réseau et les envoient au plan de décision, qui a une vision globale sur le réseau, afin de contrôler
la transmission du trafic qui circule dans le plan de données.
Le début des réseaux SDN a commencé avec le projet Ethane, lancé en 2006 à l’université de Stan-
ford. En effet, le projet Ethane [71] définit une nouvelle architecture pour les réseaux d’entreprises.
L’objectif d’Ethane était d’avoir un contrôleur centralisé pour gérer les règles (policies) et la sécu-
rité dans le réseau. Ethane utilise deux composantes : un contrôleur pour décider si un paquet
doit être transmis, et un switch Ethane composé de table et d’une chaîne de communication
entre les deux. Ethane était une source d’inspiration pour un système d’exploitation consacré
aux réseaux dénommé Nox [78], et pour un nouveau concept appelé aujourd’hui « réseaux pro-
grammés par logiciel » (SDN, Software-Defined Networking). Nous notons que les chercheurs
d’Ethane sont derrière Nox et SDN.
2.3 Software-Defined Networking
Selon l’ONF (Open Network Fundation) [116] (un consortium d’entreprises à but non lucratif
fondé en 2011 pour promouvoir SDN et normaliser ses protocoles) SDN est une architecture qui
sépare le plan de contrôle du plan de données, et unifie les plans de contrôle dans un software de
contrôle externe appelé « Contrôleur », pour gérer plusieurs éléments du plan de données via des
APIs (Application Programming Interface). Notons que l’ONF regroupe plus de 100 entreprises
comportant les géants du web, les opérateurs de télécoms et les fabricants ce qui montre l’intérêt
immense des industriels pour SDN. Dans cette section, nous présentons l’architecture du SDN et
décrivons ses principales composantes.
2.3.1 Architecture SDN
Traditionnellement, un réseau informatique est composé d’équipements réseau interconnectés

tels que des switchs et des routeurs (Figure 2.1a). Dans chaque équipement, nous trouvons un
mécanisme de transmission dans la couche de transmission et un plan de contrôle qui incorpore
le système d’exploitation et les applications. Dans ce modèle, les équipements réseau sont fermés
et nous n’avons aucune possibilité d’ajouter une nouvelle application. L’installation de nouveaux
protocoles dépend des cycles de production qui peuvent être longs. Afin d’ouvrir les équipements
réseau et de séparer les applications de la couche de transmission, l’architecture de « réseaux
8
programmés par logiciel », ou SDN, a vu le jour. Elle est composée de trois couches principales
et d’interfaces de communication (Figure 2.1b). Nous décrivons dans la suite ces couches ainsi
que les interfaces de communication entre les couches.
Couche de contrôle
(Applications et service) Couche d’application

API
Applications d’équilibrage de Applications de
Couche de transmission charge et de routage business et de Cloud
Couche de contrôle Couche de contrôle API Nord
(Applications et service) (Applications et service)

Couche de contrôle
API API
Contrôleur API Est/Ouest Contrôleur API Est/Ouest Contrôleur
Couche de transmission Couche de transmission
SDN SDN SDN
Couche de contrôle
API Sud
(Applications et service)
API Couche de transmission

Couche de transmission
Switches physiques Switches virtuels
Switch/Routeur
(a) Réseau traditionnel (b) Réseau SDN
Figure 2.1: Comparaison entre l’architecture des réseaux traditionnels (a) et celle des réseaux
SDN (b)
La couche la plus basse est la couche de transmission, aussi appelée « plan de données ». Elle con-
tient les équipements de transmission (FEs : Forwarding Element) tels que les switchs physiques
et virtuels. Son rôle principal est de transmettre les données, surveiller les informations locales et
collecter les statistiques. La couche de contrôle, également appelée « plan de contrôle », est con-
stituée d’un ou de plusieurs logiciels de contrôle (Contrôleurs), ces contrôleurs utilisent des inter-
faces Sud ouvertes pour contrôler le comportement des FEs et communiquent via des APIs Nord
avec la couche supérieure pour superviser et gérer le réseau. La couche d’application (la plus
haute dans la figure) héberge les applications qui peuvent introduire de nouvelles fonctionnal-
ités réseau, comme la sécurité, la configuration dynamique et la gestion. La couche d’application
exploite la vue globale et distante du réseau offerte par le plan de contrôle pour fournir des direc-
tives appropriées à la couche de contrôle. Des exemples d’applications réseau seront présentés
dans la section 2.5.
Trois types d’interfaces permettent aux contrôleurs de communiquer avec leur environnement :
interface Sud, Nord et Est/Ouest. Nous les détaillons par la suite.
2.3.2 Interfaces de communications
Le contrôleur interagit avec les autres couches à travers les interfaces Sud et Nord et avec les
autres contrôleurs à travers une interface Est-Ouest.
9
2.3.2.1 Interfaces Sud
Ce sont des interfaces de communication permettant au contrôleur d’interagir avec les switchs /
routeurs de la couche d’infrastructure. Le protocole le plus utilisé et déployé comme interface de
Sud est OpenFlow, c’est un élément fondamental pour construire des solutions SDN. OpenFlow
est régulièrement mis à jour par l’ONF, sa dernière version est 1.5.0 [92]. Un switch qui supporte
l’OpenFlow contient des tables spéciales appelées « tables de flux », ces tables sont similaires
à la table MAC sauf qu’elles stockent et gèrent des règles appropriées à chaque flux au lieu des
adresses MAC. Plus de détails sur le protocole OpenFlow et la notion de flux seront donnés dans
la section 2.4.
La Figure 2.2 illustre le processus de communication entre un contrôleur et un switch supportant
le protocole OpenFlow lorsqu’une nouvelle règle doit être instaurée dans le switch.
Figure 2.2: Processus de communication entre les commutateurs et le contrôleur
Quand un paquet est reçu par le commutateur, son champ d’entête est examiné et comparé avec
le champ ‘Match’ dans les entrées de la table de flux. Si le match est identifié, le commutateur
exécute l’action correspondante dans la table de flux. Par contre, s’il n’y a pas de match (1), une
demande est envoyée au contrôleur (2) sous la forme d’un ’Packet_in’, puis le contrôleur décide
selon sa configuration une action pour ce paquet, et envoie une nouvelle règle de transmission
sous la forme d’un ‘Packet_out’ et ‘Flow-mod’ au commutateur (3). Enfin, la table de flux du
commutateur est actualisée (4).
A part OpenFlow, Il existe d’autres alternatives d’interface Sud, par exemple le Framework ForCES
(Forwarding and Control Element Separation) [50], qui a été proposé par l’IETF en 2004 (avant
SDN) dans le cadre de développement d’un nouveau protocole pour standardiser l’échange des
10
informations entre le plan de contrôle et le plan de transmission (éléments de la transmission).
Les éléments de contrôle utilisent le protocole ForCES pour modifier le comportement des élé-
ments de la transmission à travers les LFB (Logical Function Blocks), qui peuvent s’organiser de
façon modulaire pour former des mécanismes de transmission plus complexes. L’architecture
SoftRouter [118] sépare aussi les fonctionnalités du plan de contrôle de celles du plan de données
et relie de manière dynamique les éléments de contrôle avec les données. Bien que ForCES et
SoftRouter soient apparus avant SDN, ils peuvent néanmoins jouer le rôle d’OpenFlow. D’autres
technologies réseau sont aussi des candidats d’interface Sud, notamment les éléments de calcul
des chemins PCE et le protocole LISP (Locator/Identifier Separation Protocol) [9]. Les indus-
triels comme Cisco et Juniper, utilisent aussi des protocoles Sud mais propriétaires comme Open
Network Environment Platform Kit (OnePK) [25], et Contrail [26].
2.3.2.2 Interfaces Nord
Les interfaces Nord servent à programmer les éléments de la transmission en exploitant l’abstraction
du réseau fourni par le plan de contrôle. Elles sont considérées davantage comme des API que
comme protocole de programmation et de gestion de réseau. Au moment de la rédaction de ce
document, il n’existe aucun standard intervenant entre la couche de contrôle et celle d’application
du côté d’ONF ou d’autres organisations. Selon l’ONF, plusieurs niveaux d’abstraction et dif-
férents cas d’utilisation peuvent être caractérisés, ce qui signifie qu’il peut y avoir plusieurs in-
terfaces Nord pour servir tous les cas d’utilisation. Parmi les propositions des industriels, nous
trouvons une API basée sur REST API (REpresentational State Transfer) [107] pour fournir une
interface programmable utilisable par les applications du commerce.
2.3.2.3 Est/Ouest
Les interfaces côté Est/Ouest sont des interfaces de communication qui permettent générale-
ment la communication entre les contrôleurs dans une architecture multi-contrôleurs pour syn-
chroniser les états du réseau [120]. Ces architectures sont très récentes et aucun standard de
communication inter-contrôleur n’est actuellement disponible.
2.3.3 Plan de contrôle
Le rôle du plan de contrôle est de contrôler et de gérer les équipements de l’infrastructure, et de

les relier avec les applications. Il est composé d’un ou de plusieurs contrôleurs et il est considéré
comme système d’exploitation du réseau. Les premières versions du SDN présentent un plan de
contrôle composé d’un seul contrôleur centralisé. Par la suite des architectures distribuées util-
isant plusieurs contrôleurs ont été proposées pour améliorer les performances et la scalabilité 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. Dans
11
Controleurs Langage OpenFlow Débit kilo Multithreaded Distribué Difficulté
flux/s de
développe-
ment
NOX C++ 1.0, 1.1, 30 Non Non Moyen
1.2, 1.3
POX Python 1.0 30 Non Non Facile
Ryu Python 1.0, 1.1, 33 Non Non Moyen
1.3, 1.4,
1.5
Floodlight Java 1.0, 1.1, 1500 Oui Oui Difficile
1.2, 1.3,
1.4
OpenDayLight Java 1.0, 1.3 - Oui Oui Difficile
Table 2.1: Caractéristiques des contrôleurs SDN
le reste de ce chapitre, nous considérons le cas d’un seul contrôleur et dans le chapitre suivant
nous parlerons du cas des contrôleurs multiples.
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. La Table 2.1 résume les caractéristiques des contrôleurs SDN les plus connus :
Nous présentons ci-dessous une liste non exhaustive des contrôleurs SDN:
• Nox [78]: 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 [13],
le QNOX [66], NOX supportant la qualité de service (QoS), FortNOX [103], 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 [106], un contrôleur basé sur NOX en
langage python, dont le but est d’améliorer les performances du contrôleur original NOX.
• Maestro [77]: 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’applicatio-
ns. Il atteint ses performances à travers la distribution des tâches du coeur aux threads
disponibles et la minimisation de la mémoire consommée. En plus, Maestro peut traiter
les demandes issues de multiples flux par une seule tâche d’exécution, ce qui augmente son
efficacité.
• Beacon [28]: développé en java par l’université de Stanford, il est aussi basé sur les tech-
nologies de multithreads et est multiplateforme. Son architecture modulaire permet au
12
gestionnaire d’exécuter uniquement les services désirés.
• SNAC [115]: 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 con-
figurer les équipements réseaux et contrôler leurs évènements.
• Floodlight [49] : est une variante de Beacon caractérisée par sa simplicité et sa perfor-
mance. Il a été testé avec les commutateurs OpenFlow physiques et virtuels. Il est au-
jourd’hui supporté et amélioré par une large communauté de développeurs, comprenant
des industriels comme Intel, Cisco, HP, Big switch et IBM.
• McNettle [14]: c’est un contrôleur SDN programmé par Nettle [15], qui est un DSL (Do-
main 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.
• RISE [113]: conçu pour les expérimentations des réseaux à grande échelle, RISE est un
contrôleur basé sur Trema [123]. 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.
• Ryu [110] : 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.
• Opendaylight [90]: est un projet open source implémenté en java et multiplateforme. Il

supporte le Framework OSGi [99] pour la programmation locale du contrôleur et le REST
[107] bidirectionnel. Les entreprises comme ConteXteam, IBM, NEC, Cisco, Plexxi, et Er-
icsson sont très actives dans ce projet.
2.4 OpenFlow
Le protocole OpenFlow [79] est actuellement considéré comme un protocole utilisé comme une
interface Sud dans les architectures basées sur SDN, cependant, dans ses débuts il a été la première
implémentation réelle du concept SDN avec toute une architecture composée par les switchs, une
chaine de communication sécurisée et un contrôleur de référence. Le protocole OpenFlow a été
initialement proposé et implémenté par l’université de Stanford, et il a été standardisé par la
suite par l’ONF. Dans cette section, nous commençons par introduire la structure d’OpenFlow
puis nous décrivons ses différentes spécifications, et nous terminons par les différents éléments
de transmission qui supportent OpenFlow.
13
Champs d’en-tête Compteurs Actions
Table 2.2: Table de flux de commutateur OpenFlow 1.0
2.4.1 Architecture du protocole OpenFlow
L’architecture d’OpenFlow est une implémentation réelle des réseaux SDN, nous la détaillons ici
pour bien comprendre les concepts SDN. Cette architecture est basée sur trois composantes : (1)
l’infrastructure appelée aussi le plan de données, composée des commutateurs OpenFlow; (2) le
plan de contrôle, constitué par un ou plusieurs contrôleurs ; (3) la chaîne sécurisée qui connecte
les commutateurs avec le plan de contrôle. Un commutateur OpenFlow est un équipement de
transmission qui contient des tables de flux. Ces tables de flux contiennent un ensemble d’entrées
aussi appelées règles, où chacune est constituée par les champs d’en-tête, des compteurs et des
actions (Table 2.2).
Les champs d’en-tête d’une entrée contiennent les informations nécessaires pour déterminer le
paquet auquel cette entrée sera appliquée. Pour permettre une transmission rapide des paquets
avec OpenFlow, le commutateur utilise une mémoire de type TCAM (Ternary Content Address-
able Memory) qui permet une recherche rapide des masques. Le champ d’en-tête peut aussi
identifier différents protocoles selon les spécifications d’OpenFlow, comme Ethernet, IPv4, IPv6
ou MPLS. Les Compteurs sont réservés à la collecte des statistiques de flux. Ils enregistrent le
nombre de paquets et d’octets reçus et la durée des flux dans la mémoire temporaire. Les Actions
spécifient comment les paquets d’un flux seront traités. Les Actions communes sont « transmet-
tre », « supprimer », « modifier le champ », etc. Le contrôleur est responsable de l’installation
et de la mise à jour des tables de flux des commutateurs. En insérant, modifiant et supprimant
les entrées de flux, le contrôleur peut modifier le comportement des commutateurs en ce qui
concerne la transmission.
Il existe trois types de communication dans le protocole OpenFlow : la communication Contrôleur-
vers-commutateur, asynchrone et symétrique. La communication Contrôleur-vers-commutateur
est responsable de la détection des fonctionnalités, de la configuration, de la programmation du
commutateur et de la collecte des informations comme la configuration. La communication asyn-
chrone est initiée par le commutateur OpenFlow et est utilisée pour informer le contrôleur du
passage des paquets ou du changement de l’état du commutateur (exemple Packet-in et Port-
status). Finalement, les messages symétriques sont envoyés soit par le commutateur, soit par le
contrôleur (ex : Hello, Echo).
Le mécanisme de transmission utilisé par le protocole OpenFlow est illustré dans la Figure 2.3.
Quand un switch reçoit un paquet, il compare son en-tête avec les règles de la table des flux.
Si le masque configuré dans le champ d’en-tête d’une règle correspond à l’en-tête du paquet, la
règle avec la plus haute priorité est sélectionnée, puis le switch actualise son compteur pour cette
règle. Finalement, le switch effectue les actions spécifiées par la règle sur le paquet (Ex : le switch
14
envoie le paquet vers un port de sortie). Sinon, le switch notifie son contrôleur concernant ce
paquet abrité dans la mémoire tampon. Le switch encapsule le paquet ou le 1er octet du paquet
utilisant un message Packet-in et l’envoie au contrôleur; il est très commun d’encapsuler l’en-tête
et le nombre d’octets du paquet. Le contrôleur reçoit ce message et identifie l’action appropriée à
ce paquet, il installe une ou plusieurs entrées dans le switch. Par la suite, les paquets tamponnés
sont transmis selon les règles ; en insérant l’ID du tampon dans le flux ou explicitement dans les
messages Packet-out. Souvent, le contrôleur installe le chemin complet pour le paquet dans le
réseau en modifiant les tables de flux de l’ensemble des switchs constituant le chemin.
Champs d’en-tête Compteurs Actions
Correspondance
Paquets issues Analyse des champs Exécution des actions
aux tables de
du réseau d’en-tête sur les paquets
flux
Aucune correspondance
Notifier le
contrôleur
Figure 2.3: Processus de transmission des paquets avec Openflow 1.0 au sein des commutateurs
2.4.2 Spécifications d’OpenFlow
Nous examinons dans cette partie les différentes spécifications d’OpenFlow, en se focalisant sur
les opérations supportées, les changements entres les versions et les fonctionnalités des dif-
férentes versions.
2.4.2.1 OpenFlow v 1.0
La spécification du protocole OpenFlow 1.0 [79] est apparue en décembre 2009. Elle est au-
jourd’hui la version la plus déployée dans les switchs industriels. Les paquets Ethernet et IP sont
identifiés selon l’adresse source et de destination. En plus, les champs Ethernet-type et VLAN
sont utilisés pour l’Ethernet, les champs DS (Differentiated Services), ECN (Explicit Congestion
Notification) et le champ protocole sont utilisés pour l’IP. En outre, l’identification des paquets
peut aussi dépendre du port source et de destination de TCP ou UDP.
La Figure 2.3 présente le mécanisme de traitement des paquets d’OpenFlow v 1.0. L’algorithme
d’identification des paquets commence par une comparaison des champs Ethernet et VLAN, et
15
continue si nécessaire avec le champ d’en-tête d’IP. Si le type d’IP correspond au TCP ou UDP,
les champs d’en-tête de la couche de transport seront pris en compte. Plusieurs actions sont
déployées par flux, la plus importante étant l’action de transmission, qui transmet le paquet à
une porte bien spécifique ou le diffuse vers tous les ports. Le contrôleur peut demander au switch
d’encapsuler tous les paquets d’un flux et de les envoyer au contrôleur. Ces actions permettent le
contrôle d’accès au réseau avec OpenFlow. Une autre action autorise la modification des champs
d’en-tête du paquet, par exemple la modification des tags VLAN, de la source IP, des adresses de
destination, etc. La version 1.0 du protocole OpenFlow fournit aussi un service de qualité (QoS)
basique supportant l’utilisation des files d’attente avec l’option de taux minimal des files d’attente
(disponible uniquement dans cette version). Un switch OpenFlow peut gérer une ou plusieurs
files d’attente, et chaque file est rattachée à un port. Le contrôleur OpenFlow peut s’informer sur
les files d’attente disponibles au sein du switch. L’action ‘Enqueue’ permet l’ajout des paquets aux
files d’attente, ces paquets seront traités selon les propriétés des files d’attente. Les contrôleurs
OpenFlow peuvent seulement s’informer sur les files d’attente et sur leurs propriétés. Mais avec
la version 1.2 du protocole OpenFlow [95], le protocole OF-CONFIG [91] permet la modification
des propriétés des files d’attente.
La version 1.1 d’OpenFlow [94] est disponible depuis février 2011. Elle propose des changements
significatifs par rapport à la version 1.0, notamment le pipeline des tables de flux multiples et
la table de groupe. Dans la version 1.0, une liste des actions est appliquée aux paquets de flux
après leur identification, ces actions sont spécifiées directement dans les entrées de la table de
flux (Figure 2.3). Avec la version 1.1, l’ensemble des actions sont cumulées lors de l’exécution du
pipeline (Figure 2.5), et sont appliquées au paquet à la fin du pipeline.
Exécuter
Paquets l’ensemble
sources Table de Table de Table de des actions
Flux 0 Flux 1 Flux N
En-tête du paquet En-tête du paquet En-tête du paquet En-tête du paquet
Porte d’entrée Porte d’entrée Porte d’entrée Porte d’entrée
Métadonnée Métadonnée Métadonnée Métadonnée
Ensemble des Ensemble des Ensemble des Ensemble des
actions actions actions actions
Correspondre et Correspondre et Correspondre et

actualiser actualiser actualiser
Figure 2.4: Pipeline d’OpenFlow 1.1
De nouvelles informations ont été ajoutées pour l’exécution des pipelines comme le champ Méta-
données (Metadata), les instructions et la liste des actions (Actions sets). Le champ Métadonnées
16
Champs d’en-tête Compteurs Instructions
Table 2.3: Table de flux pour l’OpenFlow v1.1
Instruction Argument Sémantique

Apply-Actions Action(s) Appliquer les actions immédiatement sans les
ajouter à l’ensemble des actions
Write-Actions Action(s) Configurer une action spécifique dans le champ des
actions
Clear-Actions - Supprimer les actions
Write-Metadata Métadonnées Actualiser le champ de la Métadonnée
Goto-Table ID de la table Faire correspondre à la table suivante
Table 2.4: Liste des instructions pour la version 1.1 d’OpenFlow
peut collecter les Métadonnées d’un paquet durant la phase d’identification et les transmettre
d’une étape de pipeline à la suivante. Les entrées de la table de flux contiennent les instructions
au lieu des actions (Table 2.3).
La liste des instructions possibles dans la version 1.1 d’OpenFlow est donnée dans la Table 2.4.
L’instruction ‘Apply-Actions’ applique directement l’action sur le paquet sans attendre que le
pipeline se termine. Ces actions ne seront pas ajoutées à la liste des actions. L’instruction ‘Write-
Actions’ ajoute des actions dans la liste des actions. L’instruction ‘Clear-Actions’ efface la liste
des actions. L’instruction ‘Write-metadata’ actualise le champ des métadonnées, et finalement,
l’instruction ‘Goto’ se réfère à l’ID de la table de flux suivante où l’identification prendra place.
Pour éviter une boucle infinie, seule la table avec l’ID de la table actuelle est permise dans le
champ ‘Goto’. S’il n’y a pas d’instruction ‘Goto’, le pipeline se termine et les actions accumulées
sont appliquées au paquet.
Le deuxième changement dans cette version est l’ajout d’une nouvelle table appelée la table
de groupe. La table de groupe supporte les fonctions complexes de transmission, qui peuvent
s’appliquer à un groupe de flux. Cela consiste en des entrées de la table de groupe comme présen-
tée dans la Table 2.5. Une entrée de la table de groupe peut être appliquée si l’entrée de la table de
flux utilise une instruction appropriée qui se réfère à son identifiant de groupe (group identifier).
En particulier, les entrées de la table de flux multiples peuvent pointer sur un identificateur de
groupe pour que l’entrée de la table de groupe s’effectue sur les flux multiples.
L’entrée de la table de groupe contient le type de groupe, un champ compteur et un champ
pour la liste des actions. Les compteurs sont utilisés pour collecter les statistiques concernant
les paquets traités par ce groupe, et la liste des actions stocke l’ensemble des actions qui seront
Identifiant du groupe Type du groupe Compteurs Liste des actions
Table 2.5: Entrées de la table du groupe pour la version 1.1 ou plus d’OpenFlow
17
Identificateur de mesure Meter band Compteurs
Table 2.6: Entrées de la table de mesure OpenFlow 1.3
exécutées selon le type du groupe (all, select, indirect, fast failover, …). Comme une fonctionnalité
optionnelle, OpenFlow 1.1 effectue l’identification des labels MPLS, les classes de trafic et les
actions spécifiques à MPLS comme l’insertion ou la suppression des labels MPLS. En général,
le nombre des actions supportées par la version 1.1 est supérieur à celui de la version 1.0. Par
exemple, le champ temps de survie (TTL Time To Live) dans l’en-tête IP peut décrémenter, ce qui
n’est pas supporté par la version précédente. OpenFlow v 1.1 fournit des champs de statistiques
additionnels. Par conséquent, les contrôleurs peuvent collecter les statistiques de la table et les
entrées de groupe, ainsi que les listes des actions.
OpenFlow v 1.2 [95] a été proposé en décembre 2011, il est livré avec un support étendu de
protocoles, en particulier IPv6. Cette version peut identifier les paquets IPv6 selon les adresses
source et de destination, le nombre de protocoles, le label de flux, la classe du trafic et le champ
d’ICMPv6. Les industriels ont de nouvelles possibilités pour étendre OpenFlow afin qu’il sup-
porte d’autres capacités d’identification. Le support du protocole IPv6 est dû au nouveau modèle
de correspondance appelé OXM (OpenFlow eXtensible Match). L’OXM utilise la structure TLV
(Type-Length-Value) pour remplacer la structure de correspondance statique avec une nouvelle
très flexible. Avec la version 1.2, un switch peut simultanément être connecté et administré par
un ensemble de contrôleurs. Le switch initialise la connexion, et les contrôleurs acceptent la ten-
tative de connexion. Un contrôleur est défini comme un maître et programme le switch, l’autre
contrôleur est un esclave, il peut prendre la place du maître si ce dernier tombe en panne.
L’OpenFlow version 1.3 [96] est apparue en juin 2012 et introduit une nouvelle fonctionnalité
pour l’opération, l’administration et la gestion (OAM, Operation, Administration and Manage-
ment). Pour cette version, la table de mesure (meter table) a été rajoutée dans l’architecture
des switchs OpenFlow. La Table 2.6 présente la structure des entrées de la table de mesure.
La mesure est directement attachée à une entrée de la table de flux par son identificateur de
mesure, qui mesure le taux de paquets assignés à l’entrée. La ’Meter band’ est utilisée pour con-
trôler le nombre de paquets en éliminant ceux qui excèdent une certaine limite. Ce qui permet
l’implémentation des frameworks de QoS simples ou complexes.
Le support des contrôleurs multiples s’est étendu, dans la version précédente (1.2), seule la
tolérance de panne est ciblée par le schéma du maître/esclave. Avec la version 1.3, des connexions
supplémentaires peuvent être utilisées entre le switch et le contrôleur maître pour équilibrer la
18
charge entre les lignes de connexion. En plus, le filtrage des évènements par connexion est intro-
duit, cela permet aux contrôleurs de capter uniquement les types de messages qui les intéressent.
Par exemple, un contrôleur responsable de la collecte des statistiques du réseau peut être con-
sidéré comme un contrôleur auxiliaire et enregistrer uniquement les statistiques des évènements
générés par les switchs. OpenFlow 1.3 supporte aussi les en-têtes extensibles d’IPv6, qui incluent
l’identification des en-têtes ESP (Encrypted Security Payload), ainsi que l’authentification et le
saut après saut (hop-by-hop) d’IPv6.
2.4.2.5 OpenFlow 1.4
L’ONF améliore le support d’OXM dans la version 1.4 d’OpenFlow [97] en octobre 2013. La
structure TLV pour les ports, les tables et les files d’attente a été rajoutée au protocole, et la
configuration des ports optiques est devenue possible. En plus, les contrôleurs peuvent envoyer
les messages de contrôle sous un seul message aux switchs. Des améliorations mineures ont été
aussi incluses dans cette version comme les tables de groupe, le contrôle de fonctionnalités et la
suppression des flux dans les tables pleines.
2.4.2.6 OpenFlow 1.5
Un an plus tard (décembre 2014), la version 1.5 d’OpenFlow [92] est apparue avec beaucoup
d’améliorations comme la notion des tables de sortie, et plus de 18 changements sont inclus dans
cette nouvelle version. Avec la version 1.4, tout le traitement se fait selon la table d’entrées,
cependant dans la version 1.5, le traitement se fait selon les tables d’entrées et de sorties (Figure
2.5).
Exécuter
Traitement à
l’ensemble
Port l’entrée
Table de Table de Table de des actions
d’entrée Flux 0 Flux 1 Flux N
Table de
groupe
Traitement à Exécuter
la sortie
Table de Table de Table de l’ensemble
des actions Port de
Flux 0 Flux 1 Flux N
sortie
Figure 2.5: Pipeline d’OpenFlow 1.5
19
Switchs OpenFlow Source Langage Origine Version
ouverte d’OpenFlow
Open vSwitch Oui C/Python Contribution 1.3
multiple
Reference Openflow [93] Oui C Université beta 0.8.9
de Stanford/
Nicira
Pica8 [105] Non C Pica8 1.2
Indigo [60] Oui C/Lua Big Switch 1.0
Pantou/ OpenWRT [104] Oui C - 1.0
Table 2.7: Types des commutateurs virtuels et leurs caractéristiques
2.4.3 Plan de données OpenFlow
Les éléments de transmission, principalement les switchs, doivent supporter les APIs sud et en
particulier le protocole OpenFlow. Nous pouvons diviser ces commutateurs en trois éléments
principaux [79], la couche physique (ou le chemin de données - datapath), la couche logicielle (le
chemin de contrôle – control path), et l’agent OpenFlow :
• Le chemin de données effectue la recherche et la transmission des paquets. Il est consti-

tué d’une ou de plusieurs tables de flux et d’une table de groupe. Les tables de flux sont
généralement enrichies par le contrôleur, et la table de groupe permet d’ajouter rapidement
des méthodes pour la transmission de flux.
• Le chemin de contrôle est une chaîne qui connecte le commutateur au contrôleur pour la
signalisation et pour des raisons de programmation. Les commandes et les paquets sont
échangés à travers cette chaîne en utilisant le protocole OpenFlow.
• L’agent OpenFlow fournit l’outil de communication entre le contrôleur et le commuta-

teur. Les informations échangées peuvent inclure les informations des paquets reçus, des
paquets envoyés, de la collection des statistiques, des actions à effectuer envers un flux
spécifique, etc.
Nous distinguons deux types de switchs OpenFlow : les commutateurs virtuels sous la forme
d’un logiciel comme Open vSwicth (OVS) [89], et les commutateurs physiques comme NetFPGA
[51]. Les commutateurs virtuels sont généralement bien implémentés et riches en fonctionnal-
ités. Cependant, même les plus matures souffrent de la vitesse de transmission, généralement
lente. La Table 2.7 résume les différents types de commutateurs virtuels avec leurs caractéris-
tiques.
Les commutateurs physiques implémentent l’OpenFlow comme une Application Specific Inte-
grated Circuit (ASIC). De tels circuits sont caractérisés par leur vitesse de transmission, équiva-
lente à la ligne de transmission, et par un grand nombre de ports, mais le manque de flexibilité et
20
de fonctionnalités limite leur utilisation [108]. Récemment, plusieurs équipementiers supportent
l’OpenFlow dans leurs commutateurs physiques, notamment HP, NEC, Pronto, Juniper, Cisco,
Dell, Intell, etc.
2.5 Applications SDN
Les réseaux SDN ont une large variété d’applications dans les environnements réseaux, et per-
mettent un contrôle personnalisé, une opportunité d’éliminer les équipements intermédiaires
et ils simplifient également le développement et le déploiement de nouveaux services et proto-
coles réseaux. Selon IDC (International Data Corporation) [114], le marché de SDN composé
des équipements d’infrastructure, des logiciels de contrôle et de virtualisation, des applications
de réseau et de sécurité, sera évalué à 12.5 milliards de dollars en 2020. Cette section présente
quelques exemples d’applications SDN.
2.5.1 Data center et Cloud computing
Ces dernières années ont été fortement marquées par une nouvelle technologie qui est le cloud
computing ou l’informatique en nuage. Cette technologie consiste à concentrer les ressources
(stockage, calcul, etc) dans des centres de traitement de données et de les offrir comme plate-
forme ou service à l’utilisateur. Cette tendance a augmenté la quantité de données manipulées et
par conséquent l’explosion du nombre de centres de données. Cette situation pose un défi pour
les réseaux qui transportent le trafic, surtout pour les grands opérateurs qui possèdent plusieurs
centres de données connectés. Le géant d’Internet Google a expérimenté pendant 3 ans les béné-
fices du SDN dans la gestion et le contrôle de ses centres de données autour du globe. Le projet
consiste à construire un réseau cœur expérimental appelé B4 [65] en parallèle avec son réseau
cœur opérationnel qui porte le trafic Internet. B4 connecte les centres de données distribués de
Google en séparant les plans de contrôle et de données. Cela permet un déploiement rapide des
nouveaux services et la centralisation du service de l’ingénierie du trafic dans un contrôleur SDN,
ce qui a augmenté le débit du réseau de 30 % [84] et l’utilisation des ressources réseau jusqu’à 95
% [65]. La Gestion des ressources informatiques est le défi le plus important des réseaux Cloud.
SDN est hautement considérée comme une des solutions les plus récentes, qui permet de config-
urer et de gérer facilement le Cloud et les centres de données. Oracle SDN [98] est un exemple
de système qui fournit un réseau virtualisé du centre de données. Ce système relie dynamique-
ment des machines virtuelles avec les serveurs de réseau. À l’aide de l’interface du gestionnaire
d’Oracle Fabric, la configuration et la surveillance de réseau virtuel est possible en tout lieu, et
le déploiement de nouveaux services comme le pare-feu, l’équilibrage de charge et le routage
devient à la demande. Selon Oracle, leur proposition augmente de 30 fois les performances des
applications.
21
2.5.2 Multimédia et QOS
L’architecture Internet d’aujourd’hui repose sur l’envoi des paquets sans prendre en considéra-
tion le type des paquets et la qualité de la transmission. Les applications multimédias comme
le streaming vidéo, la vidéo à la demande, la vidéo-conférence, la WebTV, etc, nécessitent des
ressources réseau stables et tolèrent les erreurs et les retards de transmission. En se basant sur
la vue centralisée du réseau offerte par SDN, on peut sélectionner selon le débit, des chemins
différents pour les divers flux de trafic. En [58] les auteurs fournissent le Video over Software-
Defined Networking (VSDN), une architecture de réseau qui détermine la trajectoire optimale en
utilisant une vue d’ensemble du réseau. Le VSDN a été implémenté dans NS3, et son comporte-
ment a été analysé à l’aide de la complexité des messages entre le VSDN et les hôtes/switchs
(ajout d’une nouvelle table de flux, demande d’un nouveau service, supression du service), de la
bande passante et du délai de transmission sur le réseau. VSDN est un projet de recherche en
cours avec d’autres améliorations à apporter.
2.5.3 Sécurité
Grâce à l’architecture centralisée de SDN, le contrôleur peut détecter les attaques rapidement
et limiter leurs effets. Plusieurs chercheurs ont présenté des mécanismes pour détecter les at-
taques par déni de service (Dos et DDos). Par exemple, dans [130] les auteurs proposent d’isoler
le périphérique réseau des attaques intra-LAN à l’aide d’OpenFlow. Dans l’architecture sug-
gérée, le composant IDS est chargé de détecter les attaques en reconnaissant les équipements
non sécurisés, et d’informer le contrôleur. Les résultats ont montré que cette architecture est as-
sez efficace sur un réseau LAN réel. Un nouveau plan de sécurité a été proposé dans [8]. Le rôle
de ce plan est d’inspecter tous les échanges de flux entre les switchs et le contrôleur pour prévenir
les attaques de type ‘IP spoofing’. Les résultats de simulation montrent que l’introduction de ce
plan permet de renforcer, en temps réel, les différents niveaux de sécurité avec un minimum de
configuration tout en gardant une surcharge très faible sur le contrôleur, puisque tout le traite-
ment est placé en dehors du contrôleur. Cela a permis de bloquer rapidement les attaques au
niveau du contrôleur et des switchs et de tracer leurs sources.
2.5.4 Réseaux sans fil
SDN a ete aussi appliqué dans le domaine des réseaux sans fil, en particulier 5G. En fait, selon
le rapport d’Ericsson [38], le trafic mobile a augmenté de 60 % entre 2015 et le premier trimestre
de l’année 2016. Gérer cette nouvelle masse de données est le plus grand défi des opérateurs,
puisqu’une mauvaise gestion conduirait à une interférence entre les différents signaux sans fils
et par conséquent dégraderait la qualité d’utilisation (QoE) du service pour les individus. Le
SDWN (Software Defined Wireless Network) a été proposé comme solution d’intégration du
SDN pour les réseaux sans fil, pour faciliter la gestion et supporter le déploiement de nouvelles
22
applications dans l’infrastructure réseau. De nouvelles architectures basées sur la séparation du
plan de contrôle et de données ont été proposées, notamment le CSDN (CellularSDN) [3] et le
SoftAir [59]. Ces architectures collectent les données des utilisateurs et les conditions du réseau,
et les font remonter au contrôleur afin d’optimiser la consommation d’énergie, l’utilisation des
ressources et la personnalisation des services aux utilisateurs.
Le concept de SDN a été également une source d’inspiration pour l’amélioration du rendement
des réseaux domicile (HAN) [101] et de Big data [69]. Ce dernier est gourmand en ressources
puisqu’il collecte et traite des volumes très larges des utilisateurs. Pour éviter la consommation
de la bande passante, il faut avoir une infrastructure flexible et dimensionnée. Le SDN répond
à ces exigences et adapte en temps réel le réseau à l’évolution des besoins en optimisant la cen-
tralisation des données, accélérant le traitement et simplifiant la gestion des commutateurs.
2.6 Conclusion
Dans ce chapitre, après un bref rappel de l’historique des réseaux programmables, nous avons
présenté le concept et l’architecture de SDN ainsi que les détails de l’implémentation du protocole
OpenFlow. Enfin, nous avons donné quelques applications de SDN. Ces applications montrent
l’intérêt qu’a suscité SDN auprès des chercheurs et des industriels dans le domaine des réseaux.
Nous pensons que cet intérêt est dû à la simplification de l’architecture des équipements réseau
et à l’abstraction du réseau. À travers les interfaces de communication fournies par le contrôleur,
les développeurs peuvent communiquer avec le réseau et proposer de nouveaux services.
Alors que le concept de SDN offre plusieurs avantages comme la facilité de gestion des réseaux et
l’introduction de nouvelles applications, il soulève cependant de nouveaux défis de performances
surtout au niveau du plan de contrôle puisqu’il concentre toute la complexité et l’intelligence du
réseau. Dans le prochain chapitre, nous présentons une étude bibliographique consacrée aux
performances des réseaux SDN.
23
Chapitre 3
Performances des réseaux SDN basés sur

le protocole OpenFlow
3.1 Introduction
Comme nous l’avons vu dans le chapitre précédent, l’approche SDN peut offrir plusieurs avan-
tages, comme la centralisation du contrôle et de la gestion, ainsi que la simplification des éléments
de transmission, mais elle soulève aussi des défis en terme de performance et de scalabilité. En
fait, les premières propositions et déploiements de réseaux SDN utilisaient un seul contrôleur
centralisé, cela pose le problème d’avoir un point unique de défaillance (SPOF, Single Point Of
Failure), et l’incapacité du contrôleur à gérer une grande quantité de demandes de flux et, par
conséquent, l’incapacité à évoluer lorsque la taille du réseau augmente. Par exemple, le premier
contrôleur SDN, appelé NOX, a un temps d’installation de flux de moins de 10 ms et peut gérer
jusqu’à 30000 demandes par seconde [78]. Par la suite, d’autres contrôleurs ont été proposés
comme Floodlight [49] et OpenDayLight [90] pour améliorer les performances d’un seul con-
trôleur. En revanche, pour éviter le problème d’un point de défaillance unique et pour aborder la
question de la scalabilité, des architectures du plan de contrôle comportant plusieurs contrôleurs
ont été proposées. Ces architectures génèrent de nouvelles questions telles que : le nombre de
contrôleurs nécessaires, le placement des contrôleurs et la communication entre les contrôleurs.
Dans ce contexte, nous distinguons deux principales propositions des conceptions de plan de
contrôle : logiquement centralisés et logiquement distribués. Les deux propositions ont leurs
avantages et leurs inconvénients.
L’objectif de ce chapitre est de donner un état de l’art des principales études et propositions qui
ont été faites dans la littérature concernant les performances des réseaux SDN. Ceci contraire-
ment à d’autres études bibliographiques [35, 127] qui couvrent tous les aspects des réseaux SDN
et ne se concentrent pas sur les problèmes de performances et les solutions proposées. Ce tra-
vail a donné lieu à un article dans le journal ‘Journal of Networks’ [45]. Dans ce chapitre, nous
commençons par les améliorations, aussi bien logicielles que matérielles, qui ont été faites pour
améliorer les performances des commutateurs OpenFlow. Par la suite, nous nous focalisons sur
les techniques utilisées, comme le multithreading et la virtualisation afin d’accélérer le traite-
ment des demandes au sein d’un contrôleur physiquement centralisé. Puis, nous présentons les
architectures multi-contrôleurs et discutons de leurs avantages et de leurs inconvénients. Nous
terminons ce chapitre par les méthodes et les outils qui ont été utilisés dans la littérature pour
évaluer les performances des réseaux SDN.
3.2 Performances des commutateurs OpenFlow
Récemment, des modèles de commutateurs basés sur les flux (OpenFlow) ont émergé avec plus de
souplesse par rapport aux commutateurs Ethernet. Dans cette section, nous présentons une étude
qui compare les commutateurs OpenFlow et les commutateurs traditionnels en terme de perfor-
mances et ensuite nous discutons les contributions qui ont été apportées au plan de données d’un
réseau SDN. Ces contributions sont classées en deux catégories : logicielles et matérielles.
3.2.1 Comparaison avec les commutateurs traditionnels
Depuis l’arrivée des commutateurs OpenFlow, une comparaison en matière de performances

avec les commutateurs traditionnels était nécessaire. Dans [2], les auteurs évaluent les perfor-
mances réalisables par un commutateur OpenFlow et par les commutateurs traditionnels couche
2 et couche 3. Dans leur évaluation, les auteurs ont testé l’effet de la taille des paquets et le type
du trafic sur les performances des différents commutateurs considérés. Dans toutes les expéri-
ences réalisées, le commutateur OpenFlow offre de très bonnes performances par rapport aux
commutateurs traditionnels. Malgré ces résultats encourageants, les commutateurs OpenFlow
doivent être améliorés pour supporter la charge des réseaux de production, ces améliorations
pouvent être au niveau de l’architecture physique (ASIC) ou au niveau logiciel.
3.2.2 Améliorations logicielles
Les commutateurs OpenFlow ont deux types de tables de recherche : hachage et linéaire. La table
de hachage, également appelée table de correspondance exacte, utilise une fonction de hachage,
et contient jusqu’à 131072 entrées. La table linéaire utilise les masques des paquets pour faire
correspondre les paquets aux flux; c’est une petite table qui contient seulement 100 entrées. Dans
l’article [124], les auteurs introduisent une nouvelle technique : ‘Flow Director’. Elle est utilisée
pour diriger les paquets entrants aux files d’attente de réception. Le Flow Director est consid-
éré comme une table de recherche supplémentaire, qui stocke une correspondance entre la file
d’attente de réception et le port de sortie. Les auteurs observent contrairement à la taille de la
table linéaire, la taille de la table de hachage et celle du Flow Director n’affectent pas les perfor-
25
mances du commutateur OpenFlow, et que la mise à jour du commutateur OpenFlow améliore le
débit de commutation de plus de 25 % par rapport au débit du commutateur OpenFlow ordinaire.
Une autre amélioration que nous mentionnons dans ce paragraphe concerne les compteurs et
les statistiques qui restent dans un commutateur OpenFlow. Mogul et al. dans [63] ont annoncé
que parmi les avantages des réseaux SDN, on trouve le contrôle précis des flux en maintenant les
compteurs par flux (par exemple: les paquets reçus, octets reçus et durée) dans le plan de données
et les rend visibles aux contrôleurs externes. Ils proposent un compteur SDN (SDC, Software De-
fined Computing) pour migrer tous les compteurs du SDN de l’ASIC au CPU du commutateur
local, par conséquent ils proposent théoriquement le SDC pour accroître la flexibilité, accéder
efficacement aux compteurs et réduire la complexité des cartes ASIC.
3.2.3 Améliorations matérielles
Un commutateur OpenFlow prend généralement deux décisions importantes : la gestion de file

d’attente (queuing management) et la planification des opérations (scheduling operations). La
première concerne la taille maximale des files d’attente et la seconde consiste à décider quel
paquet doit être envoyé par la suite, lorsqu’un lien sortant est libre ? Les auteurs de [11] proposent
d’étendre la flexibilité du SDN pour couvrir les files d’attente et de planification des décisions
prises dans le plan de données en ajoutant une petite carte FPGA au commutateur. Cette solution
permet de reconfigurer les paramètres de planification et ceux des files d’attente et de les ajuster
aux objectifs de l’application réseau. Ceci s’est traduit par une amélioration significative des
performances et de la souplesse du plan de données.
D’autres études ont proposé de nouvelles méthodes pour tirer parti d’un processeur supplémen-
taire intégré dans le commutateur. Luo et al. dans [131] implémentent un processeur multi-cœur
au niveau de la carte réseau pour réduire le nombre d’opérations et le délai des paquets au niveau
du processeur du commutateur. Les résultats montrent une réduction de 20 % sur les retards de
paquets par rapport aux commutateurs OpenFlow traditionnels. Dans la même direction, les
auteurs de [52] ont proposé d’augmenter la taille des tables de transmission et de la mémoire
tampon des commutateurs actuels. L’idée principale est de combiner les capacités du processeur
avec celles de la carte ASIC pour un traitement rapide des données. Dans leur solution, le com-
mutateur OpenFlow n’est pas un composant passif ; il échange les flux, contrôle les files d’attente
et décide de la redirection du trafic. Les auteurs proposent d’utiliser le processeur comme un co-
processeur du trafic dans les commutateurs pour adresser les limitations de la taille des tables
de transmission et la mémoire tampon dédiée au paquet. Ce qui rend le commutateur plus pro-
grammable et offre plus de fonctionnalités réseau. Un prototype a été élaboré et un débit de 3,9
Go/s est atteint.
D’après les études précédentes, différents paramètres peuvent influer sur la performance d’un
commutateur OpenFlow, comprenant le temps de traitement dans les cartes ASIC modernes (all-
in-one), le délai de recherche dans les tables de correspondance, la gestion de la file d’attente
26
et la planification des opérations. Les améliorations proposées conduisent à améliorer les per-
formances des commutateurs OpenFlow, et ils encouragent les entreprises à les utiliser dans les
réseaux de production. Dans la section suivante, nous présentons les études de performances
des contrôleurs OpenFlow.
3.3 Performances des contrôleurs OpenFlow
Dans les environnements SDN en particulier, les premiers déploiements avec un seul contrôleur
physique, le contrôleur reste la pièce fondamentale de l’architecture et le point critique de son
succès, parce qu’il prend en charge toutes les décisions concernant le fonctionnement du réseau.
C’est pourquoi les chercheurs ont toujours essayé d’améliorer les performances des contrôleurs
et leur capacité à gérer un très grand nombre d’équipements réseau. Deux métriques importantes
permettent de caractériser les performances d’un contrôleur : le temps nécessaire pour instaurer
une nouvelle règle dans les switchs (latence) et le nombre de requêtes traitées par seconde (débit).
NOX, le premier contrôleur développé pour gérer le réseau SDN, a un débit de 30000 flux par
seconde et une latence de 10 ms [78]. Par la suite plusieurs contrôleurs (plus de 30) ont été
proposés par l’industrie et les laboratoires. Cette section présente quelques travaux intéressants
sur les performances des contrôleurs SDN en donnant un aperçu des solutions et des techniques
qui ont été proposées pour améliorer les performances des contrôleurs SDN.
3.3.1 Améliorations basées sur le multithreading
Dans le but d’améliorer les performances du contrôleur SDN, les chercheurs utilisent la technique
de multithreading. Les Auteurs de [13] ont introduit un nouveau contrôleur multi-thread, appelé
NOXMT (nouvelle version du contrôleur OpenFlow NOX). La principale conclusion est que les
NOX-MT améliorent le débit du contrôleur de plus de 30 fois. En effet, NOX-MT tire pleinement
parti des processeurs multi-coeurs à l’aide de techniques de multithreading qui peuvent exé-
cuter plusieurs tâches simultanément et manipuler des tâches différentes en même temps, ce qui
rend l’utilisation des ressources disponibles optimale. Une importante étude qui se penche sur
l’impact du multithreading sur les performances est donnée en [10]. Les auteurs effectuent une
comparaison entre les différents contrôleurs en terme de performance, en particulier de débit.
En fait, deux facteurs principaux distinguent les contrôleurs, le premier est l’algorithme de dis-
tribution des messages entrants entre les threads, et le second est le mécanisme utilisé pour la
communication des équipements du réseau. La variation du nombre de threads de 1 à 12, per-
met de constater que les contrôleurs ayant un seul thread (NOX et Ryu) ont un débit très limité,
parce qu’ils ne peuvent pas gérer un grand nombre de flux et ne présentent aucune évolutivité
par rapport au nombre de cœurs du processeur utilisé, toutefois le contrôleur Beacon, qui est
multi-thread, peut gérer un grand nombre de flux par seconde. L’évolutivité du Maestro est lim-
itée à 8 cœurs vu que le contrôleur ne s’exécute pas avec plus de 8 cœurs et la performance du
27
Floodlight augmente parallèlement à l’augmentation du nombre de cœurs. Enfin, Beacon permet
d’obtenir un débit de près de 7 millions de flux par seconde et affiche la meilleure évolutivité. En
conclusion, les caractéristiques et les performances des contrôleurs SDN peuvent être très dif-
férentes. Ainsi, il est important de choisir avec soin le contrôleur OpenFlow, Beacon présentant
la meilleure performance et la meilleure évolutivité.
3.3.2 Améliorations basées sur la virtualisation
La virtualisation du réseau est une abstraction particulière d’un réseau physique qui permet de
supporter plusieurs réseaux logiques fonctionnant sur une infrastructure physique commune.
SDN sépare efficacement le plan de données et le plan de contrôle, alors que les réseaux virtuels
séparent les réseaux logiques et physiques. Les deux concepts sont certes différents, mais on peut
tirer parti de la virtualisation du réseau pour améliorer les performances des réseaux SDN. Les
chercheurs proposent d’ajouter une nouvelle couche appelée FlowVisor [109] entre le plan de
contrôle et le plan de données. FlowVisor permet à plusieurs contrôleurs hétérogènes de cohab-
iter dans la même infrastructure physique en partitionnant les tables de flux du commutateur.
Chaque contrôleur peut gérer son réseau logique avec son propre espace d’adresse et son propre
mécanisme de transmission. Cette technique permet d’une part d’améliorer les performances du
réseau en exploitant au maximum les ressources physiques disponibles, et d’autre part de laisser
le trafic expérimental s’exécuter parallèlement au trafic de production sur la même infrastruc-
ture réseau. Considérant que FlowVisor peut être comparé à une technologie de virtualisation
complète, FlowN [27] est une solution de virtualisation basée sur les conteneurs (containers) où
chaque conteneur est conçu pour résoudre le problème de multi-tenant (tous les clients bénéfi-
cient d’une solution à travers la même infrastructure) dans les environnements de cloud. FlowN
permet de partager la plateforme de contrôle sur tous les domaines du cloud où chaque tenant a
un contrôle total sur son réseau virtuel, et peut déployer n’importe quelle application sur le con-
trôleur. En comparant FlowN et Flowvisor dans un réseau virtuel évolutif, les auteurs concluent
que FlowN a une charge plus élevée (latence) en raison de la base de données, mais qu’il évolue
mieux que FlowVisor (dans le cas de 100 réseaux virtuels ou plus).
3.4 Amélioration des performances en utilisant plusieurs contrôleurs
Plusieurs raisons ont conduit à l’utilisation de contrôleurs SDN multiples, notamment la nécessite
de gérer des réseaux hétérogènes, l’amélioration des performances, l’évolutivité, la fiabilité et
la multitude de domaines administratifs des réseaux WAN. Par exemple, plusieurs technologies
peuvent intervenir dans les réseaux de transport du centre de données, comme IP, MPLS, optique,
etc. Dans ce cas, il peut y avoir plus d’un contrôleur SDN gérant les switchs du centre de données,
les switchs d’agrégations et les switchs optiques. En outre, pour obtenir l’approvisionnement de
bout en bout et la gestion des ressources dans les réseaux informatiques, il peut y avoir un besoin
28
d’interaction et de coordination entre les réseaux optiques et IP/MPLS. Ce genre de coordination
est obtenu à travers le déploiement de plusieurs contrôleurs SDN, et l’interaction entre eux peut
optimiser la complexité des multicouches et l’ingénierie intelligente du trafic. En cas d’erreur, le
déploiement des contrôleurs multiples est nécessaire pour restaurer et optimiser les couches IP et
optiques. L’utilisation des contrôleurs multiples peut offrir plusieurs avantages, mais soulève de
nouvelles questions, auxquelles cette section tente de répondre en présentant certains éléments,
tels que le nombre suffisant de contrôleurs pour une architecture donnée, leur emplacement, et
la communication inter-contrôleurs.
3.4.1 Nombre et emplacement des contrôleurs
Le temps de réponse d’un contrôleur est un facteur primaire pour décider si un contrôleur sup-
plémentaire doit être déployé. Le problème du nombre et de l’emplacement des contrôleurs a été
abordé dans quelques travaux. La première étude sur ce sujet a été réalisée par Heller et al dans
[128]. Ils s’intéressent à déployer le concept SDN dans les architectures WAN où la latence est
un problème dominant. Le meilleur choix d’emplacement du contrôleur dépendra de la latence
de propagation fixée dans les équipements de la topologie, ce facteur gardant une stabilité et une
vitesse raisonnable entre les réactions du contrôle et le contrôleur distant. Les chercheurs intro-
duisent le problème d’emplacement des contrôleurs et examinent les compromis entre les nœuds
et les contrôleurs lors de l’optimisation de la latence. Ils trouvent que les contrôleurs addition-
nels fournissent au retour une baisse de délai dans la plupart des topologies et que le nombre de
contrôleurs dépendra de la topologie réseau et du choix des métriques. Dans certains cas, un seul
contrôleur est suffisant pour répondre aux attentes communes du réseau en respectant le délai
de communication.
Les chercheurs en [129] étudient l’emplacement le plus fiable des contrôleurs SDN. Pour ceci, ils
présentent d’une part une nouvelle métrique appelée le pourcentage attendu du chemin de con-
trôle valide quand une défaillance de réseau se produit, d’autre part l’algorithme qui produit les
résultats les plus idéaux. Les chemins de contrôle sont les trajets définis par le réseau pour faire
communiquer les commutateurs avec leur contrôleur, et les contrôleurs entre eux-mêmes, par
conséquent ce pourcentage reflète la fiabilité du contrôle d’un réseau SDN. L’étude résulte du fait
que l’algorithme ‘Greedy’ est celui qui fournit la solution la plus optimale et que l’emplacement
du contrôleur doit être soigneusement choisi, et dépend de l’algorithme utilisé. Une autre étude
similaire dans [12] essaye d’optimiser la fiabilité du réseau de contrôle SDN en minimisant le
pourcentage attendu des pertes au niveau des chemins de contrôle. Pour évaluer la fiabilité, les
chercheurs utilisent l’algorithme ‘Brute force’, afin de générer toutes les combinaisons possibles
des contrôleurs dans chaque emplacement potentiel, et mesurent le coût de chaque emplace-
ment. Ils constatent que l’utilisation de quelques contrôleurs réduit la fiabilité. Cependant, pour
toutes les architectures testées, dépasser un certain nombre de contrôleurs peut avoir un effet
indésirable. Par conséquent, ils trouvent que le meilleur nombre de contrôleurs est entre [0,035n
29
- 0,117n], où ‘n’ est le nombre de nœuds.
Récemment, des propositions ont été faites pour distribuer physiquement les contrôleurs. Nous
présentons par la suite deux catégories de solutions : la première catégorie propose un plan de
contrôle physiquement distribué, mais logiquement centralisé à travers la synchronisation de
toutes les informations concernant le réseau et l’équilibre de charges entre les contrôleurs. La
seconde catégorie suggère une architecture de plan de contrôle logiquement distribué, où chaque
contrôleur gère son domaine et distribue les informations utiles avec les autres instances.
3.4.2 Plan de contrôle logiquement centralisé
La distribution physique du plan de contrôle dans le SDN a été abordée dans différents travaux.
Cette catégorie de solutions déploie un plan de contrôle logiquement centralisé utilisant plusieurs
contrôleurs, partageant les charges et synchronisant les données entre les contrôleurs afin d’amél-
iorer les performances et l’évolutivité des réseaux SDN. Chaque contrôleur doit synchroniser
toutes les informations concernant ses commutateurs. L’intérêt de cette solution apparaît dans
les réseaux de centres de données (data center), où les contrôleurs partagent une grande quantité
d’informations pour assurer la cohérence d’un réseau large avec précision. Parmi les solutions
qui utilisent un plan de contrôle logiquement centralisé, nous trouvons :
• HyperFlow [12] : utilise deux composantes majeures, un contrôleur implémenté comme

application sur le NOX [78] et un système de distribution des évènements utilisant WheelFS
[64] pour construire un modèle de messagerie de type publié/souscrire (Publish/Subscribe).
En conséquence, HyperFlow peut supporter plus d’évènements de flux en gardant un délai
d’installation de flux minimal.
• Onix [117] : C’est le fruit de la collaboration entre Google et Nicira [85]. Onix suggère
un système distribué basé sur le cluster. Ce dernier est responsable de la logique pro-
grammable du contrôle du réseau, et de la distribution des états du réseau entre les in-
stances qui composent le cluster. L’équipe Onix implémente quatre composants dans le
contrôleur pour assurer un réseau distribué. L’infrastructure physique (commutateur et
routeur), l’infrastructure de connexion (canal de contrôle), Onix et enfin la logique de
contrôle. Avec l’utilisation du cluster, chaque état du contrôleur est enregistré dans la
structure de données appelée la base des informations réseaux (NIB, Network Information
Base). Pour répliquer les NIBs entres les contrôleurs Onix, deux modèles de cohérence
sont fournis, la base de données transactionnelle (transactional database) et la table Hash
distribuée (DHT, Distributed Hash Table). Onix ne propose pas un nouveau mécanisme,
mais prouve que le déploiement des architectures de contrôleurs multiples est faisable avec
les technologies existantes.
• Opendaylight (ODL) [90]: fonctionne en mode simple où un seul contrôleur est utilisé,
et en mode cluster pour construire un réseau distribué et fournir une haute disponibilité,
30
fiabilité, et évolutivité. Il utilise le Framework Akka [18] pour synchroniser les données
entre les contrôleurs multiples. En effet, ODL fournit la persistance en distribuant les bases
de données, l’accès à distance en constituant des connexions entre les membres du cluster
et la découverte des membres en utilisant le protocole Gossip [4].
• Kandoo [112] : introduit une architecture distribuée de contrôleurs basée sur deux couches
de plan de contrôle. La couche basse contient un groupement de contrôleurs locaux qui
gèrent les applications locales et qui ne nécessitent aucune connaissance de l’architecture
totale du réseau. Un contrôleur racine centralisé constitue la couche supérieure, son rôle
est de déterminer le comportement du réseau désiré et d’exécuter les applications qui né-
cessitent une vue globale de l’architecture. Cette architecture résulte en une réduction du
nombre d’évènements traités par le plan de contrôle du réseau.
• Elascon [5]: Les réseaux distribués sont caractérisés par une variation de charge sur les
contrôleurs, toutes les solutions précédentes adoptent un mappage (switchs, contrôleur)
de manière statique. À l’aide du mécanisme du cluster, Elascon fournit plus de flexibilité et
propose un protocole de migration des switchs basé sur le trafic qui circule dans le réseau.
Cela facilite le mouvement des switchs d’un contrôleur à un autre et minimise la charge
sur les contrôleurs.
• Onos [100]: acronyme de Système d’Exploitation pour les Réseaux ouverts (Open Net-
work Operating System), où chaque contrôleur individuel partage une base de données
commune en utilisant le modèle de cluster. Onos fournit deux prototypes, le premier ser-
vant à extraire une vue globale du réseau à partir de l’architecture distribuée, destiné aux
applications qui nécessitent une évolutivité du réseau et une tolérance de panne. Le deux-
ième prototype est conçu pour l’amélioration des performances notamment la latence des
événements.
• Constructeurs: Plusieurs constructeurs des contrôleurs SDN comme HP [57], Cisco [24],
Vmware [83] et NEC [81] proposent un modèle distribué du SDN sous forme de cluster.
Ces solutions présentent les différentes méthodes de synchronisation des changements du réseau,
où tous les contrôleurs contiennent toutes les décisions au même moment, mais cela est limité
pour partager les charges et les données dans un réseau avec un seul domaine. Néanmoins, ils ne
sont pas adaptés aux réseaux étendus composés de plusieurs domaines ou systèmes autonomes
(AS), et nécessitent un trafic extensif entre les contrôleurs pour garder une vue globale sur le
réseau.
3.4.3 Plan de contrôle logiquement distribué
Une autre approche pour utiliser les contrôleurs multiples consiste à distribuer logiquement le
plan de contrôle, en proposant une interface intégrée, un mécanisme de pont Est-Ouest ou un
31
plan de contrôle SDN distribué. Parmi les solutions qui utilisent un plan de contrôle logiquement
distribué, nous trouvons :
• SDNi [120]: IETF développe un protocole Est/Ouest appelé SDNi pour réaliser une inter-
connexion entre les contrôleurs SDN. Dans ce projet, les chercheurs décrivent une inter-
face pour échanger les informations entre plusieurs domaines supportant le SDN, afin de
synchroniser la base de données réseau et coordonner les décisions entre les contrôleurs
(Figure 3.1). Une proposition d’implémentation du SDNi est fournie par la société TATA
(TCS) [61], en proposant le protocole BGP (Border Gateway Protocol) comme candidat
pour implémenter SDNi.
• DISCO [68] : Disco propose des contrôleurs SDN logiquement distribués, où chaque con-
trôleur DISCO commande son domaine réseau et communique avec les autres extensions
en utilisant un canal de contrôle appelé ‘Agent’. Alors, il fournit un plan de contrôle dis-
tribué et ouvert pour les réseaux multi-domaines en utilisant une communication orientée
vers les messages. Le succès derrière DISCO, c’est qu’il sépare le plan de contrôle en deux
plans. La partie intra-domaine qui rassemble les principales fonctionnalités du contrôleur,
et la partie inter-domaine qui gère la communication entre les autres contrôleurs, en en-
voyant un agent de type réservation, état du réseau ou opérations d’interruption. Cette
solution a été testée pour l’interruption des topologies inter-domaine, les demandes de pri-
orité de service bout-en-bout (end-to-end) et les cas de migration des machines virtuelles
(VM).
• WEBridge [102]: La proposition ‘WEBridge’ aborde le même problème, mais dans le cas de
plusieurs systèmes d’exploitation. Elle utilise trois nouveaux modules pour créer une vue
globale sur le réseau et garantir l’intégrité des données entre les contrôleurs, ces modules
sont la virtualisation réseau, le pont Est-Ouest et l’extension LLDP. Le module de virtual-
isation réseau permet une abstraction du réseau physique au réseau virtuel pour chaque
domaine. Par la suite, le module ‘WEBridge’ utilise un modèle de publier/souscrire pour
synchroniser les données entre les contrôleurs. Enfin, le rôle de l’extension LLDP est de
permettre à ‘WEBridge’ de supporter plusieurs contrôleurs issus de différents contrôleurs.
3.5 Techniques d’évaluation des performances des réseaux SDN
Les trois techniques le plus souvent utilisées pour évaluer les performances d’un réseau, sont
le modèle analytique, la simulation, et l’expérimental. Ce dernier est généralement basé sur
des mesures obtenues à partir de l’infrastructure physique du réseau. Dans cette section, nous
présentons les différentes techniques d’évaluation utilisées au sein des réseaux SDN.
32
Contrôleur SDN
Contrôleur SDN Commutateur Contrôleur SDN

OpenFlow
Commutateur Commutateur
OpenFlow OpenFlow
Figure 3.1: Architecture distribuée des réseaux SDN
3.5.1 Modèles analytiques
À notre connaissance, il existe peu d’études sur les performances des réseaux SDN basées sur le
modèle analytique. La première étude [111] utilise le formalisme réseau ‘Calculus’ pour analyser
le délai et les limites de la taille des files d’attente des commutateurs et des contrôleurs SDN.
Une deuxième étude est basée sur la théorie des files d’attente [67], dont elle permet d’évaluer la
probabilité de perte de paquets et le délai de transmission dans le système. Cependant, ce modèle
est très basique, et ne prend pas en considération toute la complexité des réseaux SDN.
3.5.2 Plateformes d’expérimentation
Plusieurs plateformes d’expérimentation ont été développées pour aider les chercheurs et les
développeurs d’applications à tester et valider leurs propositions. Parmi les plus utilisées, nous
citons GENI [53] aux États-Unis, AKARI [56] au JAPON [70] et OFELIA [87] en Europe. Par
exemple, la communauté OFELIA fournit gratuitement aux utilisateurs externes une plateforme
réseau expérimentale, construite à partir de plusieurs types de réseaux appelés ‘Island’ comme
i2CA, IBBT, ETHZ. Chaque ‘Island’ est équipée de différents types de commutateurs OpenFlow
et de serveurs, avec des capacités différentes. Les métriques de performance mesurées dans ce
genre de plateforme donnent des résultats très proches de la réalité, et permettent d’avoir une
idée sur le comportement du système étudié avant la phase d’industrialisation. Plusieurs projets
33
ont été testés sur ces plateformes, comme le protocole OpenFlow [79], testé sur GENI, et les
performances du plan de données [2], sur FEDERICA.
3.5.3 Outils de simulation
Plusieurs outils de simulation et d’émulation comme Mininet [21] ont été développés pour implé-
menter les réseaux basés sur OpenFlow dans une seule machine, et aussi pour tester les nouvelles
applications.
• Mininet (nous présentons l’instation et les commandes d’utilisation dans l’Annexe A.1 et
A.2) : est un émulateur d’environnement SDN, développé par l’université de Stanford, et
peut être utilisé pour construire des réseaux virtuels et estimer les métriques de perfor-
mance pour différentes topologies avec des configurations différentes.
• NS3 [119] : une autre option est d’utiliser le simulateur NS dans sa version 3 qui supporte
la version 0.8.9 du protocole OpenFlow dans son environnement.
• EstiNet [39] : est un simulateur propriétaire supportant la version 1.3.2 du protocole Open-
Flow. Il propose deux modes de fonctionnement, simulation et émulation, et peut simuler
des milliers de switchs. EstiNet consomme moins de ressources et il est considéré comme
étant le plus performant et le plus évolutif.
• OMNET++ [88] : est un projet open source dont le développement en C++ a commencé en
1992 par Andras Vargas à l’université de Budapest. En 2013, Omnet++ support le protocole
OpenFlow v1.0.
Pour analyser les performances des commutateurs OpenFlow, des Frameworks ouverts ont été
proposés, nous trouvons :
• OFLOPS [23] : Il permet de générer des tests pour les commutateurs OpenFlow, tels que
l’utilisation du CPU et le comptage des paquets. Cependant, il ne prend pas en charge les
contrôleurs SDN.
• Cbench [73] : est un outil de test de performance conçu spécialement pour les contrôleurs
SDN. Cbench simule un nombre défini de switchs qui sollicitent au maximum le contrôleur
en envoyant des paquets de type ‘Packet_in’ et en attendant les réponses sous la forme de
paquets de type ‘flow-mod’. Il existe deux modes de fonctionnement dans Cbench, appelés
latence et débit. Dans le mode latence, chaque switch configuré envoie un seul paquet
‘Packet_in’ au contrôleur et attend un paquet ‘flow-mod’, puis répète le même processus.
Le nombre total de réponses reçu durant la période de test est utilisé pour calculer la latence
moyenne de traitement des demandes. Dans le mode débit, chaque switch configuré envoie
constamment, et autant que possible, le nombre de ‘Packet_in’, afin de mesurer la capacité
maximale du contrôleur.
34
• OpenSketch [76] : il collecte les informations mesurées du plan de données et du plan de
contrôle. Dans le plan de données, OpenSketch fournit des bibliothèques de mesure qui
configurent automatiquement le scénario de test et réservent les ressources à différentes
tâches de mesure.
3.6 Conclusion
Dans ce chapitre, nous avons donné un aperçu des études les plus importantes fournissant des
solutions pour améliorer les performances des réseaux SDN pour le plan de données et pour le
plan de contrôle. En effet, depuis l’émergence du SDN, plusieurs travaux se sont focalisés sur les
performances. Cela ne signifie pas que le SDN cause plus de problèmes de performance que les
réseaux traditionnels, mais il reflète l’intérêt immense de la communauté vis-à-vis de cette nou-
velle technologie, qui permet notamment la programmabilité et facilite la gestion des réseaux.
À travers les différentes études, nous avons constaté que le taux de traitement du processeur, le
débit et le délai de traitement sont les facteurs clés qui influencent les performances du plan de
données. De même, nous avons remarqué que le plan de contrôle, considéré comme la couche
fondamentale de l’architecture du SDN, a reçu beaucoup d’attention en matière de performance,
et les derniers contrôleurs sont devenus plus efficaces. Cependant, nous pensons que le dé-
ploiement de contrôleurs multiples dans les réseaux largement distribués contenant plusieurs
domaines, tels qu’Internet, nécessite une analyse de fond et plus d’investigation sur le nombre
de contrôleurs, le protocole de communication entre les contrôleurs et le coût de la synchroni-
sation. Dans ce contexte, la suite de ce rapport sera consacrée à l’évaluation et à l’amélioration
des performances des différentes architectures du plan de contrôle.
35
Chapitre 4
Évaluation des performances du plan de

contrôle physiquement centralisé
4.1 Introduction
Dans le chapitre précédent, nous avons présenté un état de l’art sur les performances des réseaux
SDN que ça soit au niveau du plan de données ou du plan de contrôle. Dans ce chapitre et les
chapitres suivants, nous présentons nos propres études sur les performances des réseaux SDN
en considérant les différentes architectures du plan de contrôle présentées précédemment. Nous
commençons dans ce chapitre avec l’architecture initiale des réseaux SDN qui consistait à utiliser
un seul contrôleur (ou ce qu’on appelle un plan de contrôle physiquement centralisé). Au début
de la thèse, nous avons commencé par cette architecture, car elle était la plus répandue et aussi
pour maîtriser les outils de simulation spécifiques à SDN et OpenFlow avant de passer à des
architectures multicontrôleurs. Ainsi, nous avons réalisé une étude de cas du contrôleur Ryu
[110] basé sur OpenFlow.
Avec un seul contrôleur physique, les commutateurs sollicitent le contrôleur à chaque fois qu’ils
n’y a pas de règle qui correspond au paquet reçu dans leur table de flux. Dans ce cas, le contrôleur
traite le paquet selon l’application désirée et instaure les actions appropriées dans les tables de
flux des commutateurs. Ceci pose le problème des performances du contrôleur et sa capacité à
traiter un grand nombre de demandes (débit), surtout quand la taille du réseau augmente. Aussi,
le temps d’installer une nouvelle règle (latence) est très important car il influence le délai de
traitement des paquets et par conséquent il peut améliorer le fonctionnement du réseau. Dans
cette étude, nous évaluons le débit et le délai pour différentes tailles du réseau. En fait, nous
voulions avoir une idée sur les limites, en nombre de noeuds, d’un seul contrôleur physique. Pour
améliorer les performances, nous avons aussi proposé d’utiliser la technique de multi-instances
que nous allons présenter en détail en section 4.3.2. Les résultats de cette étude ont donné lieu à
une publication dans (Lecture Notes in Computer Science LNCS) [46].
Le reste de ce chapitre est organisé comme suit : dans la section 2, nous présentons l’environnement
de test et les expériences que nous allons réaliser dans cette étude. Dans la section 3, nous présen-
tons et analysons les résultats de simulation obtenus. Enfin, nous donnons notre conclusion sur
cette étude dans la section 4.
4.2 Environnement d’évaluation et description des expériences
4.2.1 Environnement d’évaluation
Étant donné que les études présentées dans ce rapport ont été réalisées dans différentes périodes
de la thèse, nous avons utilisé différents contrôleurs, outils et environnements de test. Cette
différence nous a permis d’explorer plus de possibilités et d’enrichir nos expériences. Notons
que tous les outils utilisés durant cette thèse sont gratuits et disponibles en ligne, cela permet
donc la reproduction de tous les résultats de ce rapport. Avant de nous lancer dans la description
des outils de test de chaque étude, nous montrons les points communs entre toutes les études
présentées dans ce rapport.
Toutes les expériences sont tournées sous l’émulateur Mininet (v. 2.0) [21], un outil largement
utilisé dans la communauté SDN et il permet de simuler des topologies classiques comme bus,
anneau, hiérarchique, ou personnalisées, qui reflètent la configuration exacte d’une topologie
d’entreprise (Annexe A). Pour construire le plan de données nous avons opté pour Open vSwitch
(OVS v.2.0.90) [89] comme switch de transmission Openflow, parce qu’il est très mature et open
source. Chaque switch est attaché à un hôte virtuel conçu par Mininet. Ces hôtes sont consid-
érés comme des petites machines Linux, et supportent une variété de services, comme le service
web client/serveur. En outre, le protocole utilisé pour la communication entre le contrôleur et
les switchs est OpenFlow [79], qui a été décrit dans le deuxième chapitre. Afin d’isoler les ex-
périences du système d’exploitation, nous simulons des machines virtuelles (VMs) à travers une
application de virtualisation nommée VirtualBox [125]. Nous réservons au moins deux VMs, une
pour le réseau émulé et une autre pour le contrôleur. Dans certains cas nous utilisons jusqu’à
9 VMs pour réaliser l’expérience. Ces VMs sont interconnectés à travers l’émulateur GNS3 [55]
en utilisant un switch Ethernet virtuel. Dans les cas où une connexion entre les VMs et le réseau
Internet est nécessaire, un routeur virtuel sera utilisé. Nous adoptons dans cette étude le Frame-
work Ryu (Annexe B.1) dans sa version 3.2 comme contrôleur SDN. Il est basé sur python et
fournis des APIs pour communiquer entre les applications et l’infrastructure réseau. De plus,
nous utilisons les outils Ping et Cbench [73] pour mesurer les métriques de performance du con-
trôleur.
37
Contrôleur SDN
OVS d'extrémité OVS 2 OVS 3 OVS d'extrémité
Hôte d'extrémité Hôte 2 Hôte 3 Hôte d'extrémité
Figure 4.1: Topologie linéaire gérée par un contrôleur SDN centralisé
4.2.2 Description des expériences
Dans la Figure 4.1, nous considérons une topologie linéaire, où nous commençons les tests
avec deux commutateurs, puis nous augmentons progressivement le nombre de commutateurs,
jusqu’à 100 pour l’étude du délai et 256 pour l’étude du débit. La topologie est gérée par un
contrôleur centralisé qui reçoit tous les paquets de destination inconnue afin de décider de leur
sort.
Notre objectif est de mesurer les performances d’un réseau utilisant un contrôleur SDN central-
isé. Cette mesure nous permettra d’isoler l’effet de centraliser le plan de contrôle dans un seul
contrôleur et de quantifier l’impact son impact sur les performances du réseau. Deux paramètres
seront considérés pour l’évaluation des performances, le débit et le délai. Le débit correspond au
nombre de flux traités par seconde. Le deuxième paramètre est le délai de communication entre
les deux extrémités du réseau. Ce délai comprend le délai de transmission des données sur les
liaisons entre les hôtes d’extrémité et le délai de la sollicitation du contrôleur pour décider d’une
action appropriée pour le paquet reçu.
Afin d’isoler le délai de sollicitation du contrôleur, nous avons utilisé un autre scénario du réseau
sans contrôleur considéré comme référence, où nous préinstallons toutes les actions dans la ta-
ble de flux des commutateurs (technique proactive). Dans ce cas, le délai comprend le délai de
transmission des données sur les liaisons entre les hôtes d’extrémité et le délai d’installation
38
des règles appropriées au flux sur toutes les tables de flux des commutateurs. Ces règles conti-
ennent une action de type ‘Normal’, c’est-à-dire que le commutateur commence par découvrir
l’adresse MAC source issue du port d’entrée avant de chercher le port de sortie conduisant à
l’adresse MAC de destination en envoyant un message de diffusion. Notons que les résultats de
cette étude dépendent des performances de la machine sur laquelle l’expérimentation se déroule.
Nous avons utilisé une machine de 2 coeurs en processeur et 4 Go en RAM.
4.3 Résultats de simulation
Dans cette section, nous présentons les résultats obtenus durant nos expériences. Deux métriques
seront considérées: le débit et le délai.
4.3.1 Débit du contrôleur
Lorsque le contrôleur reçoit les messages OpenFlow (Packet_in) venant de chaque OVS, il doit
répondre par des messages (Packet_out) contenant sa décision vis-à-vis du paquet. Le débit d’un
contrôleur représente sa capacité à gérer ces messages. Dans la Figure 4.2, nous évaluons le
débit du contrôleur en fonction du nombre de switchs. Par exemple, dans le cas de 128 OVS,
avec 10 serveurs connectés à chaque OVS, on peut voir que le contrôleur Ryu peut traiter un peu
près 33000 flux par seconde. Globalement, nous pouvons considérer que le débit diminue avec
l’augmentation des OVS qui constituent le réseau, à cause du nombre élevé de demandes reçues
par le contrôleur. En fait, dans le cas de 4 commutateurs le contrôleur reçoit les demandes de
4 sources uniquement, c’est-à-dire 4 sockets qui communiquent avec le contrôleur utilisant le
protocole TCP. Par contre, quand le nombre de sources augmente (128 ou 256) le contrôleur doit
répondre à des centaines de sources en confirmant à chaque fois que les messages transités sont
reçus avec succès. Cette charge influence le débit du contrôleur, car il n’est pas équipé par les
outils d’optimisation comme le parallélisme.
4.3.2 Délai du réseau
Dans la Figure 4.3, nous présentons le délai entre deux extrémités selon le nombre de commu-
tateurs OVS pour les deux scénarios (avec et sans contrôleur). Nous pouvons constater que le
temps de communication augmente en fonction de la taille du réseau pour les deux scénarios.
Ce qui est normal puisque, quand la topologie s’étend linéairement, la communication entre les
deux extrémités requiert plus de temps. Cependant, il y a une différence visible entre les deux
scénarios. Dans le cas où nous utilisons le contrôleur, nous observons que jusqu’à 60 OVS, le
temps total est inférieur à une seconde, et proche à celui obtenu dans le réseau de référence.
Quand le nombre d’OVS dépasse 60, nous remarquons une augmentation rapide du temps total
nécessaire pour que les deux extrémités puissent communiquer. Par exemple, pour 100 OVS, le
39
Débit (flows/sec) 45000
40000
35000
30000
4 16 32 64 128 256
Switchs
Figure 4.2: Débit en fonction du nombre de switchs
délai est proche de 4 secondes, alors qu’il est égal à 1.5 dans le cas sans contrôleur, soit une dif-
férence de 2.5 secondes dû à la sollicitation du contrôleur avec un pourcentage d’augmentation1
ègale à 166 %. Ces résultats montrent l’effet de centraliser le contrôle et la gestion sur un seul
contrôleur, surtout lorsqu’il est surchargé par un grand nombre de flux, ce qui peut dégrader les
performances puisqu’il prendra plus de temps pour traiter ces flux. Par conséquent, et d’après ces
résultats, nous constatons qu’un seul contrôleur ne peut pas gérer un réseau de grande taille. Par
la suite, nous proposons la technique de multiples instances afin d’augmenter les performances
du contrôleur Ryu.
La technique de multiples instances est largement utilisée dans les problèmes complexes actuels,
en particulier avec la technologie de virtualisation et de Cloud, où on peut instancier des switchs
et des routeurs à partir des composantes de base. Nous avons utilisé quatre instances où chaque
nouvelle instance étant implémentée pour gérer une partie du réseau et ainsi éliminer la sur-
charge sur le contrôleur. Ces copies du contrôleur sont instanciées de la même fonction prin-
cipale ‘Main’ du contrôleur, mais selon plusieurs ports de communication (6633, 6634, 6635 et
6636).
Dans la Figure 4.4 nous ajoutons une courbe (en noir) correspondant à l’utilisation d’instances
multiples. Nous pouvons d’abord constater que le comportement des instances multiples en
terme de délai est meilleur qu’un seul contrôleur. Par exemple, dans le cas du réseau de 100
commutateurs, le délai est de 2.5 secondes au lieu de 4 secondes soit une diminution de 37.5
%. Ce qui illustre que nous pouvons tirer profit des instances multiples afin de traiter plus de
demandes des switchs avec un minimum de délai.
1
(Va-Vd)/Vd * 100, Va: la valeur d’arrivée et Vd: la valeur de départ
40
Figure 4.3: Délai en fonction du nombre des commutateurs OVS pour les deux scénarios avec
contrôleur et sans contrôleur
Figure 4.4: Délai en fonction du nombre des commutateurs OVS pour les différents scénarios
(avec contrôleur, sans contrôleur et multiples instances)
41
4.4 Conclusion
Cette première étude nous a permis d’abord d’étudier l’architecture de base du réseau SDN où un
seul contrôleur est chargé de la gestion de tous les commutateurs avant d’attaquer des études plus
complexes. C’etait aussi l’occasion de maîtriser les outils de simulation ‘Mininet’ et de mesures
de performance comme ‘Cbench’. Par conséquent, nous avons constaté qu’un seul contrôleur
ne peut pas gérer correctement le réseau au-delà d’un certain seuil qui est de l’ordre de 60 com-
mutateurs (selon notre machine de test). En dépassant ce seuil, le contrôleur devient un goulot
d’étranglement du réseau puisque son débit diminue et son délai augmente jusqu’à 4 secondes
dans un réseau de 100 commutateurs. Pour remédier à ce problème et avec un seul contrôleur,
il faut soit installer au préalable toutes les actions sur les tables de flux des commutateurs, ce
qui n’est pas faisable en pratique, soit utiliser plusieurs instances du contrôleur. Ces dernières
ont permis d’améliorer les performances du réseau, ce qui permet d’espérer que l’utilisation de
multi-contrôleurs améliorera davantage les performances.
Dans les prochains chapitres, nous allons étudier les architectures du plan de contrôle composé
par plusieurs contrôleurs, notamment le plan de contrôle logiquement centralisé et logiquement
distribué.
42
Chapitre 5
Évaluation des performances des

architectures du plan de contrôle
logiquement centralisé
5.1 Introduction
Dans le chapitre précédent, nous avons présenté les résultats de simulations sur l’architecture
initiale du SDN. Dans cette architecture, le fonctionnement du réseau dépend entièrement d’un
seul contrôleur opérationnel qui est considéré comme un système d’exploitation du réseau. Avec
l’augmentation du trafic et du nombre de commutateurs constituant le réseau, un seul contrôleur
peut facilement tomber en panne et laisser le réseau sans système d’exploitation. En outre, même
si le contrôleur est opérationnel, son débit diminue avec l’augmentation de la taille du réseau, sa
latence est aussi affectée puisque le contrôleur doit traiter un grand flux de demandes issues de
son plan de données.
Pour éviter ce scenario et améliorer les performances des plans de contrôle composés par plusieurs
contrôleurs ont été proposée. Parmi ces architectures on trouve le plan de contrôle logiquement
centralisé que nous traitons dans ce chapitre. Plusieurs avantages peuvent être soulignés en
utilisant des contrôleurs multiples. En particulier, minimiser le délai contrôleur-commutateur
[128], garantir certain seuil de fiabilité [42] ou même trouver un compromis à travers plusieurs
métriques du réseau [30]. Cependant, le déploiement des contrôleurs multiples apporte ces béné-
fices à un coût. Afin de garder une vue logiquement centralisée du réseau, la base de données
locale d’un contrôleur doit être synchronisée avec le reste des contrôleurs. Cette base de don-
nées contient des informations divers, y compris les nœuds qui constituent la topologie réseau
(Ex : leurs types et capacités,…), les caractéristiques des différentes liaisons entre les nœuds et
les chemins qui ont été formés dans le réseau, etc. Quand un nouvel événement se produit par
exemple le commutateur se connecte à un contrôleur, ce dernier ajoute cette information à sa
base de données et doit la synchroniser avec les autres contrôleurs pour que la vue du réseau
demeure consistante pour les applications (routage, load balancer, firewall, etc).
L’objectif de ce chapitre est de montrer la faisabilité de déploiement des contrôleurs multiples
selon les exigences industrielles en terme de délai et de charge de synchronisation. Plusieurs
études ont abordé la question de contrôleurs multiples, avec des approches différentes. Les
études [29, 128] ont proposé des solutions à l’emplacement des contrôleurs selon la latence nœud-
contrôleur, contrôleur-contrôleur et la distribution de charge entre les contrôleurs. Pour résoudre
le problème de l’approvisionnement dynamique des contrôleurs, les auteurs de [17] ont ajusté
dynamiquement les contrôleurs multiples dans le réseau en se basant sur le changement des con-
ditions du réseau. Nous proposons dans ce chapitre une analyse du coût de la synchronisation
entre les contrôleurs dans des topologies réelles de réseaux étendus, ce coût est exprimé en délai
et en charge de communication inter-contrôleurs. Cette étude a donnée lieu à une publication
dans le journal ‘International Journal of High Performance Computing and Networking’ [44].
Le reste de ce chapitre est organisé comme suit : dans la section 2, nous présentons les expériences
et les environnements de simulation utilisés dans cette étude. La section 3 est consacrée à une
analyse du coût de la synchronisation à partir des résultats de simulation. Dans la section 4, nous
présentons nos conclusions sur cette architecture.
Dans cette section, nous présentons les caractéristiques physiques du serveur où nous avons
déroulé nos expériences et les outils d’émulation utilisés, puis nous décrivons les différents scé-
narios et topologies considérés.
Afin d’évaluer le coût de synchronisation associé au déploiement des contrôleurs SDN multiples,
nous avons émulé différentes topologies de réseaux étendus (WAN) sur un serveur physique. Ce
dernier est caractérisé par un processeur Intel Xeon 8 cœurs fonctionnant à 2.67 Ghz et une RAM
égale à 14 Go. Dans cette étude, nous réservons pour chaque contrôleur une VM sur l’hyperviseur
VirtualBox [125], chacune de ces VM est équipée par un cœur virtuel en CPU et 1 Go de RAM.
La machine qui simule le réseau virtuel utilise Mininet [21], ce qui permet de créer les topologies
SDN considérées dans la Figure 5.2. Un maillage total est établi entre les VMs afin d’assurer une
synchronisation correcte entre tous les contrôleurs, ce qui signifie que chaque contrôleur pos-
sède une connexion avec les autres contrôleurs, organisés sous forme d’un cluster. Notre choix
de contrôleur SDN s’est porté sur OpenDayLight [90] (une brève description est donnée dans
l’annexe B.2) et plus précisément dans sa version Hydrogen, puisqu’elle supporte le déploiement
des contrôleurs multiples à travers la technologie de Clustering, et qu’il est activement supporté
et maintenu par une large communauté SDN.
44
Hôte
Switch Contrôleur
Hôte VM_dÓpenDayLight
Hôte
Switch
Switch
VM de Mininet Contrôleur
VM_dÓpenDayLight
Interface physique
Switch virtuel
Hôte physique
Figure 5.1: Environnement d’évaluation
La Figure 5.1 résume l’environnement global d’évaluation. La connectivité entre les nœuds à
l’intérieur de la VM de Mininet et les contrôleurs correspondants est assurée par des switchs
virtuels qui interconnectent toutes les machines virtuelles. Ces machines utilisent le protocole
NTP (Network Time Protocol) pour synchroniser leurs horloges. Ceci est important pour obtenir
des mesures de délais corrects dans les expériences que nous allons présenter dans la section 5.3.
5.2.2 Description des expériences
Afin de traiter des cas des réseaux étendus, nous avons simulé six différentes topologies que nous
présentons dans la Figure 5.2. Nous notons que tous les points présentent les switchs et que les
points en bleu présentent en plus des switchs la position des contrôleurs. Ces topologies sont
obtenues sur Internet Topology Zoo [122] (nous expliquons comment simuler des topologies
larges sur Mininet dans l’annexe A.3). Le choix des emplacements des contrôleurs (coloré en
bleu sur la Figure 5.2) n’est pas fait de façon arbitraire ou d’une façon qui privilégie le délai inter-
contrôleur, mais nous avons utilisé la solution proposée dans [47] qui a pour objectif d’atteindre
une haute fiabilité entre les switchs et les contrôleurs.
La table 5.1 présente le nombre de switchs et le nombre des contrôleurs correspondant à chaque
topologie. Nous distinguons deux catégories de scénarios. Dans la 1ère catégorie des topologies
(Grident, EliBackbone et BtNorthAmerica) le nombre de contrôleurs est fixé et égale à 2 mais
nous augmentons la taille du réseau (9, 20 puis 36). L’objectif de cette catégorie est de voir l’effet
de la taille et la complexité de la topologie sur le coût de la synchronisation inter-contrôleur. Dans
la 2ème catégorie (HiberniaUk, Noel et Goodnet) nous varions le nombre de contrôleurs (4, 6 puis
45
Spokane
San Francisco Newark New York Portland Tacoma
Boise
Washington, DC Seattle
Sacramento Minneapolis
Salt Lake City
Palo Alto
Chicago Rochester
Atlanta
Newark
Dallas Santa Clara Las Vegas
Los Angeles
Houston Los Angeles Phoenix
Dallas
Washington DC
Miami
Houston
(a) Gridnet (b) Elibackbone Atlanta
Helena
Billings Eugene
Boise Bracewell
Spokane
Tukwita Portland
Cheyenne Seattle Shouthport Leeds
Salt Lake
Burbank Liverpool Manchester
Phoenix
Sheffield
Albuquerque Tucson Sunnyvale Los Angeles
Denver
Node1 Dallas Houston

Chicago Birmingham Leicester
Cermak
Tampa
Eckington Atlanta
Kansas Peterborough
Newark New York
Cambridge
Node2
Washington
Minneapolis Bristol
Omaha Boston
Reading London
Europe
Sioux City Fargo
(c) BtNorthAmerica (d) HiberniaUk
Vancouver
Bellingham
Mt Vernon
Hartford
Evernett Chicago New York
Salt Lake City
Coeur Washington, DC
Denver
Westin Spokane d’Alene Sane Jose
Wenatchee
Tacoma
Olympia Oklahoma City Chattanooga
Ellensburg Los Angeles
Phoenix Atlanta
Othello Pullman Tucson Birmingham
Yakima
Lewiston Jacksonville
Kennewick New Orleans
Tampa
Wala wala
Portland
(e) Noel (f) Goodnet
Figure 5.2: Topologies des réseaux WAN considérées
46
Topologie Nombre de switchs Nombre de contrôleurs
Gridnet 9 2
EliBackbone 20 2
BtNorthAmerica 36 2
HiberniaUk 15 4
Noel 19 6
Goodnet 17 8
Table 5.1: Topologies évaluées
8). Cependant, la taille du réseau est presque fixe (15, 19 et 17). Le but de cette 2ème catégorie
de topologie est d’étudier l’impact du nombre de contrôleurs et leur emplacement sur le coût de
synchronisation. Notons qu’il n’est pas nécessaire de prendre un grand nombre de contrôleurs
puisque selon [47], 75 % des 124 topologies d’Internet Topology Zoo nécessitent moins de dix
contrôleurs pour garantir une haute disponibilité et une haute fiabilité au réseau.
Dans le but d’obtenir des mesures statistiquement significatives, nous exécutons une série de 10
expériences indépendantes pour chaque topologie. Pour chaque exécution, nous démarrons tous
les contrôleurs et nous les laissons s’exécuter pendant un temps défini pour former le cluster.
Par la suite, nous lançons la topologie Mininet pour que chaque nœud puisse se connecter aux
contrôleurs selon les emplacements donnés par l’algorithme présenté dans [47]. Le protocole
OpenFlow est utilisé comme protocole sud entre les commutateurs et les contrôleurs. Dès que
les commutateurs établissent une connexion OpenFlow avec les contrôleurs, nous injectons un
nouveau flux de trafic dans le réseau grâce à l’outil Iperf [62] (Annexe A.4). Pour cela, nous
fixons un hôte émulé comme serveur et le reste des hôtes sont considérés comme clients, qui
commencent alternativement une connexion TCP avec ce serveur. Sachant que chaque nouvelle
connexion générée par un client différent sollicite le commutateur pour une transmission au
serveur, ce dernier sollicite le contrôleur en envoyant un message de type Packet_in, parce qu’il
ne trouve pas une entrée qui correspond au paquet reçu dans sa table de flux. À cet effet, le
contrôleur décide du sort de ce flux. Par défaut, le contrôleur répond par un message de type
Flow-mod aux commutateurs, pour instaurer, de manière réactive, une règle de transmission sous
la forme d’un nouveau flux dans la table de flux.
Lors des expériences qu’on déroule pour chaque topologie plusieurs évènements sont générés,
ce qui provoque des changements dans l’état du réseau. Chacun de ces changements doit être
synchronisé avec le reste des contrôleurs en utilisant le mécanisme de cluster, implémenté par le
contrôleur Opendaylight. Nous considérons trois évènements parmi tous les types d’évènements.
D’abord, nous avons l’évènement de type New switch, lorsque les nœuds se connectent à leurs
contrôleurs. Cela provoque effectivement un changement de l’état du réseau en ajoutant un
nœud dans la vue de la topologie du contrôleur. Puis, quand nous injectons un flux TCP dans
le réseau, le contrôleur apprend l’existence de la source de données (ou éventuellement aussi la
destination) à travers l’évènement de type New host. Cet évènement est déclenché lorsque le con-
47
trôleur reçoit un message de type Packet_in contenant un paquet dont la source (ou destination)
était inconnue. La vue de la topologie est ainsi enrichie. Par la suite, quand le contrôleur installe
un nouveau flux dans un switch, il génère le troisième type d’évènement New flow, et actualise sa
vue sur le réseau en conséquence. Tous ces flux ne sont pas affichés par défaut par le contrôleur,
une modification du code interne du contrôleur a été nécessaire.
5.3 Analyse du coût de la synchronisation
Dans cette section, nous présentons d’abord les métriques de performance que nous allons mesurer
dans cette étude. Ensuite, nous présentons et analysons les résultats de simulation pour les deux
catégories de scénarios décrits dans la section précédente.
5.3.1 Métriques de performance
Afin d’évaluer le coût de synchronisation entre les contrôleurs, nous calculons pour toutes les
topologies que nous avons considéré deux métriques de performance, à savoir :
• Le délai de synchronisation : le temps entre la génération d’un nouvel évènement par

un contrôleur et la réception de cet évènement par les autres contrôleurs. Cette métrique
dépend de la quantité d’informations échangées entre les contrôleurs, de la bande passante
disponible, du délai de propagation et du temps de traitement de chaque contrôleur.
• La charge de synchronisation : le taux de données employées pour la synchronisation des

messages entre les contrôleurs. On précise qu’on considère tous les trafics bidirectionnels
entre les contrôleurs.
Le délai de synchronisation est une métrique clé dans un système distribué, en particulier dans
un réseau constitué de contrôleurs distribués [32]. Sous un modèle fortement consistant comme
celui qu’on considère avec le modèle cluster, un délai élevé limite le temps de réponse du système
tout entier. La contribution du délai de propagation au délai de synchronisation entre deux con-
trôleurs est presque fixe et causée par la distance (et les équipements) que les bits traversent le
long du chemin. Le temps de traitement dans un contrôleur dépend de la charge et de la capacité
physique de l’équipement, il peut être réduit soit en équilibrant la charge entre les contrôleurs
du cluster, soit en améliorant les capacités physiques du contrôleur. Le délai de synchronisa-
tion dépend aussi de la bande passante du chemin entre les contrôleurs. Dans cette étude, nous
ne limitons pas dans la configuration la bande passante disponible pour la synchronisation, afin
d’explorer le maximum de débit de données nécessaire pour notre expérience, ce qui nous donne
approximativement une borne supérieure sur la charge de synchronisation.
Afin de tester la faisabilité du déploiement des contrôleurs logiquement centralisés, nous com-
parons systématiquement le délai de synchronisation avec deux délais typiques des réseaux
48
1000
Charge_de_synchronisation
900
800
700 bootstrap maintenance events maintenance events&&&maintenance

Charge(Kbps)
600
500
400
300
200
100
0
0 20 40 60 80 100 120
Temps(s)
(a) Charge de synchronisation obtenue pour la topologie Gridnet
1400
1200
1000
Charge(Kbps)
800
600
400
200
0
0 20 40 60 80 100 120 140 160 180
Temps(s)
(b) Charge de synchronisation obtenue pour de la topologie Elibackbone
49
2000
1800
1600
1400
Charge(Kbps)
1200
1000
800
600
400
200
0
0 50 100 150 200 250 300
Temps(s)
(c) Charge de synchronisation obtenue pour de la topologie BtNorthAmerica
Figure 5.3: Evaluation de la charge de synchronisation par les topologies avec deux contrôleurs
actuels. Nous considérons deux cibles, à savoir :
• Temps de protection d’un anneau (Ring protection) (50 ms) : temps cible de restauration
d’un réseau en anneau de type SONET, entre la détection de la panne et le détournement
du trafic vers la direction opposée de l’anneau.
• Temps de restauration d’un réseau maillé (shared-mesh restoration) (200-250 ms) : temps
cible de restauration d’un réseau maillé, entre la détection de la panne et le détournement
du trafic à un nouveau chemin.
Dans le reste de cette section, nous présentons et discutons les résultats obtenus. D’abord par 2
contrôleurs puis par un nombre de contrôleurs k>2.
5.3.2 Expériences avec 2 contrôleurs
5.3.2.1 Analyse de la charge de synchronisation
La Figure 5.3, présente les résultats de simulation de la charge de synchronisation exprimée en

Kbits par second (Kbps) en fonction du temps pour les topologies Gridnet (Figure 5.2(a)), EliBack-
bone (Figure 5.2(b)) et BtNorthAmerica(Figure 5.2(c)). Dans la figure nous distinguons 3 phases,
à savoir :
50
• Phase de ‘bootstrap’ : qui consiste à l’échange des informations entre les contrôleurs pour
la création du cluster.
• Phase de ‘events’ : durant cette phase les contrôleurs synchronisent leurs nouveaux évène-
ments comme New switch, New host et New flow.
• Phase de maintenance : entre la phase de ’bootstrap’ et ’events’ un intervalle de temps

d’arrêt est fixé pour ne pas surcharger le réseau puisque les évènements viennent en masse.
Cet intervalle est utilisé aussi entre la première phase de synchronisation des évènements
et la deuxième et varie selon la topologie.
D’après la Figure 5.3, la phase de ‘bootstrap’ n’est pas très consommatrice en bande passante pour
les scénarios avec deux contrôleurs. Nous pouvons constater que la charge reste faible et atteint
au maximum un pic de 450 Kbps ou moins. Ceci est normal puisque les commutateurs ne sont
pas encore attachés aux contrôleurs et il n’y a aucune information à synchroniser concernant le
réseau. Par conséquent, la charge reste inférieure à un seuil raisonnable.
À mesure que divers évènements se produisent, l’état du réseau change et doit être synchronisé
entre les contrôleurs. Dans nos expériences, ces évènements arrivent en masse (bursts). Plus le
nombre d’évènements consécutifs est élevé, plus la charge est élevée. Dans la Figure 5.3(a), nous
trouvons des points proches de 1Mbps lorsque les 9 commutateurs (Figure 5.2(a)) se connectent
aux contrôleurs. Le besoin en bande passante est moindre pour les autres type d’évènements,
en particulier quand de nouveaux hôtes sont découverts et que de nouveaux flux sont installés
dans les commutateurs. Dans ces cas, la charge de synchronisation atteint des pics entre 300-600
Kbps. Entre les périodes des évènements, nous trouvons des phases consacrées à la maintenance.
Nous pouvons constater que ces phases engendrent de faible charges, toujours inférieure à 100
Kbps.
Puisque la topologie EliBackbone (Figure 5.2(b)) est constituée de plusieurs nœuds, il y a plus
d’évènements à synchroniser dans chaque ‘burst’. En effet, il existe plus de nœuds qui se con-
nectent aux contrôleurs, plus d’hôtes à découvrir et par conséquent plus de flux à installer.
Hormis la phase de construction du cluster, la charge de synchronisation pour les autres phases
est plus élevée (Figure 5.3(b)) en comparaison avec celle obtenue dans la topologie précédente.
En général, les mêmes tendances sont observées dans la Figure 5.3(c) du réseau BtNorthAmerica
(Figure 5.2(c)). En parliculier, dans la phase de synchronisation d’évènements nous avons des
pics qui dépassent 1.8 Mbps. Quand on passe de 9 nœuds (Gridnet) à 36 nœuds, alors la charge
de synchronisation a presque triplée. Par conséquent, on déduit que le nombre de nœuds est un
paramètre important qui impacte négativement la charge de synchronisation.
5.3.2.2 Analyse du délai de synchronisation
Dans la Figure 5.4, nous présentons le délai de synchronisation d’évènements exprimé en mil-
lisecondes en fonction du temps. Nous exprimons chaque type d’évènement par une forme
51
géométrique unique (carré : New host, rond : New switch et losange : New flow). Dans cette
figure, nous représentons aussi le temps de protection en anneau qui est notre critère de fais-
abilité en matière de délai. Afin de mieux distinguer le délai propre à la synchronisation nous
donnons également le délai de propagation. Nous gardons les mêmes topologies et phases con-
sidérées durant l’analyse de la charge de synchronisation.
Nous remarquons que le délai de synchronisation est assez faible et inférieur au temps de pro-
tection en anneau pour toutes les topologies considérées et pour les trois types d’évènements,
malgré le fait que les expériences se déroulent dans un environnement d’émulation comme le
nôtre. Aussi, le délai de synchronisation pour plusieurs évènements est dominé par le délai de
propagation. Le délai de traitement et de transmission sont ignorés dans ces cas puisqu’ils dépen-
dent des performances des commutateurs utilisés pour la transmission. En plus, les évènements
de type New flow génèrent plus de délai par rapport aux évènements New host, cela est dû au pro-
cessus d’installation des flux dans les commutateurs et l’échange des messages de confirmation
entre le contrôleur et les commutateurs. Quand on passe de 9 switchs à 36 switchs, on voit que le
nombre d’évènements à échanger augmente et leurs délais aussi, mais sans aucun dépassement
du temps de protection.
Pour invistiguer davantge sur l’effet du nombre de switchs sur le délai de synchronisation nous
comparons entre les trois topologies en utilisant le graphe de type ‘box-and-whisker plot’ dans
la Figure 5.5. Dans cette figure, nous présentons également les ‘outliers’, ce sont des points qui
n’appartiennent pas à l’ensemble des résultats. Dans notre cas, elles sont en dessous du temps de
protection d’un anneau 200-250 ms pour les trois topologies. Nous remarquons qu’avec plus de
nœuds (équivalent à plus d’évènements à installer), il y a une forte probabilité que certains évène-
ments soient affectés par la grande charge sur le contrôleur. Toutefois, la totalité des change-
ments du réseau peuvent être synchronisés rapidement. Cependant, ces résultats sont issus par
le déploiement de juste deux contrôleurs, c’est pourquoi nous étudions par la suite le cas de k>2
contrôleurs.
5.3.3 Expériences avec K>2 contrôleurs
Dans cette sous-section, nous analysons les résultats pour les topologies avec plus de deux con-
trôleurs. Dans ces cas, la quantité d’évènements est plus importante par rapport au cas de deux
contrôleurs, c’est pour cela que nous présentons des figures avec des résultats agrégés. La Figure
5.6(a) fournit la charge des trois topologies exprimée en échelle logarithmique. Nous remar-
quons que la charge augmente en fonction du nombre de contrôleurs avec 75 % des données des
échantillons qui nécessitent moins de 300, 600, et 800 Kbps respectivement pour les topologies
HiberniaUK (Figure 5.2(d)), Noel (Figure 5.2(e)) et Goodnet (Figure 5.2(f)). Mais, nous pouvons
trouver des pics dus aux évènements en ‘burst’, dépassant respectivement 4, 6 et 8 Mbps. Rap-
pelons que pour les topologies HiberniaUK, Noel et Goodnet on utilise respectivement 4, 6 et 8
contrôleurs ce qui est équivalent un peu près à une charge de synchronisation de 1 Mbps par
52
60
Delaihdehsynchronisat ion
NewhSwit ch
ringhprot ect ion NewhHost
NewhFlow
50
Boot st rap m aint enance event s m aint enance event sh& hm aint enance
40
Delaih(m s)
30
20
delaihdehpropagat ion
10
0
0 20 40 60 80 100 120
Tem psh(s)
(a) Délai de synchronisation pour la topologie Gridnet
60
DelaiHdeHsynchronisat ion
NewHSwit ch
NewHHost
ringHprot ect ion NewHFlow
50
40
DelaiH(m s)
30
20
delaiHdeHpropagat ion
10
0
0 50 100 150 200
Tem psH(s)
(b) Délai de synchronisation pour la topologie Elibackbone
53
60
DelaiHdeHsynchronisat ion
NewHSwit ch
NewHHost
ringHprot ect ion NewHFlow
50
40
DelaiH(m s)
30
20
delaiHdeHpropagat ion
10
0
0 50 100 150 200 250 300
Tem psH(s)
(c) Délai de synchronisation pour la topologie BtNorthAmerica
Figure 5.4: Evaluation du délai de synchronisation pour les topologies avec deux contrôleurs
contrôleur.
Malgré le fait que nous utilisions un environnement d’émulation avec un seul serveur, la Fig-
ure 5.6(b) montre que le délai lui aussi augmente en fonction du nombre de contrôleurs, mais
l’avantage est que 75 % d’évènements sont synchronisés avec un délai inférieur au temps cible
de restauration. Pour ceux qui dépassent ce temps, ils sont toujours inférieurs au temps cible de
restauration d’un réseau maillé. Par conséquent, dans un environnement réel, on peut s’attendre
à des délais inférieurs. Ainsi, on peut conclure que le déploiement d’une architecture de plan de
contrôle logiquement centralisé est faisable d’un point de vue de délai.
5.4 Conclusion
Distribuer les états du réseau en gardant une vue centralisée sur le réseau, signifie que la base
de données entre les contrôleurs doit être toujours synchronisée. Dans cette deuxième étude,
nous avons examiné ce coût de synchronisation, puisqu’il est considéré comme un facteur clé
pour comprendre les limites et la faisabilité du SDN dans les réseaux opérationnels. Nous avons
simulé des topologies réelles de réseaux étendus et nous avons évalué le coût de synchronisation
pour une plateforme de contrôle SDN logiquement centralisée ’OpenDayLight’. Malgré que nous
avons utilisé un environnement d’émulation, de ressources limitées pour les contrôleurs et les
topologies, le délai de synchronisation était faible et inférieur au temps de protection d’un anneau
54
Ring protection
50
40
30
20
10 99%
Figure 5.5: Comparaison entre les délais des topologies basées sur deux contrôleurs
et de restauration d’un réseau maillé.

En conclusion, notre étude montre la faisabilité des architectures logiquement centralisées en
terme de délai de synchronisation dans un seul domaine. Cependant, l’utilisation du cluster
avec une vue consistante augmente la charge de synchronisation, ce qui peut être un défi de
déploiement de cette architecture dans un réseau plus large. Un autre défi, est la gestion de
l’architecture logiquement centralisée dans un environnement de production hétérogène carac-
térisé par l’intervention de plusieurs opérateurs gérant plusieurs domaines ce qui nécessite un
accord permanent sur la synchronisation des données entre tous opérateurs. Dans le chapitre
suivant, nous proposons notre stratégie de déploiement de plan de contrôle distribué composé
de plusieurs contrôleurs dans une topologie multi-domaines.
55
10000
1000
Charge(Kbps)
100
10 75%
Median
25%
Max
Min
1
HiberniaUk Noel Goodnet
(a) Charge de synchronisation
99%
(b) Délai de synchronisation
Figure 5.6: Délai et charge pour k>2 contrôleurs et selon différentes topologies
56
Chapitre 6
Implémentation et évaluation d’une

interface Est/Ouest pour un plan de
contrôle SDN logiquement distribué
6.1 Introduction
Comme nous avons vu dans les chapitres précédents, le besoin d’utiliser des contrôleurs multi-
ples devient une nécessité pour surmonter le problème du SPOF et améliorer les performances.
Rappelons que deux catégories d’architectures de plan de contrôle ont été proposées dans la
littérature [19, 45]. La première catégorie, que nous avons évaluée dans le chapitre précédent,
utilise un plan de contrôle logiquement centralisé, où l’ensemble des contrôleurs collaborent
pour fonctionner comme un seul contrôleur centralisé. Cela est effectué en synchronisant tous
les états du réseau entre les contrôleurs et en offrant une vue consistante du le réseau pour les
applications du contrôle. Plusieurs implémentations ont été consacrées à cette catégorie et son
déploiement est certainement bénéfique pour l’équilibrage de charge, la tolérance aux pannes, la
sécurité, la performance et l’évolutivité. Cependant, garantir un plan de contrôle logiquement
centralisé nécessite une synchronisation extensive entre les contrôleurs, qui peut conduire à une
charge considérable (comme nous avons vu précédemment) et augmenter la latence, spéciale-
ment dans les réseaux largement distribués. Cela peut poser un problème de scalabilité des con-
trôleurs rangés sous forme de cluster dans les très grands réseaux WAN, surtout avec plusieurs
opérateurs utilisant différentes techniques et règles de transmission. La deuxième catégorie des
solutions tente d’étendre le concept SDN aux réseaux WAN composés de plusieurs domaines.
Elle consiste à utiliser des contrôleurs logiquement distribués où chaque contrôleur a seulement
une vue du domaine dont il est responsable et distribue les informations nécessaires aux autres
contrôleurs.
Sachant que les réseaux WAN sont caractérisés par un coût et une latence élevés, dûs à la com-
plexité de l’infrastructure et des protocoles qui manipulent le trafic (ex, BGP et MPLS), la commu-
nication entre les contrôleurs a une importance primordiale dans les architectures SDN logique-
ment distribuées. Cependant, comme cette architecture est la plus récente, nous avons constaté
un manque d’étude pour cette architecture et aucun standard n’est disponible. Ce qui nous a
motivé à travailler sur cette architecture et contribuer à son évolution. Ce chapitre est entière-
ment consacré à cette deuxième catégorie. Nous avons d’abord proposé notre contribution qui
consiste à une nouvelle interface de communication destinée au plan de contrôle logiquement
distribué. Cette interface est caractérisée par des modes de communication configurés selon le
rôle de chaque contrôleur. La présentation de cette interface ainsi que les premiers résultats
des simulations de faisabilité (proof of concept) ont donné lieu à une publication dans le journal
‘International Journal of Communication Networks and Distributed Systems’ [41]. Par la suite,
nous avons enrichi cette interface, en tenant compte de la sécurité et la qualité de service, par des
services distribués comme le Firewall, Load Balancer et SSL. La proposition des algorithmes et
leurs implémentations, ainsi que l’évaluation approfondie de l’interface à travers des scénarios
de topologies réelles ont donné lieu à une publication dans le journal ‘Computers and Electrical
Engineering’ [40].
Le reste de ce chapitre est organisé comme suit. Dans la section 2, nous avons proposé notre
modèle de communication en expliquant l’algorithme de l’interface et le rôle de ses modules,
nous avons présenté aussi les modes de communication et leurs utilités dans l’architecture. Dans
la section 3, nous présentons les algorithmes utilisés dans les services distribués proposés à savoir
SSL, DFS et DLBS. La section 4 détaille les outils et les scénarios utilisés pour l’évaluation de
l’interface. La section 5 présente une analyse des résultats obtenus. Nous terminons ce chapitre
dans la section 6 par des conclusions sur l’utilisé de cette nouvelle interface.
6.2 Interface de Communication pour le plan de contrôle distribué

(CIDC)
La communication entre les contrôleurs multiples dans une architecture distribuée a un effet
significatif sur le réseau tout entier. Le modèle du cluster est utilisé par plusieurs types de con-
trôleurs distribués comme OpenDayLight (ODL) et ONOS. Ce modèle synchronise les données
entre les contrôleurs sans prendre en considération la nature du réseau et les services requis. Par
conséquent, une énorme quantité de données est échangée entre les contrôleurs, ce qui n’est pas
requis tout le temps et pour tous les contrôleurs, ceci d’une part, et d’autre part il consomme
la bande passante et affecte le débit du contrôleur (plus de détails dans la section 5). Pour ces
raisons, nous concevons et implémentons une interface personnalisée baptisée CIDC (Commu-
nication Interface for Distributed Control-plane). Cette interface fonctionne selon des modes
de communication très utiles pour différents scénarios. Chaque contrôleur configure la liste de
contrôleurs avec lesquels il va échanger ses évènements.
58
6.2.1 Modes de communication
Nous proposons trois modes de communication utilisés entre les contrôleurs :
• Mode Notification : utilisé pour notifier aux autres contrôleurs qu’un changement s’est
produit dans le réseau du contrôleur. Ce changement peut être un nouveau commuta-
teur connecté ou déconnecté, un nouveau flux (de type flow-mod) installé dans un com-
mutateur, ou un nouvel équipement découvert. Ce mode est utilisé pour la gestion et la
vérification du réseau.
• Mode Service : permet la synchronisation des informations concernant les tables de flux,
tables de métrique, bande passante des liaisons, statut des liaisons et les règles (policies)
appliquées aux autres contrôleurs. Il est bénéfique aux applications qui nécessitent une
vue globale sur tout le réseau et une certaine qualité de transmission. Ce mode est destiné
à l’amélioration de la qualité de service, la sécurité, le routage, etc.
• Mode Full : regroupe les deux modes cités précédemment, et ajoute plus de détails comme
‘Packet_in’, ‘Packet_out’, et ‘Port_status’. Ce mode peut être utilisé pour les contrôleurs
qui gèrent des domaines critiques et sensibles.
Pour illustrer le concept des modes de communication, nous prenons un scénario issu des réseaux
de production. Supposons qu’une société informatique ayant une architecture composée de trois
sites, un siège et deux annexes. Afin d’améliorer leurs services et suivre les changements de leurs
infrastructure physique, la société utilise des contrôleurs SDN dans chaque site. Ces contrôleurs
doivent communiquer entre eux pour synchroniser leur vue du réseau. Si la société déploie
un cluster, les changements des réseaux annexes seront échangés entre eux et avec le siège,
quel que soit le type d’évènement, parce que tous les évènements sont stockés dans une base
de données partagée entre les contrôleurs. Ce qui consommera plus de bande passante et peut
affecter la qualité des autres services. Cependant, avec notre interface nous pouvons éviter les
changements entre les annexes et garder uniquement ceux entre chaque annexe et le siège, en
les configurant en mode Notification et chaque contrôleur de l’annexe garde dans sa liste de
contrôleur l’adresse IP du contrôleur responsable du siège. En plus, si un nouveau service doit
être utilisé entre deux domaines, il suffit de configurer leurs contrôleurs en mode Service, en
précisant même un ou plusieurs services à synchroniser. Dans le cas où une annexe de la société
contient des informations sensibles (par exemple, les bases de données du backup), nous pouvons
configurer son contrôleur en mode Full avec le siège, de cette façon les administrateurs du siège
peuvent suivre en détail les changements du réseau annexe.
6.2.2 Conception et architecture de l’interface CIDC
L’interface de communication entre les contrôleurs peut être une source de problèmes si elle n’est
pas bien conçue. Deux modèles de communication entrée/sortie sont disponibles : entrée/sortie
59
bloquées et non bloquées. En effet, Dans notre conception de l’interface CIDC, nous avons choisie
de travailler avec le modèle non bloqué, parce qu’il est plus performant que le modèle bloqué.
En fait, le modèle bloqué utilise plusieurs ‘threads’ pour communiquer avec les contrôleurs mul-
tiples, ce qui consomme plus de ressources et nécessite une synchronisation parfaite entre les
‘threads’. Cependant, le modèle non bloqué peut utiliser un seul ‘thread’ pour communiquer avec
plusieurs contrôleurs en se basant sur un composant cœur de ce modèle appelé ‘Sélecteur’, ce qui
élimine la charge et le processus de synchronisation que les ‘threads’ produisent. Le sélecteur
gère les connexions concurrentes en vérifiant à chaque instant si un ‘socket’ est prêt pour la lec-
ture ou l’écriture. Nous ajoutons que le modèle non bloqué peut supporter TCP comme protocole
de transport, les erreurs de communication comme les pertes de paquet sont alors gérées par le
mécanisme du TCP.
Nous prenons en considération deux aspects durant la phase de conception de l’interface CIDC:
• Modularité : notre interface est totalement modulaire, nous avons conçu quatre modules
basiques : Consumer, Producer, Data collector et Data updater, nous donnons dans les para-
graphes suivants le rôle de chacun d’entre eux. La modularité nous permet d’activer ou de
désactiver n’importe quel module, ce qui facilite les tests des modules et personnalise le
comportement de chaque module. Par exemple, pour garder la consommation de la bande
passante minimale, le contrôleur peut activer les modules ‘consumer’ et ‘data updater’,
et désactiver les autres. Donc, le contrôleur suivra tous les changements des domaines
voisins, et fonctionne comme un système de surveillance du réseau. En outre, la modular-
ité isole les problèmes en cas de dysfonctionnement, et donne une certaine flexibilité pour
programmer de nouveaux services.
• Performance: durant la phase de conception nous avons pris en considération que le con-
trôleur SDN traite un nombre énorme de flux par seconde. Ainsi, nous avons découplé les
canaux de communication expéditeur (Producer) et récepteur (Consumer). Cela améliore
le nombre de paquets traités issus des contrôleurs distants, et élimine également le délai
entre les modules, généré par l’interférence entre les canaux de communication.
La Figure 6.1, présente l’architecture de l’interface CIDC. Nous distinguons trois majeures parties
constituant cette figure. La première est constituée des modules situés à gauche de la figure, ils
présentent les modules basiques de fonctionnement d’un contrôleur SDN comme Module Man-
ager, Device Manager, Topology Manager, etc. Notons que ces modules sont propres au contrôleur
Floodlight (FL) (Annexe B.3) sur lequel on s’est basé pour implementer notre interface CIDC.
Ces modules sont généralement communs à toutes les implémentations de contrôleurs SDN. La
deuxième partie est située au milieu de la figure et encadrée en gras. Ce sont les modules qui
composent notre interface notamment Consumer, Producer, Data updater et Data collector. Un
petit fichier de configuration est ajouté dans notre interface, il centralise toutes les informations
de configuration, comme la liste des adresses IP des contrôleurs avec lesquels il va échanger les
60
Contrôleur SDN
Contrôleurs distants
Interface Est/Ouest
Module Manager Thread Pool Web UI
S Consumer
Producer
Data updater Consumer Sélecteur
Device Manager Topology Manager Link Discovery S Consumer
Producer
Data collector Producer

S Consumer
OpenFlow Services
Producer
Controller
Switches Trace Configuration
Memory
Données locales Données externes S Sélecteur
Figure 6.1: Architecture de l’interface CIDC au sein du contrôleur SDN
informations, le mode d’échange (Notification, Service ou Full), et les ports où les Consumers
vont écouter les nouvelles informations. La troisième partie, située à droite, présente les con-
trôleurs distants équipés par la même interface. Un sélecteur (S) est utilisé entre les contrôleurs
selon le modèle entrée/sortie non bloqué. Nous faisons remarquer que les flèches en rouge sig-
nifient le sens des données externes reçues et traitées par ce contrôleur et les flèches en bleu
pointillé montrent le sens des données internes collectées et envoyées aux contrôleurs distants.
Notre interface est basée sur les écouteurs d’évènement (Listeners) pour collecter les données
d’un contrôleur et les envoyer à sa collection de contrôleurs. Par la suite, les contrôleurs distants
consomment cette information et actualisent leur état en se basant sur le genre d’informations
qu’ils reçoivent (voir le déroulement de l’algorithme dans cette section). Les modules de l’interface
restent actifs tout le temps, c’est-à-dire, ils sont à l’écoute des évènements qui se produisent dans
l’infrastructure (plan de données) et ils les traitent en temps réel de façon asynchrone.
Nous décrivons ci-dessous, le rôle de chaque module de l’interface :
• Module Consumer : c’est le premier module qui s’exécute dans l’interface. Il établit un canal
avec tous les Producers des contrôleurs distants afin de récupérer tous les changements et
notifications qui ont eu lieu dans les domaines voisins.
• Module Data Updater : dès que le Consumer reçoit une nouvelle information, il l’envoie au
Data Updater qui traite les informations selon leur nature (Notification ou Service).
• Module Data Collector: quand le mode de communication (Notification, Service, ou Full)

est configuré par le contrôleur, ce module collecte grâce au Listeners en temps réel les
informations qui vont être exposées aux autres contrôleurs. L’information collectée diffère
selon le mode configuré ; par exemple, dans le mode notification, ce module va exposer les
informations suivantes au Producer. Switchs : son code Dpid, son statut (connecté ou
61
déconnecté), Équipement : son adresse IP et MAC, son statut (actif ou éteint) et Flux : les
flux de type Flow_mod.
• Module Producer: il joue le rôle inverse du Consumer; il notifie à tous les contrôleurs con-
figurés dans sa liste les changements qui apparaissent dans son réseau. C’est un expéditeur
des évènements recueillis par le module Data Collector.
Notre interface est conçue pour une architecture multi-contrôleurs, où chaque contrôleur est
à la fois Consumer et Producer, et il peut choisir une collection de contrôleurs avec lesquels il
veut échanger les informations. En outre, les modes de communication peuvent différer d’un
contrôleur à un autre selon la position dans le réseau et selon le rôle à jouer. Par exemple, le
protocole OSPF catégorise les routeurs en plusieurs types comme les zones ‘Backbone’, ‘Stub’,
‘NSSA Non-so-Stub Area’. Donc, le type est configuré selon la zone que le routeur va gérer.
6.2.3 Fonctionnement de l’interface CIDC
La Figure 6.2, présente le fonctionnement de notre algorithme. Quand un contrôleur est mis en
marche, il initialise les modules par défaut comme Module Manager, Topology Manager, Device
Manager, Thread Pool, etc. Le Producer démarre en lisant la configuration de l’interface pour
reconnaître le mode configuré et les adresses IP des Consumers distants qui feront partie de sa
liste de contrôleurs. Si le mode est Notification, le Producer envoie des messages de notification
à tous les Consumers quand un changement est reconnu dans son domaine. En outre, si le mode
configuré est Service, le Producer partagera les règles (policies) de tous les services configurés.
Dans le cas où le mode configuré est Full, le Producer communiquera tous les évènements et
services avec plus de précision.
Le Producer commence par initialiser les connexions en envoyant des messages ‘Hello’, chaque
Consumer qui répondra, rejoindra alors la liste des Consumers. À ce stade, les canaux sont con-
figurés et attendent un nouvel évènement reçu de la part du module Data Collector. Ce dernier
est équipé par plusieurs types d’écouteurs pour les modules cœurs du contrôleur (Gestionnaire
de la topologie, routage, commutateurs, Firewall….). Quand un changement se produit, le Data
Collector envoie le nouvel état du réseau au Consumer à travers les canaux établis par le Pro-
ducer, pour plusieurs raisons. Soit pour notifier les contrôleurs distants qu’un changement dans
un domaine s’est produit, ou pour synchroniser les données entre les contrôleurs pour les ser-
vices distribués. Ces évènements seront décodés dès qu’ils seront reçus par les Consumers. Par la
suite, le module Data Updater reçoit ces données à partir du Consumer et commence à les traiter
selon la nature de l’information. S’il y a une nouvelle règle à instaurer, elle sera envoyée vers
l’application appropriée pour une mise à jour. Si l’information est une simple notification, elle
sera enregistrée dans un fichier log et affichée dans la console comme message de notification.
Il existe plusieurs évènements qui déclenchent un échange de messages entre les contrôleurs. Par
exemple, pour joindre la liste des contrôleurs, chaque contrôleur déclenche un message ‘Hello’
62
Producer Enregistrer
dans le
Applications fichier Log
Configuration Nouvelle
Oui Non
règle
Initialiser
Traiter les
paquets
Connection DataUpdater
Non
établie Oui
Attenter de
nouvelles Décoder
connexions Encoder
Consumer 1
Canaux sont
Applications DataCollector
prêts Consumer 2
Consumer N
Figure 6.2: Déroulement de la communication entre les contrôleurs dans l’interface CIDC
vers les contrôleurs voisins qui vont former le groupe. Dans le cas d’un changement de statut
de l’infrastructure (nouveaux switchs et hosts), un message est envoyé à tous les contrôleurs
configurés en mode Notification ou Full. Un autre exemple, quand un contrôleur s’est arrêté
accidentellement, une notification est envoyée aux contrôleurs voisins pour les alerter qu’un
contrôleur n’est plus accessible, et que l’administrateur doit prendre la bonne décision. En util-
isant le mode service, le contrôleur maintient l’écoute au réseau local et synchronise les règles
(policies) du mode service avec tous les contrôleurs intéressés.
6.3 Services distribués proposés pour l’interface CIDC
Après avoir définit l’interface CIDC et ses modules ainsi que les différents modes de communica-
tion, nous l’avons enrichi avec plusieurs services distribués. Dans cette section, nous présentons
ces services qui sont le cryptage de données inter-contrôlleurs avec SSL, le Firewall et le Load
Balancer distribués. Aussi, nous présentons les algorithmes de fonctionnement de ces services
implémentés dans le contrôleur.
6.3.1 Cryptage de la communication inter-contrôleurs avec le protocole SSL
La confidentialité et la sensibilité des données est une préoccupation majeure dans le domaine
des technologies de l’information, en particulier pour les réseaux informatiques. Il existe deux
préoccupations de sécurité dans les réseaux SDN : d’une part, les attaques externes qui peuvent
toucher directement le plan de contrôle, puisque toute l’intelligence du réseau est située à ce
63
Producer
Canal est
Oui Non
connecté
Attendez DataUpdater
Oui SSL
Non Décoder
Premier
Oui
paquet Décrypter
Démarrer ‘Handshake’ Non

- ‘Hello’ Client Démarrer ‘Handshake’
- Création de clés de session Décoder - ‘Hello’ serveur
Non - Création de clés de session
Premier
Yes
Non paquet
Encoder
Encoder
SSL Oui
Encrypter
Consumer 1
DataCollector Canaux sont prêts
Consumer 2
Consumer N
Figure 6.3: Déroulement du service SSL dans l’interface CIDC
niveau. Attaquer ce plan signifie avoir un contrôle total sur le réseau. D’autre part, les attaques
internes par déni de service (DDos, Distributed Denial Of Service) qui ont pour objectif de rendre
le contrôleur indisponible pour le réseau, en saturant le contrôleur par un nombre intense de
requêtes de flux (Packet_in). Cela est possible si la chaîne de communication entre le contrôleur et
les switchs n’est pas sécurisée (le protocole OpenFlow exige que cette chaine doit être sécurisée).
Distribuer le plan de contrôle minimise déjà ce risque, mais il faut renforcer la sécurité dans ce
contexte distribué.
Le protocole SSL [7] est couramment utilisé pour sécuriser les pages HTTP (HTTPS), le service e-
mail SMTP (SMPTS), et même les systèmes de base de données. Nous proposons donc d’intégrer
un service de sécurité basé sur le protocole SSL dans l’interface de communication entre les
contrôleurs, pour s’assurer du chiffrement des paquets quand la synchronisation des données
entre les contrôleurs a lieu. Notre interface se base sur le framework Netty [82], qui supporte
les classes de traitement des messages SSL. Cette interface crypte les paquets lors de l’envoi des
données par le Producer et les décrypte quand le Consumer les reçoit. Par compromis entre la
sécurité et les performances (bande passante, débit, latence), nous choisissons une clé symétrique
pour crypter et décrypter les informations.
La Figure 6.3, présente le déroulement de l’algorithme du service SSL dans l’interface CIDC. Après
que le Producer ait établi les chaînes de communication avec les Consumers, il encode et envoie
64
par défaut les paquets en clair. Cependant, quand le protocole SSL est activé dans le fichier de
configuration, le Producer commence une phase de Handshake avec les autres Consumers lorsque
le premier paquet est échangé. Puis, le paquet est encodé, crypté, et envoyé au Consumer. Ce
dernier, décode et décrypte les messages dans le cas de l’activation du SSL. Finalement, les paquets
sont envoyés au module Data Updater pour leur traitement.
6.3.2 Service de Firewall distribué dans l’interface CIDC
Le rôle du Firewall dans un réseau informatique est de filtrer les paquets qui transitent dans le
réseau selon plusieurs critères, comme l’adresse IP source et de destination et le port TCP/UDP
source ou destination. Il s’assure que tous les paquets passent par une inspection minutieuse,
et autorise ou bloque le passage des paquets selon les règles fixées par l’administrateur [126].
L’architecture SDN offre l’avantage de ne pas déployer un Firewall physique dédié dans l’infrastr-
ucture réseau. En effet, on peut le déployer comme une solution logicielle implémentée comme
service dans la couche Application du modèle SDN [86]. Nous distinguons deux approches lors du
déploiement d’un service Firewall dans les réseaux SDN. Soit le contrôleur est le seul équipement
qui inspecte les paquets transitant dans le réseau, soit les équipements de transmission (switchs)
inspectent les paquets selon les règles installées par le contrôleur dans la table de flux. Pour
réduire la charge sur le contrôleur, nous choisissons la deuxième approche, où le contrôleur
installe au départ les règles dans les switchs et évite ainsi d’impacter chaque paquet par une
latence supplémentaire.
Le Firewall basé sur les flux a été implémenté comme un nouveau module dans la version officielle
du contrôleur Floodlight. La notion de DFS (Distributed Firewall Service) est utilisée pour indi-
quer que le Firewall n’est plus centralisé, il est intégré comme service programmable à l’intérieur
des équipements [83]. Cette notion a été utilisée dans un contexte de virtualisation, mais à notre
connaissance, il n’existe pas de proposition de DFS pour les architectures SDN multi-contrôleurs.
Nous proposons donc l’implémenter du DFS dans les architectures SDN multi-contrôleurs pos-
sédant plusieurs domaines. Par exemple, supposons que nous avons deux domaines, chacun est
géré par son propre contrôleur (respectivement C1 et C2) et contenant chacun un host (h1 et h2).
L’administrateur de C1 configure une règle de Firewall qui interdit la communication entre h1 et
h2, cependant C1 ne sait pas où se trouve h2. Dans ce cas, C1 doit informer C2 de cette nouvelle
règle pour qu’il l’installe automatiquement dans son domaine. Dans le cas du Firewall, nous in-
spectons les paquets selon leur adresse IP source ou de destination, mais notre algorithme peut
être appliqué pour l’inspection selon l’identificateur du switch (switch ID) avec la même logique.
Dans la Figure 6.4, nous décrivons notre algorithme qui permet de partager avec les contrôleurs
distants les règles du Firewall (FW) et aussi de Load Balancing (LB) que nous allons présenter
dans la sous-section suivante. Après l’application d’une nouvelle règle, le module Data Collector
récupère les changements et vérifie si la règle doit être partagée avec les autres contrôleurs.
Cette vérification est basée sur l’adresse IP source et destination des hosts découverts. Si l’une
65
Application
Non Service Oui
Ignorer
DataCollector
Règle
No Yes
existe
Producer Attente de
nouveaux paquets
Encoder la
Règle
Consumer
Décoder La
Règle
DataUpdater
La règle est une

Oui instance de Non
Firewall
Activer le
Firewall s’il est
désactivé La règle est une
Oui instance de Load Non
Balancer
Ignorer
Règle
Application Non Oui
existe
Installer la Ignorer
règle
Figure 6.4: Déroulement des services distribués (DFS et DLBS) dans l’interface CIDC
des adresses n’est pas disponible localement, cela signifie qu’on est dans le cas du DFS, et le
réseau doit filtrer les paquets basés sur les adresses IP des hosts qui n’appartiennent pas au même
domaine. Dans ce cas, le Data Collector envoie cette règle au module Producer pour encodage et
transmission aux Consumers distants. Quand un Consumer reçoit une nouvelle règle étiquetée
‘Firewall’, il la décode et l’envoie au Data Updater pour vérification. Par la suite, le Data Updater
active le Firewall et examine les adresses IP source et destination. Si l’une des deux adresses est
identifiée localement, la règle est instaurée comme une nouvelle règle du Firewall. Si les deux
adresses ne figurent pas dans la liste des adresses locales, le Data Updater ignore cette règle et
reste en attente de nouvelles règles envoyées par le Consumer.
L’activation et la manipulation du DFS est faite à travers ‘Rest API’ [74] sous la forme de listes
d’accès (ACL). Un exemple des règles du Firewall est donné ci-dessous :
• Activer le FW : $ curl http://localhost:8080/wm/firewall/module/enable/json

66
• Ajouter une règle de permission pour tous les flux qui transitent entre le service a.b.c.d
et le serveur e.f.g.h, ne pas specifier une action signifie une permission :$ curl -X POST d
‘“src-ip”: “a.b.c.d/32”, “dst-ip”: “e.f.g.h/32”’ http://localhost:8080/wm/firewall/rules/json
6.3.3 Service d’équilibrage de charge distribué (routé)
L’équilibrage de charge (LB, Load Balancer) est une technique qui permet d’améliorer les per-
formances en répartissant la charge sur plusieurs serveurs. En effet, ceci permet d’optimiser les
ressources disponibles et aide à réduire la latence du réseau. En pratique, le LB est utilisé sous
forme de hardware au sein du réseau, mais son coût est très élevé et ses règles sont rigides. Dans
les réseaux SDN, le LB a été introduit sous forme de service [75] pour organiser et coordonner
entre les serveurs du réseau. Le contrôleur Floodlight supporte les fonctions du LB, mais il est
limité à un seul contrôleur physique. Notre contribution est d’étendre la version existante du
LB vers les multi-contrôleurs. Cela permet la synchronisation des règles du LB entre tous les
contrôleurs qui composent le groupe et autorise à un client d’accéder à des services disponibles
dans les domaines distants. Nous implémentons ces fonctionnalités dans notre interface CIDC
sous le mode service.
Trois règles sont appliquées (au lieu d’une seule dans l’algorithme du Firewall) à travers les ‘Rest
API’ pour réaliser les fonctions du LB. Les paramètres utilisés dans ces règles sont : l’adresse IP
Virtuelle (Vip), la liste des adresses (Pool) et les membres (Member) de la liste.
Le LB commence par insérer les règles Vip et Pool à travers l’API nord, puis il ajoute les mem-
bres pour entourer le Vip. Quand un flux de type ‘Packet_in’ est détecté et contient l’adresse IP
de destination de la Vip configurée, le LB sélectionne un serveur en se basant sur l’algorithme
round-robin pour traiter le flux. Notre interface CIDC (Figure 6.4), et plus précisément le module
DataCollector, est en permanence attentif à ces changements du réseau local. Un nouvel écou-
teur a été conçu et implémenté pour recevoir les évènements nouvellement installés comme les
Vip, Pool, et les membres. Et si le service du LB distribué est configuré, le DataCollector délivre
ces informations au Producer pour les partager avec les autres contrôleurs en les étiquetant ‘Load
Balancer’. Le Producer encode et envoie ces règles aux Consumers distants, qui décodent et trans-
mettent les règles vers leurs modules DataUpdater pour leur traitement. Le service LB est activé
par défaut par le contrôleur, ce n’est donc pas la peine de le réactiver chaque fois qu’une règle
de ce service est reçue. Quand la règle est identifiée comme règle du LB et si elle est nouvelle,
le DataUpdater instaure cette règle. Un des cas d’utilisation le plus fréquent de cet algorithme
est l’équilibrage de charge routé ou distribué (Distributed Load Balancer) dans les architectures
distribuées comme Internet quand un service est disponible dans un domaine et que les clients
sont dans d’autres domaines.
Pour activer le service LB, nous présentons ci-dessous la forme des règles qui doivent être ap-
pliquées:
67
• Pour installer une nouvelle Vip avec le nom ‘vip1’, adresse ‘a.b.c.d’, port ‘x’:
$ curl -X POST –d ’”id”:”1”,”name”:”vip1”,”protocol”:”icmp”,”address”:”a.b.c.d”,”port”:”x”’’ http:
//localhost:8080/quantum/v1.0/vips/
• Pour installer une nouvelle liste avec le nom ‘pool1’ associée au vip1:
$ curl -X POST -d ’”id”:”1”,”name”:”pool1”,”protocol” :”icmp”,”vip id”:”1”’ http://localhost:8080/
quantum/v1.0/pools/
• Pour installer des nouveaux membres, avec la 1ère adresse IP est a.b.c.e, et la 2ème est a.b.c.f,
et associer les membres avec la liste pool1:
$ curl -X POST -d ’”id”:”1”,”address”:”a.b.c.e”,”port”:”x”,”pool id”:”1”’ http://localhost:8080/ quan-
tum/v1.0/members/
$ curl -X POST -d ’”id”:”2”,”address”:”a.b.c.f”,”port”: ”x”,”pool id”:”1”’ http://localhost:8080/
quantum/v1.0/members/
Dans cette section, nous présentons les caractéristiques physiques du serveur où nous avons
déroulé nos expériences et les outils d’émulation utilisés, puis nous décrivons les différents scé-
narios et topologies considérés. Nous terminons cette section par une présentation des métriques
de performances mesurées lors des expériences.
Pour évaluer les métriques de performance d’un réseau SDN multi-domaines logiquement dis-
tribué, nous émulons dans un serveur physique différentes topologies WAN (Figure 6.5) réelles
en utilisant l’émulateur Mininet [21] dans sa version 2.1.0+. Les caractéristiques de ce serveur
sont, 14 Go de RAM et 8 cœurs logiques dont chacun est de type Intel Xeon 2.67Ghz. Chaque do-
maine du réseau émulé utilise deux machines virtuelles (VM), une pour le contrôleur SDN et une
autre pour le réseau. La VM du réseau local est connecté au contrôleur et composé de switchs
virtuels de type Open VSwitch (OVS) [89] (version 1.4.6) auquel nous attachons un hôte virtuel.
Chaque VM a 2Go de mémoire et 1 CPU et la connexion entre les VMs est établie par GNS3 [55].
Le protocole sud de communication entre les OVS et les contrôleurs est OpenFlow 1.1.
Nous choisissons de construire une topologie WAN circulaire constituée de plusieurs domaines,
qui seront interconnectés à travers des tunnels GRE (Generic Routing Encapsulation). Notons que
chaque contrôleur SDN gère un seul domaine. Un maillage complet est établi entre les contrôleurs
SDN, c’est-à-dire que chaque contrôleur a une connexion directe avec les autres contrôleurs.
Toutes les VM utilisent le protocole NTP (Network Time Protocol) pour la synchronisation de
leurs horloges, ceci permet d’assurer la précision et la cohérence des résultats de performances
68
Bracewell
Shouthport Leeds
Liverpool Manchester
SanfFrancisco Newark NewfYork Sheffield
Washington,fDC
Birmingham Leicester
Atlanta
Peterborough
Dallas
LosfAngeles
Cambridge
Houston
Bristol
Miami Reading London
(a) Gridnet (b) HiberniaUk

Manchester Tanger
NewfYork
London Amsterdam
Rabat Fez
Casa
Findhoven
Berlin
Paris
Rennes Frankfurt
Porto Munich Marrakech
Lisbon Madrid Barcelona Agadir
Faro
(c) Claranet (d) Marwan
Figure 6.5: Topologies des réseaux WAN considérés
qui seront calculés dans la prochaine section. Notons enfin que nous configurons les liaisons
entre les switchs et les hôtes virtuels à 1Gbps de bande passante et 30 ms de délai.
6.4.2 Description des scénarios
Afin d’évaluer notre interface CIDC dans un environnement multi-contrôleurs, nous considérons
le contrôleur Opendaylight (ODL) (version Hydrogen) configuré en mode cluster et le contrôleur
Floodlight (FL) (version 1.1) équipé par l’interface CIDC comme nous l’avons expliqué dans la
section 6.2.2. Pour mesurer l’intérêt des modes de communication personnalisés et les services,
nous comparons nos résultats avec ceux obtenus avec ODL en mode cluster même si ce mode est
adapté à l’architecture de plan de contrôle logiquement centralisée. En fait, nous ne connaissons
pas pour l’instant une autre méthode déjà implémentée et disponible pour l’architecture logique-
ment distribuée avec laquelle on peut se comparer. Nous notons que vu l’aspect modulaire de
notre interface, elle pourra être intégrée dans d’autres contrôleurs avec que FL des modifications
minimales.
Nous considérons quatre topologies différentes Gridnet, Claranet, Marwan et HiberniaUK issues
69
Domaine 3
Contrôleur
Domaine 4 Domaine 2
Claranet
Contrôleur Contrôleur
Domaine 1
Claranet Claranet
Contrôleur
Tunnel
Claranet
Figure 6.6: Illustration d’une topologie multi-domaines Claranet_4 dont chaque domaine est géré
par son contrôleur SDN
de la plateforme des topologies d’internet (Internet Topology zoo) [122]. Pour construire des
topologies multi-domaines, nous dupliquons la même topologie sur un certain nombre N de do-
maine. Par exemple la topologie Claranet_4 signifie que nous avons 4 domaines interconnectés
et qu’à l’intérieur de chaque domaine nous avons la topologie Claranet comme illustre la Figure
6.6. Nous résumons dans la Table 6.1, les topologies multi-domaines considérées, ainsi que le
nombre de nœuds et de liaisons.
Pour obtenir des résultats précis et selon les recommandations de [1], nous exécutons 5 expéri-
ences indépendantes, pour chaque scénario et configuration. Pour chaque exécution nous démar-
rons les contrôleurs SDN pour former le cluster dans le cas de l’ODL, ou pour établir un réseau
maillé dans le cas de notre interface (FL adapté). Par la suite, nous démarrons la topologie dans
chaque domaine en utilisant l’émulateur Mininet. Si les connexions OpenFlow sont établies avec
succès, nous injectons à partir des hôtes connectés aux switchs un trafic sous forme de nouveaux
flux en utilisant l’outil Iperf [62]. L’objectif de cette injection du trafic est de former une situation
de changement dans le réseau local que le contrôleur doit partager avec les autres contrôleurs.
Dans le cas du contrôleur ODL, nous utilisons le mécanisme du cluster déjà implémenté pour
synchroniser les nouveaux évènements. Cependant, dans le cas du FL, nous utilisons l’interface
CIDC pour échanger ces évènements selon le mode de communication configuré (Notification,
Service ou Full). Nous choisissons, comme l’étude du chapitre précédent, trois évènements qui
sont les plus significatifs parmi les autres, à savoir New switch, New host et New flow. Avec notre
70
Topologies Topologie Nombre de Nombre de Nombre de
multi- Domaines Nœuds Liaisons
domaines
HiberniaUK HiberniaUK_2 2 30 62
HiberniaUK HiberniaUK_3 3 45 92
Gridnet Gridnet_3 3 27 87
Claranet Claranet_3 3 45 101
Claranet Claranet_4 4 60 135
Marwan Marwan_4 4 24 51
Marwan Marwan_5 5 30 64
Table 6.1: Topologies considérées dans les tests
interface CIDC, nous pouvons gérer l’échange de ces évènements avec précision en utilisant les
modes de communication, ce qui n’est pas disponible dans les options du contrôleur ODL.
6.4.3 Métriques de performance
Nous considérons cinq paramètres pouvant affecter les performances d’un contrôleur SDN dans
un réseau distribué. Nous distinguons deux groupes de paramètres. Dans le 1er groupe, nous
évaluons le délai et la charge de communication inter-contrôleurs (que nous appelons ici ICO:
Inter-controller Communication Overload) nécessaires à la synchronisation des informations
dans un réseau WAN large. La deuxième catégorie est liée au système tel que le processeur
(CPU), la mémoire (RAM), et les threads. Ces paramètres sont consommés par chaque contrôleur
du réseau pendant l’expérience. Nous décrivons toutes les métriques ci-dessous :
• Délai de la synchronisation (ms): le temps nécessaire pour qu’un contrôleur génère un

évènement et que les autres contrôleurs soient au courant du même évènement.
• Charge de communication inter-contrôleur ICO (Kbps): le taux total du trafic bidirection-

nel échangé entre les contrôleurs qui composent le réseau.
• Consommation du processeur (%): le pourcentage d’utilisation du processeur (CPU) par le

contrôleur par seconde.
• Consommation de la mémoire (%): le pourcentage d’utilisation de la mémoire (RAM) par

le contrôleur par seconde.
• Consommation des threads : le nombre de threads par seconde utilisés par le contrôleur
durant l’expérience.
Pour les cinq métriques, nous conduisons une comparaison entre les deux scénarios. Ainsi, pour
montrer la faisabilité de notre interface en particulier pour le délai, nous le comparons avec la
71
valeur 50 ms comme expliqué dans le chapitre précédent. Dans la section suivante, nous évaluons
les métriques de performance pour les différentes topologies multi-domaines, et nous examinons
aussi les services distribués implémentés dans l’interface CIDC.
6.5 Analyse des résultats de simulation
Dans cette section, nous discutons les résultats de simulation pour les deux scénarios. Pour
chaque métrique, nous comparons les résultats obtenus par le contrôleur ODL avec ceux du
contrôleur FL modifié par notre interface CIDC. En plus, les services implémentés sont évalués
et testés pour différentes topologies et selon plusieurs modes de communication.
6.5.1 Analyse du délai
La Figure 6.7 donne le délai de synchronisation des évènements en fonction du temps. Pour
les deux scénarios, nous avons simulé trois topologies multi-domaines Gridnet_3 (Figure 6.5(a)),
Claranet_4 (Figure 6.5(c)) et Marwan_5 (Figure 6.5(d)), dont la différence réside dans le nombre de
contrôleurs et de switchs. Comme nous l’avons expliqué au chapitre précédent, il existe quatres
phases à savoir, Bootstrap, événements de switchs, maintenance et évènements host et flux. La
phase de ‘Bootstrap’ concerne la charge de synchronisation et non pas le délai puisqu’il n’y a
aucun événement à échanger dans cette phase et donc pas de délai à calculer. Nous notons
que tous les délais seront comparés avec le délai de référence (50 ms) et que notre interface est
configurée en mode Notification.
Dans la Figure 6.7(a), nous remarquons que le délai est faible (moins de 5 ms) pour notre interface
CIDC dans la phase 4 (évènements host et flux), il est un peu élevé (25 ms ou moins) dans la
phase 2 d’échange des événements de switchs. Cette dernière, n’est qu’une phase transitoire où
les contrôleurs commencent un processus de prise de contact (Handshake) avec les nouveaux
switchs, ce qui consomme du temps et de la bande passante. Alors que la phase 4 est la phase
qui se produit plus fréquemment et considérée comme une phase de fonctionnement normal
du réseau. Concernant ODL, le délai de synchronisation est plus élevé que FL avec des pics
qui atteignent 50 ms dans la phase 2 et 4. En plus, avec un burst d’évènements host et flux,
ODL devient instable en terme de délai. Ce dernier peut passer de 5, 10 puis 30 ms entre deux
évènements. Les mêmes tendances peuvent être observées dans la Figure 6.7(b) et 6.7(c).
Nous remarquons aussi que l’interface CIDC est peu sensible au nombre de switchs notamment
dans Claranet_4 (Figure 6.7(b)) où le réseau est composé par 60 switchs et le délai est resté faible
dans la phase 4 (5ms ou moins). Cela est dû à l’architecture distribuée du plan de contrôle, où
chaque contrôleur gère son domaine et notifie les autres domaines de ses changements. Tandis
que, l’ODL est sensible à l’augmentation des switchs et dépasse parfois 50 ms. Ceci est dû au fait
que chaque contrôleur ODL perçoit qu’il est le seul contrôleur qui gère tous les switchs du réseau
et partage les évènements avec tous les autres contrôleur pour garder une vue consistante sur le
72
(a) Gridnet_3 composée de 27 switchs
60
ODL
CIDC
50
40
Delai (m s)
30
20
10
0
0 100 200 300 400 500
Tem ps (s)
(b) Claranet_4 composée de 60 switchs
73
70
ODL
CIDC
60
50
Delai (m s)
40
30
20
10
0
0 50 100 150 200 250
Tem ps (s)
(c) Marwan_5 composée de 30 switchs
Figure 6.7: Délais des évènements pour ODL et CIDC selon plusieurs topologies
réseau. Ainsi, dans la phase 4, l’ODL doit traiter un flux de paquets dans sa liste d’attente avant
de procéder à l’envoi des nouveaux changements. Ce problème a été résolu dans notre interface
CIDC par la séparation entre l’expéditeur Producer et le récepteur Consumer des évènements.
Ces résultats prouvent qu’ODL n’est pas très adapté aux grands réseaux multi-domaines.
Finalement, nous constatons qu’en passant de 3 domaines (Figure 6.7(a)) à 5 domaines (Figure
6.7(c)) et en gardant approximativement le même nombre de switchs (30), le délai de synchroni-
sation est resté faible dans la phase 4 pour le cas du CIDC, alors qu’il y a plusieurs dépassements
du délai de référence dans le cas d’ODL. En fait, avec plus de domaines connectés il y a plus de
contrôleurs et donc plus d’évènements à partager.
6.5.2 Analyse de la charge de communication inter-contrôleurs (ICO)
Afin d’avoir une meilleure idée sur la charge de communication inter-contrôleur (ICO) de notre
interface, nous considérons des topologies de tailles variables et des configurations différentes.
La Table 6.2, présente une comparaison de la charge (ICO) entre notre interface CIDC et Open-
daylight selon plusieurs topologies multi-domaines. Dans cette table, nous comparons la version
non sécurisée (TCP) de l’interface avec ODL. Nous allons présenter dans la sous-section des ser-
vices distribués une autre comparaison avec la version sécurisée (TCP+SSL) de l’interface. Pour
une meilleur compréhension, nous présentons à la fois la charge ICO et le nombre de paquets
74
Topologies Nombre de CIDC (TCP) Opendaylight
Nœuds
ICO(Mbits/s) Paquets ICO(Mbits/s) Paquets
Hibernia_2 30 962 9162 80 761 152 768
Hibernia_3 45 1 944 19495 388 070 705 591
Gridnet_3 27 2 018 18966 144 404 294 330
Claranet_4 60 1 916 22278 1 003 612 1 713 127
Marwan_4 24 693 7976 177 412 348 678
Marwan_5 30 1 308 14624 312 723 583 366
Table 6.2: Comparaison de la charge et le nombre de paquets échangés pour plusieurs topologies
multi-domaines
échangés pour chaque topologie et scénario.

Nous remarquons que le nombre de paquets échangés dans le cas de l’ODL est très largement
supérieur à celui de l’interface CIDC. Par exemple, avec la topologie Hibernia_3 composée de 45
switchs, les paquets échangés sont 705 591 pour ODL et 19 495 pour CIDC, et avec la topologie
Claranet_4 composée de 60 switchs, le nombre de paquets échangés est 1 713 127 dans le cas du
ODL et seulement 22 278 dans le cas du CIDC. Alors, ODL est sensible au nombre de switchs,
ce comportement a été déjà observé lors de l’évaluation du délai. Nous constatons le nombre
de controleur impacte ICO du ODL plus que CIDC. Par exemple, si on compare le pourcentage
d’augmentation1 entre Hibernia_2 et Marwan_5,on constate que ce pourcentage est de 36 % pour
CIDC alors qu’il égale à 287 % dans le cas du ODL. Donc, le contrôleur ODL est très sensible au
nombre de contrôleurs.
Notre interface est très peu impactée par le nombre de switchs et de contrôleurs puisque chaque
contrôleur gère uniquement son domaine et échange les paquets, en se basant sur le mode con-
figuré, avec les autres contrôleurs. Par contre dans le cas d’ODL, chaque contrôleur reconstruit la
structure de données pour garder une vue consistante sur tout le réseau, avec l’augmentation du
nombre de switchs et de contrôleur qui construit le cluster, ODL génère plus de charge et de délai.
Nous pouvons constater que l’utilisation de l’interface CIDC apporte un gain très significatif en
terme de délai et de charge par rapport à ODL. Ainsi, on voit clairement l’intérêt d’utiliser les
modes de communication que nous avons proposés.
6.5.3 Consommation des ressources du système
La Figure 6.8, présente la consommation des ressources du système avec la topologie Claranet_4.
Nous remarquons dans la Figure 6.8a que le pourcentage de CPU consommé par FL décrémente
progressivement de 78 % dans la phase de Bootstarp à moins de 10 % dans la phase d’host et Flux.
Avec ODL, la consommation du CPU est très variable dans les deux premières phases atteignant
1
(Va-Vd)/Vd * 100, Va: la valuer d’arrivée et Vd: la valeur de départ
75
100
Boot- Evenements Evenements ODL
strap Switch Host et flux FL+CIDC
80
60
Cpu (%)
40
20
00 100 200 300 400 500 600

Temps(s)
(a) Consommation du CPU
35
ODL
Boot- Evenements Evenements FL+CIDC
30 strap Switch Host et flux
25
Memoire (%)
20
15
10
00 100 200 300 400 500 600

Temps(s)
(b) Consommation de la RAM
76
7
Boot- Evenements Evenements ODL
strap Switch Host et flux FL+CIDC
6
5
Nombre de Thread
00 100 200 300 400 500 600

Temps(s)
(c) Consommation de Thread
Figure 6.8: Consommation des ressources systèmes avec la topologie Claranet_4
des fois le pic de 90 % mais diminue à moins de 20 % dans la phase de synchronisation des hosts et
Flux. La différence de consommation de la mémoire RAM dans la Figure 6.8b est très visible, notre
contrôleur se stabilise dans la phase de Bootstrap à 10 % de RAM alors que ODL consomme 28
% de RAM à partir de la phase 3. Concernant le nombre de thread (Figure 6.8c), nous constatons
que ce nombre atteigne deux fois 6 dans le cas du ODL dans la phase 2 ce qui confirme que ODL
est influencé par le nombre de noeuds alors que le contrôleur FL consomme entre 3 à 4 thread
dans cette phase. En plus, dans la phase 3 la consommation des threads est minimale pour les
deux contrôleurs avec une petite amélioration de notre contrôleur FL. À partir de ces résultats,
nous pouvons observer le gain en terme de consommation des ressources (CPU, RAM et Thread)
de notre contrôleur, cela est dû essentiellement aux nombreuses optimisations que nous avons
considérées durant la phase de conception et aussi de l’implémentation d’une interface dédiée à
la communication inter-contrôleur au lieu d’utilisation d’un modèle de cluster. Dans la section
suivante, nous allons évaluer les services distribués que nous avons proposés pour l’interface
CIDC.
6.5.4 Évaluation des services distribués
Dans cette partie, nous évaluons les services distribués notamment la sécurisation du trafic
inter-contrôleur avec SSL, le service de Firewall distribué (DFS, Distributed Firewall Service) et
l’équilibrage de charge distribué (DLBS, Distributed Load Balancer Service).
77
Topologies Nombre de CIDC (TCP) CIDC Opendaylight
Nœuds (TCP+SSL)
Hibernia_2 30 962 1013 80 761
Hibernia_3 45 1 944 1914 388 070
Gridnet_3 27 2 018 2048 144 404
Claranet_4 60 1 916 2361 1 003 612
Marwan_4 24 693 912 177 412
Marwan_5 30 1 308 1451 312 723
Table 6.3: ICO en Mbits/s pour CIDC non sécurisée, sécurisée et Opendaylight
6.5.4.1 Service distribué SSL
La Table 6.3 est semblable à la Table 6.2 sauf qu’on a remplacé les paquets TCP par TCP+SSL ce
qui correspond à l’ajout du service SSL dans l’interface CIDC.
Nous remarquons que malgré l’utilisation du protocole SSL, la métrique ICO est restée largement
faible à celle de ODL. Cela est dû au fait que le protocole SSL est un processus intensif uniquement
lors de la phase de prise de contact (Handshak) par rapport à la phase de cryptage de données.
Par exemple, l’effet du TCP+SSL par rapport au TCP varie de 30 Mbits/s pour le cas Gridnet_3
à 445 Mbits/s pour le cas Claranet_4 puisque le nombre de switchs augmente de 27 à 60. Aussi,
le nombre de contrôleurs n’a pas d’effet sur le SSL puisque dans le cas de 5 contrôleurs la dif-
férence d’ICO entre CIDC TCP et TCP+SSL ne dépasse pas 143 Mbits/s. Par conséquent, nous
constatons à travers tous les résultats que la sécurisation des échanges entre les contrôleurs par
SSL n’introduit pas une forte pénalité sur la charge ICO, ce dernier reste toujours très faible à
celui obtenu dans le cas du contrôleur ODL.
6.5.4.2 Services distribués DFS et DLBS
Dans la Table 6.4, nous présentons les métriques de performance à savoir l’ICO et le délai lors de
l’utilisation du mode Service (DFS et DLBS) et Full de notre interface. Nous fixons la topologie
multi-domaine Hibernia_3 et nous varions le nombre de règles partagées entre les contrôleurs
de 10, 30 et 50. Chaque règle contient les informations nécessaires pour permettre ou interdire la
communication entre deux hôtes dans le cas du DFS ou pour établir un équilibrage de charge dans
le cas DLBS. À travers cette évaluation, nous pouvons voir la faisabilité d’implémenter des ser-
vices distribués dans notre algorithme et même l’effet de l’automatisation des configurations sur
les performances du réseau. On rappelle que le mode Full incorpore en plus du mode Notification
et Service (FW, LB et SSL), d’autre informations comme les Paquet_in, Paquet_out et Port_status.
Nous allons aussi comparer les résultats obtenus avec ceux calculés lors de l’évaluation de l’ICO
(6.5.2) pour le cas du topologie Hibernia_3. La même logique sera appliquée au DLBS. Nous no-
tons que le délai calculé dans cette expérience et le temps total nécessaire pour partager toutes
les règles avec tous les contrôleurs. Dans le cas du mode Full, ce délai est composé du délai de
78
Nombre de règle Mode Service Mode Full
Firewall Load Balancer
Délai(s) ICO(Mbits/s) Délai(s) ICO(Mbits/s) Délai(s) ICO(Mbits/s)
10 3.37 58 3.7 60 4.28 7 136
30 10.43 83 10.82 75 13.87 7 462
50 16.46 117 17.76 94 24.5 7 705
Table 6.4: Evaluation du mode Service et Full pour la topologie Hibernia_3
FW et de LB.
D’après la Table 6.4, nous remarquons que le délai de DLBS est toujours un peu plus grand que
celui du DFS. Par exemple, le délai du DLBS et DFS est respectivement 10.82s et 10.43s dans le
cas de 30 règles, soit une augmentation de 0.39s entre les deux services, cette augmentation est
de l’ordre de 1.3s dans le cas de 50 règles. La différence des délais entre le DLBS et DFS est due
au type de règle que le contrôleur va échanger avec ses voisins lors de l’utilisation du service
DLBS. Ce dernier doit partager trois types de règles (vip, pool et membre) pour que la règle soit
correctement instaurée dans le contrôleur et partagée avec les autres contrôleurs. Avec plus de
règles à partager le DLBS consomme plus de temps par rapport à DFS mais la différence reste
minimale. Nous observons aussi que la métrique ICO augmente avec l’augmentation des règles.
Dans le cas du mode Full, nous observons les mêmes tendances que le mode Service, le délai
augmente avec l’augmentation du nombre de règles. Dans le cas de 50 règles il est égale à 24.5s,
mais cette augmentation reste minimale par rapport au nombre de règles qui est multiplié par 2
(FW+LB). D’autre part, l’effet des règles sur l’ICO n’est pas très significatif, cependant, il existe
d’autres facteurs qui interviennent dans ce mode. Dans notre interface, le mode Full inclut le
service DFS, DLBS et le cryptage inter-contrôleurs avec SSL, en plus les notifications détaillées
de tous les changements produits dans un domaine. Malgré l’augmentation de la charge ICO
du mode Full, le gain qu’il peut apporter en terme de sécurité et de qualité de service pour les
domaines sensibles peut compenser cette augmentation. En comparant ces résultats avec ceux
obtenus dans l’expérience précédente de l’ICO (Table 6.2) avec la même topologie (Hibernia_3),
nous constatons que dans le cas de 50 règles le mode Full échange 7705 Mbps, ce qui est largement
inférieur par rapport au mode cluster du contrôleur ODL soit 388 070 Mbps et sans utiliser aucune
sécurité de communication ni de qualité de service.
En conclusion, l’avantage d’utiliser les modes de communication est très visible surtout en terme
de performance et de flexibilité. En plus, dans le cas des domaines sensibles, nous pouvons con-
figurer le mode en Full pour un contrôle précis de tous les changements du réseau. L’utilisation
de ce mode reste largement avantageuse par rapport au modèle cluster de ODL.
79
6.6 Conclusion
Dans ce chapitre, nous avons proposé une nouvelle interface de communication pour les plans de
contrôle logiquement distribués appelée CIDC. Cette interface est basée sur des modes de com-
munication pour échanger les informations en temps réel avec les contrôleurs qui construisent
le réseau distribué. Le concept, l’implémentation, et l’évaluation de notre CIDC sont donnés en
détails en se basant sur le contrôleur Floodlight. Les résultats de la simulation sont comparés
par rapport au contrôleur Opendaylight, exécuté en mode cluster pour supporter les contrôleurs
multiples. Pour évaluer le comportement des deux contrôleurs dans les architectures distribuées,
nous avons choisi cinq métriques de performance, à savoir le délai, la charge de communication
(ICO), la consommation de CPU et de RAM et le nombre de thread. Les résulats montrent que le
délai et ICO sont faibles, et la mémoire consommée par le FL est deux fois faible que celle con-
sommée par l’ODL. Dans un domaine nécessitant un contrôle extensif, nous pouvons configurer
notre interface CIDC en mode Full et échanger plus d’informations concernant les changements
qui se produisent dans le réseau local. Cela signifie que nous pouvons faire un compromis entre
les performances et le contrôle granulaire du réseau.
Pour vérifier la faisabilité de la nouvelle version du FL en terme de sécurité et de qualité de service,
trois services distribués ont été implémentés et évalués à travers l’interface CIDC, notamment
le Firewall, Load Balancer et le cryptage inter-contrôleur par le protocole SSL. L’utilisation des
services distribués montre qu’il n’existe aucune contrainte de performance, surtout en terme de
la charge ICO qui est largement faible par rapport au contrôleur ODL. Pour conclure, la majorité
des changements du réseau et des services peuvent être synchronisés rapidement et facilement,
et l’utilisation des modes de communication personnalise le comportement de chaque contrôleur
dans le réseau distribué et apporte plus de précision de contrôle au réseau tout entier.
80
Chapitre 7
Conclusion générale
Le concept de SDN ou de réseaux programmés par logiciel est une architecture qui facilite la ges-
tion et le contrôle des réseaux, et permet une introduction rapide des services réseau à travers la
programmation et la séparation du plan de contrôle du plan de données. Grâce à cette nouvelle
architecture, les administrateurs peuvent gérer le réseau d’une manière unifiée à partir du plan de
contrôle, et peuvent introduire ou éliminer n’importe quel service à travers le plan d’application
sans changer l’infrastructure physique. Ces avantages ont un coût sur le plan de contrôle, en par-
ticulier, avec l’architecture initiale des réseaux SDN qui utilise un seul contrôleur (physiquement
centralisé) et soulève des problèmes de performance et de scalabilité du contrôleur. Par la suite,
des architectures du plan de contrôle avec plusieurs contrôleurs ont été proposées. Étudier, éval-
uer et tester la faisabilité de ces architectures est une phase primordiale avant leur déploiement
dans les réseaux de production. Cette thèse a été consacrée à l’étude des performances des dif-
férentes architectures du plan de contrôle des réseaux SDN.
Avant d’entamer les études techniques et les tests de performance, nous avons commencé d’abord
par une étude bibliographique sur les travaux d’évaluation et d’amélioration des performances
des réseaux SDN. Par la suite, nous avons proposé une étude de cas du contrôleur Ryu avec une
topologie linéaire. Cette étude nous a confirmé l’intuition et les résultats d’autres études faites
avec d’autres contrôleurs sur les limites du contrôleur et sa capacité à traiter les requêtes d’un très
grand nombre de switchs. Dans notre cas, la limite est de l’ordre de 60 switchs ce qui montre que
cette architecture est plus adaptée aux réseaux locaux de type LAN. Cette étude nous a permis
aussi de maitriser les outils de simulation des topologies et les outils de mesure de performance
spécifiques à SDN.
Pour des raisons de performance, évolutivité, et de tolérance aux pannes (Fault tolerence), des
architectures avec plusieurs contrôleurs ont été proposées. Nous avons considéré dans une 2ème
étude une architecture de plan de contrôle logiquement centralisé, en particulier, le mode cluster
fourni par le contrôleur OpenDayLight (ODL). Ces architectures multi-contrôleurs nécessitent
une communication inter-contrôleur afin de synchroniser les états du réseau et assurer une vue
logiquement centralisée. Nous avons donc évalué le coût de synchronisation en terme de délai
et de charge et nous avons comparé les résultats avec les critères de faisabilité utilisés dans les
réseaux de production. Les résultats obtenus à travers des simulations de topologies réelles util-
isées dans les réseaux WAN nous ont montré que le délai de synchronisation pour plusieurs
évènements est très faible. En fait, il est inférieur au temps typique de restauration dans les dé-
ploiements des réseaux courants. Nous avons remarqué aussi qu’avec plus de nœuds, c’est-à-dire
plus d’évènements à gérer, il y a une forte probabilité que certains évènements soient affectés
par la grande charge sur le contrôleur. Cette étude nous a prouvé que le déploiement de con-
trôleurs multiples logiquement centralisés est faisable du point de vue de délai surtout dans un
réseau WAN constitué d’un seul domaine. Cependant, pour garder une vue consistante sur le
réseau, le modèle de cluster utilisé génère une grande charge lors de la synchronisation des états
du réseau entre les contrôleurs. D’autant plus que dans un réseau WAN de plusieurs domaines
géré par plusieurs opérateurs l’accord sur un plan de contrôle logiquement centralisé peut poser
un problème.
Dans les plans de contrôle logiquement distribués, chaque contrôleur gère son réseau et com-
munique, si nécessaire, avec les autres contrôleurs. Nous avons proposé notre propre modèle
de communication inter-contrôleur adapté à ces plans distribués. Dans ce modèle, nous avons
proposé une interface de communication appelée CIDC qui s’implémente sur chaque contrôleur.
Elle est basée sur trois modes de communication que l’administrateur peut configurer afin de per-
sonnaliser le comportement de chaque contrôleur selon sa position, son rôle, et les ressources
disponibles. Ces modes sont « Notification », « Service », et « Full ». L’utilisation des modes de
communication ajoute plus de flexibilité à la gestion des réseaux distribués et réduit les ressources
consommées. D’autre part, nous avons proposé dans notre interface la possibilité d’implémenter
des services distribués comme le pare-feu (Firewall) et l’équilibrage de charge (Load Balancer)
de bout-en-bout en distribuant la configuration des services entre les domaines. Ceci permet
d’améliorer la sécurité et la qualité de service des communications. Nous avons implémenté
l’interface CIDC dans le contrôleur ‘Floodlight’ qui ne supporte par les communications inter-
contrôleur dans sa version officielle. L’évaluation montre la faisabilité de notre interface et les
services distribués en terme de délai en comparaison avec les critères utilisés dans les réseaux
de production. La comparaison des résultats du délai et de la charge de synchronisation avec
ODL montrent l’intérêt des modes que nous avons proposé. En ce qui concerne la consomma-
tion des ressources, notre contrôleur utilise moins de processeurs, deux fois moins de mémoire
par rapport à ODL.
Comme perspective, nous souhaitons tester notre interface dans les larges plateformes de teste
comme OFELIA et GENI pour estimer sa capacité et ses limites. Une autre voie de développement
est d’implémenter de nouveaux services vu l’aspect modulaire de notre interface. Ces services
peuvent être soit l’ingénierie de trafic, l’approvisionnement dynamique de la bande passante
(BoD, Bandwidth on Demand) ou la sécurité entre les contrôleurs en proposant par exemple un
nouveau protocole de sécurité.
82
Nous souhaitons également exploiter dans les années futures les nombreuses possibilités que
SDN peut apporter à divers domaines et avec plusieurs technologies à savoir virtualisation, Big
data et Opensatck. Le concept SDN pourra aussi résoudre des problèmes réels des réseaux de
production. Par exemple, avec un contrôleur centralisé l’opérateur de télécom peut superviser
son réseau de transport en récoltant l’état du trafic échangé. Ce contrôleur peut aussi signaler
les risques de congestion ce qui aidera à préserver la qualité de service.
83
Annexe A
Mininet et Iperf
Le but de cette annexe et les autres est d’expliquer toutes les opérations et méthodes utilisées
durant nos expériences. Nous notons aussi que toutes les commandes utilisées dans nos expéri-
ences sont uniquement opérationnelles sous le système Linux. Il existe deux façons de configurer
les topologies sous l’émulateur Mininet, soit à travers les lignes de commande CLI ou en utilisant
un code python
A.1 CLI
Pour créer une topologie, nous utilisons la commande :

$ sudo mn –topo linear,3 –switch ovs –controller remote,ip=10.0.0.1
Cette commande crée une topologie de type bus composée par trois switch OVS (Open vSwitch)
où chacun est interconnecté par un hôte. Ce réseau est géré par un contrôleur accessible à dis-
tance à travers l’adresse ip 10.0.0.1.
$ sudo mn –topo linear,3,2 –switch ovs –controller remote,ip=10.0.0.1
La commande crée la même topologie mais avec deux hôtes connectés à chaque switch
$ sudo mn –topo tree,depth=2,fanout=4 –switch ovs –controller remote,ip=10.0.0.1
Cette commande construit une topologie hiérarchique, où le terme ‘depth’ signifie le nombre
de niveaux dans ce cas c’est 2, et ‘fanout’ est le nombre de switchs interconnectés à chaque
switch. Dans notre cas, le nombre total des switches est 5 parce que le 1er switch connecte
quatre switches selon le ‘fanout’ et construit au final deux niveaux de switch. Pour tester la
connectivité entre tous les hôtes de la topologie, nous utilisons la commande :
$ mininet > pingall
Pour vérifier la connectivité entre deux hôtes, il suffit de les appeler par leur nom utilisant la
commande ping, par exemple :
$ mininet > h1 ping h2
Autre méthode de tester la connectivité à travers ping :
$ mininet > h1 xterm
Un nouveau terminal de l’hôte 1 apparaît, et vous pouvez maintenant tester votre connectivité à
travers la commande ping en spécifiant l’adresse de destination :
Rooteval: # ping 10.0.0.2
Pour voir toutes les commandes supportées par Mininet, il faut utiliser la commande help :
$ mininet > help
Pour sortir d’émulateur, vous utilisez la commande ‘exit’.
A.2 Code python des topologies
la deuxième méthode de simuler une topologie est d’utiliser un code python avec les biblio-
thèques de mininet. Cette méthode est la plus utilisée parce qu’il permet de construire d’autres
topologies que bus, tree, ou ring. En dessous un exemple de topologie aléatoire :
#!/usr/bin/python
from mininet.net import Mininet
from mininet.node import Controller, OVSSwitch, RemoteController
from mininet.cli import CLI
from mininet.log import setLogLevel
def myTopo():
”Création d’un topologie en anneau”
net = Mininet( controller=RemoteController, switch=OVSSwitch, build=True )
print ”Network for Multi controllers”
print ”*** Création du contrôleur”
c1 = net.addController( ’c1’, ip=’10.0.0.1’ port=6633 )
print ”*** Création des switches”
s1 = net.addSwitch( ’s1’ )
print ”*** Création des hôtes”
h1=net.addHost (‘h1’)
h3=net.addHost (‘h3’)
85
print ”*** Création des liaisons ”
net.addLink(s1,s2)
net.addLink(s2,s3)
net.addLink(s3,s1)
net.addLink(s1,h1)
net.addLink(s2,h2)
print ”*** Démarrer le réseau network”
net.build()
c1.start()
s1.start( [ c1 ] )
s2.start( [ c1 ] )
s3.start( [ c1 ] )
print ”*** Running CLI”
CLI( net )
print ”*** Stopping network”
net.stop()
if __name__ == ’__main__’:
setLogLevel( ’info’ )
myTopo ()
Ce programme est un script de python qui commence par la déclaration des bibliothèques util-
isées dans le programme, puis déclare une fonction ‘main’ appelée myTopo qui sera exécutée
à la fin du script. Avec ce code, nous avons créé une topologie en anneau composée par trois
switches, où uniquement les switches s1 et s3 sont attachés à des hôtes. Ce réseau est géré par
un contrôleur accessible à l’adresse 10.0.0.1 et au port 6633.
Pour compiler et exécuter cette topologie, nous utilisons la commande suivante
$ sudo chmod a+x myTopo.py
$ sudo ./myTopo.py
Vous pouvez utiliser plusieurs contrôleurs dans le code Mininet :
c1 = net.addController( ’c1’, ip=’10.0.0.1’ port6̄633 )
c2 = net.addController( ’c2’, ip=’10.0.0.2’ port6̄634 )
…
c1.start()
86
c2.start()
Il faut aussi configurer les switches qui appartiennent à chaque contrôleur :
s1.start( [ c1 ] )
s2.start( [ c2 ] )
Les switches peuvent fonctionner sous la direction de deux contrôleurs, un maitre et l’autre
esclave.
s1.start( [ c1,c2 ] )
Pour que les contrôleurs distants soient opérationnels selon ses nouvelles modifications, il faut
les configurer sous les mêmes ports que Mininet.
A.3 Émulation de topologies réelles
Afin de simuler des topologies réelles des réseaux étendus, le site web (topologie zoo) nous four-
nit ces topologies sous la forme d’un fichier d’extension graphtml. Un outil appelé auto-mininet
permet de convertir ces fichiers sous la forme de code python compatible avec Mininet. La com-
mande suivante fait la conversion
$ sudo .GraphML-Topo-to-Mininet-Network-Generator.py -f myTopo.graphtml
Avec myTopo.graphtml est la topologie téléchargée du site web topology zoo et le code GraphML-
Topo-to-Mininet-Network-Generator.py est l’algorithme qui fait la conversion. Cette commande
nous crée un autre fichier python adapté avec les topologies de Mininet sous le nom myTopo.grap-
html-GraphML-Topo-to-Mininet-Network-Generator.py. Nous notons que l’utilisation d’auto-
mininet n’est pas obligatoire pour créer des topologies de grande échelle, mais réduit énormé-
ment le temps de conception des topologies.
A.4 Tests de performances en utilisant l’outil iperf
La commande ping n’est pas la seule utilisée dans les hôtes de Mininet, ces hôtes peuvent exécuter
n’importe quelles commandes ou applications qui sont disponibles sous le système Linux. Iperf
est parmi ces applications qui sont utilisées pour exécuter des tests developpés. L’objectif de ces
tests est d’évaluer la bande passante entre deux ou plusieurs hôtes dont un est spécifié comme
serveur et les autres comme des clients, un exemple de commande iperf :
Serveur : mininet > h1 iperf -s &
Client : mininet> h2 iperf -c h1
87
Annexe B
Exemples de Contrôleurs SDN
Dans cette annexe, nous présentons brièvement les trois contrôleurs que nous avons utilisé dans
nos études à savoir Ryu (chapitre 4), OpenDayLight (chapitre 5) et Floodlight (chapitre 6). Nous
donnons en particulier, les commandes pour l’installation et l’exécution. Nous choisissons trois
contrôleurs parmi les autres, notamment Ryu, Opendaylight et Floodlight.
B.1 Ryu
Ruy est un contrôleur SDN appelé aussi un ‘framework’ SDN fournissant des composants qui
facilitent la gestion des réseaux et la création des applications de contrôle. Ruy est basé sur
Python et supporte la majorité des versions d’OpenFlow.
Pour télécharger et installer le contrôleur :
% git clone git://github.com/osgr/ryu.git
% cd ryu; python ./setup.py install
Pour démarrer le contrôleur avec l’application de switch:
% cd /home/ryu && ./bin/ryu-manager –verbose ryu/app/simple_switch_13.py
Cette commande démarre le contrôleur et utilise une application de commutation pour transmet-
tre les paquets, la version d’Openflow utilisé est 1.3. Par défaut, le contrôleur fonctionne dans le
port 6633, mais on peut le modifier en utilisant la commande :
% ryu-manager –verbose –ofp-tcp-listen-port 6610 ./ryu/examples/hub.py
Mais il faut que le code mininet soit aussi modifié lors de la déclaration du contrôleur.
% c1 = net.addController( ’c1’, port=6610 )
La modification des ports nous aide à exécuter plusieurs contrôleurs dans la même topologie, ou
chaque ensemble de switch est géré par un contrôleur à travers un port unique.
B.2 Opendaylight
Opendaylight est parmi les contrôleurs les plus utilisés. Il est supporté par une grande com-
munauté, parce qu’il contient des dizaines de services et fonctionnalités. Il est basé sur Java
et supporte le ‘multithreading’ qui améliore les performances. C’est pour ces raisons que nous
l’avons choisi comme contrôleur pour notre deuxième étude. Les commandes ci-dessous com-
plètent et expliquent toutes les étapes que nous avons suivi afin de récupérer les résultats de
simulation.
Pour télécharger et démarrer le contrôleur :
% wget https://nexus.opendaylight.org/content/groups/public/org/opendaylight/integration/distribu-
tion-karaf/0.2.2-Helium-SR2/distribution-karaf-0.2.2-Helium-SR2.tar.gz
% tar xf distribution-karaf-0.2.2-Helium-SR2.tar.gz
% cd distribution-karaf-0.2.2-Helium-SR2
% /̃controller-base/opendaylight> sudo ./run.sh
Pour exécuter le contrôleur en mode cluster, il faut utiliser au minimum deux contrôleurs, et
lors du démarrage du contrôleur toutes les adresses des contrôleurs qui construisent le cluster
doivent être annoncées.
• Contrôleur 1, 10.0.0.1 : % /̃controller-base/opendaylight> sudo ./run.sh -Dsupernodes=10.0.

0.1 [:10.0.0.2]
• Contrôleur 2, 10.0.0.2 : % /̃controller-base/opendaylight> sudo ./run.sh -Dsupernodes=10.0.

0.2 [:10.0.0.1]
En cas d’une modification dans le code du contrôleur, il faut le recompiler en utilisant la com-
mande de ‘Maven’,
% sudo mvn clean install
B.3 Floodlight
Un autre contrôleur également très utilisé par les développeurs SDN est Floodlight. Il est basé
sur Java et supporte la technologie de ‘multithreading’. Nous l’avons choisi comme contrôleur
durant la troisième étude.
Pour installer le contrôleur :
% git clone git://github.com/floodlight/floodlight.git
% cd floodlight
% ant
89
Pour exécuter le contrôleur:
% java -jar target/floodlight.jar
Pour utiliser Floodlight sous eclipse
% ant eclipse
Pour modifier le code, on peut l’importer comme n’importe quel projet java dans Eclipse par
exemple.
90
Liste des Acronymes
ACL Access Control List

AN Active Network
API Application Programming Interface
ATM Asynchrones Transfer Mode
BGP Border Gateway Protocol
CIDC Communication Interface for Distributed Control plane
DCAN Devolved Control of ATM Networks
DFS Distributed Firewall Service
DHT Data Hash Table
DLBS Distributed Load Balancer Service
Dpid Datapath id
DS Differentiated Services
DSL Domain Specific Language
ECN Explicit Congestion Notification
ESP Encrypted Security Payload
FE Forwarding Element
FL Floodlight
ForCES Forwarding and Control Element Separation
FW Firewall
GRE Generic Routing Encapsulation
GSMP General Switch Management Protocol
HAN Home Area Network
ICMP Internet Control Message Protocol
ICO Inter-controller Communication Overhead
IDC International Data Corporation
IETF Internet Engineering Task Force
LB Load Balancing
LFB Logical Function Blocks
LISP Locator/Identifier Separation Protocol
LLDP Link Layer Discovery Protocol
MPLS Multiprotocol Label Switching
NIB Network Information Base
NSSA Non So Stub Area
NTP Network Time Protocol
OAM Operation, Administration and Management
ODL OpenDayLight
OnePK Open Network Environment Platform Kit
ONF Open Network Fundation
ONOS Open Network Operating System
OpenSign Open Signalisation
OSGI Open Services Gateway initiative
OVS Open VSwitch
OXM OpenFlow eXtensible Match
PCE Path Computation Element
PN Programmable Network
QoS Quality of Service
Rest Representational State Transfer
SDC Software Defined Computing
SDN Software Defined Networks
SDNi Software Defined Network interface
SPOF Single Point Of Failure
TCAM Ternary Content Addressable Memory
TLV Type Length Value
VLAN Virtual Local Area Network
VM Virtual Machine
WAN Wide Area Network
92
Référence
[1] A. Basil, B. Vengainathan, V. Manral, M. Tassinari, and S. Banks, ‘Benchmarking Methodol-

ogy for SDN Controller Performance’. [En ligne]. Disponible: https://tools.ietf.org/
html/draft-bhuvan-bmwg-sdn-controller-benchmark-meth-00, 2015.
[2] A. Bianco, R. Birke, L. Giraudo, and M. Palacin, ‘Openflow switching: Data plane perfor-
mance’, IEEE International Conference on Communications (ICC), IEEE xplore, pp. 1–5, 2010.
[3] A. Bradai, K. Singh, T. Ahmed, and T. Rasheed. ”Cellular software defined networking: a
framework”, IEEE Communications Magazine, IEEE CosSoc, 53(6), pp. 36-43, 2015.
[4] A. Demers, D. Greene, C. Hauser, W. Irish et al, ‘Epidemic Algorithms for Replicated Database
Maintenance’, Proceedings of the Sixth Annual ACM Symposium on Principles of Distributed
Computing. Vancouver, Canada, pp. 1–12, 1987.
[5] A. Dixit, F. Hao, S. Mukherjee, T. V. Lakshman, and R. Kompella, ‘Towards an elastic dis-
tributed sdn controller’, Proceedings of the second ACM SIGCOMM workshop on Hot topics in
software defined networking. New York, NY, USA: ACM, pp. 7–12, 2013.
[6] A. Doria, F. Hellstrand, K. Sundell, and T. Worster, “General Switch Management Protocol
(GSMP) V3. RFC 3292 (Proposed Standard)”, 2002.
[7] A. Freier, P. Kocher, and P. Karlton, ‘The SSL Protocol Version 3.0’, [En ligne]. Disponible:
https://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00,1996.
[8] A. Hussein, I.H Elhajj, A. Chehab, and A. Kayssi. ”SDN Security Plane: An Architecture for
Resilient Security Services”, IEEE International Conference on Cloud Engineering Workshop
(IC2EW). IEEE xplore, 2016.
[9] A. Rodriguez-Natal, S. Barkai, V. Ermagan, D. Lewis, F. Maino, and D. Farinacci. “Soft-

ware Defined Networking extensions for the Locator/ID Separation Protocol”, [En ligne].
Disponible: https://tools.ietf.org/html/draft-rodrigueznatal-lisp-sdn-00,
2014.
[10] A. Shalimov, D. Zuikov, D. Zimarina, V. Pashkov, and R. Smeliansky, ‘Advanced Study of

SDN/OpenFlow Controllers’, Proceedings of the 9th Central & Eastern European Software En-
gineering Conference in Russia. ACM SIGSOFT, Moscow, Russian Federation, pp. 1–6, 2013.
[11] A. Sivaraman, K. Winstein, S. Subramanian, and H. Balakrishnan, ‘No Silver Bullet: Ex-
tending SDN to the Data Plane’, Proceedings of the Twelfth ACM Workshop on Hot Topics in
Networks, ACM, pp. 1–7, 2013.
[12] A. Tootoonchian and Y. Ganjali, ‘HyperFlow: A distributed control plane for OpenFlow’,
Proceedings of the internet network management conference on Research on enterprise network-
ing. Berkeley, CA, USA, pp. 3–3, 2010.
[13] A. Tootoonchian, S. Gorbunov, Y. Ganjali, M. Casado, and R. Sherwood, “On controller per-
formance in software-defined networks”, Workshop on Hot Topics in Management of Internet,
Cloud, and Enterprise Networks and Services Hot-ICE,USENIX, 2012.
[14] A. Voellmy and J. Wang, “Scalable Software Defined Network Controllers”, Proceedings of
the ACM SIGCOMM Conference on Applications, Technologies, Architectures, and Protocols for
Computer Communication. New York, NY, USA: ACM, pp. 289–290, 2012.
[15] A. Voellmy and P. Hudak, “Nettle: Taking the Sting Out of Programming Network Routers”,
Practical Aspects of Declarative Languages, Lecture Notes in Computer Science, pp. 235–249,
2011.
[16] A. Greenberg, G. Hjalmtysson, D.A. Maltz, A. Myers, J. Rexford, G. Xie, H. Yan, J. Zhan
et H. Zhang, “A Clean Slate 4D Approach to Network Control and Management”, ACM
SIGCOMM Computer Communication Review, 35(5), pp. 41–54, 2005.
[17] A.A. Dixit, F. Hao, S. Mukherjee, et al, ’Elasticon: an elastic distributed sdn controller’,
Proceedings of the tenth ACM/IEEE symposium on Architectures for networking and communi-
cations systems. New York, NY, USA: ACM, pp. 17-28, 2014.
[18] Akka : Build powerful concurrent & distributed applications more easily. [En ligne].
Disponible: http://akka.io/, 2016.
[19] B. A. Nunes, M. Mendonca, X.-N. Nguyen, et al, ‘A survey of software-defined network-

ing: Past, present, and future of programmable networks’, IEEE Communication Survey and
Tutorial, 16(3), pp. 1617–1634, 2014.
[20] B. Heller, R. Sherwood, and N. McKeown, ‘The controller placement problem’, Proceedings
of the first workshop on Hot topics in software defined networks,ACM, pp. 7–12, 2012.
[21] B. Lantz, B. Heller, and N. McKeown, ‘A Network in a Laptop: Rapid Prototyping for
Software-defined Networks’, Proceedings of the 9th Workshop on Hot Topics in Networks,ACM
SIGCOMM, pp. 1–6, 2010.
[22] B. Schwartz, A. W. Jackson, W. T. Strayer, W. Zhou, R. D. Rockwell, and C. Partridge, “Smart

Packets for active networks”, IEEE Second Conference on Open Architectures and Network Pro-
gramming Proceedings OPENARCH ’99, IEEE xplore, pp. 90–97, 1999.
94
[23] C. Rotsos, N. Sarrar, S. Uhlig, R. Sherwood, et al, ‘OFLOPS: An Open Framework for Open-
Flow Switch Evaluation’, Passive and Active Measurement, Springer Berlin Heidelberg, Lecture
Notes in Computer Science, pp. 85–95, 2012.
[24] Cisco Application Policy Infrastructure Controller (APIC). [En ligne]. Disponible:
http://www.cisco.com/c/en/us/products/cloud-systems-management/
application-policy-infrastructure-controller-apic/index.html, 2016.
[25] Cisco’s One Platform Kit (onePK), [En ligne]. Disponible: http://www.cisco.com/web/
IN/solutions/trends/sdn/index.html, 2016.
[26] Contrail Open SDN NFV & Cloud Solutions – Juniper Networks, [En ligne]. Disponible:
http://www.juniper.net/us/en/products-services/sdn/contrail, 2016.
[27] D. Drutskoy, E. Keller, and J. Rexford, ‘Scalable Network Virtualization in Software-Defined

Networks’, IEEE Internet Computer, IEEE xplore, 17(2), pp. 20–27, 2013.
[28] D. Erickson, “The Beacon Openflow Controller”, Proceedings of the Second ACM SIGCOMM
Workshop on Hot Topics in Software Defined Networking. New York, NY, USA: ACM, pp. 13–18,
2013
[29] D. Hock, M. Hartmann, S. Gebert, et al., ‘Pareto-optimal resilient controller placement in

SDN-based core networks’, 25th International Teletraffic Congress (ITC),IEEE xplore, pp. 1–9,
2013.
[30] D. Hock, S. Gebert, M. Hartmann, et al. ’POCO-framework for Pareto-optimal resilient con-
troller placement in SDN-based core networks’, IEEE Network Operations and Management
Symposium (NOMS), IEEE xplore, pp. 1-2, 2014.
[31] D. J. Wetherall, J. V. Guttag, and D. L. Tennenhouse, “ANTS: a toolkit for building and
dynamically deploying network protocols”, IEEE Open Architectures and Network Program-
ming,IEEE xplore, pp. 117–129, 1998.
[32] D. Levin, A. Wundsam, B. Heller et al, ‘Logically centralized?: state distribution trade-offs
in software defined networks’, Proceedings of the first workshop on Hot topics in software
defined networks. New York, NY, USA: ACM, pp. 1–6, 2012.
[33] D. S. Alexander, W. A. Arbaugh, M. W. Hicks, P. Kakkar, A. D. Keromytis, J. T. Moore, C. A.

Gunter, S. M. Nettles, and J. M. Smith, “The SwitchWare active network architecture”, IEEE
Network, IEEE xplore, 12(3), pp. 29–36, 1998.
[34] A.T. Campbell, H.G. De Meer, M.E. Kounavis, K. Miki, B.J. Vicente et D. Villela, “A survey
of Programmable Networks”, SIGCOMM Computer. Communication Review, 29(2), pp. 7–23,
1999.
95
[35] D. Kreutz, F.M.V. Ramos, P.E. Verissimo, C.E. Rothenberg, S. Azodolmolky et S. Uh-
lig, “Software-defined networking: A comprehensive survey”, Proceedings of the IEEE,IEEE
xplore, 103(1), pp. 14–76, 2015.
[36] Devolved Control of ATM Networks, [En ligne]. Disponible: https://www.cl.cam.ac.

uk/research/srg/netos/projects/archive/dcan/, 2016.
[37] A.T. Campbell, I. Katzela, K. Miki et J. Vicente, “Open Signaling for ATM, Internet and
Mobile Networks (OPENSIG’98)”, SIGCOMM Computer Communication Review, 29(1), pp. 97–
108, 1999.
[38] Ericsson mobility report. [En ligne]. Disponible : https://www.ericsson.com/res/

docs/2016/ericsson-mobility-report-2016.pdf, 2016.
[39] EstiNet – version 9. [En ligne]. Disponible: www.estinet.com, 2016.
[40] F. Benamrane, M. Ben Mamoun, and R. Benaini, ”An East-West interface for distributed
SDN control plane: Implementation and evaluation”, Computers & Electrical Engineering, 57,
pp. 162-175, 2017.
[41] F. Benamrane, M. Ben Mamoun, and R. Benaini, ”New Method for Controller-to-Controller
Communication in Distributed SDN Architecture”, International Journal of Communication
Networks and Distributed Systems, 2016.
[42] F. Ros, and P. Ruiz, ’Five Nines of Southbound Reliability in Software Defined Networks’,
Proceedings of the ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking
(HotSDN 2014). New York, NY, USA: ACM, pp. 31–36, 2014.
[43] F. Benamrane et M. Ben Mamoun, “Software Defined Networks : Etat de l’art”, Proceedings
de la 2ème Edition des Journées Doctorales en Systèmes d’Information, Réseaux et Télécommu-
nications JDSIRT’13, pp. 188–192, 2013.
[44] F. Benamrane, F.J. Ros et M. Ben Mamoun, “Synchronisation cost of multi-controller de-
ployments in software-defined networks”, International Journal of High Performance Com-
puting and Networking, 9(4), pp. 291–298, 2016.
[45] F. Benamrane, M. Ben Mamoun et R. Benaini, “Performances of OpenFlow-based software-

defined networks: an overview”, Journal of Networks,10(6), pp. 329–337, 2015.
[46] F. Benamrane, M. Ben Mamoun et R. Benaini, “Short: A case study of the performance of an
openflow controller”, Proceedings of 2th edition of the international Conference on NETworked
sYStems (NETYS), pp. 330–334, 2014.
[47] F.J. Ros et P.M. Ruiz. ‘On reliable controller placements in software-defined networks’. Com-
puter Communications, sciencedirect, 77, pp. 41-51, 2016.
96
[48] Facebook statistics, [En ligne]. Disponible: https://zephoria.com/
top-15-valuable-facebook-statistics/, 2016.
[49] Floodlight OpenFlow Controller. [En ligne]. Disponible: http://www.

projectfloodlight.org/floodlight/, 2016.
[50] Forwarding and Control Element Separation (ForCES) Forwarding Element Model,RFC
3746, April, 2004. [En ligne]. Disponible: https://tools.ietf.org/html/rfc5812, 2010.
[51] G. A. Covington, J. Naous, D. Erickson, and N. Mckeown, “Implementing an OpenFlow

Switch on the NetFPGA platform”, Proceedings of the 4th ACM/IEEE Symposium on Architec-
tures for Networking and Communications Systems. ser. ANCS ’08. New York, NY, USA: ACM,
pp. 1-9. 2008.
[52] G. Lu, R. Miao, Y. Xiong, and C. Guo, ‘Using CPU As a Traffic Co-processing Unit in Com-
modity Switches’, Proceedings of the First Workshop on Hot Topics in Software Defined Net-
works. New York, NY, USA: ACM, pp. 31–36, 2012.
[53] GENI : exploring networks of the future. [En ligne]. Disponible: http://www.geni.net/,
2016.
[54] Global Mobile Data Traffic Forecast Update, 2015-2020’ ,Cisco Visual Networking In-
dex, White Paper, Cisco, [En ligne]. Disponible: http://www.cisco.com/c/en/us/
solutions/collateral/service-provider/visual-networking-index-vni/
mobile-white-paper-c11-520862.html, 2016.
[55] GNS3 : The software that empowers network professionals. [En ligne]. Disponible: https:
//www.gns3.com/, 2016.
[56] H. Harai, ‘Designing New-Generation Network: Overview of AKARI Architecture Design’,

2009.
[57] HP Virtual Application Networks (VAN) SDN Controller. [En ligne]. Disponible: http:
//h17007.www1.hp.com/us/en/networking/products/network-management/HP_
VAN_SDN_Controller_Software/index.aspx?jumpid=reg_r1002_usen_c-001_
title_r0001#.Vzho_eRvDqk, 2016.
[58] I. Owens and A. Durresi, ”Video over Software-Defined Networking (VSDN)”, 16th Inter-
national Conference on Network-Based Information Systems (NBiS), Sciencedirect, pp. 44-51,
2013.
[59] I.F Akyildiz, P. Wang, and S. Lin. ”SoftAir: A software defined networking architecture for
5G wireless systems”, Computer Networks, 85, pp. 1-18, 2015.
[60] Indigo: Open source OpenFlow Switches. [En ligne]. Disponible: https://github.com/
floodlight/ivs, 2016.
97
[61] Inter-SDN Controller Communication-Using Border Gateway Protocol TCS. [En
ligne]. Disponible: http://www.tcs.com/resources/white_papers/Pages/
InterSDN-Controller-Communication.aspx, 2016.
[62] iPerf - The TCP, UDP and SCTP network bandwidth measurement tool. [En ligne].
Disponible: https://iperf.fr/, 2016.
[63] J. C. Mogul and P. Congdon, ‘Hey, You Darned Counters!: Get off My ASIC!’, Proceedings
of the First Workshop on Hot Topics in Software Defined Networks. New York, NY, USA: ACM,
pp. 25–30, 2012.
[64] J. Stribling, Y. Sovran, I. Zhang, X. Pretzer, J. Li, M. F. Kaashoek, and R. Morris, ‘Flexible,
Wide-area Storage for Distributed Systems with WheelFS’, Proceedings of the 6th Symposium
on Networked Systems Design and Implementation. NSDI’09, USENIX, pp. 43–58, 2009.
[65] Jain, Sushant, et al. ”B4: Experience with a globally-deployed software defined WAN”, ACM
SIGCOMM Computer Communication Review, 43(4), pp. 3-14, 2013.
[66] K. Jeong, J. Kim, and Y.-T. Kim, “QoS-aware Network Operating System for software de-
fined networking with Generalized OpenFlows”, IEEE Network Operations and Management
Symposium NOMS,IEEE xplore, pp. 1167–1174, 2012.
[67] K. Mahmood, A. Chilwan, O. N. Østerbø, and M. Jarschel, ‘On The Modeling of OpenFlow-
based SDNs: The Single Node Case’, Proceedings of Computer Science and Information Tech-
nology (CS & IT), Cornell University, 4, pp. 207–217, 2014.
[68] K. Phemius, M. Bouet, and J. Leguay, ‘DISCO: Distributed multi-domain SDN controllers’,
IEEE Network Operations and Management Symposium (NOMS), IEEE xplore, pp. 1–4, 2014.
[69] L. Cui, F. R. Yu, and Q. Yan. ”When big data meets software-defined networking: SDN for
big data and big data for SDN”, IEEE Network, 30(1), pp.58-65, 2016.
[70] M. Campanella and F. Farina, ‘The FEDERICA infrastructure and experience’, Computer.
Network, 61, pp. 176–183, 2014.
[71] M. Casado, M. J. Freedman, J. Pettit, J. Luo, N. McKeown et S. Shenker, “Ethane: Taking

Control of the Enterprise”, Proceedings of the Conference on Applications, Technologies, Archi-
tectures, and Protocols for Computer Communications, pp. 1–12, 2007.
[72] D. Tennenhouse et D. Wetherall, “Towards an active network architecture”, ACM Computer

Communication Review, 26(2), pp. 5–17, 1996.
[73] M. Jarschel, F. Lehrieder, Z. Magyari, and R. Pries, ‘A Flexible OpenFlow-Controller Bench-

mark’, European Workshop on Software Defined Networking, pp. 48–53, 2012.
[74] M. Masse, ‘REST API Design Rulebook’, 1 edition, O’Reilly Media, 2011.
98
[75] M. Qilin and S. Weikang, ‘A Load Balancing Method Based on SDN’, Seventh International
Conference on Measuring Technology and Mechatronics Automation. IEEE, pp. 18–21, 2015.
[76] M. Yu, L. Jose, and R. Miao, ‘Software Defined Traffic Measurement with OpenSketch’, 10th
Symposium on Networked Systems Design and Implementation (NSDI 13),USENIX, pp. 29–42,
2013.
[77] Maestro, [En ligne]. Disponible: http://zhengcai.github.io/maestro-platform/,

2016.
[78] N. Gude, T. Koponen, J. Pettit, B. Pfaff, M. Casado, N. McKeown et S. Shenker, “NOX: To-
wards an Operating System for Networks”, ACM SIGCOMM Computer Communication Re-
view, 38(3), pp. 105–110, 2008.
[79] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker,

and J. Turner, “OpenFlow: Enabling Innovation in Campus Networks”, ACM SIGCOMM
Computer Communication Review, vol. 38, no. 2, pp. 69–74, 2008.
[80] N. Feamster, J. Rexford et E. Zegura, “The Road to SDN: An Intellectual History of Pro-
grammable Networks”, ACM SIGCOMM Computer Communication Review, 44(2), pp. 87–98,
2014.
[81] NEC ProgrammableFlow PF6800 Controller. [En ligne]. Disponible: https://www.necam.

com/sdn/Software/SDNController/, 2016.
[82] Netty: an asynchronous event-driven network application framework, [En ligne].

Disponible: http://netty.io/, 2016.
[83] Network Virtualization with VMware NSX Virtualized Network. [En ligne]. Disponible:
https://www.vmware.com/products/nsx, 2016.
[84] Networking Scale. [En ligne]. Disponible: https://code.facebook.com/posts/

1036362693099725/networking-scale-may-2016-recap/, 2016.
[85] Nicira Networks, [En ligne]. Disponible: http://www.nicira.com, 2016.
[86] O. R. EHIMEN and I. OYAKHILOME, ‘Development of a Software Based Firewall System

for Computer Network Traffic Control’, Leonardo Electron. J. Practice Technologie, 15(2), pp.
75–80, 2009.
[87] Ofelia : OpenFlow test facility in Europe. [En ligne]. Disponible: http://www.
fp7-ofelia.eu, 2016.
[88] Omnet++: Discrete Event Simulator. [En ligne]. Disponible: https://www3.informatik.

uni-wuerzburg.de/research/ngn/openflow.shtml, 2016.
99
[89] Open vSwitch. [En ligne]. Disponible: http://openvswitch.org/, 2016.
[90] OpenDaylight: A Linux Foundation Collaborative Project. [En ligne]. Disponible: http:
//www.opendaylight.org/, 2016.
[91] OpenFlow Management and Configuration Protocol OF-CONFIG 1.2. [En ligne].
Disponible: https://www.opennetworking.org/images/stories/downloads/
sdn-resources/onf-specifications/openflow-config/of-config-1.2.pdf,
2014.
[92] OpenFlow Switch Consortium and Others. OpenFlow Switch Specification

Version 1.5.0, [En ligne]. Disponible: https://www.opennetworking.org/
images/stories/downloads/sdn-resources/onf-specifications/openflow/
openflow-switch-v1.5.0.noipr.pdf, 2014.
[93] OpenFlow Switch Specification Version 0.8.9. [En ligne]. Disponible: http://archive.
openflow.org/documents/openflow-spec-v0.8.9.pdf, 2008.
[94] OpenFlow Switch Specification Version 1.1.0. [En ligne]. Disponible: https:
//www.opennetworking.org/images/stories/downloads/sdn-resources/
onf-specifications/openflow/openflow-spec-v1.1.0.pdf, 2011.
onf-specifications/openflow/openflow-spec-v1.2.pdf, 2011.
[98] Oracle SDN. [En ligne]. Disponible: http://www.oracle.com/us/products/

networking/virtual-networking/sdn/overview/index.html, 2016.
[99] OSGi Alliance – The Dynamic Module System for Java. [En ligne]. Disponible: https:
//www.osgi.org/, 2016.
[100] P. Berde, M. Gerola, J. Hart, Y. Higuchi, et al, ‘ONOS: Towards an Open, Distributed SDN
OS’, Proceedings of the Third Workshop on Hot Topics in Software Defined Networking, ACM
New York, NY, USA, pp. 1–6, 2014.
100
[101] P. Gallo, K. Kosek-Szott, S. Szott, and I. Tinnirello. ”SDNhome: A method for controlling
future wireless home networks”, IEEE Communications Magazine, IEEE xplore, 54(5), pp. 123-
131, 2016.
[102] P. Lin, J. Bi, and Y. Wang, ’WEBridge: west–east bridge for distributed heterogeneous SDN
NOSes peering’, Security and Communication Networks, Wiley, 8(10), pp. 1926-1942, 2015.
[103] P. Porras, S. Shin, V. Yegneswaran, M. Fong, M. Tyson, and G. Gu, “A Security Enforcement
Kernel for OpenFlow Networks”, Proceedings of the First Workshop on Hot Topics in Software
Defined Networks,Sigcomm, pp. 121–126, 2012.
[104] Pantou: OpenFlow 1.0 for OpenWRT. [En ligne]. Disponible: http://archive.
openflow.org/wk/index.php/Pantou_:_OpenFlow_1.0_for_OpenWRT, 2016.
[105] Pica8: PicOs for Open Switches. [En ligne]. Disponible: http://www.pica8.com/, 2016.
[106] POX, [En ligne]. Disponible: https://github.com/noxrepo/pox, 2016.
[107] R. Fielding, “Architectural Styles and the Design of Network-based Software Architec-
tures”, Ph.D. dissertation, UNIVERSITY OF CALIFORNIA, IRVINE, 2000.
[108] R. Neugebauer, “Selective and Transparent Acceleration of OpenFlow Switches”.

Netronome, Tech. Rep, 2013.
[109] R. Sherwood, M. Chan, A. Covington, et al, ‘Carving Research Slices out of Your Production
Networks with OpenFlow’, Computer Communication Review, SIGCOMM, 40(1), pp. 129–130,
2010.
[110] Ryu SDN Framework. [En ligne]. Disponible: http://osrg.github.io/ryu/, 2016.
[111] S. Azodolmolky, R. Nejabati, M. Pazouki, P. Wieder, et al, ‘An analytical model for soft-
ware defined networking: A network calculus-based approach’, IEEE Global Communications
Conference (GLOBECOM), IEEE xplore, pp. 1397–1402, 2013.
[112] S. Hassas Yeganeh and Y. Ganjali, ‘Kandoo: A Framework for Efficient and Scalable Of-
floading of Control Applications’, Proceedings of the First Workshop on Hot Topics in Software
Defined Networks. New York, NY, USA: ACM, pp. 19–24, 2012.
[113] S. Ishii, E. Kawai, T. Takata, Y. Kanaumi, S. Saito, K. Kobayashi, and S. Shimojo, “Extending
the RISE controller for the interconnection of RISE and OS3E/NDDI”, 18th IEEE International
Conference on Networks ICON. IEEE, pp. 243–248, 2012.
[114] SDN Market. [En ligne]. Disponible: https://www.idc.com/getdoc.jsp?

containerId=prUS41005016, 2016.
101
[115] SNAC: Simple Network Access Control, [En ligne]. Disponible: https://github.com/
bigswitch/snac, 2016.
[116] Software-Defined Networking (SDN) Definition, [En ligne]. Disponible: https://www.

opennetworking.org/sdn-resources/sdn-definition, 2016.
[117] T. Koponen, M. Casado, N. Gude, J. Stribling, et al, ‘Onix: A Distributed Control Plat-
form for Large-scale Production Networks’, Operating Systems Design and Implementation
(OSDI’10), Usenix, 10, pp. 1–6, 2010.
[118] T. Lakshman, T. Nandagopal, R. Ramjee, K. Sabnani, and T. Woo, “The softrouter architec-
ture”, Workshop Hot Top Network,ACM SIGCOMM, 2004.
[119] T. R. Henderson, M. Lacage, G. F. Riley, C. Dowell et al, ‘Network simulations with the
ns-3 simulator’, SIGCOMM Demonstration, USA, 14, 2008.
[120] T. Tsou, P. Aranda, H. Xie, R. Sidi, H. Yin, and D. Lopez, “SDNi: A Message Exchange Proto-
col for Software Defined Networks (SDNS) across Multiple Domains”, [En ligne]. Disponible:
https://tools.ietf.org/html/draft-yin-sdn-sdni-00, 2012.
[121] The cost of network downtime for Service Providers, [En ligne]. Disponible: http://www.
noction.com/blog/cost_network_downtime, 2016.
[122] Topology zoo. [En ligne]. Disponible: http://www.topology-zoo.org/, 2016.
[123] Trema controller: Full-Stack OpenFlow Framework in Ruby and C. [En ligne]. Disponible:
https://trema.github.io/trema/, 2016.
[124] V. Tanyingyong, M. Hidell, and P. Sjödin, ‘Improving PC-based OpenFlow Switching Per-
formance’, Proceedings of the 6th ACM/IEEE Symposium on Architectures for Networking and
Communications Systems. New York, NY, USA: ACM, pp. 1–2, 2010.
[125] VirtualBox : open-source hypervisor. [En ligne]. Disponible: https://www.

virtualbox.org/, 2016.
[126] W. Stallings, ‘Network Security Essentials Applications and Standards’, 5 edition, Boston
Pearson, 2013.
[127] W. Xia, Y. Wen, C. H. Foh, D. Niyato, and H. Xie, “A survey on software-defined network-
ing”, IEEE Communications Surveys & Tutorials, 17(1), pp. 27–51, 2014.
[128] Y. HU, W. WANG, X. GONG, X. QUE, and S. CHENG, ‘On the placement of controllers in
software-defined networks’, the Journal. China Universities of Posts and Telecommunications,
19(2), pp. 92–171, 2012.
102
[129] Y. Hu, W. Wendong, X. Gong, X. Que, and C. Shiduan, ‘Reliability-aware controller place-
ment for Software-Defined Networks’, IFIP/IEEE International Symposium on Integrated Net-
work Management (IM 2013), IEEE xplore, pp. 672–675, 2013.
[130] Y. Juba, H.-H. Huang, and K. Kawagoe, ”Dynamic Isolation of Network Devices Using
OpenFlow for Keeping LAN Secure from Intra-LAN Attack”, Procedia computer science, 22,
pp. 810-819, 2013.
[131] Y. Luo, P. Cascon, E. Murray, and J. Ortega, ‘Accelerating OpenFlow Switching with Net-
work Processors’, Proceedings of the 5th ACM/IEEE Symposium on Architectures for Network-
ing and Communications Systems. New York, NY, USA: ACM, pp. 70–71, 2009.
103
View publication stats

These Benamrane

Transféré par

Informations du document

Titre original

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

These Benamrane

Transféré par

Droits d'auteur :

Formats disponibles

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

Etude des Performances des Architectures du Plan de Contrôle des Réseaux

Thesis · January 2017

Fouad Benamrane Mouad Ben Mamoun

SEE PROFILE SEE PROFILE

Congestion management in overlay networks (OrangeLabs) View project

The user has requested enhancement of the downloaded file.

A mes chers parents

2 Software Defined Networking et OpenFlow 6

3 Performances des réseaux SDN basés sur le protocole OpenFlow 24

4 Évaluation des performances du plan de contrôle physiquement centralisé 36

5 Évaluation des performances des architectures du plan de contrôle logiquement cen-

6 Implémentation et évaluation d’une interface Est/Ouest pour un plan de contrôle SDN

B Exemples de Contrôleurs SDN 88

Liste des Acronymes 91

3.1 Architecture distribuée des réseaux SDN . . . . . . . . . . . . . . . . . . . . . . 33

4.1 Topologie linéaire gérée par un contrôleur SDN centralisé . . . . . . . . . . . . 38

5.1 Environnement d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.1 Architecture de l’interface CIDC au sein du contrôleur SDN . . . . . . . . . . . 61

2.1 Caractéristiques des contrôleurs SDN . . . . . . . . . . . . . . . . . . . . . . . . 12

5.1 Topologies évaluées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.1 Topologies considérées dans les tests . . . . . . . . . . . . . . . . . . . . . . . . 71

1.1 Contexte général et objectifs de la thèse

Internet a connu un énorme succès et a transformé le monde en trois décennies seulement en

• Programmer les équipements réseaux à travers des API.

1.3 Organisation du mémoire

Le reste de ce mémoire est organisé en six chapitres :

Software Defined Networking et

2.2 Historique des réseaux SDN

2.3 Software-Defined Networking

2.3.1 Architecture SDN

Traditionnellement, un réseau informatique est composé d’équipements réseau interconnectés

(Applications et service) Couche d’application

Couche de contrôle Couche de contrôle API Nord

(Applications et service) (Applications et service)

API Couche de transmission

(a) Réseau traditionnel (b) Réseau SDN

2.3.2 Interfaces de communications

Figure 2.2: Processus de communication entre les commutateurs et le contrôleur

2.3.2.2 Interfaces Nord

2.3.3 Plan de contrôle

Le rôle du plan de contrôle est de contrôler et de gérer les équipements de l’infrastructure, et de

Table 2.1: Caractéristiques des contrôleurs SDN

• Maestro [77]: utilise la technologie du multithreading pour effectuer le parallélisme au bas

• Opendaylight [90]: est un projet open source implémenté en java et multiplateforme. Il

Table 2.2: Table de flux de commutateur OpenFlow 1.0

2.4.1 Architecture du protocole OpenFlow

Champs d’en-tête Compteurs Actions

2.4.2 Spécifications d’OpenFlow

2.4.2.1 OpenFlow v 1.0

2.4.2.2 OpenFlow v 1.1

Correspondre et Correspondre et Correspondre et

Figure 2.4: Pipeline d’OpenFlow 1.1

Table 2.3: Table de flux pour l’OpenFlow v1.1

Instruction Argument Sémantique

Table 2.4: Liste des instructions pour la version 1.1 d’OpenFlow

Identifiant du groupe Type du groupe Compteurs Liste des actions

Table 2.6: Entrées de la table de mesure OpenFlow 1.3

2.4.2.3 OpenFlow v 1.2

2.4.2.4 OpenFlow v 1.3

2.4.2.5 OpenFlow 1.4

2.4.2.6 OpenFlow 1.5

Figure 2.5: Pipeline d’OpenFlow 1.5