Soutenance mémoire
Télécharger le fichier pdf d’un mémoire de fin d’études
Études de différentes couches de l’architecture SDN
Un réseau SDN est composé de trois couches comme le montre la figure 2.1 (la couche applicative, la couche de contrôle et la couche d’infrastructure) reliées via des API ascendantes (Northbound) et des API descendantes (Southbound).
La couche applicative comprend des fonctions applicatives et réseau, comme des pare-feu et un équilibreur de charge. Les réseaux traditionnels utilisent une appliance spéciale pour ces fonctions tandis qu’un réseau SDN utilise le contrôleur pour gérer le comportement du panneau de données. La couche de contrôle gère les stratégies et le flux du trafic au sein de l’ensemble du réseau. La couche d’infrastructure est constituée des commutateurs physiques du réseau. Chaque couche a ses propres fonctions spécifiques. Alors que certaines d’entre elles sont toujours présentes dans un déploiement SDN, comme l’API Southbound, les systèmes d’exploitation de réseau ou contrôleur, l’API Northbound et les applications de réseau, d’autres peuvent être présentes uniquement dans les déploiements particuliers, tels que l’hyperviseur ou la virtualisation basée sur le langage et les APIs Est/Ouest. Les points suivants présentent chaque couche, selon une approche du bas vers le haut. Pour chaque couche, les propriétés et les concepts de base sont expliqués.
La couche Infrastructure :
La couche infrastructure est constituée des périphériques réseaux physiques et virtuels. Un dispositif SDN est composé d’une API pour la communication avec le contrôleur, une couche d’abstraction, et une fonction de traitement des paquets. Dans le cas d’un commutateur virtuel, cette fonction de traitement des paquets est un logiciel de traitement. Dans le cas d’un commutateur physique, la fonction de traitement des paquets est réalisée dans le matériel pour la logique de traitement. La couche d’abstraction incarne une ou plusieurs tables de flux. La logique de traitement des paquets se compose de mécanismes pour prendre des mesures sur la base des résultats de l’évaluation des paquets entrants et trouver le lien le plus prioritaire.
Lorsqu’une correspondance est trouvée, le paquet entrant est traité localement à moins qu’il ne soit explicitement transmis au contrôleur [7]. En l’absence de correspondance, le paquet ne peut être copié qu’à l’unité de commande du dispositif de commande pour un traitement ultérieur.
Ce procédé est également appelé le contrôleur consommant du paquet. Dans le cas d’un commutateur matériel, ces mécanismes sont mis en oeuvre par le matériel spécialisé. Dans le cas d’un commutateur logiciel, ces mêmes fonctions sont mises en miroir par le logiciel. Depuis, l’affaire du commutateur logiciel est un peu plus simple que le commutateur matériel.
Plus récemment, un rôle a refait surface dans le centre de données pour le commutateur logiciel pur. Un tel commutateur est mis en oeuvre en tant que logiciel d’application qui fonctionne habituellement en conjonction avec un hyperviseur dans un support de centre de données. Comme une VM (Machine virtuelle), le commutateur virtuel peut être instancié ou déplacé sous contrôle logiciel. Il sert normalement de commutateur virtuel et travaille collectivement avec un ensemble d’autres commutateurs virtuels pour constituer un réseau virtuel.
SDN Southbound API :
L’API en direction du sud est l’un des composants les plus critiques d’un système SDN, qui établit une passerelle entre les dispositifs de transfert et le plan de commande. Elle permet au contrôleur de contrôler le comportement du réseau en gérant les entrées de flux de tous les équipements sous-jacents. L’API vers le sud fournit une interface commune aux couches supérieures permettant au contrôleur d’utiliser différentes directions sud APIs (par exemple, OpenFlow, POF, OpFlex et OpenState) et plug-ins de protocole pour gérer les périphériques physiques ou virtuels existants ou nouveaux (par exemple, SNMP, BGP et NetConf). Actuellement, OpenFlow est la norme la plus acceptée pour la norme en direction du sud.
Protocole OpenFlow
OpenFlow est standardisé par l’Open Networking Foundation (ONF). OpenFlow est un protocole qui décrit l’interaction d’un ou plusieurs serveurs de contrôle avec les commutateurs compatibles OpenFlow. Un contrôleur OpenFlow installe les entrées de tables de flux dans les commutateurs, de sorte que ces commutateurs peuvent transférer le trafic en fonction de ces entrées. Ainsi, les commutateurs OpenFlow dépendent de la configuration des contrôleurs.
Un commutateur OpenFlow est déterminé par une ou plusieurs tables de flux (flow table). Chaque table s’assimile à un ensemble de flux, qui consistent chacun en une liste de discriminants relatifs au contenu d’une trame, associée à des actions de traitement à appliquer aux trames correspondantes. Lorsqu’un paquet parvient au switch, les valeurs contenues dans ses en-têtes sont comparées aux différentes valeurs enregistrées dans la première table de flux du switch. Les actions qui peuvent suivre sont de diverses natures : transfert de la trame par une interface, suppression, modification de champs d’en-têtes, et/ou transmission du traitement à une table de flux ultérieure. Le regroupement des flux définit l’intégralité des fonctions qui pourront être appliquées aux paquets reçus par le switch. Un flux par défaut doit être défini pour chaque table, explicitant le comportement à adopter. Lorsqu’une trame ne correspond à aucun flux spécifique, le cas courant comme le montre la Figure 2.2, consiste à envoyer au contrôleur un message de type packet-in. Selon le paramétrage, celui-ci peut contenir l’intégralité de la trame, un nombre limité de ses octets (possiblement aucun) ou encore une référence de mémoire tampon. Le contrôleur répondra généralement par un packet-out donnant l’instruction à suivre.
En mettant en relation une adresse de destination précise, contenue dans l’en-tête des paquets IP, avec une des interfaces en particulier, il est possible d’établir une règle de routage classique. Les spécifications prennent en charge plusieurs types de champs d’en-tête: adresses MAC, identifiants de VLAN, adresses IPv4 et IPv6, ports TCP et UDP, labels MPLS et ainsi fournir un solide remplacement pour le routage sur IP. Le protocole OpenFlow a subi des améliorations rapides depuis la sortie de nombreuses nouvelles versions. Le Tableau 2.1 ci-dessous résume quelques-unes des améliorations significatives d’OpenFlow..
La couche Contrôle :
Est basée sur le contrôleur SDN qui offre une visibilité globale du réseau et des équipements d’infrastructure. Le contrôleur est le coeur du réseau, qui génère des configurations de réseau basées sur les politiques définies par l’opérateur du réseau. Il résume les détails de niveau inférieur et les met à la disposition du plan applicatif via des services essentiels par exemple : la topologie du réseau, l’état, la découverte de périphérique, … etc..
Le contrôleur SDN permet d’implémenter rapidement un changement sur le réseau en traduisant une demande globale (par exemple : prioriser l’application X) en une suite d’opérations sur les équipements réseau (requêtes NetConf, ajouts d’états OpenFlow, configuration en CLI…). Les ordres sont donnés au contrôleur par une application via l’API Northbound. Les éditeurs logiciels de contrôleurs publient la documentation de l’API afin de permettre d’interfacer des applications. Le contrôleur communique avec les équipements du plan de données via une ou plusieurs APIs Southbound. OpenFlow se positionne comme une API sud agissant directement sur le plan de données. D’autres API permettent d’agir sur le plan de management ou de contrôle. NetConf est par exemple une API sud permettant au contrôleur de configurer un équipement. Un contrôleur pourra même parler directement en CLI avec un équipement pour actionner une fonctionnalité [9]. Afin de pouvoir interagir avec le réseau, le contrôleur a besoin d’une vue précise de ce dernier. C’est ainsi que le concept de NIB (Network Information Base) a vu le jour. Cette NIB est construite au niveau du contrôleur et permet à ce dernier de savoir comment implémenter chaque ordre abstrait, trouver les équipements qui doivent être reconfigurés, s’assurer de la capacité de ces derniers à implémenter une directive, les API supportées par l’équipement, etc.
Il y’a un ensemble très diversifié de contrôleurs et de plates-formes de contrôle avec un design différent et des choix architecturaux. Les contrôleurs existants peuvent être classés en fonction de nombreux aspects. D’un point de vue architectural, le plus pertinent est de savoir s’ils sont centralisés ou distribués..
Un contrôleur centralisé est une seule entité qui gère tous les dispositifs de transmission du réseau. Naturellement, il représente un point de défaillance unique et peut avoir des limites d’échelles. Un seul contrôleur peut ne pas être suffisant pour gérer un réseau avec un grand nombre d’éléments de plan de données. Les contrôleurs centralisés tels que les NOX- MT, Maestro, Beacon, et Floodlight ont été conçus comme des systèmes hautement concurrents, pour atteindre le débit requis par les réseaux de classe entreprise et centres de données. Ces contrôleurs sont basés sur des conceptions multithread pour explorer le parallélisme des architectures informatiques multi-coeur. A titre d’exemple, Beacon peut traiter plus de 12 millions de flux par seconde en utilisant de grandes tailles de noeuds de calcul des fournisseurs de Cloud comme Amazon. D’autres contrôleurs centralisés ciblent les environnements spécifiques tels que les centres de données, les infrastructures de Cloud computing et les réseaux de classe transporteur. En outre, les contrôleurs comme Rosemary offrent des fonctionnalités spécifiques et des garanties, à savoir la sécurité et l’isolement des applications. En utilisant une architecture basée sur les conteneurs appelé micro -NOS, il atteint son objectif principal d’isoler les applications et la prévention de la propagation des défaillances dans toute la pile SDN.
Contrairement à une conception centralisée, un système d’exploitation réseau distribué peut être adapté pour répondre aux exigences potentiellement de tout environnement, des réseaux de petite à grande échelle. Un contrôleur distribué peut être une grappe centralisée de noeuds ou d’un ensemble d’éléments physiquement distribués. Alors que la première alternative peut offrir un débit élevé pour les centres de données très denses, ce dernier peut être plus résistant aux différents types de défaillances logiques et physiques. La plupart des contrôleurs distribués offrent de faibles cohérences sémantiques, ce qui signifie que les mises à jour des données sur les noeuds distincts seront éventuellement mises à jour sur tous les noeuds du contrôleur. Un contrôleur SDN typique fournit un ensemble de fonctionnalités de base, notamment un gestionnaire de topologie, un gestionnaire de statistiques, un gestionnaire de périphériques, un gestionnaire de notifications, la transmission du chemin le plus court et des mécanismes de sécurité. Les quatre premiers composants sont auto-descriptifs dans un environnement réseau.
Etude de quelques contrôleurs SDN
Cette section décrit brièvement les contrôleurs SDN à source ouverte (Open Source) examinés dans le cadre de ce projet. Il existe de nombreux contrôleurs SDN. Par exemple, répertorie 28 contrôleurs différents. Seulement un sous-ensemble de ceci est inclus dans cette recherche. Sont inclus les contrôleurs qui répondent à la plupart des exigences suivantes :
Les contrôleurs qui sont librement disponibles.
Contrôleurs récemment mis à jour.
Contrôleurs ayant reçu plusieurs mises à jour.
Contrôleurs avec le soutien d’une grande communauté ou d’une entreprise.
Les contrôleurs qui ont des fonctionnalités spéciales liées à la QoS.
Project Floodligth
[19] est un contrôleur SDN populaire pour le protocole OpenFlow écrit en Java. Il prend entièrement en charge OpenFlow 1.0 et 1.3, et partiellement les versions 1.1, 1.2 et 1.4. Floodligth prend en charge deux types d’applications: les applications de module et les applications REST.
Les applications de module sont des applications implémentées en Java et compilées avec le contrôleur. Ces applications sont exécutées dans le même code que le code Floodligth. Ce couplage direct a des avantages et des inconvénients. Ces applications de module sont hors du champ de cette recherche.
Les applications REST sont des applications qui utilisent l’API REST de Floodligth pour communiquer avec le contrôleur. À l’aide de cette API, des informations peuvent être obtenues à partir du contrôleur et des informations de routage peuvent être envoyées au contrôleur. Cette API est plus limitée que l’API d’application du module, mais elle est découplée du contrôleur lui-même.
Floodligth est principalement développé par Big Switch Networks, mais compte un certain nombre de membres issus de sociétés ou non..
La couche Application :
Les applications mettent en oeuvre le contrôle logique qui sera traduit en commandes à être installées dans le plan de données, pour dicter le comportement des dispositifs de transmission.
Les applications soumettent des stratégies de haut niveau au plan de contrôle, qui est chargé de les appliquer sous forme de règles de flux sur les périphériques de transfert du réseau. Le plan d’application SDN comprend une ou plusieurs applications réseau (par exemple, la QOS, la visualisation, etc.) qui interagissent avec les contrôleurs afin d’utiliser une vue abstraite du réseau pour leurs processus de prise de décision internes. Une application SDN installée au sommet du contrôleur comprend une logique d’application SDN et un pilote A-CPI (utilisé pour communiquer avec le contrôleur).
De nombreuses applications SDN différentes ont déjà été développées et l’objectif actuel est de disposer d’un support App Store pour les SDN, permettant aux clients de télécharger et d’installer de manière dynamique des applications réseau. La plupart des applications SDN appartiennent à l’une des cinq catégories suivantes: ingénierie du trafic, sécurité et fiabilité, mise en réseau de Datacenter, la surveillance et la gestion de la mobilité dans les réseaux sans fils. Il existe une catégorie d’applications qui exploitent les fonctionnalités SDN pour créer des solutions qui n’existaient pas auparavant. Par exemple, Application des règles en tant que service (Policy Enforcement as a Service (PEPS)), qui fournit un contrôle d’accès entre couches et entre domaines permettant un modèle de protection «défense en profondeur», dans lequel les demandes d’accès infructueuses sont abandonnées avant d’engager le serveur du fournisseur de données. Cela pourrait potentiellement être utilisé pour construire la prochaine génération de firewalls et améliorer la sécurité. Alternativement, des solutions telles que AWESoME exploitent les capacités SDN pour introduire le nouveau concept de gestion «per service», permettant aux administrateurs de gérer de manière exhaustive tout le trafic d’un service, c’est-à-dire de gérer tout le trafic généré par l’utilisateur accédant à un service donné, et non juste le trafic liés aux serveurs propriétaires.
La variété d’applications réseau, combinée avec l’utilisation de cas réels de déploiements, devrait être l’une des principales forces à favoriser une large adoption de SDN.
Définition de la qualité de service
La qualité de service désigne la capacité du réseau à transporter dans de bonnes conditions les flux issus de différentes applications. Cette notion est introduite pour qualifier et quantifier les besoins des applications et l’offre des fournisseurs de service, ceci dans le but de faire converger ces deux aspects. Pour certains, la QoS s’exprime sous la forme du respect par le réseau des bornes de performance, alors que pour d’autres elle est liée à la disponibilité du réseau et sa capacité de fournir un service continu. Pour d’autres encore, elle permet de différencier le trafic pour un traitement spécial et dépend des ressources disponibles dans le réseau (bandes passantes, tampons de mémoire, etc.). La qualité d’un service est une notion subjective. Selon le type de service envisagé, la qualité pourra résider dans le débit (téléchargement ou diffusion vidéo), le délai (pour les applications interactives ou la téléphonie), la disponibilité (accès à un service partagé) ou encore le taux de pertes de paquets.
La QoS dans les réseaux représente l’ensemble des définitions et des méthodes nécessaires à la différenciation des flux et des services, en termes de débit, de délai de bout en bout, de variation de délais ou gigue et de taux de perte des paquets.
Ces paramètres de QoS forment des critères de performance qui peuvent aussi inclure la fiabilité et le temps de réponse. L’élément clé de cette définition est que la combinaison de ces paramètres.
Les métriques de QoS
La gestion efficace de la QoS s’appuie sur un ensemble de paramètres qualitatifs et quantitatifs. Les paramètres qualitatifs donnent une description de la qualité perçue par l’utilisateur final, telle que la qualité de la voix ou de la vidéo. Les paramètres quantitatifs expriment le niveau de qualité relatif au réseau, tel que le temps d’acheminement des paquets de bout en bout.
Les métriques les plus importantes de la QoS dans les réseaux IP sont comme suit :
Le débit
Le débit exprime les besoins des usagers en quantité de données émises à travers le réseau par unité de temps. Il est mesuré en bits par seconde. Selon les applications, les exigences en débit varient en valeur et en nature (constante ou variables). Le débit maximal qu’on peut observer entre deux extrémités d’un réseau est souvent appelé « bande passante ». Nous avons la relation suivante qui lie le débit à la bande passante [32]: 0 ≤ Débit ≤ Bande passante
Le délai
Le délai de bout en bout représente l’intervalle de temps nécessaire à la transmission d’un paquet de données depuis la source jusqu’à la destination. Il est composé de deux parties : une partie fixe qui correspond au temps de propagation et une partie variable appelée délai de traitement. Le délai fixe et composé des délais de codage et décodage, de mise en forme des paquets, de transmission et de propagation.
La gigue
La gigue ou variation des délais de bout en bout représente la variation de latence des paquets. Le réseau doit respecter ce paramètre lors de la transmission de la voix et la vidéo-conférence. Elle est principalement due aux délais dans les files d’attente des routeurs et constitue la source de nombreux problèmes pour les applications multimédias. Ce phénomène peut transformer un flux périodique en un flux non périodique, perturbant la traversée d’un réseau. La gigue se manifeste sous deux formes : des agrégations de paquets : les conséquences sont l’augmentation de la sporadicité du trafic et donc du débit instantané ; une dispersion de paquets : cela a notamment un effet sur le dimensionnement de la mémoire au niveau du récepteur qui sert à récupérer le flux d’origine de façon correcte.
Les pertes de paquets
Les pertes de paquets sont liées à la sporadicité du trafic et d’attente des routeurs. La perte d’un paquet dont le contenu est sémantiquement important signifie qu’une partie essentielle de l’information sera absente lors de sa réception par le terminal destinataire. Ceci remet en cause la qualité et l’intégrité du son ou de l’image dans le cas de flux multimédia.
Les architectures de QoS
Le modèle IntServ
Le modèle Integrated Services (IntServ) est une architecture qui spécifie les éléments garantissant la QoS de bout en bout dans les réseaux à commutation de paquets. Il est proposé pour assurer la QoS à l’architecture Internet sans perturber le bon fonctionnement du protocole IP. Les composantes clés de l’architecture offrent deux nouvelles classes de service supplémentaire par rapport au service traditionnel du Best-effort. Cependant, ce dernier ne garantit aucun critère de QoS. IntServ définit deux types de service. Le premier est la charge contrôlée qui n’offre aucune garantie sur le délai de bout en bout et la perte mais il garantit l’absence de congestion des trafics du réseau. Le second type est le service garanti la bande passante et le délai d’acheminement limité. Ce modèle repose sur le protocole de signalisation RSVP d’acheminement des informations routeurs répondant aux demandes et aux exigences des flux. Les routeurs assurent les fonctionnalités de contrôle d’admission de flux et de réservation de ressources. RSVP est le protocole qu’utilisent les applications pour réserver des ressources du réseau.
Le chemin (unicast ou multicast) est établi par l’émetteur, et la réservation effective des ressources nécessaires est effectué par le(s) récepteurs).Les messages de réservation sont émis périodiquement par les récepteurs. Ils participent au maintien d’un état logique du flot. Quand ils ne passent plus, le chemin et les ressources associées sont relâchés
À grande échelle, le modèle IntServ admet beaucoup de limitations. En effet, en utilisant le protocole RSVP, IntServ doit maintenir les états de réservation de chaque flux traversant les routeurs. Lorsque le nombre de flux augmente, la gestion des états devient une tâche difficile qu’IntServ ne peut pas supporter. Il en découle une détérioration des performances dans le réseau. IntServ nécessite également un grand échange de messages de rafraichissement entrainant ainsi un accroissement de la charge du réseau et par conséquent une augmentation de la probabilité de suppression des paquets. RSVP souffre de problèmes de mise à l’échelle, il convient seulement aux réseaux de petite taille et il n’est pas très performant pour les grands réseaux. L’apparition d’autres architectures plus simples, et qui reposent sur les mêmes principes d’étiquetage, de priorité des paquets et de classification des services tout en allégeant les opérations complexes de maintien d’informations d’état et de réservation de ressources, a réduit d’une façon remarquable l’implémentation de IntServ. Parmi ces architectures, on présente dans la section suivante le modèle DiffServ qui est considéré comme le principal concurrent d’IntServ, mais aussi comme une adaptation d’IntServ pour l’implémentation à grand échelle.
Le modèle DiffServ
La scalabilité était le principal obstacle à la croissance d’IntServ en tant que mécanisme de QoS. DiffServ [6] a été introduit pour résoudre ce problème. Pendant qu’IntServ traitait le trafic de bout en bout, DiffServ appliquait des politiques à chaque saut. C’est ce qu’on appelle le « Per-Hop Behavior » (PHB). Contrairement à IntServ qui fonctionnait par flux, DiffServ fonctionne sur des flux agrégés. Les paquets peuvent être classés à l’aide des bits DSCP (Differentiated Services Code Points) successeur des bits Type Of Service (TOS) contenus dans l’en-tête du paquet. Tous les paquets avec le même en-tête reçoivent le même traitement, quels que soient les flux dont ils font partie. Contrairement à IntServ, DiffServ devient ainsi plus facile à mettre en oeuvre et à maintenir sans trop de frais de transmission de messages et d’accord global. La Figure 3.3 représente le fonctionnement du protocole DiffServ.
|
Table des matières
Introduction Générale
CHAPITRE 1. CADRE THEORIQUE ET METHODOLOGIE
1.1. Problématique
1.2. Objectifs
1.2.1. Objectif Général
1.2.2 Objectifs Spécifiques
1.3. Méthodologie
CHAPITRE 2 : ETAT DE L’ART DU SOFTWARE DEFINED NETWORKING (SDN)
2.1. Définitions et Concepts
2.2 Études de différentes couches de l’architecture SDN
2.2.1 La couche Infrastructure
2.2.2 La couche Contrôle
2.2.3 La couche Application
CHAPITRE 3 : INTODUCTION A LA QUALITE DE SERVICE DANS LES RESEAUX IP
3.1 Définition de la qualité de service
3.2 Les métriques de QoS
3.2.1. Le débit
3.2.2. Le délai
3.2.3. La gigue
3.2.4. Les pertes de paquets
3.3 Les architectures de QoS
3.3.1. Le modèle IntServ
3.3.2 Le modèle DiffServ
3.3.3 Le Multi-Protocol Label Switching (MPLS)
3.4 Mécanismes de gestion de QoS dans les réseaux IP
CHAPITRE 4 : ETUDE COMPARATIVE DE SOLUTIONS DE GESTION DE QoS DANS LES RESEAUX SDN
4.1 Qualité de service dans les réseaux SDN
4.2 OpenFlow et la QoS
4.3. Mécanismes de gestions de QoS dans les réseaux SDN
4.3.1. Mécanismes de gestion de politique de QoS
4.3.2 Mécanismes de réservation de ressources
4.3.3 Mécanismes de routage par flux
4.3.4. Gestion des files d’attente et les mécanismes de planification
4.3.5 Mécanismes sensible à la QoE
CHAPITRE 5 : MISE OEUVRE ET VALIDATION DE LA SOLUTION QoSFlow
5.1 Architecture cible et fonctionnement
5.2 Choix technologique
5.2.1 Choix du contrôleur
5.2.2 Choix de l’environnement de simulation
5.2.2.1 Mininet
5.3 Paramètres de simulation
5.4 Tests et Validation
5.4.1 Phases d’implémentation de la maquette
5.4.1.1 Procédure d’installation d’Opendaylight
5.4.1.2 Création de la topologie dans mininet
5.4.2 Mise en oeuvre de la simulation
5.4.2.1 Simulation sans la QoS
5.4.2.2 Configuration de la QoS
5.4.2.3 Simulation avec la QoS
Conclusion Générale et perspectives
Bibliographie
Télécharger le rapport complet
Svp est ce que je peux avoir ce rapport pour mon pfe