Rapport PFE 2019 Final PDF

2018 - 2019
Conception et implémentation d’une solution

SD-WAN pour le fournisseur Tunisie Télécom
Réalisé par : Hamza Chouchene
Encadrant ESPRIT : Mme Olfa Chabbouh
Encadrant Entreprise : Mme Fatma Ghandour

Nom et prénom Signature
Encadrante académique
Encadrante de l’entreprise
Remerciements
C’est un devoir bien agréable que de venir rendre hommage, au terme de ce travail, à ceux
sans lesquels il n’aurait pas pu être réalisé.
Je tiens à exprimer mes remerciements et ma gratitude à tous ceux qui ont voulu apporter
l’assistance nécessaire au bon déroulement de mon stage
En particulier l’expression de ma très grande reconnaissance à Mme Fatma Ghandour, et

Mme Arwa Chaibi pour l’opportunité qu’elles m’ont offerte pour travailler sur ce projet
intéressant et de me prendre en charge tout au long de la période du stage, pour leur
encadrement, leur disponibilité et pour leur soutien constant qu’elles n’ont cessé de me
prodiguer.
J’adresse, aussi ma gratitude, à mon encadrante académique Mme Olfa Chabbouh pour ses
précieux conseils, son estimable aide, son attention et le suivie qu’elle a apporté à ce travail.
Enfin, mes remerciements vont à tous les enseignants de ESPRIT pour la qualité de la
formation qu’ils nous ont fournie et tous les membres du jury pour avoir accepté de juger ce
travail.
Résumé
Cette étude intitulée "Conception et mise en place d’une architecture SD-WAN pour le
fournisseur de service Tunisie Telecom" s’inscrit dans une stratégie de l’entreprise vers la
virtualisation des services réseau. Ce travail s’inscrit dans le cadre de projet de fin d’études et
consiste à mettre en place une architecture SD-WAN pour le fournisseur de service. Le projet
s’appuie principalement sur quatre volets à savoir : la mise en place d’une architecture Cloud
Privée, la virtualisation des fonctions réseaux dans l’infrastructure Cloud, le contrôle du réseau
à travers un contrôleur SDN, bénéficier d’un contrôle sur ses liaisons à travers le SD-WAN et
le développement d’une application web qui permet au client de gérer sa propre infrastructure.
Une application a été mise en place en utilisant le gestionnaire de ressource cloud OpenStack
et le Framework de développement web Django.
Cette application développée pour le fournisseur de service numérique Tunisie Telecom donne
la possibilité à ses clients d’accéder à ses propres infrastructures virtuelles et les gérer via son
interface portail WEB qui communique avec les services à travers des APIs.
Mots clés: Cloud computing, OpenStack, IAAS, SDN, SD-WAN
Abstract
This study entitled "Design and Implementation of an SD-WAN Architecture for the service
provider Tunisie Telecom "is part of a strategy of the company towards the virtualization of
network services. This work as part of a final project consists of set up an SD-WAN
architecture for the service provider. The project is articulated mainly on four aspects namely
: setting up a Private Cloud architecture, the virtualization of network functions in the cloud
infrastructure, the control of the network to through an SDN controller, take advantage of
innovative services like SD-WAN and the development of a web application that allows the
customer to manage their own infrastructure. An application has been implemented using the
OpenStack Cloud Resource Manager and the web development framework for the Django
python language. This application developed for the digital service provider Tunisie Telecom
gives the possibility to its customers to access its own virtual infrastructures and manage them
via its portal interface WEB that communicates with services through APIs.
Keywords: Cloud computing, OpenStack, IAAS, SDN, SD-WAN
Table des matières
Introduction Générale ............................................................................................................. 1
Chapitre 1 : Cadre du projet .................................................................................................. 3
1. Présentation de l’entreprise d’accueil ............................................................................. 3
2. Présentation générale de Tunisie Telecom ..................................................................... 3
1.1. Les services de Tunisie Telecom ............................................................................. 3
1.2. Organigramme de Tunisie Telecom ........................................................................ 4
3. Présentation du Projet ..................................................................................................... 4
3.1. Le contexte du projet ............................................................................................... 5
3.2. Problématique .......................................................................................................... 6
3.3. Objectifs et fonctionnalités ...................................................................................... 7
4. Méthodologie .................................................................................................................. 8
Chapitre 2 : Etat de l’art ....................................................................................................... 11
1. Le SD-WAN ................................................................................................................. 11
1.1. Introduction ........................................................................................................... 11
1.2. Définition du SD-WAN ......................................................................................... 11
1.3. Choix de la solution utilisée .................................................................................. 12
2. Le Cloud Computing..................................................................................................... 13
2.1. Définition du Cloud Computing ............................................................................ 13
2.2. Le besoin au Cloud Computing ............................................................................. 13
2.3. Les cinq caractéristiques du cloud computing ....................................................... 14
2.4. Les bénéfices du cloud .......................................................................................... 15
2.5. Modèles de services ............................................................................................... 16
2.6. Etude comparative et choix de la solution Cloud .................................................. 19
2.6.1. Solutions open source existantes .................................................................... 19
2.6.2. Architectures et Services ................................................................................ 19

2.6.3. Support de l’hyperviseur ................................................................................ 20
2.6.4. Réseaux .......................................................................................................... 21
2.6.5. Choix de la solution Cloud ............................................................................. 22
2.6.6. Les composants d’OpenStack ........................................................................ 23
3. SDN............................................................................................................................... 28
3.1. Définition du SDN (Software Defined Network) .................................................. 28
3.2. Plan de composition des équipements réseaux ...................................................... 30
3.3. Étude comparative et choix de la solution SDN .................................................... 30
3.3.1. Comparaison des contrôleurs Open-Source ................................................... 31
3.3.2. Solution SDN adoptée .................................................................................... 32
Chapitre 3 : Spécification des besoins et conception .......................................................... 34
1. Identification des besoins .............................................................................................. 34
1.2. Besoins fonctionnels de la solution Cloud ............................................................ 34
1.3. Besoin fonctionnel de la solution SDN ................................................................. 35
1.4. Besoin non fonctionnel .......................................................................................... 35
2. Diagramme des cas d’utilisation ................................................................................... 36
2.1. Diagramme de cas d’utilisation général ................................................................ 36
2.2. Raffinement des cas d’utilisation .......................................................................... 37
3. Diagramme d’activité.................................................................................................... 39
4. Diagramme de séquence système ................................................................................. 41
5. Conception de l’architecture SD-WAN ........................................................................ 44
5.1. Conception de l’architecture d’Openstack ............................................................ 44
5.1.1. Le Network as a Service sur Openstack ......................................................... 44
5.1.1.1. Le Service Réseau Neutron ........................................................................ 44
5.1.1.2. Les agents Neutron ..................................................................................... 45
5.1.2. Les types réseaux virtuels dans Openstack .................................................... 47
5.1.2.1. Réseau Option 1 : réseaux fournisseurs ...................................................... 47

5.1.2.2. Réseau Option 2 : réseaux libre-service ..................................................... 48
5.1.2.3. Choix de l’option réseau ............................................................................. 48
5.2. Les services à virtualiser........................................................................................ 49
6. Intégration du contrôleur SDN opendayligtht dans Openstack .................................... 52
6.1. Le mécanisme d’intégration d’openstack et opendaylight .................................... 52
6.2. Concept du plugin modulaire de Neutron ML2..................................................... 53
6.3. Intégration API Neutron dans Opendaylight ......................................................... 54
Chapitre 4 : Réalisation ......................................................................................................... 55
1. Environnement matériel et logiciel ............................................................................... 55
2. Présentation de la maquette .......................................................................................... 55
3. Mise en place de l’application OpenStack .................................................................... 56
3.1. Architecture logique .............................................................................................. 56
3.2. Préparation d’environnement de travail ................................................................ 57
3.3. Vérification et test de l’application ....................................................................... 58
3.4. Configuration réseau du composant Neutron ........................................................ 60
3.5. Création du routeur virtuel vCPE .......................................................................... 62
3.6. Gestion des groupes de sécurité............................................................................. 63
3.7. Création d’instance ................................................................................................ 64
3.8. Virtualisation des fonctions réseau NATaaS et FWaaS ........................................ 65
4. Mise en place de la solution SD-WAN Contrail ........................................................... 66
4.1. Architecture physique ............................................................................................ 66
4.2. Vérification et test de la solution FWaaS .............................................................. 68
4.3. Vérification et test de la solution SD-WAN .......................................................... 70
5. Réalisation du Portail Client ......................................................................................... 72
5.1. Interface de l’application Web .............................................................................. 72
Conclusion générale ............................................................................................................... 77
Bibliographie ............................................................................................................................. i
Liste des figures
Figure 1. 1: Organigramme de l’entreprise ................................................................................ 4

Figure 1. 2: Architecture d’un CPE traditionnel ........................................................................ 5
Figure 1. 3: CPE virtuel avec ses services hébergés chez le fournisseur ................................... 7
Figure 1. 4: Architecture Logique du SDN ................................................................................ 8
Figure 1. 5: Diagramme du Gantt .............................................................................................. 9
Figure 2. 1: Architecture SD-WAN ......................................................................................... 12

Figure 2. 2: Architecture de la solution Contrail SD-WAN .................................................... 13
Figure 2. 3: Caractéristiques du cloud ..................................................................................... 14
Figure 2. 4: Les différents couches de modèle de service ....................................................... 16
Figure 2. 5: Architecture en couche du cloud .......................................................................... 17
Figure 2. 6: Architecture SaaS ................................................................................................. 17
Figure 2. 7: La chaîne de la plateforme PaaS .......................................................................... 18
Figure 2. 8: Ressources du modèle IaaS .................................................................................. 18
Figure 2. 9: Logo d’OpenStack ................................................................................................ 23
Figure 2. 10: utilisation des solutions cloud open source ........................................................ 23
Figure 2. 11: Architecture-Interactions Nova .......................................................................... 24
Figure 2. 12: Architecture-Interactions de Glance ................................................................... 25
Figure 2. 13: Architecture-Interactions de neutron .................................................................. 26
Figure 2. 14: architecture de Keystone .................................................................................... 27
Figure 2. 15: architecture-Interactions de Cinder .................................................................... 28
Figure 2. 16: Séparation des différents plans ........................................................................... 29
Figure 2. 17: Architecture en couche du SDN ......................................................................... 30
Figure 2. 18: Architecture d’OpenDaylight ............................................................................. 33
Figure 3. 1: Diagramme du cas d’utilisation général des différents acteurs ............................ 36

Figure 3. 2: Diagramme du cas d’utilisation "gérer des projets" ............................................. 37
Figure 3. 3: Diagramme du cas d’utilisation "gérer la liste des images" ................................. 38
Figure 3. 4: Diagramme du cas d’utilisation "gérer utilisateur" .............................................. 38
Figure 3. 5: Diagramme du cas d’utilisation "gérer la liste des services" ............................... 39
Figure 3. 6: Diagramme d’activité du cas d’utilisation "Ajouter une règle firewall" .............. 40
Figure 3. 7: Diagramme d’activité du cas d’utilisation "Ajouter une instance" ...................... 40
Figure 3. 8: Diagramme d’activité du cas d’utilisation "Ajouter un membre" ........................ 41
Figure 3. 9: Diagramme de séquence du cas d’utilisation "S’authentifier" ............................. 41
Figure 3. 10: Diagramme de séquence du cas d’utilisation "Ajouter une instance" ................ 42
Figure 3. 11: Diagramme de séquence du cas d’utilisation "créer une règle de Firewall" ...... 43
Figure 3. 12: architecture de déploiement de neutron.............................................................. 45
Figure 3. 13: Architecture de flux de trafic d’une instance vers le réseau externe .................. 46
Figure 3. 14: Réseau fournisseur : Plan de service .................................................................. 47
Figure 3. 15: Réseau libre-service : Plan de services............................................................... 48
Figure 3. 16: Accès d’une instance à internet .......................................................................... 49
Figure 3. 17:Accès à partir d’internet à une instance............................................................... 50
Figure 3. 18: Flux du trafic entre une instance et le FWaaS .................................................... 51
Figure 3. 19: La communication entre APIs de Openstack et Opendaylight........................... 52
Figure 3. 20: Plugin ML2 du composant neutron .................................................................... 53
Figure 3. 21: Intégration ODL dans Openstack ....................................................................... 54
Figure 4. 1: Architecture de déploiement ............................................................................... 56
Figure 4. 2: Architecture logique d’OVS ................................................................................ 57
Figure 4. 3: Création de Quota ................................................................................................ 58
Figure 4. 4: Création de l’utilisateur personnel ...................................................................... 59
Figure 4. 5: Création de l’utilisateur adm ............................................................................... 59
Figure 4. 6: Affectation du rôle membre à personnel ............................................................. 59
Figure 4. 7: Affectation du rôle Administrateur à adm ........................................................... 59
Figure 4. 8: Création d’un flavor ............................................................................................ 60
Figure 4. 9: Création d’image ................................................................................................. 60
Figure 4. 10: Création du réseau int_net ................................................................................. 61
Figure 4. 11: Création du sous réseau interne "selfservice" ................................................... 61
Figure 4. 12: Création du réseau externe "provider" .............................................................. 62
Figure 4. 13: Création du sous réseau externe "provider" ...................................................... 62
Figure 4. 14: Création du routeur virtuel ................................................................................ 63
Figure 4. 15: Liste des espaces des noms et des ports ............................................................ 63
Figure 4. 16: Création des groupes de sécurité ....................................................................... 64
Figure 4. 17: Vérification et test de la création d’instance du réseau public (réseau
fournisseur) .............................................................................................................................. 64
Figure 4. 18: Création d’une adresse IP flottante ................................................................... 65
Figure 4. 19: Affectation d’adresse IP flottante à l’instance du réseau privé ......................... 65
Figure 4. 20: Vérification de connectivité entre les instances ................................................ 66
Figure 4. 21: Architecture globale de SD-WAN Contrail ...................................................... 66
Figure 4. 22: Attribution des adresses IP du vCPE ................................................................. 67
Figure 4. 23: Identifier le numéro de série du vCPE .............................................................. 67
Figure 4. 24: Ajout d’un vCPE au niveau de l’orchestrateur CSO ......................................... 68
Figure 4. 25: Affectation du numéro de série du vCPE à son image ...................................... 68
Figure 4. 26: script d’auto-installation ZTP............................................................................ 69
Figure 4. 27: Liste des vCPE des différents sites.................................................................... 69
Figure 4. 28: Ajout d’une politique de sécurité du Firewall du vCPE .................................... 70
Figure 4. 29: Liste de règles de filtrage du vCPE ................................................................... 70
Figure 4. 30: Création d’un profile SLA ................................................................................. 71
Figure 4. 31: Déploiement d’une stratégie SD-WAN............................................................. 71
Figure 4. 32: Basculement du trafic entre les 2 liens WAN ................................................... 72
Figure 4. 33: Interface d’authentification ............................................................................... 72
Figure 4. 34: Interface d’acceuil ............................................................................................. 73
Figure 4. 35: Interface de création d’instance ......................................................................... 73
Figure 4. 36: Interface de création d’un utilisateur ................................................................. 74
Figure 4. 37: Interface liste des routeurs virtuels .................................................................... 74
Figure 4. 38: Interface liste des sous-réseaux ......................................................................... 75
Figure 4. 39: Interface liste des floating IPs ........................................................................... 75
Liste des tableaux
Tableau 1. 1: Comparaison entre le réseau traditionnel WAN et le réseau SD-WAN .............. 6
Tableau 2. 1: La différence entre les solutions cloud .............................................................. 20

Tableau 2. 2: Les hyperviseurs supportés par les solutions cloud ........................................... 21
Tableau 2. 3: Comparaison des solutions cloud par fonctionnalité réseau .............................. 22
Tableau 2. 4: Comparaison des contrôleurs open-source ........................................................ 32
Tableau 3. 1: Fonctionnalités des deux versions .................................................................... 52
Tableau 4. 1: L’environnement matériel et logiciel ................................................................ 55

Liste des abréviations
PAAS Platform as a Service

FWaaS Firewall as a Service
NaaS Network as a Service
NATaaS Network Address Translation as a Service
SDN Software Defined Network
SD-WAN Software Defined Wide Area Network
SAAS Software as a Service
MPLS Multiprotocol Label Switching
WAN Wide Area Network
IAAS Infrastructure as a Service
API Application Programming Interface
KVM Kernel-based Virtual Machine
CPE Customer-Premises Equipment
vCPE Virtual customer-premises Equipment
ZTP Zero Touch Provisioning
VxLAN Virtual Extensible LAN
NIST National Institute of Standards and Technology
LBaaS Load Balancing as a Service
ODL Opendaylight
OVSDB Open vSwitch Database
ML2 Modular Layer 2
SLA Service Level Agreement
Introduction générale
Introduction Générale
Les technologies SDN (Software Defined Networks) et NFV (Network Functions

Virtualization) devraient révolutionner à terme les architectures des réseaux des opérateurs, et
permettre de déployer des nouveaux services de manière beaucoup plus rapide et avec des
coûts significativement réduits. Elles changeront complètement l’écosystème des
infrastructures de Télécommunication dans les années à venir.
La Virtualisation des fonctions Réseaux (Network Functions Virtualisation) est un élément
déterminant pour optimiser l’utilisation des ressources du réseau en virtualisant des fonctions
habituellement mises en œuvre dans le matériel propriétaire, réduisant ainsi pour les opérateurs
les coûts d’investissement et d’exploitation.
Dans un monde qui tourne autour du Web, les utilisateurs finaux demandent et attendent
davantage de personnalisation et de contrôle de leurs environnements de services. Ils
souhaitent pouvoir accéder à leurs services réseau (qu’il s’agisse de routage dynamique
spécifique aux applications ou de fonctions de sécurité avancées) par le biais d’un portail afin
d’ajouter, de supprimer ou de modifier ces services à la demande, mais aussi disposer d’une
distribution rapide.
En d’autres termes, les utilisateurs finaux veulent bénéficier d’un contrôle total de leurs
services réseau, sans compromis en termes de simplicité et de fiabilité.
Le problème pour ces clients est la complexité des CPE car il est difficile de les adapter à
l’évolution technologique des services réseaux virtualisés et ils ne sont pas flexible dans le cas
de déploiement de nouveaux services de façon simple et rapide, en plus, il nécessite toujours
une intervention humaine pour les dépanner ou les entretenir.
Pour répondre à cette problématique, l’objectif de ce projet consiste à implémenter une
architecture réseau basée sur la virtualisation des composantes du réseau CPE ( Customer
Promise Equipement)tels que NAT, le filtrage de trafic par un firewall aussi le DNS,
équilibrage de charge, ce qui constitue un avantage certain pour répondre aux défis actuels, le
contrôle automatisé des liaisons de connexion WAN de l’entreprise afin d’assurer une
continuité des services et une bonne qualité de service des liaisons (MPLS,xDSL,4G).
Le présent rapport se compose de quatre chapitres. Le premier chapitre introduit le cadre
général de ce projet, une présentation de l’organisme d’accueil, le contexte du projet et la
problématique afin de décrire la solution et les objectifs à accomplir pour répondre à aux
besoins de l’entreprise.
Hamza Chouchene 2018/2019 1

Introduction générale
Le deuxième chapitre intitulé état de l’art, décrit les différentes technologies utilisées dans
notre projet comme le Cloud Computing en spécifiant ses caractéristiques, ses modèles de
services et déploiement et les solutions Open source existantes. Par la suite, nous allons décrire
la solution Openstack, son architecture, ses services et ses composants. Nous allons aussi
présenter dans ce chapitre la technologie réseau SDN son principe, son architecture et les
solutions Open Source existantes afin de choisir la solution qui répond à nos besoins. Enfin,
nous allons expliquer le SD-WAN.
Le troisième chapitre nommé spécification des besoins et conception sert à annoncer les
besoins fonctionnels et non fonctionnels auxquels doit répondre notre projet, ainsi que la
conception de la solution Cloud et SDN à déployer.
Le dernier chapitre sera dédié pour la réalisation, nous allons présenter la mise en œuvre de
l’architecture SD-WAN avec tous ces composants (solution cloud et solution SDN). Puis, nous
allons introduire l’étape de l’implémentions de notre solution ainsi que les tests effectués, les
résultats obtenus et les différentes interfaces de l’application client que nous avons développé.
Ce rapport sera clôturé par une conclusion générale et quelques perspectives pour notre projet.

Chapitre 1 : Cadre du projet
Introduction
Ce premier chapitre introduit le cadre général de ce projet. Nous présentons dans une première
partie l’organisme d’accueil : Tunisie Télécom. Nous décrivons dans une deuxième partie le
contexte de notre projet ainsi que la problématique et les objectifs à atteindre, afin de trouver
les différentes solutions et démarche qui seront abordées.
1. Présentation de l’entreprise d’accueil

Ce premier chapitre consiste à présenter l’entreprise TUNISIE TELECOM, ainsi qu’une
description brève de notre projet, ensuite nous expliquons le contexte de notre projet, les
fonctionnalités et les objectifs à accomplir.
2. Présentation générale de Tunisie Telecom

Tunisie Télécom (TT) est le nom commercial de l’Office National des Télécommunications.
Depuis sa création, Tunisie Telecom cherche à renforcer l’infrastructure des télécoms en
Tunisie, à améliorer le taux de couverture et à augmenter sa compétitivité.
Elle participe activement à la promotion de l’usage des TIC et au développement des sociétés
innovantes dans le domaine des télécommunications.
Leadeur du marché des télécoms en Tunisie, Tunisie Telecom a doté un ensemble de normes
qui met le client au-dessus de ses priorités. L’adoption de ces valeurs se traduit en particulier
par le suivi continu des standards de l’entreprise et l’amélioration de la qualité des services.
Tunisie Telecom compte dans ses rangs plus de six millions d’abonnés dans la téléphonie fixe
et mobile. Elle est constituée d’une trentaine de directions régionales et de plus de quinze mille
points de vente privés et elle embauche plus de dix mille collaborateurs.
1.1. Les services de Tunisie Telecom
En tant que l’opérateur historique, Tunisie Telecom est chargé de :
❖ L’implémentation, l’exploitation et l’entretien des réseaux publics de
télécommunications.
❖ L’offre de tous les services publics ou privés de télécommunications correspondants
aux divers besoins à caractères social et économique.
❖ Le développement des nouveaux services de télécommunications.
❖ La contribution au développement des études et des recherches scientifiques liées au
secteur des télécommunications.

❖ La participation dans la recherche pour l’enseignement supérieur en matière

télécommunications.
1.2. Organigramme de Tunisie Telecom
L’organisme administratif de Tunisie Telecom se présente sous la forme d’un ensemble de dix
directions centrales, chacune d’elles est rattachée un ensemble de tâches Figure 1.1.
Pour cette raison que la majorité des directions centrales se sont subdivisées en un ensemble
de sous directions ou départements responsables à des tâches bien spécifiques.
Notre stage a été effectué au sein de la Direction de planification et ingénierie dans le local
Testbed situé au Berges du Lac. Cette direction est spécialisée dans la recherche, la
planification, la conception et le test des nouvelles technologies qui sont nécessaires au
fonctionnement des différents services de la compagnie. De plus, elle est responsable de la
collaboration avec les autres directions responsable à la maintenance et l’exploitation de
l’infrastructure de réseau distribuées en Tunisie avec les clients de Tunisie Télécom.
3. Présentation du Projet
Dans cette partie nous exposons en premier lieu le contexte général du projet. Puis, nous
indiquons la problématique ainsi que les objectifs visés par la réalisation de la solution
demandée. La figure 1.1 représente l’organigramme de l’entreprise
Figure 1. 1: Organigramme de l’entreprise

3.1. Le contexte du projet

Tunisie Telecom déploie actuellement, différentes technologies et services au niveau du WAN,
LAN, des équipements CPE (Customer Premise Equipment), Firewall, des service réseaux
dédiés pour satisfaire les besoins des abonnés.
Ces CPE sont déployés au niveau du site client, pour lui permettre de se connecter à travers le
réseau MPLS à d’autres sites ou vers d’autre technologie du réseau internet (xDSL,4G).
Les CPE traditionnels (Figure 1.2) présentent, aujourd’hui, un inconvénient majeur qui est la
difficulté de l’adapter avec le changement technologique. Le CPE est le point de frontière entre
le site du réseau client au réseau du fournisseur de services.
Figure 1. 2: Architecture d’un CPE traditionnel
L’augmentation des supports quels qu’ils soient dans l’entreprise rend les environnements
réseaux de plus en plus complexe.
Il faut prendre compte aussi que dans les architectures traditionnelles, de nombreux
équipements additionnels doivent être mise en place lorsque de nouveaux services (Load
balancer, Firewall, IPSEC/VPN, IPS...) sont implémentés.
Le maintien des CPE traditionnels au niveau des sites clients devient alors de plus en plus
difficile et coûteux.
Dans la démarche de réduire la complexité, la rigidité, les coûts de la technologie MPLS et
d’améliorer la performance des applications, le SD-WAN (Software-Defined WAN) permet
aux entreprises de construire et de déployer les nouvelles infrastructures WAN hybrides qui
combinent l’utilisation de différents liens (MPLS, internet) de façon optimale.

Tableau 1. 1: Comparaison entre le réseau traditionnel WAN et le réseau SD-WAN
Fonctionnalités Traditionnel WAN SD-WAN

Overlay MPLS VXLAN GRE IPSEC DMVPN
Networks
Topologie Traditionnel Control centralisé & topologie distribuée
Infrastructure Complexe Simple
Sécurité Elevée Très Elevée
Fiabilité Bien Excellente

Automatisation Non Oui
Performance Elevée Très Elevée
Routage Traditionnel Protocol désigné pour le flux
basé sur la gestion du trafic
Bande passante Chère Bas Prix
Modèle CPE intégré verticalement Déployé en x86 virtualisé
Hardware
Analytiques Non Oui
Service Chaning Capacité limitée Capacité Native
Architecture Service limité à la portée Rx Transport model & service découplé
Model
3.2. Problématique
Les CPE traditionnels sont complexes et l’implémentation de nouveaux services nécessite
généralement l’installation de périphériques supplémentaires, afin de déployer ces services
(Firewall, Load-balancer, VPN...), parfois on est dans l’obligation de remplacer un CPE
existant.
Certainement, la complexité des CPE n’est pas la solution, car ils présentent plusieurs
problèmes parmi lesquels nous citons :
• L’adaptation difficile à l’évolution et changement technologique.
• La rigidité et le manque de flexibilité lorsqu’il s’agit de déployer de nouveaux services
de façon rapide et simple.

• La difficulté du dépannage et de l’entretien car ils nécessitent une intervention humaine

manuelle fréquemment faite équipement par équipement.
3.3. Objectifs et fonctionnalités
Notre objectif est d’implémenter une architecture réseau SD-WAN basée sur la virtualisation
des composants et fonctionnalités du réseau et le contrôle des liaisons WAN, ce qui constitue
un avantage certain pour répondre aux défis actuels. Notre projet est basé sur la virtualisation
des services des CPE en utilisant une solution cloud Open-Source, ainsi qu’un contrôleur SDN
qui va gérer la couche de niveau 2 et la mise en place d’une solution SD-WAN qui sécurise et
contrôle la qualité du trafic.
Figure 1. 3: CPE virtuel avec ses services hébergés chez le fournisseur
La Virtualisation de CPE vise à fournir le matériel minimum requis sur le site du client et à
déplacer la charge du travail du CPE traditionnelles vers le réseau de l’opérateur (Figure 1.3).
Les services virtualisés sont hébergés sur le site de l’opérateur qui dispose des outils centralisés
nécessaires, les instances virtuelles telles que les fonctions réseau virtualisées (VNF) sont
orchestrées par l’orchestrateur NFV et l’infrastructure du réseau est contrôlé et géré par le
contrôleur SDN, qui applique la stratégie globale du réseau, les valeurs ajoutées de cette
solution SDN sont :
❖ Le gain en terme du coût pour les clients et pour les opérateurs aussi puisque la
virtualisation permettre de réduire les frais d’opération réelles ainsi que les frais de
support et de déploiement du matériel.
❖ La facilité de déploiement : dans le cas des services directement disponibles chez les
fournisseurs, les clients pourront facilement les déployer s’ils les souhaitent.

❖ La rapidité : La manœuvre via un portail self-service ne devrait prendre que quelques

minutes.
Le Software Defined Network (SDN) est un principe d’architecture des fonctions réseau et des
systèmes qui les pilotent, qui facilite la gestion de ces fonctions réseau virtualisées permettant
de mettre en œuvre des architectures dynamiques et scalables.
IL repose sur le principe de la séparation physique du plan de contrôle et du plan
d’acheminement du réseau, avec un contrôle de plusieurs équipements par le plan de contrôle.
Le principe du SDN est donc de remplacer les routeurs et les commutateurs des niveau 1 à 4
par une machine physique dont le traitement des flux IP est modifié en temps réel par un outil
de contrôle, appelée contrôleur SDN.
La couche de contrôle a pour rôle d’implémenter des instructions sur le commutateur SDN.
Les instructions peuvent concerner des affectations de VLANs (port d’accès), du routage et
des traitements spécifiques de services réseaux (équilibrage de charge, haute disponibilité,
QoS).
Ainsi, l’architecture SDN est basée sur l’évolution de l’architecture illustrée par la figure 1.4 :
Figure 1. 4: Architecture Logique du SDN
4. Méthodologie
Après une étude sur les méthodes d’analyse et selon ls type du projet et ses spécificités, nous
avons choisi comme une démarche qui répond à notre besoin fonctionnel la méthode 2TUP
qui est un processus de développement logiciel qui implémente le Processus Unifié.
Le 2TUP propose un cycle de développement en Y qui sépare les aspects techniques des
aspects fonctionnels. Il commence par une étude préliminaire qui consiste principalement à
dégager les acteurs qui vont interagir avec le système à construire, les messages échangés entre
les acteurs et le système, à produire le cahier des charges et à modéliser le contexte (le système

est une boîte noire, les acteurs l’entourent et sont reliés à lui, sur l’axe qui lie un acteur au
système on met les messages que les deux s’échangent avec le sens).
Le processus est l’enchaînement de trois phases essentielles.
❖ Une branche fonctionnelle : c’est la partie analyse et l’étude de l’application.
❖ Une branche technique : c’est la partie d’étude d’implémentation (architecture
technique).
❖ Une phase de réalisation : conception et implémentation.
La branche fonctionnelle se charge de la connaissance du métier de l’entreprise. Cette branche
capture des besoins fonctionnels, ce qui produit un modèle focalisé sur le métier des utilisateurs
finaux.
La branche technique se charge des pratiques et/ou des contraintes techniques.
Les techniques développées pour le système sont indépendantes des fonctions à réaliser.
La figure 1.5 présente la répartition des différentes tâches de projet sur la période de réalisation
du projet.
Figure 1. 5: Diagramme du Gantt
La phase de réalisation consiste à réunir les deux branches, permettant de mener une
conception préliminaire qui délivre les services techniques et fonctionnels et la conception
détaillé qui valide les fonctionnalités du système et enfin la livraison d’une solution adaptée
aux besoins.
La figure 1.5 présente la répartition des différentes tâches de projet sur la période de réalisation
du projet.

Conclusion
Dans ce chapitre, nous avons présenté en premier lieu l’entreprise d’accueil. Ensuite, nous
avons présenté la problématique ainsi que les objectifs à accomplir et la méthode qui sera suivie
pour la réalisation de notre projet. Dans le chapitre qui le suit, nous menons une étude sur les
applications et technologie existantes.

Chapitre 2 : Etat de l’art
Introduction
Dans ce chapitre nous présentons les différentes technologies qui se présentent dans le projet.
Nous commençons tout d’abord par présenter le SD-WAN et les technologies sur lesquelles il
s’appuie.
Par la suite, nous présentons le Cloud Computing et les réseaux en tant que services ainsi que
le SDN, afin de fixer un guide de référence dans l’analyse des besoins et la conception de notre
solution. Nous étudions les différentes solutions Open source du Cloud Computing.
Aussi, nous entamons une étude comparative de ces différentes solutions. Enfin, nous étudions
les différentes technologies SDN présentes sur le marché.
1. Le SD-WAN
1.1. Introduction
La migration des applications dans le cloud et Datacenter privés des entreprises amène à
repenser fortement le WAN. Ce dernier évolue pour garantir la performance et la sécurité des
applications. Des solutions dites "SD-WAN” sont apparues ces dernières années, avec pour
ambition de répondre aux nouveaux challenges apparus sur le WAN. L'architecture permet
d'ajouter simplement sur chaque site une connexion Internet en plus des connexions WAN
habituelles et d'utiliser chaque liaison de manière optimale.
1.2. Définition du SD-WAN
L'ONUG définit clairement les cas d'usage pour le SD-WAN et met au premier plan le besoin
de baisser les coûts associés au WAN en tirant profit de l'Internet. Il s'agit de mettre en œuvre
une architecture WAN hybride où une connexion Internet complète la connexion WAN privée
traditionnelle sur le site distant. Cette connexion Internet a 2 objectifs :
❖ Avoir un accès direct aux applications hébergées dans le cloud.
❖ Offrir un second lien entre le site distant et le site principal ou Datacenter de
l'organisation.
Sur cette connexion Internet un tunnel sécurisé est construit. Les applications sont
dynamiquement routées sur les 2 liaisons (liaison privée et tunnel sécurisé sur Internet) en
tenant compte de la performance des liaisons, de l'utilisation des liens. La mise en place de
liaison Internet permet ainsi selon l'ONUG de diminuer les coûts globaux de connexion, tout
en restant maître des SLA. [ONUG]

Le SD-WAN fait évoluer la mission du routeur : au-delà d'un transfert de paquets, il est
maintenant en charge de router les applications pour garantir leur performance et leur sécurité.
Au-delà de la mise en place d'une architecture hybride, le SD-WAN a comme postulat que la
solution doit être simple à déployer pour une organisation, et ne doit pas être réservée aux
opérateurs et experts du WAN. Aussi des interfaces de management simples caractérisent le
SD-WAN, avec la possibilité d'offrir une abstraction du réseau. Le figure 2.1 illustre
l’architecture simple du SD-WAN. [JRES 2017]
Figure 2. 1: Architecture SD-WAN
1.3. Choix de la solution utilisée

✓ Contrail juniper SD-WAN :
Contrail SD-WAN permet de créer une architecture évolutive au fur et à mesure pour
développer un réseau au-delà des limites des clouds privés et publics. Il simplifie la croissance
tout au long de la migration de routeurs sécurisés vers SD-WAN, vers SD-Branch et finalement
vers un réseau multicouches automatisé par intelligence artificielle (IA). Dans une entreprise
axée sur l'IA, l'automatisation simplifie les opérations en offrant fiabilité et agilité, tout en
étendant la visibilité sur l'ensemble de l'environnement multicouches. [Juniper Contrail]
✓ Cloud-Based service or Self-Managed
Le Contrail SD-WAN utilise Contrail Service Orchestration (CSO) pour concevoir, sécuriser,
automatiser et exécuter tout le cycle de vie du service sur les plates-formes de services réseau
de la série NFX, les plates-formes de routage universelles MX Series 5G et les passerelles de
services de la série SRX, ainsi que les points de terminaison cloud protégés par le pare-feu

virtuel vSRX. On peut gérer le logiciel Contrail Service Orchestration ou rechercher une
solution gérée auprès de notre choix de fournisseurs et ça présente un grand avantage pour
cette solution.
Figure 2. 2: Architecture de la solution Contrail SD-WAN
2. Le Cloud Computing
Dans cette partie, nous définissons le concept du cloud computing en développant ses
caractéristiques, puis nous expliquons des modèles de service ainsi que ses modèles de
déploiement.
2.1. Définition du Cloud Computing
Le cloud computing est un modèle permettant un accès réseau omniprésent, pratique et à la
demande à un pool partagé de ressources informatiques configurables (réseaux, serveurs,
stockage, applications et services) pouvant être rapidement mis en service et libéré avec un
effort de gestion minimal. L’interaction avec le fournisseur de services, se fait sur une base de
paiement à l’utilisation sur Internet, c’est selon Le NIST (National Institute of Standards and
Technology). [NIST]
2.2. Le besoin au Cloud Computing
Dans l’environnement concurrentiel d’aujourd’hui, les entreprises sont de plus en plus pressées
d’améliorer leur efficacité et de transformer leur IT pour obtenir plus avec moins. Les
entreprises ont besoin de moins de temps sur le marché, d’une meilleure agilité, d’une plus
grande disponibilité et de moins de dépenses pour répondre aux besoins changeants et au
rythme accéléré de l’innovation.

Ces exigences métiers posent plusieurs défis aux équipes informatiques. Certains des
principaux défis sont de servir les clients du monde entier 24 heures sur 24, d'actualiser
rapidement les technologies et de fournir des ressources informatiques plus rapidement, le tout
à un coût réduit. Ces défis de longue date sont résolus avec l'émergence d'un nouveau style
informatique, appelé cloud computing qui permet aux organisations et aux particuliers
d’obtenir et de fournir des ressources informatiques en tant que service.
2.3. Les cinq caractéristiques du cloud computing
Le Cloud Computing est basé sur cinq caractéristiques qui sont représentées dans la figure 2.3:
Figure 2. 3: Caractéristiques du cloud
✓ Service à la demande
Un consommateur peut se servir unilatéralement des capacités informatiques, telles qu’une
instance d’un serveur et le stockage réseau, selon les besoins automatiquement sans nécessiter
d'interaction humaine avec chaque fournisseur de services. Un fournisseur de services cloud
publie un catalogue de services contenant des informations sur tous les services cloud
disponibles pour les consommateurs.
✓ Accès réseau large bande
Les fonctionnalités sont disponibles sur le réseau et accessibles via des mécanismes standard
qui favorisent l'utilisation de plates-formes client hétérogènes ou épaisses (par exemple,
téléphones mobiles, tablettes, ordinateurs portables et stations de travail).
✓ Partage des ressources
Les ressources informatiques du fournisseur sont regroupées pour servir plusieurs
consommateurs à l’aide d’un modèle multi-locataire, différentes ressources physiques et
virtuelles étant attribuées et réaffectées de manière dynamique en fonction de la demande des

consommateurs. Il existe un sentiment d’indépendance de localisation en ce que le client n’a

généralement aucun contrôle ni connaissance sur la localisation exacte des ressources fournies,
mais peut éventuellement spécifier une localisation à un niveau d’abstraction supérieur.
✓ Elasticité
Les capacités peuvent être provisionnées et libérées de manière élastique, dans certains cas
automatiquement, pour évoluer rapidement vers l'extérieur et vers l'intérieur en fonction de la
demande. Pour le consommateur, les fonctionnalités disponibles pour le provisioning semblent
souvent illimitées et peuvent être adaptées à n'importe quelle quantité et à tout moment. Les
consommateurs peuvent tirer parti de l'élasticité rapide du cloud en cas de fluctuation de leurs
besoins en ressources informatiques.
✓ Facturation à l'usage
Les systèmes Cloud contrôlent et optimisent automatiquement l'utilisation des ressources en
exploitant une capacité de mesure à un niveau d'abstraction approprié au type de service par
exemple les comptes de stockage, de traitement, de bande passante et d'utilisateurs actifs.
L'utilisation des ressources peut être surveillée, contrôlée et rapportée, offrant une transparence
à la fois au fournisseur et au consommateur du service utilisé.
Le Cloud permet aux utilisateurs d’utiliser les ressources d’une manière flexible. Cela impacte
aussi bien la manière de consommer ces ressources que la manière de les fournir.
2.4. Les bénéfices du cloud
Le cloud computing offre les principaux avantages suivants :
• Coût informatique réduit : les services cloud peuvent être achetés sur la base d’un paiement
à l’utilisation ou d’un abonnement. Cela réduit ou élimine les dépenses en capital du
consommateur (CAPEX).
• Agilité professionnelle : le cloud computing permet d'allouer et de faire évoluer rapidement
la ressource virtuelle. Le cloud peut diminuer le temps requis pour provisionner et déployer de
nouveaux services et applications de plusieurs mois à quelques minutes. Cela permet aux
entreprises de réagir plus rapidement aux changements du marché et de réduire les délais de
mise sur le marché.
• Évolutivité flexible : le cloud computing permet aux consommateurs de monter en charge,
de se réduire ou de s’étaler la demande en ressources informatiques facilement. Les
consommateurs peuvent redimensionner leurs ressources cloud et automatiquement sans
aucune intervention des fournisseurs de services cloud. La capacité de fourniture de services

flexible du cloud donne souvent aux utilisateurs de services un sentiment d’évolutivité

illimitée.
• Haute disponibilité : le cloud computing permet d’assurer la disponibilité des ressources à
différents niveaux, en fonction de la politique et des priorités du consommateur. Les
composants d'infrastructure redondants (serveurs, chemins d'accès réseau et équipements de
stockage, ainsi que les logiciels en cluster) permettent la tolérance de panne pour les
déploiements dans le cloud. Ces techniques peuvent englober plusieurs datacenters situés dans
différentes régions géographiques, ce qui évite l'indisponibilité des données en raison de
défaillances régionales.
2.5. Modèles de services
Le Cloud Computing sert avant tout à apporter de nouveaux services à l’entreprise. Ce qu’on
appelle “modèles de services” décrit les différentes catégories de services accessibles depuis
une plate-forme de Cloud. La figure 2.3 représente les couches de modèle de service
Figure 2. 4: Les différents couches de modèle de service
En effet, le Cloud Computing se décompose en trois grands modèles de service dont les plus
connus sont le SaaS, le PaaS et le IaaS, aussi dénommés SPI (Software, Platform,
Infrastructure), comme il est présenté dans la figure ci-dessous :

Figure 2. 5: Architecture en couche du cloud
La base de la pyramide correspond au travail de l’architecte réseau et aux services de l’IaaS,

soit utiliser les ressources d’un fournisseur et les services web de base, la couche intermédiaire
correspond au travail du développeur et au service PaaS dans un environnement spécifique, et
la couche haute s’adresse aux utilisateurs finaux. On y retrouvera des applications SaaS,
comme Gmail ou Office 365…
✓ Software as a Service (SaaS)
La capacité fournie au consommateur consiste à utiliser les applications du fournisseur
s'exécutant sur une infrastructure Cloud. Les applications sont accessibles à partir de divers
périphériques clients via une interface de client léger, telle qu'un navigateur Web par exemple :
un courrier électronique basé sur le Web ou une interface de programme. Le consommateur ne
gère ni ne contrôle l’infrastructure cloud sous-jacente, y compris le réseau, les serveurs, les
systèmes d’exploitation, le stockage ou même les fonctionnalités d’applications individuelles,
à l’exception possible des paramètres de configuration d’application spécifiques à un
utilisateur.
La figure 2.6 illustre l’architecture de service SaaS.
Figure 2. 6: Architecture SaaS

✓ Platform as a Service (PaaS)

La capacité fournie au consommateur consiste à déployer sur l'infrastructure de cloud des
applications créées ou acquises par le consommateur et créées à l'aide de langages de
programmation, de bibliothèques, de services et d'outils pris en charge par le fournisseur. Le
consommateur ne gère ni ne contrôle l’infrastructure cloud sous-jacente, y compris le réseau,
les serveurs, les systèmes d’exploitation ou le stockage, mais contrôle les applications
déployées et éventuellement les paramètres de configuration de l’environnement d’application.
[EMC]
Figure 2. 7: La chaîne de la plateforme PaaS
✓ Infrastructure as a Service (IaaS)

La capacité fournie au consommateur consiste à fournir un traitement, un stockage, des réseaux
et d'autres ressources informatiques fondamentales permettant au client de déployer et
d'exécuter des logiciels arbitraires, pouvant inclure des systèmes d'exploitation et des
applications. Le consommateur ne gère ni ne contrôle l’infrastructure cloud sous-jacente, mais
il contrôle les systèmes d’exploitation et les applications déployées. [EMC]
Figure 2. 8: Ressources du modèle IaaS

2.6. Etude comparative et choix de la solution Cloud

2.6.1. Solutions open source existantes
Dans le monde du Cloud, le logiciel libre est de plus en plus sollicité par les fournisseurs pour
offrir des services dédiés. Deux arguments sont souvent mis en avant pour le choix du libre, la
gratuité et le développement plus rapide et agile. C’est pour cela, nous considérons uniquement
que les solutions Open-Source dans notre étude.
Nous prenons aussi la liberté d’exclure certaines solutions dont la documentation n’est pas
disponible ou dont la communauté ou l’activité de développement est extrêmement faible ou
dont la stabilité et les fonctionnalités sont clairement inadaptés à l’usage professionnel et
potentiellement à grande échelle que nous prévoyons. Après la phase de recherche initiale, il
en ressort que nous avons quatre solutions Open-Source viables que nous allons comparer sur
différents aspects est qui sont Openstack, Eucalyptus, OpenNebula et Cloudstack.
2.6.2. Architectures et Services
Toutes les solutions disposent donc de services similaires dans leurs rôles mais différents dans
leurs implémentations et dans l’organisation architecturale de ces derniers. On retient par
exemple les services suivants :
❖ Services API : reçoivent l’ensemble des requêtes d’interactions avec l’IaaS et se
chargent de la distribution de celles-ci aux services concernés.
❖ Service de bases de données : enregistre l’ensemble des données liées à l’IaaS et au
Services.
❖ Ordonnanceur : organise la répartition des ressources (telles que les instances) travers
la plateforme.
❖ Services de virtualisation : exécutent et gèrent les instances (machines virtuelles) en
utilisant différents hyperviseurs.
❖ Service d’authentification : assure la sécurité pour l’ensemble de la plate-forme et des
différents services.
❖ Service d’images : distribue les images permettant la création des instances à travers
l’IaaS. Le stockage est parfois assuré par les services de stockages.
❖ Services de stockages : stockent de manière sécurisée les volumes et données des
instances.
❖ Services de réseaux : offre les capacités réseaux aux machines virtuelles, dont routeurs
virtuels, VLAN, adresses IPs flottantes publiques, etc.

❖ Services de télémétrie et de monitoring : réalisent des activités de contrôle, de

facturation, de réalisations statistiques.
Nous nommons d’un terme générique « Contrôleurs » le regroupement de différents services
(Pouvant être de différentes natures) permettant de gérer la plateforme. Une panne de ces
derniers n’entraîne pas nécessairement une indisponibilité des instances du consommateur
mais l’impossibilité pour ce dernier de les gérer : d’en créer de nouvelles, d’en modifier les
caractéristiques, de les supprimer, etc.
Certaines solutions (architecture « Monolithique ») regroupent les services ensembles - ils
sont installés comme un seul et même logiciel tandis que certaines solutions permettent la
séparation de chacun des services en plusieurs logiciels interdépendants (architecture
modulaire), ce qui accroît la flexibilité mais aussi la complexité.
Les contrôleurs doivent être rendus hautement disponibles et certains peuvent même supporter
l’équilibrage de charge (répartition des requêtes sur plusieurs contrôleurs) [MACHU 2015].
Le tableau 2.1 différencie les solutions selon les caractéristiques ci-dessous.
Tableau 2. 1: La différence entre les solutions cloud
Caractéristique OpenStack OpenNebula CloudStack Eucalyptus
Public/ hybride/ Public/ hybride/ Public/ hybride/

Type de cloud Privé
privé privé privé
Architecture Modulaire Monolithique Monolithique 5 composants
Contrôleur HA Oui Oui Oui Oui
Contrôleur LB Oui - Oui -
2.6.3. Support de l’hyperviseur

Un hyperviseur est une plateforme de virtualisation, il permet de faire fonctionner plusieurs
systèmes d’exploitation sur une même machine physique. Dans notre cas, il permet de créer
des instances dans le Cloud. Le tableau 2.2 liste les différents hyperviseurs disponibles pour
les différentes solutions de Cloud Computing considérées.

Tableau 2. 2: Les hyperviseurs supportés par les solutions cloud
Hyperviseur OpenStack OpenNebula CloudStack Eucalyptus

KVM Oui Oui Oui Oui
QEMU Oui - Oui -
Xen Oui Oui Oui Oui
VMware Oui Oui Oui Oui
Hyper-V Oui - Oui -
LXC Oui - Oui -
Docker Oui - - -
XenServer Oui - Oui -
2.6.4. Réseaux
Un ensemble d’instances virtuelles sans connectivité est une infrastructure morte et ce même
ensemble avec des possibilités de connectivité limitées est au mieux, une infrastructure non
sécurisée. Certaines solutions IaaS actuelles proposent l’utilisation de SDN (Software Defined
Networking) qui permet de créer un très grand nombre de scénarios réseaux virtuels à l’aide
notamment des routeurs virtuels [MACHU 2015].
On note aussi parfois l’existence à ce niveau des services d’équilibrage de charge en tant que
services LBaaS qui offrent l’opportunité de créer des équilibrages de charges pour les
instances. Certaines solutions permettent également de créer des accès sécurisés à une
infrastructure privée et sans point d’accès évident, via VPN.
OpenStack utilise le service Neutron pour gérer le réseau. Il propose de nombreux plugins
servant de back-end, allant de l’utilisation de méthodes d’isolation simples comme le VLAN
via Linux Bridge à l’exploitation de routeurs Cisco en passant par les très répandus OpenFlow
et Open vSwitch.
Il est possible d’utiliser plusieurs mécanismes simultanément comme Linux Bridge et Open
vSwitch à l’aide de Modular Layer 2.
On note, cependant, qu’il existe une table de compatibilité entre les différentes
implémentations réseaux et les hyperviseurs et cela est vrai pour toutes les solutions. Au
premier abord, l’utilisation de OpenFlow et Open vSwitch est une solution intéressante.
Le tableau 2.3 compare les différentes solutions Cloud selon leur fonctionnalités réseaux.

Tableau 2. 3: Comparaison des solutions cloud par fonctionnalité réseau
Fonctionnalité OpenStack OpenNebula CloudStack Eucalyptus
QoS Oui Oui - -

VPN Oui - Oui -
Firewalls Oui - Oui -
Load Balancers Oui - Oui -
Support Matériels Oui - Oui -
Intrusion Detection Oui - - -

System (IDS)
SDN (Openflow / Oui Oui - -
Open vSwitch)
Isolation simple Oui Oui Oui Oui

(vlan)
2.6.5. Choix de la solution Cloud

Dans les sections précédentes, nous avons fait une étude comparative entre les solutions
Cloud les plus utilisées dans le monde sur les différents plans techniques, et il est à présent
question de faire le choix sur la solution la plus convenable pour notre environnement
technique.
Notre choix s’est fixé sur la solution openstack pour les raisons suivantes :
➢ OpenStack est en fait une plateforme de Cloud Open Source qui se compose de plus
de 30 projets, chacun apportant un service particulier à l’ensemble.
Ces services évoluent de façon indépendante. Cette architecture permet aussi d’ajouter à la
plateforme des modules additionnels plus facilement.
➢ Le niveau de support des fournisseurs – comme peut l’avoir OpenStack chez Dell,
HPE, IBM, Red Hat, Intel, OVH.
La solution est arrivée à un niveau de maturité suffisant : une nouvelle version tous les six
mois. Actuellement, elle est à sa vingtième version Stein. La figure 2.9 représente son logo.

Figure 2. 9: Logo d’OpenStack
C’est la solution open source la plus utilisée, la figure 2.10 illustre le pourcentage d’utilisation
des solutions et leur mise en place d’un environnement Cloud et montre que la plus grande part
de marché utilise la solution OpenStack.
Figure 2. 10: utilisation des solutions cloud open source
2.6.6. Les composants d’OpenStack

Pour le choix de la version avec laquelle on va travailler, il ne faut pas juste choisir la plus
récente mais aussi la plus stable pour le lancement des versions, c’est chaque six mois on aura
une et après cette période la version précédente devient stable donc on a choisi la version Rocky
qui s’articule principalement sur 5 composants de base et des APIs pour établir la
communication entre eux.
❖ Composants d’openstack
✓ Compute (Nova / Gestion des services)
Nova est le coeur de l’openstack, il gère principalement les instances qui sont créées à partir
des images fournies par le composant Glance, il ne fait pas office d’hyperviseur donc il ne peut
pas créer d’instances par lui-même, au lieu de cela, il s’appuie sur un ou plusieurs hyperviseurs
configurés pour fonctionner avec lui, prend en charge plusieurs hyperviseurs y compris KVM,
QEMU, LXC, XenServer, Hyper-V et VMWare.

La figure 2.11 représente l’architecture de l’interaction entre les composants de nova.
Figure 2. 11: Architecture-Interactions Nova
• Services du composant
Nova-api : Accepte et répond aux appels d'API de calcul de l'utilisateur final. Le service prend
en charge l'API OpenStack Compute. Il applique certaines stratégies et lance la plupart des
activités d'orchestration, telles que l'exécution d'une instance.
Nova-scheduler : Prend une requête de demande d'instance de machine virtuelle dans la file
d'attente et détermine sur quel hôte de serveur de calcul il s'exécute.
Nova-compute : Un démon de travail qui crée et met fin aux instances de machine virtuelle
via des API d'hyperviseur. Par exemple : libvirt pour KVM ou QEMU
En gros, le démon accepte les actions de la file d'attente et exécute une série de commandes
système, telles que le lancement d'une instance KVM et la mise à jour de son état dans la base
de données.
Nova-conductor module : Médie les interactions entre le service nova-compute et la base de
données. Il élimine les accès directs à la base de données sur le cloud créés par le service nova-
compute. Le module nova-conductor s’étale horizontalement. Cependant, ne le déployez pas
sur les nœuds sur lesquels le service nova-compute est exécuté.
Nova-consoleauth : Autorise les jetons pour les utilisateurs fournis par les serveurs proxy de
la console.

Nova-novncproxy : Fournit un proxy pour accéder aux instances en cours d'exécution via une
connexion VNC. Prend en charge les clients novnc basés sur un navigateur.
✓ Image service (Glance / gestion des instances)
Le service Image (Glance) permet aux utilisateurs de découvrir, d’enregistrer et de récupérer
des images de machine virtuelle. Il offre une API REST qui vous permet d'interroger les
métadonnées d'une image de machine virtuelle et de récupérer une image réelle.
Glance-api : Accepte les appels d'API Image pour la découverte, la récupération et le stockage
d'images.
Glance-registry : Stocke, traite et récupère les métadonnées sur les images. Les métadonnées
incluent des éléments tels que la taille et le type.
La figure 2.12 représente l’architecture de l’interaction entre les composants du Glance.
Figure 2. 12: Architecture-Interactions de Glance
✓ Neutron (gestion des réseaux)

Neutron est le composant OpenStack offrant le "réseau en tant que service". Il permet entre
autres de créer des réseaux, d’assigner des adresses IP aux machines virtuelles dans ces
réseaux, mais aussi de créer des accès VPN, des équilibrages de charges, des pare-feu…
Au niveau de la topologie physique, seuls les contrôleurs, qui assurent la fonction de routage
et de translation d’adresses IP, sont visibles de l’extérieur. Les noeuds de calcul, sur lesquels
les machines virtuelles sont exécutées, sont connectés à un réseau physique interne accessible
uniquement par les contrôleurs. Plutôt que de gérer les règles de filtrage réseau au niveau de
chacune de leurs machines virtuelles, les utilisateurs peuvent configurer des groupes de

sécurité, qui sont des listes de contrôle d’accès qui s’appliquent aux instances de machines
virtuelles.
Neutron-server est responsable de la réception et du traitement des requêtes concernant le
composant.
Neutron-dhcp-client offre le service DHCP aux instances virtuelles de Nova.
Neutron-l3-agent réalise le routage, le NAT et le forwarding réseau de niveau 3 en utilisant
les namespace pour gérer de façon isolée de multiples réseaux se chevauchent.
Neutron-metadata-agent permet aux instances virtuelles de communique avec Nova afin de
récupérer leurs metadata. Il fait donc office de passerelle entre les réseaux des instances et le
réseau dans lequel nova opère.
Neutron-plugin-ovs-agent est un plugin dont se sert Neutron pour effectivement créer le
réseau définit. Ici, c’est donc OpenvSwitch qui est utilisé pour créer des réseaux, qui sont par
conséquent virtuels et qui transitent via des tunnels GRE. Il est possible d’utiliser des plugins
propriétaires tels que les plugins Cisco lorsque le réseau physique est adapté.
Neutron-lbaas-agent s’occupe de la réalisation des "équilibrage de charge en tant que
service".
Neutron-vpnaas-agent permet de créer divers types de VPN, pour accéder aux réseaux
virtuels ou bien encore pour connecter plusieurs réseaux ensembles à travers potentiellement
plusieurs zones de disponibilités. [Openstack 2019]
La figure 2.13 représente l’architecture de l’interaction entre les composants de neutron
Figure 2. 13: Architecture-Interactions de neutron

✓ Keystone (gestion des identités)

Le service d'identité fournit un point d'intégration unique pour la gestion de l'authentification,
de l'autorisation et d'un catalogue de services. Il agit en tant qu’un annuaire qui centralise toutes
les authentifications et autorisations nécessaires aux multiples services d’Openstack.
Il se base principalement sur trois « entités » : l’utilisateur, le rôle et le projet.
On peut simplifier la relation entre ces trois entités en une phrase : un utilisateur a un certain
rôle dans un certain projet. Une ressource virtuelle (instance de machine, réseau, etc.) ne peut
pas être associée directement à un utilisateur. Elle est associée soit à un projet, soit à un couple
utilisateur-projet.
• Service du composant
keystone-all assure l’intégralité des tâches gérées par le composant.
✓ Block Storage (Cinder)
Cinder fournit le support de volumes (disques) persistants pour les machines virtuelles.
Cinder-api est responsable de la réception et du traitement des requêtes concernant le
composant.
Cinder-scheduler répartit les volumes à allouer à travers la plateforme en fonction des
ressources.
La figure 2.14 représente l’architecture du service Keystone
Figure 2. 14: architecture de Keystone
Cinder-volume gère les volumes effectivement. Il fonctionne avec plusieurs divers backends.
Cinder-backup permet la création et la restauration de sauvegardes de disques en cas de
défaillance.

La figure 2.15 représente l’architecture de l’interaction entre les composants de cinder
Figure 2. 15: architecture-Interactions de Cinder
3. SDN
La complexité des réseaux présente un réel problème au sein des datacenters. Cette complexité
s’explique par une augmentation importante au niveau de la virtualisation des serveurs, du
stockage ou des stations de travail, aussi par la limitation dans le déploiement automatique des
ressources dans des environnements multi-clients.
Dans le but de répondre à ces problématiques, l’IT a besoin de réduire le temps de déploiement
de ses services liés aux réseaux en adoptant le SDN en complément des technologies déjà
utilisées telles que le Cloud Computing et la virtualisation.
3.1. Définition du SDN (Software Defined Network)
Le SDN est la Séparation physique du plan de contrôle du réseau par rapport au plan de
données, et dans lequel un plan de contrôle gère plusieurs équipements en las pilotant par un
logiciel. L’idée est de pouvoir séparer le plan de contrôle du plan de données, ce qui permet de
rendre programmables les équipements réseaux et ceci d’un point de contrôle centralisé. Le
plan de contrôle est placé dans un contrôleur centralisé qui a une vue globale de la topologie
du réseau et qui peut gérer les hôtes qui s’y connectent. [ONF]

Figure 2. 16: Séparation des différents plans
Plus généralement, le plan de contrôle (souvent apparenté à la Routing Engine) est responsable
de remplir la table de transmission. Celle-ci est présente pour une seule raison : dire au second
composant majeur de l’équipement, le plan de transmission, ce qu’il doit faire de chaque
trame/paquet/ensemble de données qu’il va devoir traiter. Le plan d’acheminement désigne
généralement les composants, dédiés à la transmission de données à hautes performances sur
le réseau, que l’on appelle les ASIC.
La communication avec le contrôleur se fait par ses interfaces API dont on distingue :
❖ La NorthBound API qui permet aux applications de définir au contrôleur la stratégie
de la programmation du réseau.
❖ La SouthBound API qui permet contrôleur de charger ses instructions aux les
équipements du réseau [DOTTA 2017].
Différents protocoles peuvent être utilisés pour la communication SouthBound Interface, le
plus connu étant OpenFlow, on peut citer d’autres comme XMPP,OpFlex…

Figure 2. 17: Architecture en couche du SDN
3.2. Plan de composition des équipements réseaux

Les différents équipements réseaux se composent de plusieurs couches. On distingue :
Plan de contrôle "control plane" : Ce plan permet comme son nom l’indique de contrôler le
plan de données en établissant les règles qu’il devra suivre (la table de routage par exemple).
Parmi les protocoles qui participent à ce plan, on peut citer par exemple OSPF, STP, ARP, ou
BGP.
Plan de donnée "data plane" : C’est la partie qui gère le cœur de métier de notre équipement.
Son rôle est d’acheminer des paquets ou des trames depuis un port X vers un port Y.
Autrement dit, switch et/ou router en se basant sur des informations contenues dans des tables
(comme par exemple : FIB). On peut également définir le plan de donnée comme la gestion du
trafic qui n’est pas à destination de l’équipement lui-même, par opposition aux 2 autres plans.
Plan de gestion ou "management plane" : Ce dernier plan concerne tout ce qui concerne
l’administration de l’équipement. Il s’agit donc des flux SSH ou SNMP par exemple. Il est
parfois considéré comme une couche supplémentaire du plan de contrôle.
3.3. Étude comparative et choix de la solution SDN
De nos jours le SDN permet d’envisager une plus grande flexibilité et une meilleure efficacité
du réseau. Le réseau peut évoluer plus rapidement et devient "programmable".

C’est pour cela que nous cherchons à intégrer une solution SDN avec la solution Cloud Open
source que nous avons choisie précédemment. Pour ce faire nous allons considérer les
différentes solutions Open-Source les plus populaires et parmi lesquelles nous choisissons la
solution la plus adaptée à nos besoins, après une phase d’étude comparative.
3.3.1. Comparaison des contrôleurs Open-Source
Nous avons rassemblé les contrôleurs SDN Open- Source les plus présents sur le marché.
➢ Floodlight
Floodlight est un contrôleur Open-Source OpenFlow développé en Java, pris en charge par
BigSwitch Networks, il est sous licence Apache. Elle est facile à configurer et a montré aussi
de grandes performances. Avec toutes ses fonctionnalités, Floodlight est plus une solution
complète.
➢ POX
C’est un contrôleur Open-Source développé en Python, fournit un cadre pour le développement
et le test d’un contrôleur OpenFlow. Mais les performances POX sont clairement insuffisantes
par rapport à celles des autres contrôleurs et il n’arrive pas à exister au déploiement
d’entreprise.
➢ ONOS
ONOS fournit le plan de contrôle pour un réseau défini par logiciel (SDN), gère des
composants de réseau, tels que des commutateurs et des liaisons, et exécute des programmes
ou modules logiciels pour fournir des services de communication aux hôtes finaux et aux
réseaux voisins.
➢ Ryu
Ruy est un contrôleur qui fournit des composants logiciels avec des API bien définis et qui
permet aux développeurs de créer facilement des applications de gestion et de contrôle du
réseau. Ryu prend en charge divers protocoles de gestion des périphériques réseau, tels que
OpenFlow, Netconf, OF-config, etc. Ryu est disponible sous la licence Apache 2.0.
➢ OpenDaylight
OpenDaylight est un projet de la Fondation Linux pris en charge par l’industrie. C’est un
framework open-source pour faciliter l’accès au logiciel de définition de réseau (SDN) comme
Floodlight, il peut également être considéré comme une solution complète.
Notre étude comparative se base sur les cas d’utilisation les plus importants et les plus
populaires pris en charge par le contrôleur. Le tableau 2.4 résume la comparaison des
contrôleurs open-source prenant en compte les différents cas d’utilisation.

Tableau 2. 4: Comparaison des contrôleurs open-source
Use Cases \ Controller POX FloodLight OpendayLight ONOS Ryu

Load Balancing Oui Partiel Oui Non Oui
Monitoring des reseaux Partiel Oui Oui Oui Oui
Support de Routage Non Oui Oui Oui Oui
Support d’OpenStack Non Oui Oui Non Oui
Ingénieurie du traffic Partiel Partiel Oui Partiel Partiel
Interopérabilité avec le Non Non Oui Partiel Non

réseau traditionnel
Interconnection des DCs Non Non Partiel Partiel Partiel
3.3.2. Solution SDN adoptée

Dans la section précédente, nous avons présenté un tableau comparatif entre les différentes
solutions SDN qui se base sur les cas d’utilisation. Il est à présent temps de faire le choix de la
solution qui nous convient le mieux. La solution que nous devons choisir doit réaliser le plus
grand nombre de cas d’utilisation. La solution qui répond à tous ces critères est Opendayligth.
➢ Présentation de Opendaylight
Le contrôleur Opendaylight est une plateforme à base de machine virtuelle java et peut être
exécuté depuis n’importe quel système d’exploitation. Il vise à proposer une plateforme de
virtualisation de réseau extensible, ouverte, en s’appuyant sur des standards tels qu’OpenFlow
et en proposant une interface universelle pour le contrôle des commutateurs virtuels autant que
physiques [Hachicha 2017].
Le contrôleur utilise les outils suivants :
➢ Maven : Opendaylight utilise Apache Maven pour une automatisation plus facile à base
de fichier pom.xml qui contient la configuration du serveur java sur lequel il tourne.
➢ OSGI : C’est une bibliothèque de backend d’Opendaylight car il permet le chargement
des Bundles et les paquets des fichiers JAR.
➢ JAVA interfaces : sont utilisées pour l’écoute des événements.
➢ RESTAPIs : Ce sont les interfaces responsables de la gestion de topologie, traçage
d’hôtes, routage statique, etc... La figure 2.18 présente l’architecture basique de
Opendayligth.

Figure 2. 18: Architecture d’OpenDaylight
Les principal avantage d’OpenDaylight par rapport aux autres contrôleurs : Une architecture
microservices qui fournit à l’utilisateur des services particuliers par exemple :
❖ Activer le protocole OpenFlow ou BGP.
❖ Installer un switch virtuel L2 ou un service comme le AAA (Authentication,
Authorization and Accounting).
❖ Prise en charge de plusieurs protocoles tels que OpenFlow,SNMP NETCONF,
OVSDDB, BGP, PCEP, LISP, etc...
❖ L’aide à développer de nouvelles fonctionnalités comprenant des protocoles et des
services de réseaux. [OpenDaylight]
➢ OpenDaylight Nitrogène SR4
Dans notre projet, nous avons choisi l’implémentation d’OpenDaylight Nitrogène SR4 qui est
la septième version l’avant dernière car elle est la plus stable.
Conclusion
Les différents éléments présentés dans ce chapitre ont aidé à mieux comprendre le projet et à
définir les différentes technologies qui comportent le SD-WAN tels que le Cloud Computing
et le SDN qui présente une évolution technologique suite à l’arrivé du Cloud.
Nous avons fait une étude comparative des solutions open-sources des plateformes du Cloud
Computing ainsi que sur les différents contrôleurs SDN à intégrer dans notre solution. Ceci
nous a permis d’avoir une idée complète sur les techniques disponibles pour la création d’un
environnement Cloud et sur l’intégration du contrôleur SDN au sein du cloud.
Dans le chapitre suivant intitulé : spécification des besoin et conception on va démontrer avec
plus de détails la description technique de la solution

Chapitre 3 : Spécification des besoins et conception
Introduction
Dans ce chapitre, nous commençons en premier lieu par énoncer les besoins fonctionnels et
non fonctionnels auxquels doit répondre notre architecture SD-WAN avec tous ses
composants.
Par la suite, nous introduisons les acteurs et les diagrammes de cas d’utilisation relatifs à ces
acteurs.
1. Identification des besoins

Notre solution Cloud comprend deux types d’acteur :
❖ L’administrateur : qui a le rôle et les privilèges pour gérer le Cloud, les différents projets
et les différents membres à travers le portail administratif.
❖ Le membre du projet : qui est le client d’un ou plusieurs projets de Tunisie Telecom.
Concernant la solution SDN, elle comprend qu’un seul acteur qui est l’administrateur, et qui a
pour rôle de gérer le service réseau.
Donc, la première partie sera consacrée pour énoncer les différents besoins fonctionnels et non
fonctionnels de notre solution Cloud ainsi que la solution SDN qu’on a adoptée.
1.2. Besoins fonctionnels de la solution Cloud
➢ Gestion des projets
Un projet est un groupement logique des utilisateurs au sein de Nova, utilisé pour définir les
limites des ressources pour ce projet et l’accès aux images des machines virtuelles. Il serait
possible de consulter les projets existants et leurs statuts et de créer des nouveaux projets.
➢ Gestion d’images
Ceci concerne les images disques stockées par le service Glance. L’utilisateur pourrait
consulter la liste des images autorisées pour les projets et les éditer. Aussi, il sera possible de
lancer des nouvelles instances de cette image, créer une nouvelle ou supprimer une existante.
➢ Gestion d’instances
Une instance est une machine virtuelle en cours d’exécution ou dans un état connu comme
«suspendue» qui peut être utilisée comme un serveur matériel. L’utilisateur pourrait consulter
la liste d’instances des machines virtuelles actuelles plus quelques informations globales
comme le projet auquel elles appartiennent, le serveur hôte, l’adresse IP, la taille, le statut et
les actions en cours. Il aurait aussi les possibilités d’éditer, mettre fin, pause, redémarrer ou

supprimer une instance. Aussi, il pourrait se connecter à la console VNC de l’instance ou créer
une nouvelle.
➢ Gestion des volumes
Le tenant peut consulter la liste des volumes disques virtuels existants, créer un nouveau
volume et modifier d’autres.
➢ Gestion des gabarits
Un gabarit (flavor) est une configuration de ressources disponibles dans un serveur. Chaque
Flavor possède une combinaison unique d’espace disque et de capacité de mémoire.
L’utilisateur pourrait consulter la liste des types d’instances disponibles, leurs spécifications
en nombre de CPUs, mémoire, espace disque et créer des nouvelles définitions d’instance.
➢ Gestion des utilisateurs
Le tenant aurait la possibilité de consulter la liste d’utilisateurs enregistrés, avec la possibilité
d’ajouter ou d’éditer les détails mais pas d’ajouter l’utilisateur à plusieurs projets.
➢ Gestion de la sécurité et de l’accès
Le tenant pourrait consulter les adresses IP non associées pour connecter les instances au réseau
public avec la possibilité de création des groupes de règles du firewall et leur interface de
gestion et enfin la liste des clés SSH avec l’importation ou la création de certificat.
1.3. Besoin fonctionnel de la solution SDN
Au niveau de la solution SDN, l’administrateur est l’acteur principale, il pourrait créer à l’aide
de l’environnement du test Mininet des réseaux OpenFlow Virtuel (un contrôleur, des
commutateurs des hôtes et des liens) aussi visualiser les flux au niveau des commutateurs et
gérer l’intégration et la gestion des commutateurs au niveau de notre plate-forme Cloud à
travers le contrôleur SDN.
1.4. Besoin non fonctionnel
Service à la demande : Un utilisateur peut de son côté et sans intervention humaine, avoir à
sa disposition les ressources informatiques dont il a besoin tel qu’un temps de calcul de
serveurs, capacité de stockage…
Accès léger et facile : L’accès aux ressources ne nécessite pas d’équipement ou de logiciel
propriétaire. Il se fait à travers des applications facilement disponibles (parfois libres) depuis
un simple navigateur Internet.
Ergonomie : Les interfaces doivent être simples et conviviale.

2. Diagramme des cas d’utilisation

2.1. Diagramme de cas d’utilisation général
Les diagrammes de cas d'utilisation sont des diagrammes UML utilisés pour donner une vision
globale du comportement fonctionnel d'un système logiciel. Ils sont utiles pour des
présentations auprès de la direction ou des acteurs d'un projet, mais pour le développement,
les cas d'utilisation sont plus appropriés.
La figure 3.1 présente le diagramme de cas d’utilisation général associé à l’administrateur de
l’infrastructure cloud de Tunisie Telecom et les clients.
gérer des projets

<<include>>
créer l'infrastructure réseau de base
<<include>>
Administateur du cloud
Ajouter une instance <<include>>
Créer un firewall
<<include>>
S'authentifier
Consulter les statistiques

<<include>>
Client
<<include>>
Créer un membre
<<include>>
Allouer une adresse IP flottante
<<include>>
Associer une adresse IP flottante à une instance
Figure 3. 1: Diagramme du cas d’utilisation général des différents acteurs

2.2. Raffinement des cas d’utilisation

Cas d’utilisation "gérer des projets"
La figure 3.2 représente le diagramme du cas d’utilisation de gestion des projets.
<<include>>
créer des projets
<<include>>
consulter la liste des flavors
<<include>>
gérer la liste des images
gérer des projets <<include>>

gérer les utilisateurs s'authentifier
Administrateur
<<include>>
gérer les instances
<<include>>
consulter la liste des services
<<include>>
consulter l'état du cloud
Figure 3. 2: Diagramme du cas d’utilisation "gérer des projets"
L’administrateur du Cloud gère un ou plusieurs projets. Il peut :

❖ Créer ou supprimer ou modifier un projet.
❖ Attribuer un projet à un domaine.
❖ Attribuer un utilisateur à un projet.
Cas d’utilisation "gérer la liste des images"
La figure 3.3 représente le diagramme du cas d’utilisation de gestion de la liste des images.

ajouter une image
gérer la liste des images

Administrateur
modifier une image
supprimer une image
Figure 3. 3: Diagramme du cas d’utilisation "gérer la liste des images"
L’administrateur du Cloud peut :

❖ Créer une image par le chargement d’un fichier enregistré en local ou dans un site distant.
❖ Modifier une image.
❖ Supprimer une image.
Cas d’utilisation "gérer les utilisateur"
La figure 3.4 représente le diagramme de cas d’utilisation de la gestion d’utilisateur.
ajouter un utilisateur
gérer les utilisateurs

Administrateur affecter un utilisateur à un projet
supprimer un utilisateur
Figure 3. 4: Diagramme du cas d’utilisation "gérer utilisateur"

❖ Créer un utilisateur.
❖ Attribuer un utilisateur à un projet.
❖ Attribuer un rôle à un utilisateur.
❖ Supprimer ou modifier un utilisateur.

Cas d’utilisation "gérer la liste des service"

La figure 3.5 représente le diagramme du cas d’utilisation de la gestion de la liste des services.
Modifier l'état du service
gérer la liste des services consulter la liste des services

Administateur du cloud
Créer un Endpoint
Figure 3. 5: Diagramme du cas d’utilisation "gérer la liste des services"

❖ Consulter la liste des services tel que nova, keystone, glance, cinder…
❖ Créer un Endpoint.
❖ Modifier l’état d’un service.
Cas d’utilisation "consulter l’état du Cloud"

❖ Consulter l’usage du processeur, la mémoire, l’usage disque par les différents projets
créés.
3. Diagramme d’activité
Le diagramme d’activité modélise le comportement du système UML, permettant de
représenter le déclenchement des événements en fonction des états du système.
La figure 3.6 représente le diagramme d’activité du cas d’utilisation "Ajouter une règle
firewall” :

S'authenti fi er
Deci si on_1 [ authenti fi cati on échouée ]
Créer une régl e de fi l trage
Sai si r l es paramétres
Deci si on_2
[ fausses paramétres ]
Figure 3. 6: Diagramme d’activité du cas d’utilisation "Ajouter une règle firewall"
La figure 3.7 représente le diagramme d’activité du cas d’utilisation "Ajouter une instance" :
S'authenti fi er
[ Authenti fi cati on réussi e] [ Authenti fi cati on échouée ]

Deci si on_2
Affi cher l e tabl eau de bord
Créer une i nstance
Lancer un templ ate de VM
[ Dépasser l e quota ]
Deci si on_1
Figure 3. 7: Diagramme d’activité du cas d’utilisation "Ajouter une instance"
La figure 3.8 représente le diagramme d’activité du cas d’utilisation "Ajouter un membre" :

S'authenti fi er
[ Authenti fi cati on échouée ]

Deci si on_1
Aj outer un membre
[ Dépassement du quota ]
Deci si on_2
Sai si r l es coordonées du membre
[ membre exi stant ]
Deci si on_3
Figure 3. 8: Diagramme d’activité du cas d’utilisation "Ajouter un membre"
4. Diagramme de séquence système

Le diagramme de séquence est un diagramme UML qui permet de spécifier les interactions
entre les différentes parties du système. La figure 3.9 représente le diagramme de séquence du
cas d’utilisation "S’authentifier" :
.
Utilisateur Application Web Client plateform Openstack
1:S'authentifier
2: envoyer les paramétres du client
3 : vérifier les paramétres
alt [ paramétres non correctes ]
4: envoyer un message d'erreur

5 : Afficher l'erreur
[ paramétre correctes]
6 : Envoyer le jeton d'accéss

7 : Afficher la page d'acceuil
Figure 3. 9: Diagramme de séquence du cas d’utilisation "S’authentifier"

La figure 3.10 représente le diagramme de séquence du cas d’utilisation "Ajouter une

instance” :
ref
S'authentifier()
1:ajouter une instance
2: afficher une instance prédéfini
3 : Sélectionner instance
4 : lancer le template Build
5: Créer instance
alt [ nombre d'instances > quota ]
6: Envoyer un erreur
7: Afficher un message d'erreur
[ nombre d'instances < quota ]
8: Crée l'instance
9: crée l'instance
Figure 3. 10: Diagramme de séquence du cas d’utilisation "Ajouter une instance"

La figure 3.11 représente le diagramme de séquence du cas d’utilisation "créer une règle de
Firewall" :
ref
S'authentifier()
1:Créer une régle firewall
2: afficher le formulaire
3 : Saisir les paramétres
4 : lancer le template
5: Envoyer les paramétres
6 : vérifier les paramétres
alt [ paramétres non valides ]
7: Envoyer un erreur
8: Afficher un message d'erreur
[ paramétres valides ]
9: Crée la régle
10: crée la régle
Figure 3. 11: Diagramme de séquence du cas d’utilisation "créer une règle de Firewall"

5. Conception de l’architecture SD-WAN

La conception de l’architecture SD-WAN comprend trois étapes : La conception de
l’architecture sur l’application OpenStack, l’intégration du Contrôleur SDN dans Openstack et
la mise en place de SD-WAN.
5.1. Conception de l’architecture d’Openstack
Actuellement Tunisie Telecom déploie chez ses clients des solutions LAN, WAN, et les
équipements CPE. Et afin d’améliorer l’expérience utilisateur, on propose d’implémenter une
architecture réseau basée sur la visualisation des composants réseaux qui sont capables de
rendre virtuelle la plupart des services et fonctions dans le réseau en utilisant Openstack Rocky.
Afin de concevoir notre application, openstack présente trois modèles de déploiement :
❖ Un nœud unique : c’est un nœud ou s’exécutent tous les services d’openstack. Cette
architecture présente un problème d’insuffisance de ressources.
❖ Deux nœuds : au niveau de cette architecture, il y aura un nœud qui joue le rôle du
contrôleur openstack qui contient tous les services openstack à l’exception du service
nova, et un autre nœud qui présente un nœud de calcul (compute node) qui contient le
service nova. Sur le nœud de calcul, on peut créer un ou plusieurs machines virtuelles.
❖ Trois nœuds : au niveau de cette architecture il y aura un nœud contrôleur, un nœud de
calcul qui contient le service nova, et un nœud de réseaux qui contient les composants
du service neutron. Cette architecture est complexe au niveau de la configuration et du
déploiement.
Pour notre projet, nous avons choisi de travailler avec deux nœuds : un nœud de contrôle et un
nœud de calcul.
5.1.1. Le Network as a Service sur Openstack
Le Network as a Service sur OpenStack sert à fournir une connectivité aux instances hébergées
dans le Cloud. Neutron prend en charge la connectivité L2 et L3 des instances.
Le niveau L2 est le transport des paquets dans le même réseau. Le niveau 3 gère le routage des
paquets entre différents réseaux et les fonctions avancées comme dans certains cas le LB.
5.1.1.1. Le Service Réseau Neutron
Comme vue dans la section précédente, Neutron est un composant haut niveau qui est capable
d’interagir avec beaucoup de solutions sous-jacentes. Il est composé de plusieurs sous-services
qui sont déployés sur plusieurs nœuds de l’infrastructure OpenStack.
La figure 3.12 représente la répartition des services, plugin et les agents entre les nœuds.

Figure 3. 12: architecture de déploiement de neutron
➢ Neutron server C’est le sous-service principal qui fournit les API réseau. Il utilise la
base de données pour son fonctionnement et un service de messaging queue pour les
communications interservices du Cloud et vers ses agents.
➢ Les plugins Neutron Ce sont des éléments qui s’ajoutent au daemon principal neutron
server. Ils utilisent une grande variété de technologies pour répondre à certaines
requêtes API qui ne seront plus gérées par le service initial. Certains plugins basiques
utiliseront des Iptables, et d’autres s’interfaceront avec les solutions SDN physiques.
Les plugins accèdent également au service de messaging queue. Il existe deux
catégories de plugins, les cores et les services. Les cores plugins gèrent la connectivité
L2 et les IP des instances ; les services plugins gèrent quant à eux le NFV (Network
Function Virtualization) comme le FWaaS et le LBaaS. Exemples de plugins Neutron
: ML2, L3 router, FWaaS,LBaaS
➢ Modular Layer 2 plugin Il s’agit d’un plugin important introduit dans la release
Havana d’OpenStack (fin 2013). Il permet à Neutron d’utiliser une grande variété de
technologies réseau pour la couche L2. Ce plugin supporte différents types de réseaux
au travers d’un type driver : local, flat, vlan, gre tunnel, vxlan. Ce type driver valide la
configuration des réseaux L2 et alloue le réseau niveau Cloud. Ensuite, un "mechanism
driver" applique cette configuration sur le réseau L2. Voici une liste non exhaustive de
"mechanism driver" : Cisco, L2 population, OpenDaylight, OpenvSwich, LinuxBridge.
5.1.1.2. Les agents Neutron
Les agents se trouvent sur chaque compute node (serveurs qui hébergent les instances). Le
choix des agents dépend des plugins qui sont utilisés, certains plugins n’auront pas besoin

d’agents. Parmi les agents, le DHCP et le L3 sont particuliers, ils n’ont pas besoin d’être
présents sur tous les compute nodes. On distingue plusieurs agents tels que :
➢ neutron-dhcp-agent
➢ neutron-linuxbridge-agent
➢ neutron-l3-agent
➢ neutron-OpenvSwitch-agent
➢ neutron-lbaasv2-agent
➢ L3 agent Présent sur des nœuds dédiés au réseau, il s’occupe du routage des réseaux dans
les projets Cloud. Il s’occupe également de certaines fonctions comme le FWaaS et le
NATaaS, LBaaS,VPNaaS.
➢ DHCP agent Présent sur des nœuds dédiés au réseau, il s’occupe du DHCP pour les
réseaux dans les projets Cloud sur lesquels il est activé.
➢ L2 agent Présent sur tous les compute nodes, cet agent est responsable de la segmentation
des réseaux dans le Cloud. Il s’occupe donc de la connexion et de la sécurisation des
interfaces virtuelles. Il dialogue avec la solution SDN pour mettre en place les flux. Il
existe autant de L2 agents qu’il existe de technologies supportées par OpenStack.
La figure 3.13 représente l’architecture de flux de trafic d’une instance
Figure 3. 13: Architecture de flux de trafic d’une instance vers le réseau externe

5.1.2. Les types réseaux virtuels dans Openstack
Openstack permet de créer des réseaux virtuels avancés qui peuvent inclure des services
comme un firewall, un équilibreur de charge, et un réseau privé virtuel (VPN).
Ces services vont être associés par la suite au routeur CPE virtuel. Nous présentons dans cette
partie les types de réseaux virtuels fournis par Openstack ainsi que les services réseaux choisis
à virtualiser.
5.1.2.1. Réseau Option 1 : réseaux fournisseurs
L'option de réseau de fournisseur déploie le service de réseau OpenStack de la manière la plus
simple possible, principalement avec des services de couche 2 (bridging / switching) et la
segmentation de réseaux VLAN. Il relie essentiellement les réseaux virtuels aux réseaux
physiques et s'appuie sur l'infrastructure de réseau physique pour les services de couche 3
(routage). En outre, un service DHCP (Dynamic Host Configuration Protocol) fournit des
informations d'adresse IP aux instances. [Openstack2019]
La figure 3.14 représente la répartition des services pour la première option.
Figure 3. 14: Réseau fournisseur : Plan de service

5.1.2.2. Réseau Option 2 : réseaux libre-service

L’option de réseau self-service complète l’option de réseau de fournisseur avec les services de
couche 3 (routage) qui activent les réseaux en libre-service à l’aide de méthodes de
segmentation de superposition telles que le réseau local virtuel extensible (VXLAN).
Essentiellement, il achemine les réseaux virtuels vers des réseaux physiques à l’aide de la
traduction d’adresses réseau (NAT). De plus, cette option constitue la base de services avancés
tels que LBaaS et FwaaS. L’utilisateur OpenStack peut créer des réseaux virtuels sans avoir
connaissance de l’infrastructure sous-jacente du réseau de données. Cela peut également
inclure les réseaux VLAN si le plug-in layer-2 est configuré en conséquence. [Openstack 2019]
La figure 3.15 représente la répartition des services pour la deuxiéme option.
Figure 3. 15: Réseau libre-service : Plan de services
5.1.2.3. Choix de l’option réseau

Afin de virtualiser les fonctions réseaux et créer les vCPE, on a opté pour la deuxième option
(réseau libre-service) qui permet de supporter les réseaux libre-service (privés), les services
layer-3 (routage) et les services avancés comme LBaaS et FWaaS.

5.2. Les services à virtualiser

Dans le contexte de notre projet, on a choisi de virtualiser les différentes fonctions réseaux les
plus avancées et ceux dont on a besoin telles que NATaas et FWaas :
➢ NATaaS
La translation d’adresses réseau (NAT) est un processus permettant de modifier les adresses
source ou destination dans les en-têtes d’un paquet IP pendant que le paquet est en transit.
En général, les applications émettrices et réceptrices ne sont pas conscientes de la
manipulation des paquets IP. Dans OpenStack, le réseau externe fournit un accès Internet pour
les instances.
Par défaut, ce réseau n’autorise l’accès à Internet qu’à partir d’instances utilisant la traduction.
✓ SNAT (Source Network Address Translation)
Le routeur NAT modifie l'adresse IP de l'émetteur des paquets IP. SNAT est généralement
utilisé pour permettre aux hôtes dotés d'adresses privées de communiquer avec des serveurs
sur Internet.
Il existe différentes variantes de SNAT, sous la forme utilisée par les déploiements OpenStack,
un routeur NAT est à l’intermédiaire entre l'émetteur et le destinataire convertit l'adresse IP
source du paquet en une adresse IP publique du routeur. Le routeur remplace également le port
TCP ou UDP source par une autre valeur, et enregistre la véritable adresse IP et le port de
l'émetteur, ainsi que de l'adresse IP et du port modifiés. [OpenStack 2017]
La figure 3.16 représente la méthode d’accès d’une instance à internet.
Figure 3. 16: Accès d’une instance à internet

Pour aboutir l’accès à Internet à partir de machines virtuelles, le réseau auquel la machine
virtuelle est connectée doit être connecté à un routeur. Ce routeur doit avoir sa passerelle
définie sur le réseau externe déclarée par l’administrateur de l’infrastructure.
➢ DNAT (Destination Network Address Translation)
DNAT - Accès à une VM à partir d’internet la figure 3.17 décrit l’accès à une instance à partir
d’Internet.
Figure 3. 17:Accès à partir d’internet à une instance
Dans la translation d'adresse réseau (DNAT), le routeur NAT modifie l'adresse IP de la

destination dans les en-têtes de paquets IP. OpenStack utilise DNAT pour router les paquets
des instances vers le service de métadonnées OpenStack. Les applications exécutées à
l'intérieur d'instances accèdent au service de métadonnées OpenStack en adressant des
demandes HTTP GET à un serveur Web d'adresse IP 169.254.169.254. Dans un déploiement
OpenStack, aucun hôte ne possède cette adresse IP. Au lieu de cela, OpenStack utilise DNAT
pour modifier l'IP de destination de ces paquets afin qu'ils atteignent l'interface réseau sur
laquelle un service de metadata est à l'écoute.
➢ FWaaS
Le firewall en tant que service permet de renforcer la sécurité interne au niveau du réseaux.
FWaaS utilise iptables pour appliquer une stratégie du firewall au niveau des routeurs virtuels
vCPE. Il permet de filtrer le trafic au niveau des ports internes, ce qui les rend tous protégés.

La figure 3.18 illustre le flux de trafic entrant et sortant de la machine virtuelle :
Figure 3. 18: Flux du trafic entre une instance et le FWaaS
Au niveau d’Openstack, il existe deux versions de firewall :
➢ FWaaS version 1
L’implémentation FWaaS d'origine v1, applique une protection pour les routeurs.
Lorsqu'un firewall est appliqué à un routeur, tous les ports internes sont protégés.
➢ FWaaS version 2
La deuxième implémentation de FWaaS, v2, applique un service beaucoup plus
personnalisé.
La notion du firewall a été remplacée par un groupe de sécurité pour indiquer qu’un
firewall est constitué de deux règles : une règle d’entrée et une règle de sortie.
Un groupe de firewall n’est pas appliqué au niveau de tous les ports du routeur, mais au
niveau d’un port spécifique.
Actuellement, les ports du routeur peuvent être spécifiés. A partir de la version Pike, les
ports de machine virtuelle peuvent également être spécifiés. [Openstack 2018]
Le tableau 3.1 compare les fonctionnalités entre les deux versions :

Tableau 3. 1: Fonctionnalités des deux versions
Fonctionnalités V1 V2
Prise en charge du Firewall L3 pour les
OUI NON
routeurs
Prise en charge du Firewall L3 pour les
NON OUI
ports de routeur
Prise en charge du Firewall L2 (ports
NON NON
VM)
Support CLI OUI OUI
Horizon support OUI NON
6. Intégration du contrôleur SDN opendayligtht dans Openstack

Dans cette partie, nous allons décrire le processus de la mise en œuvre de façon détaillée de
l’intégration des différents composants d’Openstack et Opendaylight.
6.1. Le mécanisme d’intégration d’openstack et opendaylight

Le mécanisme global d’intégration OpenStack et OpenDaylight est schématisé dans la figure
3.19.
Au niveau d’OpenStack, Neutron se compose du pilote ML2, qui fonctionne comme un proxy
REST et qui transmet toutes les requêtes d’API Neutron à OpenDaylight.
OpenDaylight contient un service REST Northbound appelé service API Neutron qui
encapsule les données de ces appels d’API par proxy et les met à la disposition d’autres services
au sein d’OpenDaylight.
Les API REST ouvre la communication entre les composants d’Openstack avec Opendaylight.
La figure 3.19 représente le type de communication entre Neutron et ODL.
Figure 3. 19: La communication entre APIs de Openstack et Opendaylight

6.2. Concept du plugin modulaire de Neutron ML2

Le plug-in ML2 est un Framework Neutron qui expose son interface pour les ensembles
intégrables de pilotes spécifiques de deux types :
❖ Type de pilote pour les réseaux de la couche 2.
❖ Les mécanismes d’accès réseau pour la connexion aux réseaux.
La figure 3.20 représente les types des pilotes et les mécanismes de ML2.
Figure 3. 20: Plugin ML2 du composant neutron
Un Mechanism Driver est appelé lors de la création, de la mise à jour et de la suppression des
réseaux, des sous-réseaux ou de ports.
Chaque Mechanism Driver utilise les ressources et les informations fournies par le
TypeDriver sélectionné. [Kokhan 2014b].
Il y’a quatre TypeDriver utilisés par le plugin ML2 pour les réseaux :
❖ Local : fournit la connectivité entre les machines virtuelles et les autres périphériques
fonctionnant sur le même nœud et ne fournit aucune connectivité entre les nœuds.
❖ Flat : fournit la connectivité entre les machines virtuelles et les autres périphériques
utilisant un réseau physique qui répond à la norme IEEE 802.1D sans utiliser de réseaux
locaux virtuels, de tunnellisation ou d’autres techniques de segmentation.
❖ Vlan : fournit une connectivité entre les machines virtuelles et les autres périphériques
utilisant un réseau physique qui répond à la norme IEEE 802.1Q. Le réseau physique
est segmenté via les entêtes de VLAN donc il peut supporter jusqu’à 4094
segments sur chaque réseau physique.
❖ GRE et VxLAN : fournit une connectivité entre les machines virtuelles et d’autres
nœuds via l’utilisation des mécanismes de tunnelisation pour l’organisation de
segments de reseau. [Kokhan 2014b]

6.3. Intégration API Neutron dans Opendaylight
OpenDaylight expose le service API OpenStack Neutron - qui fournit la gestion des API
Neutron pour plusieurs implémentations. La figure 3.21 résume l'architecture de la mise en
œuvre de l'API Neutron dans OpenDaylight. Le service de l'API Neutron est principalement
composé de trois bundles différents - l'API Northbound, l'interface de fournisseur Neutron
Southbound (SPI) et le transcriber et un ensemble d'implémentations. [Rao 2015]
Figure 3. 21: Intégration ODL dans Openstack
L’avantage d’OpenDaylight est qu’il supporte plusieurs implémentations de réseaux Neutron,

en offrant plusieurs scénarios pour s’intégrer à OpenStack. OpenDaylight comprend les
options suivantes pour les implémentations d’API Neutron : OVSDB, VTN MANAGER,
Open DOVE, LISP flowMapping.
Conclusion
Dans ce chapitre, nous avons introduit les différentes étapes de la conception de la solution
SD-WAN tout en présentant les différents composants qui constituent la solution.
Nous avons commencé par dégager les différents besoins fonctionnels et non fonctionnels.
Ensuite, nous avons défini les différents cas d’utilisation. Par la suite, nous avons défini les
différents mécanismes et technologies adoptés pour satisfaire ces besoins.
Nous avons aussi détaillé, en dernier lieu, la démarche d’intégration entre les différentes
solutions. Le chapitre suivant sera consacré pour la réalisation de l’application.

Chapitre 4 : Réalisation
Introduction
Dans ce chapitre, nous allons exposer le travail achevé. Nous présenterons en premier lieu
l’environnement matériel et logiciel du projet. Ensuite, nous présentons la mise en œuvre de
l’architecture SD-WAN avec tous ces composants (solution cloud, et solution SDN).
Puis, nous introduisons l’étape de l’implémentions de notre solution ainsi que les tests
effectués, les résultats obtenus et les différentes interfaces de l’application client que nous
avons développé.
1. Environnement matériel et logiciel

Dans cette partie, nous allons présenter les différents outils et technologies réseaux, cloud et
virtualisation, que nous avons utilisés dans la réalisation de notre projet.
Le tableaux 4.1 représente l’environnement matériel et logiciel pour la réalisation de notre
projet.
Tableau 4. 1: L’environnement matériel et logiciel
Elements Technologies
Openstack Controlleur Serveur HPE Proliant DL380 Gen 9 | 92 Go RAM
Noeud Compute KVM Serveur HPE Proliant DL380 Gen | 32 Go RAM
Noeud Compute VMware ESXi Serveur HPE Proliant DL380 Gen 8 | 128 Go RAM
OpenDaylight SDN Controlleur Serveur IBM System X3650 M3 | 16 Go RAM
Solution Cloud Openstack: version Rocky: 3 Noeuds (1 control, 2

Compute)
Framework web Django version 2.0
Language de programmation Python, HTML5, CSS3, JQUERY
SDK utilisé pour OpenStack Python-nova, Python-glance, Python Heat, Python
Keystone
2. Présentation de la maquette
Afin de bien mettre en évidence les objectifs à atteindre par notre application, nous avons
déployé sous l’infrastructure physique la maquette illustrée dans la figure 4.1.

Figure 4. 1: Architecture de déploiement
3. Mise en place de l’application OpenStack

3.1. Architecture logique
Au niveau du site cloud de Tunisie Telecom, nous avons opté pour l’utilisation de modèle de
déploiement OpenStack avec deux Nœuds, un nœud de contrôleur et un noeud de calcul
(Compute). La figure 4.2 illustre l’architecture de notre application OpenStack.
Au niveau de notre architecture, on a trois types d’instance d’OVS : br-int : c’est le bridge
d’intégration qui prend en charge les services réseau tel que DHCP. Il est utilisé pour
implémenter le mode de réseau neutron.
br-tun : c’est un bridge de connectivité physique. Son rôle principal est d’encapsuler le trafic
des réseaux virtuels dans un tunnel crypté passant par le réseau physique (undelay).
Dans notre cas, VXLAN est la technique utilisée pour séparer les réseaux neutron.
br-ex : c’est un bridge qui permet d’établir la connectivité des réseaux de neutron à l’extérieur.
Au niveau connectivité, on identifie :
➢ Le réseau public (provider network) sur la plage d’adresse 10.55.72.192/26 avec une
passerelle 10.55.72.254. Ce réseau permet aux instances d’OpenStack de se connecter au
réseau public.
➢ Le réseau de données (VM data network) : sur la plage 172.16.1.0/24. Il permet aux
instances de communiquer entre elles et avec les services L3 et DHCP du réseau.

Figure 4. 2: Architecture logique d’OVS
3.2. Préparation d’environnement de travail

Au niveau de cette section, nous allons présenter l’architecture matérielle ainsi que sa
configuration et la méthode de déploiement d’OpenStack Rocky.
Dans notre projet, nous allons installer la version OpenStack Rocky par la méthode manuelle
sur deux nœuds Ubuntu 18.04 LTS (Controller, Compute), nous utiliserons un réseau interne
basé sur VXLAN pour la communication entre Nova Instance.

Environnement utilisé :
• Réseau public/fournisseur (réseau IP flottant) : 10.55.72.192/26
• Noeud de contrôle public IP : 10.55.72.210 (eno0)
• Réseau interne de données : 172.16.0.10 (eno1)
• Noeud de Calcul public IP : 10.55.72.212 (eno0)
• Réseau interne de données IP : 172.16.0.20 (eno1)
• Hyperviseur Type : QEMU / KVM
• Version du SE (chaque nœud) : Ubuntu 18.04 LTS Bionic Beaver
Pour que l’installation de la version OpenStack Rocky se déroule sans erreurs, certaines
configurations d’interfaces réseau doivent être effectuées sur tous les nœuds OpenStack avant
l’installation. Nous avons introduit dans l’annexe A, une description détaillée des étapes de
configuration.
Nous avons installé et configuré de façon manuelle sans utiliser aucun outil d’automatisation
de déploiement et d’installation comme Ansible ou Puppet pour des raisons de production.
3.3. Vérification et test de l’application
Cette étape permet de tester les différentes fonctionnalités attendues de notre site Cloud. Nous
avons commencé par la création d’un projet client qu’on a nommé testbed.
Ensuite nous avons créé un quota avec des paramètres bien définis. La figure 4.3 affiche les
paramètres du quota du composants neutron.
Figure 4. 3: Création de Quota

Ensuite, au sein de projet admin, nous avons créé un utilisateur Membre nommé personnel et
un utilisateur administrateur du projet "testbed" nommé adm. Les figures 4.4 et 4.5 représentent
respectivement les commandes de création des utilisateurs personnel et adm.
Figure 4. 4: Création de l’utilisateur personnel
Figure 4. 5: Création de l’utilisateur adm
L’affectation des rôles Membre et Administrateur aux utilisateurs personnel et adm est
représentée dans les figures 4.6 et 4.7.
Figure 4. 6: Affectation du rôle membre à personnel
Figure 4. 7: Affectation du rôle Administrateur à adm

Par la suite, nous avons défini les flavors qui vont être utilisés par le composant Nova pour
lancer les instances. Nous avons créé un flavor m2 nano. La figure 4.8 représente la commande
de création d’un flavor pour lancer des instances avec ces caractéristiques.
Figure 4. 8: Création d’un flavor
➢ Création et gestion des images

Au niveau de notre projet, nous avons créé deux images qu’on a nommé Ubuntu1804 et Cirros.
La figure 4.9 représente l’étape de création d’une image Ubuntu dans Glance Registry.
Figure 4. 9: Création d’image
3.4. Configuration réseau du composant Neutron

➢ Configuration du réseau interne (Self-service)
Au niveau de notre application OpenStack, nous avons commencé par la configuration du
réseau Interne (Self-service Network) sur la plage 172.16.1.0/24 avec la passerelle 172.16.1.1.
En premier lieu, nous avons créé un réseau interne qu’on a nommé "int_net".

La figure 4.10 représente l’étape de création du réseau interne "int_net".
Figure 4. 10: Création du réseau int_net
Par la suite, on a créé le sous réseau "selfservice" qu’on va associer au réseau "int_net". La
figure 4.11 représente l’étape de création du sous réseau selfservice.
Figure 4. 11: Création du sous réseau interne "selfservice"
➢ Configuration du réseau public (réseau fournisseur)

Nous avons commencé par créer le réseau externe qu’on a nommé "provider". La figure 4.12
représente l’étape de création du réseau public fournisseur.

Figure 4. 12: Création du réseau externe "provider"
Par la suite, nous avons créé le réseau public (réseau fournisseur) sur la plage d’adresse
10.55.72.192/26 avec la passerelle 10.55.72.254 vers le routeur physique Gateway du
Datacenter. La figure 4.13 représente l’étape de création d’un sous-réseau avec ses paramètres.
Figure 4. 13: Création du sous réseau externe "provider"
3.5. Création du routeur virtuel vCPE
Afin de créer le routeur virtuel, nous avons exécuté la commande représentée dans la figure
suivante :

Figure 4. 14: Création du routeur virtuel
Par la suite, nous avons configuré la passerelle vers le réseau externe. Ensuite, nous avons
attribué le réseau interne à l’interface du routeur virtuel.
Afin de vérifier le bon déroulement de la création du réseau et de routeur virtuel, nous pouvons
lister les espaces de noms ainsi que les ports connectés au routeur afin de déterminer les
adresses IP des passerelles du routeur vers le réseau interne et le réseau public.
La figure 4.15 représente les identifiants et les adresses IP affectées aux ports du routeur.
Figure 4. 15: Liste des espaces des noms et des ports
3.6. Gestion des groupes de sécurité

Par défaut, le groupe de sécurité « default » s’applique à toutes les instances et comprend des
règles de pare-feu qui refusent l’accès à distance. Pour l’image Linux «tel », que nous allons
utiliser pour la création d’une instance, nous avons créé notre propre groupe de sécurité qu’on
a nommé "secgroupe01" dans lequel nous avons permis le trafic ICMP ainsi que le trafic Web
et SSH. La figure 4.16 représente la création d’un groupe de règles de sécurité.

Figure 4. 16: Création des groupes de sécurité
3.7. Création d’instance

Afin de lancer une instance, nous devons spécifier le nom de l’image, le flavor, le nom du
réseau interne privé ainsi que le groupe de sécurité. Le flavor spécifie un profil d’allocation de
ressources virtuelles qui comprend le nombre de processeur virtuel, la RAM allouée, l’espace
de SWAP et la taille du disque. Nous vérifions le succès de la création de l’instance comme
suit :
Figure 4. 17: Vérification et test de la création d’instance du réseau public (réseau fournisseur)
Nous pouvons accéder à distance à notre instance via SSH ou à travers le système VNC.

3.8. Virtualisation des fonctions réseau NATaaS et FWaaS

➢ NATaaS
La fonction NAT traduit les adresses privées internes en une ou plusieurs adresses publiques
pour le routage sur Internet. La fonction NAT remplace l’adresse source IP privée contenue à
l’intérieur de chaque paquet par une adresse IP enregistrée publiquement avant d’envoyer le
paquet sur Internet.
Afin de bénéficier du service NAT, nous avons recours à l’utilisation des adresses IP flottantes.
En effet, le réseau public (provider) offre aux instances du réseau privé self-service un accès
vers l’extérieur à travers la translation d’adresse privée en adresse publique en utilisant les
adresses IP flottantes.
Nous avons commencé par créer l’adresse IP flottante. La figure 4.18 représente la commande
d’allocation d’une adresse IP flottante de pool des adresses disponibles.
Figure 4. 18: Création d’une adresse IP flottante
Ensuite, nous avons affecté cette adresse à l’instance "cirros" du réseau privé.
La Figure 4.19 représente l’étape d’affectation d’une adresse IP flottante à une instance du
réseau privé.
Figure 4. 19: Affectation d’adresse IP flottante à l’instance du réseau privé
Par la suite, nous avons testé la connectivité entre les deux instances "cirros" et "cirros123".
La Figure 4.20 représente le résultat de test de connectivité entre les instances.

Figure 4. 20: Vérification de connectivité entre les instances
4. Mise en place de la solution SD-WAN Contrail
4.1. Architecture physique
La figure 4.21 représente l’architecture globale de la solution SD-WAN Contrail.
Figure 4. 21: Architecture globale de SD-WAN Contrail
Chaque entreprise cherche à avoir une haute disponibilité de ses services numériques et une
meilleure qualité de la connectivité entre ses différents sites et avec ses clients parce que de
nos jours, on parle de la digitalisation de tous les services pour amplifier le gain en termes de
temps, flexibilité et ressources physiques et humaines. Donc pour les assurer, il faut mettre en
place des mécanismes opérationnels et efficaces, des liaisons de connections WAN
redondantes (MPLS, SDSL ,4G …) et des services virtualisés hébergés au niveau du Cloud
Provider. Mais, ces mécanismes n’ont jamais satisfaits les clients pour des divers raisons dont
la fiabilité et la sécurité des services hébergés, l’intervention humaine dans le cas de défaillance
des liaisons WAN et l’incapabilité de réagir dans le cas de dégradations de la qualité de service
des liaisons, d’où vient l’apport de la solution SD-WAN qui résout toutes ces contraintes par
l’automatisation de la configuration des CPE ( Zero Task Provisioning ).

Tout le traitement sera centralisé dans un orchestrateur Contrail Service Orchestrator (CSO)
hébergés au niveau de l’infrastructure cloud publique AWS, qui va charger la configuration au
niveau de chaque CPE des sites distants.
Dans notre cas, le fournisseur Tunisie Télécom a signé un contrat de partenariat avec le
constructeur Juniper Networks pour lui fournir de ses technologies. Comme CPE et vCPE, ils
ont choisi la série SRX 320, 4100 et l’image vSRX 0.5.
La figue ci-dessous illustre l’attribution des addresses IP aux interfaces pour connecter un
vSRX au réseau local et aux 2 liaisons WAN.
Figure 4. 22: Attribution des adresses IP du vCPE
Dans notre cas, avant l’ajouter de vCPE (vSRX) à l’orchestrateur qui va automatiser sa
configuration par le moyen d’un template lancé au niveau de sa plateforme, il faut copier le
numéro de série du produit qui est unique et qui va assurer l’identification du vSRX.
La figure ci-dessous illustre la commande qui affiche les caractéristiques physiques.
Figure 4. 23: Identifier le numéro de série du vCPE

4.2. Vérification et test de la solution FWaaS

Après la préparation de l’environnement au niveau du vCPE (vSRX), on doit l’ajouter au
niveau de la platefome de l’orchestrateur CSO pour qu’il le prend en charge sous son autorité.
La figure 4.24 illustre l’interface d’ajout des CPE.
Figure 4. 24: Ajout d’un vCPE au niveau de l’orchestrateur CSO
Dans notre cas, on a choisi l’image du SRX 320 qu’on possède déjà dans notre local et on a
copié le numéro de série du produit dans l’interface. La figure 4.25 représente l’interface de
saisi de numéro de série du vCPE.
Figure 4. 25: Affectation du numéro de série du vCPE à son image
Pour l’auto-installation ou ce qu’on appelle le Zero Touch Provisioning (ZTP), c’est

l’automatisation de la configuration du vSRX, on a besoin de lancer un template bien

spécifique à développer qui contient les différents paramètres de la configuration. La figure

4.26 illustre le script d’initialisation du vSRX.
Figure 4. 26: script d’auto-installation ZTP
Enfin, après quelque temps de chargement de la configuration de l’orchestrateur CSO vers le

vSRX nommé Hamza-vSRX, le vCPE est en état opérationnel et le site provisionné. La figure
4.27 représente la liste des différents vCPE.
Figure 4. 27: Liste des vCPE des différents sites
Parmi les services fournis par l’orchestrateur CSO hébergé dans le cloud le Firewall as a
Service FWaaS, on peut y définir des politiques des sécurité pour les différents vCPE qui
appartiennent au même domaine dans le CSO. La figure ci-dessous illustre une règle de filtrage
qui permet au vCPE Hamza-vSRX d’accéder à internet.

La figure 4.28 représente l’interface d’ajout des règles de filtrage.
Figure 4. 28: Ajout d’une politique de sécurité du Firewall du vCPE
Dans la figure 4.29, nous avons mis des règles de filtrage pour bloquer le contenu de quelques
sites internet consultés par le personnel de notre local, ici, ce n’est pas le cas du filtrage web
classique parce que ce dernier bloque l’accès par le nom de domaine du site mais la nouvelle
génération est plus avancée elle bloque le contenu du site. La figure ci-dessous illustre la liste
des règles de filtrages.
Figure 4. 29: Liste de règles de filtrage du vCPE
4.3. Vérification et test de la solution SD-WAN

Pour tester cette fonctionnalité, nous devons avoir au minimum une paire de liaison WAN
(Internet ou MPLS), que ce soit pour le cas de CPE physique de série SRX3xx ou de vSRX
l’instance de CPE, pour que nous pouvons générer un trafic sur les 2 liaisons en définissons
des mesures de QoS (Jitter, Latence,Packet Loss) dans un profile SLA à respecter sinon la
génération du trafic sera basculer vers l’autre liaison dans cas qu’ils ne sont pas assurées. Tout
d’abord, il faut les définir ces mesures par la création d’un profile SLA et la figure ci-dessous
l’illustre :

Figure 4. 30: Création d’un profile SLA
Puis nous allons choisir le trafic du Microsoft Office à générer pour tester les liens avec les
mesures définies. La figure 4.31 représente l’interface de création d’une stratégie SD-WAN.
Figure 4. 31: Déploiement d’une stratégie SD-WAN
Finalement, nous pouvons remarquer le basculement du trafic entre la première liaison WAN1
vers WAN0, lorsqu’il y a eu un dépassement de mesures de SLA définies d’avance, il est
indiqué par le curseur en bleu ou on voit le pique de trafic sur WAN0 après le dépassement de
la limite de la latence (130 ms). La figure 4.32 illustre le basculement du trafic entre les 2 liens
WAN.

Figure 4. 32: Basculement du trafic entre les 2 liens WAN
5. Réalisation du Portail Client

5.1. Interface de l’application Web
Dans cette partie, nous allons définir le contenu des différentes interfaces du portail Web ainsi
que les différents objets interactifs avec les API des services hébergés au niveau de
l’infrastructure cloud Openstack qui sont mis à la disposition de l’utilisateur. Lors du
démarrage de l’application Web, le client sera dirigé vers l’interface de l’authentification ou il
va saisir ces coordonnés d’accès.
La figure 4.33 représente l’interface d’acceuil.
En cas de succès de l’authentification, le client sera redirigé vers l’interface d’accueil qui
contient en premier lieu les différentes instances disponibles dans son projet.
La figure 4.34 illustre l’interface d’accueil du portail.
Figure 4. 33: Interface d’authentification

Figure 4. 34: Interface d’acceuil
Au niveau de l’interface d’accueil, le client peut lancer ou arrêter ces instances, aussi il peut
associer une adresse IP flottante à travers le menu déroulant. Il peut aussi consulter les
différentes informations concernant une instance tel que son état (shutdown, running), son
adresse IP et leur type fixe ou translaté et MAC.
La figure 4.35 représente l’interface "Create VM" qui va afficher les différents templates de
VM prédéfinis que le client peut choisir.
Figure 4. 35: Interface de création d’instance

La figure 4.35 représente l’interface “Create user” qui affiche tous les utilisateurs qui
appartiennent au même projet.A travers cette interface, on peut aussi ajouter un autre utilisateur
au projet.
Figure 4. 36: Interface de création d’un utilisateur
La figure 4.37 représente l’interface "My vRouter” qui affiche les différentes informations
concernant les routeurs virtuels associés au projet du client de l’entreprise.
Figure 4. 37: Interface liste des routeurs virtuels
La figure 4.38 représente l’interface "My subnets" qui affiche les adresses réseau allouées
automatiquement au moyen du service d’attribution dynamique DHCP du réseau du
gestionnaire de cloud.

Figure 4. 38: Interface liste des sous-réseaux
La figure 4.39 représente l’inteface "My floating ip" qui affiche les différentes adresses IP
flottantes (publiques) dans le projet. A travers cette interface, on peut libérer une adresse IP
flottante d’une instance, on peut aussi la créer et l’associer à une instance.
Figure 4. 39: Interface liste des floating IPs

Conclusion
Dans ce chapitre, on a présenté la phase de réalisation. En effet, on a commencé par
implémenter l’architecture Cloud sur l’instructeur physique du fournisseur Tunisie Télécom,
et on a ajouté un autre niveau de contrôle sur la connectivité Réseau par une solution SD-
WAN.
Ensuite, nous avons présenté les différentes configurations et les tests effectués, ainsi que la
réalisation de notre application web qui représente un portail pour les clients de Tunisie
Telecom.

Conclusion générale
Conclusion générale
L’objectif de notre projet de fin d’étude consiste à mettre en place une architecture SD-WAN
pour le fournisseur de service. En effet notre projet s’articule sur quatre volets à savoir : la
mise en place d’une solution cloud privée, la virtualisation des fonctions réseaux dans
l’environnement Cloud, le contrôle du réseau à travers un contrôleur SDN et le développement
d’une application web qui permet au client de gérer sa propre infrastructure.
Dans la première partie, nous avons abordé la mise en place d’une architecture IaaS sur des
différents nœuds afin de déployer la plateforme Openstack. Pour ce faire, nous avons mené
une étude comparative sur les solutions opensource qui a abouti à la sélection de ce dernier.
La deuxième partie était consacrée à ajouter une couche de contrôle de service réseau, il s’agit
de virtualiser les services réseaux avec Openstack et de contrôler le fonctionnement avec
OpenDayLight. La troisième partie était la mise en place d’une solution SD-WAN pour le
contrôle des liaisons WAN et MPLS de l’entreprise et assurer la continuité de la génération du
trafic avec une haute disponibilité et d’une façon plus sécurisée.
La quatrième partie introduit le développement de l’application Web qui est un portail pour le
client afin qu’il puisse gérer sa propre infrastructure virtuelle au sein du Cloud.
L’expérience au sein d’un cadre professionnel, a été très bénéfique. Ce stage m’a permis de
me familiariser à la vie professionnelle, d’exploiter des notions fondamentales dans le domaine
des réseaux et du cloud, et de prendre en main la gestion d’une infrastructure réseau et système
ce qui m’a aidé à approfondir ma maîtrise technique sur les technologies IT.
En termes de perspectives, notre projet pourrait être enrichi par d’autres améliorations, à
savoir :
❖ La mise en place d’une solution de haute disponibilité du contrôleur Openstack
❖ L’exploitation d’autres composants d’OpenStack tel que ZUN qui assure le service de
conteneurisation des applications en tant que service (Docker).
❖ Le développement d’autres services et fonctionnalités pour le client sur son portail tel
que la création des routeurs virtuels, la gestion des volumes.

Bibliographie
Bibliographie
✓ [ONUG] https://www.onug.net/community/working-groups/software-defined-wide-
areanetwork-sd-wan/
✓ [NIST] https://www.nist.gov/news-events/news/2011/10/final-version-nist-cloud-
computingdefinition-published
✓ [DOTTA 2017] Virginie DOTTA. Après le Cloud, place aux réseaux programmables.
https://theexpert.squad.fr/virtual-infrastructure/cloud-computing
sdn.%20html,%20Avril%202017.
✓ [Hachicha 2017] Mokhless Hachicha. Un datacenter dans le cloud Public/HA IaaS
https://www.slideshare.net/MokhlessHachicha/sdn-opendaylight
✓ [ONF] https://www.opennetworking.org/sdn-definition/
✓ [Openstack 2019] https://docs.openstack.org/neutron/rocky/install/common/get-
started-networking.html
✓ [EMC] http://aad.tpu.ru/practice/EMC/ISM%20v2_with_notes.pdf
✓ [OpenDaylight ] https://www.opendaylight.org/what-we-do/odl-platform-overview
✓ [JRES 2017] https://conf-ng.jres.org/2017/document_revision_2938.html?download
✓ [Juniper Contrail] https://www.juniper.net/us/en/products-
services/sdn/contrail/contrail-sd-wan/
✓ [Kokhan 2014b] https://plvision.eu/rd-lab/blog/sdn/openstack-icehouse-networking-
keypoints
✓ [Rao 2015] https://thenewstack.io/opendaylight-is-one-of-the-best-controllers-for-
openstack-heres-how-to-implement-it/
Hamza Chouchene 2018/2019 i

Annexe
Annexe
I. Les différentes configurations nécessaires pour l’installation

d’Openstack
1. Configuration des interfaces réseau du nœud contrôleur :

➢ La première interface eno1 sert à connecter le contrôleur avec un switch qui interconnecte
les autres nœuds dans le même réseau local et pour qu’il puisse avoir un accès à l’internet
à travers la passerelle qui est un routeur Cisco de la série 2901.
➢ La deuxième interface eno2 est dédié pour la tunnelisation VXLAN qui sera établie entre
les instances afin qu’elles se communiquent entre eux.
La configuration se fait dans la distribution de Linux, Ubuntu 18.04 LTS sous le fichier :
/etc/netplan/ 50-cloud-init.yaml , les deux figure A.1 représente la configuration de interfaces.
Figure A.1 : La configuration des interfaces du contrôleur
Hamza Chouchene 2018/2019 ii

Annexe
2. Configuration des interfaces réseau du nœud de calcul (Compute) :

Pour les configurer, il faut suivre les mêmes étapes que le nœud du contrôleur puisqu’il utilise
la même distribution de Linux Ubuntu 18.04 LTS, la figure A.2 la configuration des interfaces.
Figure A.2 : La configuration des interfaces du compute

3. Configuration des serveurs de synchronisation NTP :
Pour le bon fonctionnement des composants Openstack, il est nécessaire d’installer un serveur
de synchronisation pour que la communication entre les APIs ne sera pas en décalé ce qui
induit à l’échec de lancement des services d’où l’échec du lancement des instances.
Pour cette raison, nous avons installé le serveur Chrony qui est recommandé par la
documentation officielle d’Openstack Rocky, et nous avons choisi des serveurs japonais qui
assurent un minimum de temps de latence (ntp1.jst.mfeed.ad.jp, ntp2.jst.mfeed.ad.jp,
ntp3.jst.mfeed.ad.jp), la figure A.3 représente la configuration du Chrony.
Figure A.3 : la configuration du Chrony
Hamza Chouchene 2018/2019 iii

Annexe
4. Installation des packages d’Openstack Rocky :

Pour l’installation des packages d’Openstack Rocky sous Ubuntu 18.04 LTS, il suffit
d’exécuter les commandes affichées dans la figure A.4.
Figure A.4 : Les commandes d’installation des packages Openstack

5. Test et vérification de fonctionnement des composants d’Openstack Rocky :
Figure A.5 : Vérification des services Openstack

II. Intégration d’API Neutron dans OpenDaylight :
1. Les fonctionnalités nécessaires pour l’intégration avec Opendaylight :
Il faut tout d’abord installer les fonctionnalités responsables à la configuration des équipements
réseau par le moyen des langages de manipulation des données et les modéliser comme le
NETCONF, pour avoir une structure avec format lisible de XML à travers la langage YANG.
Les fonctionnalité dlux sont pour la partie interface graphique afin de faciliter la gestion des
équipements. La fonctionnalité netvirt-impl ou netvirt-openstack est responsable de la
communication de l’API du neutron et OpenDaylight plus précisément, intégration du
TypeDriver du ML2 que nous avons bien expliqué son rôle dans les chapitres précédents.LA
figure A.6 représente les fonctionnalités nécessaires pour l’intégration.
Hamza Chouchene 2018/2019 iv

Annexe
Figure A.6 : Les fonctionnalités nécessaires pour l’intégration
2. Les étapes à suivre pour l’intégration d’Opendaylight avec Neutron :

Pour éviter le conflit de l’essai de contrôle de la part de deux contrôleur SDN en même temps,
Il faut désactiver le serveur Neutron et son agent Open vSwitch afin qu’il donne la main à
Opendaylight, la figure A.7 montre les étapes de désactivation du Neutron et OVS.
Figure A.7 : Les étapes de désactivation de Neutron
Hamza Chouchene 2018/2019 v

Annexe
Hamza Chouchene 2018/2019 vi

Langue

Rapport PFE 2019 Final PDF

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

Rapport PFE 2019 Final PDF

Transféré par

Droits d'auteur :

Formats disponibles

2018 - 2019

Conception et implémentation d’une solution

Réalisé par : Hamza Chouchene

Encadrant ESPRIT : Mme Olfa Chabbouh

Encadrant Entreprise : Mme Fatma Ghandour

En particulier l’expression de ma très grande reconnaissance à Mme Fatma Ghandour, et

Introduction Générale ............................................................................................................. 1

Chapitre 1 : Cadre du projet .................................................................................................. 3

1. Présentation de l’entreprise d’accueil ............................................................................. 3

2. Présentation générale de Tunisie Telecom ..................................................................... 3

1.1. Les services de Tunisie Telecom ............................................................................. 3

1.2. Organigramme de Tunisie Telecom ........................................................................ 4

3. Présentation du Projet ..................................................................................................... 4

3.1. Le contexte du projet ............................................................................................... 5

3.2. Problématique .......................................................................................................... 6

3.3. Objectifs et fonctionnalités ...................................................................................... 7

Chapitre 2 : Etat de l’art ....................................................................................................... 11

1.1. Introduction ........................................................................................................... 11

1.2. Définition du SD-WAN ......................................................................................... 11

1.3. Choix de la solution utilisée .................................................................................. 12

2.1. Définition du Cloud Computing ............................................................................ 13

2.2. Le besoin au Cloud Computing ............................................................................. 13

2.3. Les cinq caractéristiques du cloud computing ....................................................... 14

2.4. Les bénéfices du cloud .......................................................................................... 15

2.5. Modèles de services ............................................................................................... 16

2.6. Etude comparative et choix de la solution Cloud .................................................. 19

2.6.1. Solutions open source existantes .................................................................... 19

2.6.2. Architectures et Services ................................................................................ 19

2.6.4. Réseaux .......................................................................................................... 21

2.6.5. Choix de la solution Cloud ............................................................................. 22

2.6.6. Les composants d’OpenStack ........................................................................ 23

3.1. Définition du SDN (Software Defined Network) .................................................. 28

3.2. Plan de composition des équipements réseaux ...................................................... 30

3.3. Étude comparative et choix de la solution SDN .................................................... 30

3.3.1. Comparaison des contrôleurs Open-Source ................................................... 31

3.3.2. Solution SDN adoptée .................................................................................... 32

Chapitre 3 : Spécification des besoins et conception .......................................................... 34

1. Identification des besoins .............................................................................................. 34

1.2. Besoins fonctionnels de la solution Cloud ............................................................ 34

1.3. Besoin fonctionnel de la solution SDN ................................................................. 35

1.4. Besoin non fonctionnel .......................................................................................... 35

2. Diagramme des cas d’utilisation ................................................................................... 36

2.1. Diagramme de cas d’utilisation général ................................................................ 36

2.2. Raffinement des cas d’utilisation .......................................................................... 37

4. Diagramme de séquence système ................................................................................. 41

5. Conception de l’architecture SD-WAN ........................................................................ 44

5.1. Conception de l’architecture d’Openstack ............................................................ 44

5.1.1. Le Network as a Service sur Openstack ......................................................... 44

5.1.1.1. Le Service Réseau Neutron ........................................................................ 44

5.1.1.2. Les agents Neutron ..................................................................................... 45

5.1.2. Les types réseaux virtuels dans Openstack .................................................... 47

5.1.2.1. Réseau Option 1 : réseaux fournisseurs ...................................................... 47

5.1.2.3. Choix de l’option réseau ............................................................................. 48

5.2. Les services à virtualiser........................................................................................ 49

6. Intégration du contrôleur SDN opendayligtht dans Openstack .................................... 52

6.1. Le mécanisme d’intégration d’openstack et opendaylight .................................... 52

6.2. Concept du plugin modulaire de Neutron ML2..................................................... 53

6.3. Intégration API Neutron dans Opendaylight ......................................................... 54

Chapitre 4 : Réalisation ......................................................................................................... 55

1. Environnement matériel et logiciel ............................................................................... 55

2. Présentation de la maquette .......................................................................................... 55

3. Mise en place de l’application OpenStack .................................................................... 56