Etude et gestion de la qualité de service dans les réseaux SDN/OpenFlow

Concept du Software Defined Network

Concevoir un réseau au sein duquel aucun utilisateur, switch ou périphérique d’extrémité n’a plus d’information que ce dont il a absolument besoin, c’est le projet qui a fait naître le concept du Software-Defined Network (SDN) avec « Software-Defined » pour « orienté logiciel ». Les SDNs ont pour but pratique, de rendre les réseaux programmables, par le biais d’un contrôleur centralisé. Aujourd’hui les commutateurs et les routeurs programment leurs tables de transmission (forwarding) localement, ce qui signifie que les périphériques réseau prennent leurs propres décisions en interne sur la meilleure façon de transférer le trafic. Ces décisions s’appuient sur les informations distribuées, collectées par des protocoles de routage comme OSPF et BGP ou des protocoles comme Spanning Tree. Mais ces protocoles sont peu flexibles.
Pour fonctionner ensemble, tous les équipements du réseau doivent suivre les règles définies par les standards. Cela laisse peu de place à la créativité ou à des exigences métiers inhabituelles. Avec les SDNs, on établit une séparation claire entre le plan de contrôle (qui définit comment un équipement transmet le trafic) et le plan de données (l’équipement qui assure effectivement le transfert des données). Dans les SDNs, le contrôleur centralisé a une visibilité sur l’ensemble du réseau, y compris les hôtes qui s’y connectent et a une vision complète De la topologie du réseau. Un contrôleur central omniscient permet aux ingénieurs de réseau de mettre en œuvre des politiques de transfert uniques et flexibles dont les seules limitations sont liées à la capacité du logiciel faisant fonctionner le contrôleur. Deux termes importants qui reviennent dans les conversations de contrôleur sont « SouthBound » et « NorthBound ». En fait si l’on considère le contrôleur comme un middleware, les applications qui disent aux contrôleurs comment programmer le réseau utilisent des interfaces de programmation « NorthBound interface » tandis que les APIs et protocoles utilisés par le contrôleur pour communiquer avec les équipements du réseau sont dits « SouthBound interface ». Le contrôleur agit comme un arbitre, en fournissant une couche d’abstraction du réseau physique sous-jacent pour les applications qui souhaite le programmer. Nous avons par exemple quelques opérations courantes qui peuvent bénéficier d’une approche SDN :
La création d’un réseau expérimental qui fonctionne sur la même infrastructure physique que le réseau de production, tout en étant logiquement isolé.
La mise en œuvre de politiques de circulation où l’on applique dynamiquement des politiques à des flux afin de maintenir une qualité de service définie(QoS).
Le routage en fonction de paramètres financiers, où les chemins de transmission sont déterminés en fonction de l’impact financier des flux transportés pour la société.
La mise en œuvre de politiques de sécurité réseau intelligentes, où des flux particuliers peuvent être isolés et basculés vers un système de détection d’intrusion pour une inspection approfondie, tandis que d’autres sont autorisés à circuler librement en fonction des exigences opérationnelles de la société.
La mise en œuvre de mirroring de flux (ou de spanning), pour dupliquer des flux à des fins de logging, de reporting ou d’analyse.

Architecture distribuée vs. Architecture centralisée

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 eut 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 multithreads pour explorer le parallélisme des architectures informatiques multicœur. A titre d’exemple, Beacon peut traiter plus de 12 millions de flux par seconde en utilisant de grandes tailles de nœuds 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 nœuds 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. Un fournisseur de cloud qui couvre plusieurs centres de données interconnectés par un réseau étendu peut exiger une approche hybride, avec des grappes de contrôleurs à l’intérieur de chaque centre de données et les nœuds de contrôleurs répartis dans les différents sites. 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 nœuds distincts seront éventuellement mises à jour sur tous les nœuds du contrôleur. Cela implique qu’il y’a une période de temps durant laquelle les nœuds distincts peuvent lire des valeurs différentes (ancienne valeur ou une nouvelle valeur) pour un même bien. La cohérence forte, d’autre part, veille à ce que tous les nœuds du contrôleur lisent la valeur de la propriété la plus à jour après une opération d’écriture. En dépit de son impact sur les performances du système, la cohérence forte offre une interface plus simple. Une autre propriété commune des contrôleurs distribués est la tolérance de panne. Quand un nœud échoue, un autre nœud voisin devra assurer les fonctions et dispositifs du nœud défaillant. Un seul contrôleur peut être suffisant pour gérer un réseau, mais il représente un point de défaillance unique. De même, les contrôleurs indépendants peuvent se propager à travers le réseau, chacun d’entre eux gérant un segment de réseau, pour réduire l’impact d’une défaillance du contrôleur unique. Si la disponibilité du plan de contrôle est essentielle, un groupe de contrôleurs peut être utilisé pour atteindre un plus haut degré de disponibilité et / ou pour supporter plusieurs dispositifs. En fin de compte, un contrôleur distribué peut améliorer la résilience du plan de contrôle, l’évolutivité et réduire l’impact des problèmes causés par la partition du réseau par exemple. Cependant la communication entre les contrôleurs SDN distribués ou Inter SDN Controller peut être implémentée en utilisant deux approches : l’approche verticale ou horizontale.

La couche infrastructure (les périphériques SDN)

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. 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 œuvre 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 œuvre 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.

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 traitements spécial et dépend des ressources disponibles dans le réseau (bandes passantes, tampons de mémoire, etc.). Le terme qualité possède une portée dans plusieurs domaines dans le supérieur aux espérances normales. Les caractéristiques recherchées peuvent inclure des aspects de réduction des pertes de données, des délais induits au minimum et des gigues constantes. Le terme qualité peut aussi être considéré comme la faisabilité ou la prédiction. Dans ce cas, la qualité fait allusion à un niveau constant de perte, de délai ou gigue ou de toutes autres propriétés. Le terme qualité est aussi utilisé pour référencer des caractéristiques particulières pour spécifier des applications ou des protocoles réseaux. Le terme service est lui aussi ambigu et peut être compris de plusieurs manières. Généralement, on utilise le terme pour décrire les capacités de communication.
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.

Le composant de routage par trajets multiples

Afin d’éviter la congestion des paquets mentionnée ci-dessus, nous avons introduit la technologie de routage multi-chemins dans plusieurs ports à grande vitesse.
L’utilisation l’algorithme de Dijkstra, lui permet de satisfaire plusieurs contraintes de QoS. Ces chemins sont stockés dans une HashMap et le contrôleur veut vérifier périodiquement l’état du réseau de ces chemins. Lorsqu’un paquet arrive à un commutateur OpenFlow qui n’a pas d’entrée de flux correspondante, il est d’abord envoyé au contrôleur. Selon l’état actuel du réseau (y compris les files d’attente et l’utilisation de la bande passante), le contrôleur choisira de manière optimale les multiples chemins disponibles dans le réseau et acheminera le flux vers les commutateurs OpenFlow pour l’acheminement des paquets. La solution QoS de recherche garantit que les paquets de données sont toujours transmis au chemin optimal actuel sélectionné par le composant de routage par trajets multiples. Par conséquent, HiQoS utilise plusieurs chemins disponibles et leur bande passante.
Dans HiQoS, le chemin avec l’utilisation minimale de la bande passante d’une file d’attente sera sélectionné comme chemin optimal pour un nouveau flux. Le contrôleur mesure périodiquement l’utilisation de la bande passante de chaque file d’attente le long du chemin. Plus l’utilisation des files d’attente est importante, plus la congestion dans le chemin est importante. Nous sélectionnons pour un flux entrant un chemin que son utilisation de bande passante des files d’attente est le minimum comparé à d’autres chemins. De cette manière, HiQoS sélectionne le chemin optimal pour éviter l’encombrement des paquets de données reçus. Cela permet au système d’obtenir des garanties QoS qui réduiront le délai et le temps de réponse du serveur, augmenteront le débit du système.

Table des matières

INTRODUCTION GENERALE
CHAPITRE 1 : PRESENTATION DU MEMOIRE
1.1 Problématique
1.2 Objectifs
1.2.1 Objectif General
1.2.2 Objectifs Spécifiques
1.3 Méthodologie
CHAPITRE 2: SOFTWARE DEFINED NETWORK ET OpenFlow
2.1 Introduction
2.2 Concept du Software Defined Network
2.3 Etude des différentes couches de l’architecture SDN
2.3.1 La couche application
2.3.2 La couche système d’exploitation réseau ou Contrôleur
2.3.3 La couche infrastructure (les périphériques SDN)
2.3.4 Comparaison des simulateurs SDN
2.4 Conclusion
CHAPITRE 3 : CONCEPTS DE QUALITE DE SERVICE
3.1 Introduction
3.2 Définition de la qualité de service
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 Modèle Multi-Protocol Label Switching (MPLS)
3.3.4 La QoS dans MPLS
3.4 Conclusion
CHAPITRE 4 : ETUDE DES SOLUTIONS DE GESTION DE LA QUALITE DE SERVICE DANS
LES RESEAUX SDN/OPENFLOW
4.1 Introduction
4.2 Qualité de Service dans les réseaux SDN
4.2.1 QoS au niveau des contrôleurs SDN
4.2.2 QoS dans le protocole openFlow
4.3 Etude des solutions de QoS dans les réseaux SDN/OpenFlow
4.3.1 La Solution OpenQoS
4.3.2 La Solution FlowQoS
4.3.3 La Solution HiQoS
4.3.4 La Solution QoSFlow
4.4 Comparaison des solutions de QoS dans SDN/OpenFlow
4.5 Conclusion
CHAPITRE 5 : SIMULATION D’UN RESEAU SDN AVEC QoS
5.1 Présentation de Mininet
5.2 Architecture Proposée
5.3 Installation de l’environnement de simulation
5.4 Mise en Œuvre de la simulation
5.4.1 Création de la topologie SDN
5.4.2 Simulation de SDN sans QoS
5.4.3 Simulation de SDN avec QoS
CONCLUSION GENERALE
PERSPECTIVES
REFERENCES