FSEA …../2019 En vue de l’obtention du diplôme de Doctorat en Science Spécialité : Ingénierie des systèmes complexes et multimédia Présentée par : Djamel Eddine HENNI Soutenue publiquement le ………………. Devant le jury composé de : Mr. LEBBAH Yahia Prof. Univ. Oran 1 A.B Président Mme. BOURENANE Malika Prof. Univ. Oran 1 A.B Examinatrice Mr. CHOUARFIA Abdellah Prof. Univ. USTO M.B Examinateur Mr. KOUNINEF Belkacem Prof. INTTIC Examinateur Mr. GHOMARI Abdelghani Mr. HADJADJ-AOUL Yassine MCA. Univ. Oran 1 A.B MCA. Univ. Rennes 1 Directeur de Thèse Co-Directeur de Thèse Gestion de la qualité de service des flux multimédia dans les réseaux SDN
Transcript
FSEA …../2019
En vue de l’obtention du diplôme
de Doctorat en Science
Spécialité : Ingénierie des systèmes complexes et multimédia
Présentée par : Djamel Eddine HENNI
Soutenue publiquement le ………………. Devant le jury composé de :
Mr. LEBBAH Yahia Prof. Univ. Oran 1 A.B Président
Mme. BOURENANE Malika Prof. Univ. Oran 1 A.B Examinatrice
Mr. CHOUARFIA Abdellah Prof. Univ. USTO M.B Examinateur
Mr. KOUNINEF Belkacem Prof. INTTIC Examinateur
Mr. GHOMARI Abdelghani
Mr. HADJADJ-AOUL Yassine
MCA. Univ. Oran 1 A.B
MCA. Univ. Rennes 1
Directeur de Thèse
Co-Directeur de Thèse
Gestion de la qualité de service des flux multimédia
dans les réseaux SDN
Thèse effectuée au sein du Laboratoire de Recherche en Informatique
Industrielle et en Réseaux (RIIR)
Département Informatique, Faculté des Sciences Exactes et Appliquées
de l’Université Oran 1, Algérie.
Remerciements
Merci à ALLAH de m’avoir octroyé la force, la patience et le courage.
La thèse résulte d’un travail personnel dont l’aboutissement implique plusieurs personnes que
je dois les remercier tous.
Tout d’abord, je dois remercier vivement mon directeur de thèse Dr. GHOMARI Abdelghani
ainsi que mon Co-directeur de thèse Dr. HADJADJ-AOUL Yassine, qui m’ont proposé un sujet
de thèse original relevant d’un domaine de recherche très intéressant. « Je souhaite en cette
occasion leur exprimer ma gratitude pour leur disponibilité associée à leur impressionnant
dynamisme scientifique tout au long de ces années de thèse ».
J’exprime mes profonds remerciements à monsieur LEBBAH Yahia, Professeur à l’université
Oran 1 Ahmed Ben Bella, pour m'avoir fait l'honneur de présider le jury de ce modeste travail.
Mes vifs remerciements accompagnés de toute ma gratitude aux membres de jury, madame
BOURENANE Malika, Professeur à l’université Oran1 Ahmed Ben Bella ; à monsieur
CHOUARFIA Abdellah, Professeur à l’USTO Mohammed Boudiaf ainsi qu’à monsieur
KOUNINEF Belkacem, Professeur à l’Institut National des Télécommunications et des
Technologies de l’Information et de la Communication (INTTIC), qui ont accepté de participer
au jury et ont bien voulu juger ce modeste travail.
Je remercie aussi l’ensemble des membres du laboratoire RIIR à commencer par le
directeur du laboratoire Prof. Hafid Hafaff, la secrétaire Melle Sara Benhamed, les doctorants,
ainsi que tous les enseignants-chercheurs qui ont contribué de près ou de loin à
l’aboutissement de ma thèse.
Merci beaucoup à mes très chers parents de m’avoir toujours encouragé et aidé à mener
à bien mes études si longtemps. Leur soutien constant à travers ces longues années m’a été
précieux.
Dédicaces
Je dédie ce modeste travail à
Mes très chers parents
Ainsi qu’à toute ma famille
Tous mes amis
Tous mes enseignants du primaire jusqu’à l’université
Tous les enseignants de l’INTTIC.
ملخص
مفهوما مهما في شبكات الكمبيوتر واالتصاالت السلكية والالسلكية تعد إدارة جودة الخدمة
ال سيما للتطبيقات في الوقت الفعلي مثل ألنها مرتبطة بشكل مباشر بتجربة المستخدم النهائي،
تدفقات الوسائط المتعددة. الهدف من جودة الخدمة الشاملة هو ضمان مستوى معين من الجودة
مع إرضاء المستخدمين النهائيين. تطورت صناعة الشبكات على مدار العشرين عاما الماضية
أي توجيه البيانات(.( وتوزيع على أساس نموذج توفر فيه أجهزة الشبكة وظيفتي التحكم )
الحزم )أي النقل( في وضع موزع. على الرغم من فعاليتها، أثبتت هذه التقنيات أنها صارمة
للغاية، مما جعل تنفيذ جودة الخدمة أكثر صعوبة. إن ظهور مفهوم الشبكات القابلة للبرمجة
.قد سهل التحكم في جودة الخدمة إلى حد كبير وأوبن فل وبروتوكول
التي تهدف إلى ضمان اتساق القرارات التي يتعين اتخاذها ،شبكة نقترح بنية الرسالة،في هذه
استراتيجية لتوجيه البيانات مع دعم جودة الخدمة وضعنا لذلك، ،الشبكاتهذا النوع من في
مع تحسين (،تدفقات األولوية )الوسائط المتعددةال جودةبطريقة متسقة لتجنب أي تدهور في
طريقة جديدة لحساب استخدام عرض النطاق هذه الرسالة فيأيضا نقترح .الموارداستخدام
الترددي بدقة مع ضبط تردد االقتراع استنادا إلى نشاط المنفذ والتبديل لتقليل الحمل الناتج
.أثناء عمليات المراقبة
المحاكاة المقترحة مع العديد من األعمال األخرى الموجودة ونتائج عمليات التقنياتلقد قارنا
فعالية التقنيات المقترحة وتحسين تلك تأوضح مينينات، برنامجباستخدام تمتالتي
QoS (Quality of Service) management is an important concept in computer net-working and telecommunications as it impacts the end user experience, especially forreal-time applications such as multimedia flows. The purpose of end-to-end QoS isto guarantee a certain level of quality while satisfying end users. Network industryhas been developed, over the last twenty years, on the basis of a model where net-work devices provide both control functions (i.e. routing) and packets’ delivery (i.e.forwarding) in a distributed mode. Although effective, these techniques have proven tobe very rigid, making the implementation of the QoS even more difficult. The recentemergence of Software Defined Networking (SDN), with OpenFlow as its most popularstandard, has considerably simplified the QoS control.
In this thesis, we propose a network architecture that guarantees the consistencyof the decisions to be taken in an SDN network. A consistent QoS routing strategyis, then, introduced in a way to avoid any quality degradation of prioritized traffic,while optimizing resources usage. We also propose a new approach calculating accu-rately the bandwidth utilization while adapting the polling frequency according toports/switches activity for the purpose of reducing the generated overhead duringmonitoring operations.
We compared the proposed approaches with several existing frameworks and theemulations results, which are performed using the Mininet environment, show theeffectiveness of the proposed techniques that clearly outperforms existing frameworks.
La gestion de la qualité de service (QoS) est un concept important dans les réseauxinformatiques et les télécommunications, car elle a un impact direct sur l’expérienceperçue par l’utilisateur final, en particulier pour les applications temps-réel commeles flux multimédia. L’objectif de la QoS de bout en bout est de garantir un certainniveau de qualité tout en satisfaisant les utilisateurs finaux. L’industrie des réseauxs’est développée, au cours des vingt dernières années, sur la base d’un modèle oùles périphériques réseaux assurent à la fois les fonctions de contrôle (c’est-à-direl’acheminement des données) et la distribution des paquets (c’est-à-dire le transfert)dans un mode distribué. Bien que efficaces, ces techniques se sont avérées très rigides,rendant la mise en œuvre de la QoS très difficile. L’émergence du concept des réseauxprogrammables (SDN), avec le protocole OpenFlow (son standard le plus populaire), aconsidérablement simplifié le contrôle de la QoS.
Dans cette thèse, nous proposons une architecture réseau qui a pour but de garantirla consistance des décisions à prendre dans un réseau SDN. Une stratégie d’achemi-nement des flux avec la prise en charge de la QoS d’une façon consistante est doncmise en place de manière à éviter toute dégradation de la qualité des flux prioritaires(multimédia), tout en optimisant l’utilisation des ressources. Nous proposons égalementune nouvelle approche permettant de calculer précisément l’utilisation de la bande pas-sante en adaptant la fréquence d’interrogation en fonction de l’activité des ports et descommutateurs afin de réduire la surcharge générée lors des opérations de supervision.
Nous avons comparé les approches proposées avec plusieurs autres travaux existants,les résultats des émulations, qui sont effectuées à l’aide de l’environnement Mininet,montrent l’efficacité des techniques proposées qui surpassent clairement celle des tra-vaux connexes.
Mots Clés: Acheminement avec QoS, SDN, OpenFlow, Consistance du réseau,Supervision, Diffusion Vidéo, Contrôleur SDN, Mesures, Gestion des réseaux, Multimé-dia.
FAI Fournisseur Accès Internet. 8, 9FEC Forwarding Equivalent Class. 18ForCES Forwarding and Control Element Separation. x, 36FTP File Transfer Protocol. 9
2.2.3 Le commutateur Open vSwitch . . . . . . . . . . . . . . . . . . 352.2.4 Le protocole Forwarding and Control Element Separation (ForCES) 362.2.5 Prérequis des éléments de transfert pour le support de ForCES . 37
2.1 Comparaison entre OpenFlow et ForCES en terme d’élément de transfert 412.2 Comparaison entre OpenFlow et ForCES du point de vue protocole . . 422.3 Prise en charge de la QoS par les différents contrôleurs . . . . . . . . . 442.4 Comparaison entre un réseau SDN et un réseau traditionnel . . . . . . 452.5 Prise en charge de la QoS dans les différentes version du protocole
3.2 Pré-requis d’une communication de type vidéo conférence . . . . . . . . 69
4.1 Overhead Obtenus en terme de nombre de requêtes . . . . . . . . . . . 764.2 Erreur Obtenue par rapport à l’approche périodique . . . . . . . . . . . 764.3 Abilene topology links’ delay . . . . . . . . . . . . . . . . . . . . . . . . 784.4 Modèle de Flux utilisé dans l’expérimentation . . . . . . . . . . . . . . 794.5 Paramètres de simulation . . . . . . . . . . . . . . . . . . . . . . . . . . 834.6 UDP rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834.7 Les résultats obtenus pour un flux UDP à un débit de 384 Kbps . . . . 854.8 Les résultats obtenus pour un flux UDP à un débit de 512 Kbps . . . . 854.9 Les résultats obtenus pour un flux UDP à un débit de 784 Kbps . . . . 85
1
Introduction Générale
Contexte et Motivation
Vue la demande croissante des flux multimédia et en particulier le streamingvidéo, les fournisseurs de services réseaux et les fournisseurs de contenu vidéo sontconfrontés au défi de maximiser leurs services en termes de quantité et de qualité touten garantissant la Quality of Service (QoS) ainsi que la Quality of Experience (QoE).En effet, dans [1], Cisco confirme que le trafic vidéo sur Internet constituera environ82 % de tout le trafic Internet grand public d’ici 2022, contre 75 % en 2017. Étantdonné que le réseau Internet est conçu pour offrir les meilleurs services possibles (c.-à-d.aucune garantie n’est offerte sur la bande passante ainsi que sur les délais) en termesde rentabilité, de fiabilité et de robustesse, il est donc impératif de mettre en placedes mécanismes garantissant les exigences techniques en termes de bande passanteet de délai pour maintenir un niveau acceptable de leur QoS/QoE. Formellement,une garantie de QoS est définie comme étant la capacité des dispositifs du réseau(équipements et média d’interconnexion) à satisfaire les exigences du trafic, qui varienten fonction du service ou de l’application réseau spécifique [2], tandis que la QoEexprime la manière dont la qualité est perçue par l’utilisateur final, elle inclut la chainede communication entière de bout-en-bout.
En effet, beaucoup de chercheurs à travers le monde ont été motivés par l’implémen-tation de différentes stratégies pour prendre en charge la QoS, comme par exemple cellebasée sur l’intégration de services (Intserv) [3]. Cette dernière fournit une solution deQoS de bout en bout avec une réservation de bande passante et un contrôle d’admissionau niveau de chaque noeud du réseau. D’autre part, elle s’assure qu’une réservation debande passante est faite par flux sur chaque lien emprunté par ce dernier. Néanmoins,IntServ possède beaucoup d’inconvénients, notamment, le protocole de signalisation quiest utilisé pour la réservation des ressources (Le RSVP (Resource Reservation Protocol)[4]), ce dernier n’est pas échelonnable, et par conséquent, il n’est pas adapté à desréseaux de grande taille comme Internet. D’autre part, chaque équipement a besoin desauvegarder l’état de chaque flux, ce mécanisme prendra rapidement de l’ampleur avecl’augmentation du nombre de flux et des équipements réseaux. Aussi, le fait que labande passante réservée ne peut être utilisée que par le flux concerné par la réservation,cela entraînera une utilisation non optimisée de la bande passante. DiffServ [5], estune autre architecture, qui prend en charge la QoS mais d’une façon plus échelonnablepar rapport à IntServ. En effet, au lieu de fournir une garantie de bande passante debout en bout pour chaque flux, elle emploie un traitement par saut (PHB, Per Hope
2
Behavior) avec une agrégation pour différentes classes de trafic. Même si la complexitéde ce mécanisme est beaucoup moins importante par rapport au modèle IntServ, labande passante est partagée par les flux de la même classe et de ce fait, il n’y a pasune garantie au sens propre de la bande passante.
La mise en place des réseaux qui supporte l’acheminement des flux multimédias’est développée, au cours des vingt dernières années, sur la base d’un modèle où lespériphériques réseau assurent à la fois les fonctions de contrôle (c’est-à-dire le routage)et la distribution des paquets (c’est-à-dire le transfert) dans un mode distribué. Bienqu’elle sont efficaces, ces techniques se sont avérées très rigides [6]. En effet, la moindremodification de ces dispositifs est très complexe à mettre en place et nécessite unprocessus de déploiement très fastidieux, qui tend à ralentir toute évolution.
Le concept des réseaux définis par logiciel, connu sous le nom anglo-saxon Software-Defined Networks (SDN) est un paradigme alternatif qui attire l’attention d’un nombrecroissant de fournisseurs de services réseaux. Il consiste principalement à séparerphysiquement le plan de contrôle de celui des données, tout en centralisant l’intelligencedu réseau sur une entité distante, appelée le contrôleur [7]. Ce dernier est responsabledu calcul des meilleurs chemins ainsi que de leurs mises à jour, tandis que les noeudsn’ont qu’à transmettre les paquets selon les règles qu’ils ont reçues du contrôleur. Ceconcept nous permet donc de programmer le comportement du réseau en fonction denos besoins tout en rendant la couche infrastructure abstraite pour les applications etles services réseaux.
La motivation principale de notre recherche consiste à implémenter de nouvellesstratégies de QoS en utilisant le concept SDN, ce dernier nous permet d’innover dansce sens afin de garantir l’acheminement correct des flux multimédia et de les protégercontre les pertes de paquets. Nous nous sommes aussi intéressés à améliorer leur QoE.
Problématique de la thèse
En simplifiant considérablement la gestion des réseaux tout en ayant la capacitéde supporter les services actuels et futurs, le concept SDN suscite l’enthousiasmeau sein de la communauté de recherche. En effet, en découplant le plan de donnéesde celui du contrôle, cela donne aux opérateurs de réseau (Network Operators) lapossibilité d’intégrer une nouvelle logique sans avoir à modifier l’infrastructure. Deplus, la centralisation du plan de contrôle réduit considérablement la complexité desservices, puisque cela nous évite d’avoir les inconvénients des applications distribuées.De ce fait, les applications multimédia temps réel telle que le streaming vidéo, parexemple, peuvent être gérées plus facilement avec l’émergence du SDN en utilisant
3
des techniques plus avancées de routage (acheminement des données) avec la prise encharge de la QoS.
Depuis de nombreuses années, le routage prenant en charge la QoS a été unepréoccupation majeure des chercheurs. L’objectif est de proposer des algorithmes deroutage qui peuvent fournir les meilleurs chemins pour satisfaire les contrats de niveaude service (Service Level Agreement (SLA)) des clients. Afin d’atteindre cet objectif,deux tâches principales doivent être accomplies, la première étant d’avoir une vueglobale de la topologie du réseau et de la tenir à jour, alors que la deuxième est detrouver les meilleurs chemins d’acheminement des flux en fonction des résultats de lapremière tâche. Par conséquent, le meilleur algorithme de routage prenant en charge leSLA est celui qui accomplie d’une façon optimale ces deux tâches.
De ce fait, malgré que plusieurs études ont abordé ces deux problématiques (avoirune vue globale de la topologie, et trouver le meilleur acheminement en fonction decette vue), très peu d’entre elles ont abordé la prise en charge de la QoS lors de lasupervision du réseau ainsi que la consistance des prises de décision lors du routage desflux de données (en particulier celles des flux temps réel tels que le streaming vidéo) etleur dispersion, afin d’optimiser l’utilisation des ressources réseaux (CPU, mémoire,espace de stockage des équipements tels que les contrôleurs et les commutateurs ou lesrouteurs). En effet, nous croyons qu’il s’agit des aspects les plus critiques pour faire desréseaux SDN une réalité dans les réseaux où les ressources sont limitées, d’où l’intérêtde proposer des solutions à ces problématiques tout en traitant les objectifs dégagés etdiscutés ci-dessous.
Objectifs de la thèse
Avec l’explosion des communications réseaux à l’échelle mondiale, le risque d’avoirdes congestions réseaux est très fréquent. Pour pouvoir véhiculer les flux multimédiad’un point à un autre dans de tels réseaux, il est très important de mettre en oeuvredes politiques de QoS prenant en charge leurs pré-requis en termes de bande passante,de délai, du taux de pertes de paquets...etc afin de garantir leur réception avec unniveau de qualité acceptable. Ainsi l’objectif de notre thèse est de proposer de nouvellestechniques prenant en charge la gestion et la mise en oeuvre de la QoS dans les réseauxSDN (avec ses deux volets, à savoir la supervision et le routage) pour acheminercorrectement les flux multimédia.
4
Contributions de la thèse
Les contributions principales de notre thèse peuvent être résumées comme suit:☞ Étude détaillée de l’état de l’art des approches de gestion et de mise en oeuvre
de la QoS dans les réseaux SDN (avec ses deux volets, à savoir la supervision etle routage) .
☞ Identification des inconvénients et des limites des techniques de gestion et de miseen oeuvre de la QoS dans les réseaux SDN, aussi bien dans la partie supervisionque celle du routage.
☞ Proposition de nouvelles solutions améliorant la gestion de la QoS des fluxmultimédia en utilisant le concept SDN.
☞ Proposition d’une nouvelle technique de supervision dans les réseaux SDN dontle but est de réduire le nombre de messages injectés dans le réseau pour des finsde supervision, tout en nous comparant à d’autres solutions connexes.
☞ Proposition d’une nouvelle technique de routage avec QoS pour les flux de vidéoconférence.
☞ Conception et implémentation d’une architecture réseau prenant en charge laQoS des flux multimédia en utilisant le concept SDN:
— L’architecture réseau proposée consiste à améliorer la qualité des flux multi-média, notamment celle du streaming vidéo.
— Elle vise à avoir une vue consistante sur le réseau, à prendre des décisionsconsistantes, et à envoyer des entrées consistantes aux commutateurs.
— Cette architecture prend en charge aussi bien les flux temps réels que lesflux best-effort.
☞ Établir un tableau comparatif de notre architecture proposée avec celles existantesdans la littérature en termes de gestion de la topologie réseau, de calcul des routes,de l’acheminement avec QoS, de lissage des flux best-effort, de la dispersion desflux multimédia selon leur concentration et de l’allocation dynamique des tempsde séjour des entrées de flux dans la table des flux des commutateurs SDN.
Structuration de la thèse
Notre thèse est structurée comme suit:☞ Le premier chapitre présente des généralités sur la gestion de la QoS des flux
multimédia, nous verrons dans ce chapitre une définition de la QoS, ses métriques,
5
des architectures réseaux de QoS standardisées par l’Internet Engineering TaskForce (IETF), leur fonctionnement, leurs avantages ainsi que leurs inconvénients,nous verrons ensuite des exemples sur les applications multimédia, les types desmédias, leur codage ainsi que leur compression.
☞ Dans le deuxième chapitre, nous présenterons un état de l’art sur le concept desréseaux SDN et la prise en charge de la QoS par ces réseaux.
☞ Le troisième chapitre est consacré à la présentation des différentes solutionsproposées.
☞ Le quatrième chapitre est dédié à l’implémentation, l’expérimentation, l’évaluationainsi qu’à la comparaison des solutions proposées avec d’autres travaux connexes.
Enfin, nous conclurons notre manuscrit avec une conclusion, des perspectives futuresainsi qu’un résumé de nos contributions scientifiques.
Chapitre 1
Généralité sur la QoS et les FluxMultimédia
1.1 IntroductionLa QoS est la capacité d’un réseau à fournir un meilleur service pour un trafic réseau
sélectionné sur diverses technologies, comme les réseaux Ethernet et 802.1, SynchronousOptical Networks (SONET), relais de trame (Frame Relay), Asynchronous TransfertMode (ATM), ainsi que les réseaux routés IP qui peuvent utiliser n’importe quelletechnologie de base d’entre elles. Le but principal de la QoS est de fournir une prioritéen assurant une bande passante dédiée, une gigue et une latence contrôlées, ainsi qu’untaux de perte de paquets acceptable. Ces besoins représentent les prérequis des fluxtemps réel comme le streaming vidéo et la téléphonie sur IP. Il est également importantde s’assurer que la priorité accordée à un ou plusieurs flux n’est pas faite au détrimentd’une baisse de qualité des autres flux moins critiques. En effet, les solutions que nousproposons dans cette thèse, prendront en charge cette remarque, comme nous allons levoir lorsque nous aborderons les deux derniers chapitres, dédiés à la présentation dessolutions proposées et à leur implémentation.
Les applications multimédias sont actuellement très répandues que ce soit dans lemonde de l’informatique ou dans la vie de tous les jours. Le qualificatif de multimédiaest très utilisé, on parle souvent de révolution multimédia ou du tout multimédia. Laperformance actuelle des différents types de périphériques disponibles sur le marché(téléphones mobiles, assistants personnels, ordinateurs portables, etc.) ainsi que l’émer-gence des réseaux et des débits actuels ont largement contribué à démocratiser ceterme. On peut désormais, échanger tout type de médias par l’intermédiaire de cesenvironnements.
1.2 Gestion de la Qualité de Service 8
1.2 Gestion de la Qualité de Service
1.2.1 Définition de la QoS
La qualité de service (QdS) ou quality of service (QoS) est la capacité à acheminer,dans de bonnes conditions un type de flux donné, en respectant ses prérequis, entermes de disponibilité des ressources réseaux, débit, délais de transmission, gigue,ainsi que le taux de perte de paquets [8]. Aussi, la QoS est un concept de gestion ayantpour but d’optimiser les ressources réseaux et de garantir de bonnes performancesaux applications critiques (temps réel). Elle permet aux fournisseur de services derespecter le SLA (Service Level Agreement (SLA)) conclu avec ses clients et d’offriraux utilisateurs des débits et des temps de réponse différenciés par applications (ouactivités) suivant les protocoles utilisés sur leurs infrastructures IP.
La gestion de la QoS est un mécanisme utilisé dans les réseaux afin d’augmenterla performance de ces derniers et optimiser l’utilisation de leurs ressources sans larevue du dimensionnement total de l’infrastructure réseau. Le protocole OSPF (OpenShortest Path First (OSPF)) ainsi que d’autres protocoles de routage dynamiques,actuellement, très utilisés dans le réseau Internet, acheminent les paquets selon leplus court chemin. Ceci, peut causer des congestions dans le réseau, du moment oùces protocoles ne prennent pas en charge la situation en temps réel du réseau (bandepassante disponibles des liens, délai de bout en bout réel...etc), ce qui représenteune contrainte aux applications ayant besoin de garanties et de QoS pour leur bonfonctionnement si le plus court chemin ne les remplie pas. Les entreprises qui utilisentle Web pour la diffusion de leurs contenus et/ou services ont besoin de QoS pour attirerplus de clients alors que les FAI (Fournisseur Accès Internet (FAI)) sont confrontésau défi d’offrir une meilleure QoS à leurs clients tout en respectant le SLA conclu. Sinous voulons implémenter de la QoS, nous devrons mesurer et améliorer les débits detransmission, les taux d’erreur ainsi que d’autres caractéristiques pouvant être mesurés,améliorés et garantis à l’avance. La QoS est particulièrement préoccupante pour latransmission continue des flux vidéo et multimédia à large bande passante, cependant,la transmission fiable de ce type de contenu est difficile dans les réseaux IP publicsutilisant les protocoles ordinaires. En effet, une application telle qu’une conversationvocale sur IP (Voice over IP (VoIP)) ou un streaming vidéo nécessite un délai et unegigue acceptables pour être d’une qualité aussi bonne que celle du téléphone et de latélévision traditionnels, et c’est ce qui est demandé par les utilisateurs. D’autre part,la communication de données est moins sensible à la latence et à la gigue, mais plussensible à la perte de paquets. Cette multitude de services implique souvent des besoins
1.2 Gestion de la Qualité de Service 9
différents en termes de QoS de la part du réseau qui transmettra les données de tellesapplications. Nous allons citer quelques métriques de la QoS, susceptibles d’intéresserle fournisseur de services, telles que la bande passante disponible, le taux de perte,la latence, ainsi que la gigue. Afin de prendre en charge la QoS, l’IETF a proposéplusieurs modèles permettant son implémentation. Les architectures et les mécanismesdéveloppés dans ce sens présentent, en réalité deux problème de QoS: l’allocation desressources et l’optimisation des performances [9]. Pour la première problématique,l’IETF a proposé deux architectures, la première, basée sur l’intégration des services(IntServ [3]), qui permet de réserver des ressources réseaux par flux pour que le niveaude service soit garanti, et la deuxième basée sur la différentiation des services (DiffServ[5]), qui permet de subdiviser le trafic en différentes classes, et donner pour chacuned’elles, un traitement différent. Le MPLS (Multi Protocol Label Switching (MPLS))ainsi que l’ingénierie du trafic (Traffic Engineering (TE)) donnent aux FournisseurAccès Internet (FAI) un ensemble d’outils permettant l’optimisation de la performanceet la gestion de la bande passante. Ils peuvent supporter la QoS à grande échelle et àun coût acceptable.
1.2.2 Les Métriques de la Qualité de Service
L’explosion de l’utilisation des applications multimédia sur les réseaux étendus(Wide Area Networks (WAN)) en général et dans Internet en particulier ont incitéles chercheurs à mener des études plus approfondies sur la QoS. En effet, augmenteruniquement les ressources telle que la bande passante afin d’éviter la congestion n’assurepas une bonne utilisation des ressources. Ce changement (en terme de dimensionnementdes ressources) était effectif pour les applications comme le FTP (File Transfer Protocol(FTP)), le HTTP (Hyper Text Transfer Protocol (HTTP)), et la messagerie d’unemanière générale. Cependant, les caractéristiques des flux multimédia sur Internet,présents de plus en plus, ont changé, et requièrent différents prérequis en termes deparamètres de QoS comme montré dans le tableau 1.1. Le réseau Internet est devenupratiquement omniprésent et utilisé pour toute communication étendues (VPN, Vidéoconférences, payement électronique, ...etc). Les applications multimédia ont besoin desservices réseaux, au-delà de ce que IP peut fournir. La latence ainsi que la synchro-nisation nécessaires pour la voix, les données et les images sont des préoccupationsmajeures. En effet, la téléphonie sur IP (ToIP) et d’autres applications multimédiastelles que la vidéo conférence, la vidéo à la demande et le streaming de médias exigentdes garanties de service ainsi que des exigences de délais strictes. La gestion de la
1.2 Gestion de la Qualité de Service 10
QoS nous permet d’assurer un débit, un délai, une gigue, ainsi qu’un taux de perte depaquets, selon les prérequis des différentes applications.
Flux Application Prérequisvidéo vidéo à la demande/vidéo conférence faible délai/bande passante garantievoix ToIP faible délai/gigue
Données messagerie, accès web faible perte de paquets/disponibilitéTable 1.1 Prérequis des différentes applications
1.2.2.1 Disponibilité de la bande passante
Elle se rapporte à la capacité inutilisée d’un lien par unité de temps. Elle dépendde la capacité du lien mais aussi de la quantité de données présente dans le lien [10].Cette métrique est une variable dépendante du temps, sachant que la capacité du lienest la quantité maximale de données pouvant transiter sur ce lien par unité de temps.Si l’on note Bdi(t) la bande passante disponible à l’instant t, Ci la capacité du lien i,et Bui(t) la quantité de données transitant sur le lien i, alors:
Bdi(t) = Ci - Bui(t)
1.2.2.2 La latence
C’est le temps total nécessaire à la transmission d’un paquet de sa source à sadestination. On parle du Round Trip Time (RTT)) pour qualifier le temps nécessaired’un aller-retour. Cette latence est liée à la congestion des liens de transmission, de lacapacité de traitement des équipements réseaux ainsi qu’à la distance parcourue parle paquet pour atteindre sa destination. Les applications sensibles à la latence sontles applications temps réel comme la transmission vidéo, la communication vocale, lesapplications interactives de type jeux-vidéo, etc. La maîtrise du délai de transmission estun élément essentiel pour bénéficier d’un véritable mode conversationnel et minimiserla perception d’écho dans la téléphonie ou dans la visiophonie. La latence dépend denombreux facteurs:
— Le débit de transmission sur chaque lien.— Le nombre d’éléments réseaux traversés.— Le temps de traversée de chaque élément, qui est lui même fonction de la puissance
et la charge de ce dernier.— Le délai de propagation de l’information.
1.2 Gestion de la Qualité de Service 11
— L’influence du codec, et du nombre d’échantillons par paquet.
— L’influence de la politique de gestion de la mémoire tampon de compensation degigue.
— L’influence du système d’exploitation utilisé, qui est un élément à prendre encompte pour minimiser les délais des applications multimédia. La figure 1.1résume les différentes latences qui rentrent en considération lors du calcul de lalatence globale.
Figure 1.1 La latence de bout en bout
1.2.2.3 La gigue
Connue aussi sous le nom de jitter, elle représente la différence des délais, commemontrée dans la figure 1.2, elle nécessite des capacités de mémoires tampons propor-tionnelles à son importance, et elle peut par conséquent agir sur la qualité de la voix.La gigue résulte principalement du fait que les paquets peuvent prendre des cheminsdifférents, de plus, la charge supportée par le réseau est instable. Donc on peut avoirdes temps d’attente différents sur la même file et pour le même flux, ce qui provoqueune variation dans le délai [11]. Le récepteur doit être capable de la compenser. Ceciest réalisable grâce à des protocoles qualifiés temps-réel. Il serait peut-être nécessairede préciser que la gigue serait présente mais non gênante dans le cas où les codecsn’élimine pas le silence, sur le plan traitement bien sûr, c’est-à-dire qu’il n’est plusindispensable de mettre en place un marquage temporel. Il est à noter que les buffersde la gigue (figure 1.3) causent un délai supplémentaire, car pour restituer le premierpaquet à la réception, il nous faut attendre jusqu’à un certain temps appelé temps delibération, donné par la formule 1.1 suivante:
1.2 Gestion de la Qualité de Service 12
tlibération− tdépart = L+J (1.1)
Figure 1.2 La gigue
Où L est la partie fixe du délai alors que J est la valeur attribuée à la gigue. Sicette dernière est très petite, le délai va s’améliorer mais on risque de ne pas avoir depaquets disponibles lorsqu’on restitue l’intégralité du paquet précédent, et inversement,si J est excessive, le délai de bout en bout peut atteindre une valeur inacceptable.
Figure 1.3 Le buffer de gigue
1.2.2.4 Taux de perte de paquets
Ce taux correspond au nombre de paquets qui n’arrivent pas correctement jusqu’àleurs destination dû à la congestion de l’infrastructure réseau (liens de transmission ouéquipements réseaux saturés). Il peut être amélioré en agissant sur plusieurs aspects,tels que le routage intelligent connu sous le nom du TE, cette métrique influence
1.3 Architectures de QoS 13
négativement sur la QoS des applications temps réel comme le streaming vidéo ouaudio, plus est elle est élevée, plus la qualité se dégrade.
Les contraintes temps réel de délai de transit évoquées ci-dessus rendent inutile laretransmission des paquets perdus, même retransmis, un datagramme d’une applicationmultimédia arriverait bien trop tard pour être d’une quelconque utilité dans le processusde reconstitution des données perdues. De ce fait et afin de réduire cette métrique,plusieurs modèles d’implémentation de la QoS ont été élaborés par l’IETF tels quele modèle à intégration de service (IntServ), à différentiation de service (DiffServ) etMPLS.
1.3 Architectures de QoS
1.3.1 L’architecture IntServ
IntServ [3] est la première tentative d’établissement d’un contrôle de la QoS dansles réseaux IP, cette solution émule le concept d’allocation des ressource dans lacommutation des circuits. Les noeuds du réseau sont obligés d’allouer des ressources àdes flux particuliers comme dans le cas d’une session d’appel dans la commutation. Eneffet, cette architecture définie trois niveaux de services:
— Le Service Garanti: il fournit des limites supérieurs en termes de délai de bout enbout, de bande passante ainsi que sur le taux de perte de paquets. Cette garantieest accomplie en se basant sur une combinaison de classifieurs, d’ordonnanceuret de contrôle d’admission.
— Le contrôleur de charge: il fournie aux flux un service approximatif à celuique recevront les flux meilleurs-effort (best-effort flows) dans un réseau noncongestionné. Ce service est accomplie grâce au contrôle d’admission.
— Meilleur effort: ce service ne fournie aucune garantie sur la moindre QoS, il estsimilaire au fonctionnement actuelle du protocole IP.
1.3.1.1 Le protocole RSVP
Pour la réservation des ressources, IntServ utilise le protocole Resource ReservationProtocol (RSVP), ce dernier utilise une signalisation basée sur le multicast, et doitmettre à jour périodiquement l’état de la réservation, ce qui fait de lui et de l’architectureun mécanisme non scalable. Pour établir une connexion, le protocole RSVP utilise deuxtypes de messages, Path et Resv, le premier est envoyé par l’émetteur, il contient les
1.3 Architectures de QoS 14
spécifications du flux (qui incluent l’adresse IP de l’émetteur), les caractéristiques duflux ainsi que les prérequis en terme de QoS. Le deuxième message (Resv) est envoyéquant à lui, du destinataire vers l’émetteur en traversant le chemin inverse du messagePath. Sur ce chemin, il définie les ressources à réserver pour le flux en question. Afin dedémonter une connexion, le protocole RSVP utilise les messages PathTear et ResvTear,le premier est envoyé de l’émetteur au destinataire, en prenant le chemin du messagePath, tandis que le deuxième est envoyé du destinataire à l’émetteur en prenant lechemin inverse du premier. Ces deux messages enlèvent l’état de la réservation, la figure1.4, montre bien ce fonctionnement. L’avantage de l’architecture IntServ est qu’ellefournie différentes classes de services [12]. Les utilisateurs peuvent donc définir leurtype de trafic et utiliser le service selon le type d’applications. Si ces dernières sontcritiques et intolérables tel que le trafic VoIP, ils peuvent utiliser le service garanti. Parcontre, pour les applications critiques mais tolérables comme par exemple le DynamicAdaptive Streaming over HTTP (DASH), ils peuvent utiliser le service contrôle decharge. Les autres applications moins critiques, comme la messagerie classique (mailing)peuvent quant à elles utiliser le service meilleur effort avec le protocole de transportTransmission Control Protocol (TCP) pour éviter les pertes de paquets. Cependant, lemaintien des états de réservation devient très difficile à gérer lorsque le réseaux monteen échelle (problème de scalability). Aussi, même si cette architecture nous permet desatisfaire les besoins en terme de QoS en garantissant la bande passante ainsi que lesressources nécessaires pour chaque flux, son implémentation avec le protocole RSVPnécessite d’avoir un état et une signalisation continue sur chaque routeur, et pourchaque flux.
1.3.1.2 Les faiblesses de l’architecture IntServ
Les inconvénients de cette architecture sont les suivants:
— La quantité d’informations sur les états augmente proportionnellement avec lenombre de flux. Ce qui exige des techniques de sauvegarde et de traitementavancées, et cela peut même être un problème de montée en échelle.
— Tous les routeurs doivent être capables de faire le contrôle d’admission, la classi-fication des paquets, ainsi que leur ordonnancement.
Par conséquent, le modèle IntServ n’a été mis en œuvre que dans un nombre limitéde réseaux, et l’IETF a décidé de développer un autre modèle (DiffServ) en tantqu’approche alternative de QoS avec peu de complexité.
1.3 Architectures de QoS 15
Contrôle d’admission
Local
Contrôle d’admission
Local
Contrôle d’admission
Distant
Requête RequêteRequêteRequête
Re
qu
ête
Point de contrôle d’admission
Réponse Réponse Ré
po
nse
Réponse Réponse
IP Phone Serveur VoIP
Figure 1.4 Exemple d’un concept IntServ
1.3.2 L’architecture DiffServ
DiffServ [5] a été introduit dans le but de contourner le problème de scalabilityd’IntServ. À la différence d’IntServ, où la réservation des ressources et le traitementdes flux sont effectués de bout en bout, DiffServ applique des politiques par saut (PerHop Behavior (PHB)). Aussi, cette technique traite un ensemble de flux (agrégats) aulieu de les traiter séparément. Les paquets sont classifiés sur la base de la valeur deleur Differentiated Service Code Point (DSCP) [13] de l’entête IP. Les autres recevrontun traitement identique de la part des équipements réseaux, peu importe le flux dontils font partie. Après la classification, chaque classe est traitée selon le PHB appliqué.
1.3.2.1 Le traitement par saut (PHB)
En effet, il existe plusieurs PHB définis, les plus courants sont les suivants:
— Le PHB par défaut: Les paquets avec un DSCP nul sont envoyés avec le niveaude traitement meilleur-effort.
— Le transfère accéléré (Expedited Forwarding (EF)): Ce type de PHB est réservéaux flux ayant besoin d’une latence, d’une gigue et d’un taux de perte de paquetstrès faible.
— Le transfère assuré (Assured Forwarding (AF)): Ce type de PHB est similaire auprincipe de contrôle de charge d’IntServ, il fournit un transfère assuré tant quele trafic ne dépasse pas un seuil donné.
1.3 Architectures de QoS 16
— Sélecteur de classe (Class Selector (CS)): Ce type de PHB est défini pour préserverla rétrocompatibilité avec la précédence IP qui précède DiffServ.
1.3.2.2 Rôle des routeurs dans une architecture DiffServ
Dans une architecture DiffServ (voir figure 1.5), les routeurs de bordure ainsi queceux du coeur du réseau assurent différentes tâches. Les premiers sont responsablesde la classification, du marquage, ainsi que des opérations de conditionnement d’unnombre limité d’agrégats ou classes de flux en utilisant le champ DSCP, alors que ceuxdu coeur sont responsables de l’ordonnancement et de la gestion des files d’attente, cequi rend DiffServ plus tolérable au facteur d’échelle (Scalability) par rapport à IntServ.Cependant, cette architecture ne fournit pas de garanties sur la QoS de bout en bout.D’autre part, il est possible d’accorder plus de priorité à une classe par rapport àd’autres, mais il est impossible de fournir certaines garanties de QoS au niveau du flux.Dans [14], les auteurs ont présenté un travail sur l’analyse de la QoS dans un réseau decommutation de paquets basé sur les réseaux de Petri stochastiques. Cela est importantdans la conception de réseaux dotés de telles fonctionnalités ; mise en forme du trafic,son contrôle, l’ordonnancement des paquets, gestion des mémoires tampon, contrôled’admission et acheminement des paquets. Trois ans plus tard, dans [15] ces auteursont étendu ce modèle pour garantir les fonctions offertes par l’architecture DiffServ.
Domaine Diffserv B
Domaine Diffserv A Domaine Diffserv C
Routeur EDGE
Routeur Cœur
Routeur D’accès
Figure 1.5 L’architecture DiffServ
1.3 Architectures de QoS 17
1.3.2.3 Conditionnement du trafic
Dans un domaine d’un FAI, les routeurs de bordure entrants (ingress borderrouters) sont responsables de la mise en correspondance des paquets avec leur classesd’acheminement, et s’assurer que le trafic est conforme au contrat de niveau de service(SLA) pour chaque client. Une fois les paquets dans le coeur de l’architecture, l’allocationdes ressource est faite uniquement sur la base des classes d’acheminement. Ces fonctions,assurées par ce type de routeurs, sont connues sous les termes de classification etconditionnement du trafic. La figure 1.6 montre les principaux composants utilisés danscette opération.
Classification MarquageLissage
Suppression
Mesure
Conditionnement de trafic
Paquets sortantsPaquets entrant
Figure 1.6 Vue logique d’une classification de paquets et d’un conditionnement detrafic
En effet, le composant responsable de la mesure (compteur) supervise et mesurechaque flux sélectionné par un classificateur par rapport à un profil et décide si lepaquet est conforme ou non. Par la suite, il informe les autres composants sur cetétat, les paquets hors profile seraient supprimés, remarqués pour un autre service,ou retenu temporairement dans le lisseur, le temps qu’ils deviennent conforme. Lespaquets conformes au profil sont mis dans différentes files d’attente en attendantd’autres traitements. Le marqueur met à jour le champ DS, puis, ajoute le paquetmarqué à la classe de transfert correspondante. Les marqueurs devraient agir surles paquets non marqués ou remarquer ceux qui ont été précédemment marqués. Lecomposant responsable du lissage est utilisé afin de réduire le débit d’un flux et le rendreconforme à son profile, alors que celui qui est responsable de la suppression, supprimeles paquets sur la base du contenu du SLA. Ce composant peut être implémenté en tantqu’un lisseur de trafic avec une mémoire tampon dont la taille est nulle. Il supprimeuniquement les paquets hors profile.
1.3 Architectures de QoS 18
1.3.2.4 Comparaison avec IntServ
En effet, les architectures IntServ et DiffServ sont différentes. DiffServ dépend dela granularité de la classe et la quantité informationnelle d’état est proportionnelle auxnombre de classes au lieu du nombre de flux, ce qui a rendu DiffServ plus scalable parrapport à IntServ avec une prise en charge d’un nombre important de flux dans unlarge domaine de FAI. Dans une architecture DiffServ, il y uniquement les routeurs debordure qui sont responsables de la classification de trafic et du marquage des paquets.Une fois cette étape faite, les routeurs du coeur utilisent le code DSCP pour déterminerle traitement à offrir aux paquets, par contre IntServ exige que tous les routeursfassent la classification des paquets afin d’identifier les paquets des flux prioritaires etles ordonnancer avec une mise en file d’attente par flux. Aussi, DiffServ garantie lesressources par le biais du provisioning, associé à la priorité des paquets plutôt qu’àune réservation par flux, comme dans IntServ, ce qui permet la création de différentsniveau de services et allocation de ressource et non pas des garanties sur la bandepassante ou délai pour des flux individuels [3][5].
1.3.2.5 Inconvénients majeurs de DiffServ
Il est claire que DiffServ est une solution scalable, qui n’exige pas une signalisationpar flux, ni un maintien d’état au niveau du coeur du réseau. Cependant, elle ne fourniepas une architecture de QoS de bout en bout. Aussi, elle ne prend pas en charge lacongestion des liens ou leur coupure, c’est à dire, que si un lien transmet un fluxprioritaire, dans un domaine DiffServ, et il est utilisé à 90%, DiffServ n’offre aucunmoyen pour basculer sur un autre chemin plus libre (pas d’ingénierie de trafic).
1.3.3 MPLS
1.3.3.1 Principe du concept MPLS
Ce concept permet de fournir une commutation très rapide des paquets IP au lieude les router (consultation de la table de routage dans chaque saut), ce qui convientparfaitement au transport des flux multimédia. Le MPLS combine les avantages dela commutation des circuits de l’ATM et du routage des paquets IP. Le principe deMPLS est de fournir des étiquettes (Labels) aux paquets, évitant ainsi une consultationcomplexe des tables de routage au niveau des routeurs. Dans un réseau basé sur MPLS,un paquet est étiqueté suite à son affectation à une Forwarding Equivalent Class (FEC),qui définira la manière d’acheminement du paquet à travers tout le réseau MPLS [16].
1.3 Architectures de QoS 19
Les paquets appartenant à la même classe auront la même étiquette, la FEC regroupel’ensemble de paquets qui rentrent dans un réseau à travers le même routeur d’entrée(ingress router) et sortent par le même routeur de sortie (egress router). Elle peutconcerner aussi les paquets ayant besoin des prérequis de QoS ou traitements similaire.La commutation des paquets dans le coeur du réseau est assuré par les Label SwitchingRouter (LSR), selon le chemin Label Switching Path (LSP) établi. L’établissementde ces chemins peut être effectué par le routage saut par saut, ou en utilisant leroutage explicite. En effet, la première option permet à chaque LSR du coeur de réseaude choisir indépendemment le prochain saut pour chaque FEC, alors que les routesexplicites peuvent être déterminées par des LSR spécifiques ou en utilisant le routagesource (source routing) où l’émetteur d’un paquet peut déterminer une partie ou latotalité du chemin menant vers la destination [17]. La figure 1.7, illustre les différentséquipements qui interviennent dans une architecture MPLS.
Figure 1.7 L’architecture MPLS [18]
L’approche de commutation des étiquettes a été conçue initialement afin d’améliorerles performances du routeur. Cependant, cette motivation a diminué avec les progrèsréalisés sur la conception des routeurs et la vitesse de transmission des données.Mais par la suite, l’avantage le plus important de cette architecture a été perçu. Eneffet, du moment où l’approche est orientée connection, les FAI peuvent l’utiliser pourimplémenter l’ingénierie du trafic dans leurs réseaux, et atteindre une variété d’objectifs,notamment sur la gestion de la bande passante, le routage, le partage de charge, laredondance de chemins ainsi que d’autres services ayant une relation avec la QoS [19].
Le concept le plus important de MPLS est sa séparation des plans de contrôleet de l’acheminement dans les noeuds du coeur du réseau (core routers). Sur le plande contrôle, les fonctions de coordination au niveau réseau tels que le routage et la
1.3 Architectures de QoS 20
signalisation ont pour but, de faciliter l’acheminement du trafic dans le réseau. L’unedes fonctions de contrôle les plus importantes, est l’établissement des LSP, car ce dernierpourrait être l’objet de différentes contraintes et préférences. Le plan de contrôle estresponsable de la gestion de la topologie du réseau ainsi que celle de la disponibilité desressources, il est responsable aussi de la signalisation et de la mise en place des LSP.Les composants responsables du transfert effectuent des opérations de commutationd’étiquettes sur la base des informations sur l’acheminement des étiquettes. La figure1.8, illustre l’architecture interne d’un LSR.
Protocoles de routage
Protocole de distribution des étiquettes
Table de routage
Informations sur l’acheminement des étiquettes
Echange des informations de routage
Echange des informations de correspondances d’étiquettes
Paquets IP sortant
Paquets étiquetés sortant
Paquets IP entrant
Paquets étiquetés entrant
Figure 1.8 Architecture d’un routeur coeur MPLS
1.3.3.2 Avantages du MPLS
Le partage de charge dans l’ingénierie du trafic devrait être capable de contrôler letrafic réseau avec précision. En effet, dans les réseaux traditionnels, l’administrateurréseau peut changer uniquement les coûts des liens (links cost), et ce changement peutaffecter l’acheminement global du trafic. Afin de mieux gérer la performance du réseau,il est nécessaire d’avoir un contrôle explicite sur les chemins empruntés par les flux detelle sorte de maximiser l’utilisation de tous les liens, et de ce fait, optimiser l’utilisationdes ressources réseaux, il est à noter, que le concept MPLS possède ce mécanisme(routage explicite), qui est idéal pour ce besoin. Dans une architecture MPLS, l’approchede commutation d’étiquette est utilisée afin de mettre en place des circuits virtuelsdans les réseaux IP. C’est circuits virtuels peuvent suivre l’acheminement basé surl’adresse IP de destination, cependant, l’acheminement explicite d’MPLS nous permetaussi de spécifier le chemin de ces circuits virtuels saut par saut. Les protocoles deroutage, tels qu’OSPF et Border Gateway Protocol (BGP) déterminent ces routesexplicites à l’avance et mettent à jour les tables de routage dans chaque routeur qui,
1.3 Architectures de QoS 21
à son tour, définie les routes. Les paquets sont dotés d’étiquettes afin d’indiquer leLSP à suivre [9]. L’utilisation des protocoles de routage dynamique standards dans ladétermination des routes explicites est la procédure par défaut, et peut être mis enplace sans l’intervention des opérateurs. D’autre part, MPLS est très flexible et peutdéfinir des chemins avec prise en charge des contraintes de routage (bande passantedisponible, priorité des paquets, objectifs des opérateurs...etc).
1.3.4 Ingénierie de Trafic
1.3.4.1 Définition
L’ingénierie de trafic est une solution qui nous permet d’installer et de contrôler lesflux dans un réseau, en tirant pleinement profit de toutes les potentialités offertes par lesressources en évitant une utilisation inégale du réseau. Cette solution est requise dansle réseau internet actuel car les protocole de routage dynamiques (Interior GatewayProtocols (IGP)) utilisent toujours le plus court chemin lors de la transmission despaquets. Plus particulièrement, ce concept nous fournie la possibilité de déplacer lesflux d’un chemin congestionné, sur un autre plus libre, même si le premier aurait étéchoisi par un IGP. L’ingénierie de trafic est un outil puissant pouvant être utilisé par lesfournisseurs de service afin d’équilibrer l’utilisation des ressources réseaux et optimiserla charge des équipements réseaux. L’ingénierie de trafic devrait être vue comme étantune assistance à l’infrastructure de routage en lui fournissant plus d’information surl’état des liens en temps réel. Le groupe de travail composé de (Traffic EngineeringWorking Group (TEWG)) et celui de l’IETF qui a travaillé sur le protocole RSVP adéfinie que l’ingénierie de trafic concerne l’optimisation de la performance des réseauxopérationnels [20]. Il englobe la mesure, la modélisation, la caractérisation ainsi que lecontrôle du flux Internet. Il applique aussi des techniques ayant pour but d’atteindredes objectifs de performance spécifiques, y compris la circulation fiable et rapide dutrafic via le réseau, l’utilisation efficace de ses ressources ainsi que la planification desa capacité. En mettant en oeuvre ce concept, les fournisseurs de services peuventoptimiser considérablement l’utilisation des ressources et la performance du réseau.
1.3.4.2 Objectif de l’ingénierie de trafic
les objectifs de l’ingénierie de trafic sont les suivants :
— Réduire la congestion ainsi que le taux de perte des paquets dans le réseau,d’ailleurs, nous avons proposé dans ce sens une technique permettant de minimiser
1.3 Architectures de QoS 22
la congestion des flux vidéo en les éparpillant dans tout le réseau, comme nousallons le voir dans la partie expérimentation des solutions proposées.
— Amélioration de l’utilisation des liens.
— Réduire la latence dans le réseau.
— Augmenter le nombre de clients avec l’infrastructure existante.
En effet, la congestion réseau est l’une des problématiques les plus difficiles rencon-trée par les fournisseurs de service. Cette congestion peut être causée par deux facteurs,le premier concerne le manque de ressources réseaux, alors que le deuxième concernel’impossibilité de basculement du trafic sur d’autres chemin plus libre, en temps réel.En fait, même si le premier facteur pourrait être résolu en augmentant les capacités duréseau, ou réduire et contrôler les nouvelles demandes, le deuxième facteur, quant àlui, devrait être corrigé par une meilleure gestion des ressources du réseau. L’objectifprincipal de l’ingénierie de trafic est de distribuer le flux réseau afin de maximiserl’utilisation des ressources réseaux et fournir les prérequis en terme de paramètres QoStels que la latence, la gigue, le débit et le taux de perte de paquets aux applicationsselon leur nature. Afin de mettre en pratique l’ingénierie du trafic, l’IETF a introduitle protocole Multi Protocol Label Switching (MPLS), l’acheminement des paquets avecprise en charge des contraintes réseaux ainsi que des protocoles de routage dynamiqueà état de lien avancés. La figure 1.9 résume les prérequis de l’ingénierie du trafic.
Interface de Gestion
MPLS(Routage Explicit)
Routage avec prise en charge des contraintes
Processus IGP conventionnel
Base de données des états de lien
Information sur la topologie réseau
Figure 1.9 Prérequis de l’ingénierie du trafic
1.3.4.3 Routage avec prise en charge des contraintes réseaux (RCR)
Ce type de routage est très utilisé lors de la mise en place des politiques de QoS. Ilconsidère les prérequis des applications lors des décisions de routage en cherchant des
1.3 Architectures de QoS 23
chemins qui vont satisfaire des contraintes uniques ou multiples (délai, gigue, bandepassante, perte de paquets...etc). Lors de l’établissement des chemins, un tel type deroutage ne considère pas uniquement la topologie du réseau mais prend en charge lesprérequis du flux, la disponibilité des ressources ainsi que d’autres éléments spécifiés parles opérateurs. De ce fait, cette technique de routage permet de trouver de long cheminsmoins congestionnés que d’en trouver d’autres plus courts mais congestionnés, ce quipermet d’optimiser l’utilisation du réseau et la distribution du trafic. Lorsque MPLS etce type de routage sont utilisés ensemble, ils rendent chacun d’eux plus efficace. MPLSfournit à l’RCR des informations précises sur les statistiques des chemins (entre lespaires de routeurs entrants et sortants), et l’RCR fournit à MPLS les chemins établis.
1.3.4.4 Métriques de routage et calcul des chemins
Les métriques de routage expriment une ou plusieurs caractéristiques d’un cheminafin de pouvoir évaluer sa convenance par rapport à d’autres chemins ayant d’autrespropriétés à acheminer les paquets selon leurs classes. Elles ont des implications majeurs,non seulement dans la satisfaction des prérequis, mais aussi dans la complexité ducalcul des chemins. Dans [9] et [21], les protocoles de routage utilisés, déterminent quecertaines routes sont préférables par rapport à d’autres sur la bases des métriques, cesdernières reflètent les propriétés de base du réseau. Il existe des protocoles de routagequi choisissent des routes sur la base de plusieurs métriques tel que l’Enhanced InteriorGateway Routing Protocol (EIGRP) de Cisco. Les métriques les plus utilisées sont lessuivantes:
— Le nombre de sauts: c’est la métrique la plus commune aux protocoles deroutage, elle représente le nombre de routeurs que devrait traverser un paquetpour atteindre sa destination. Les protocoles de routage comme le RoutingInformation Protocol (RIP) ou l’Interior Gateway Routing Protocol (IGRP)(version antérieur d’EIGRP) utilisent cette métrique lors du calcul des chemins,les meilleurs chemins, sont ceux qui contiennent le moins de sauts.
— La bande passante: Elle est mesurée en bits par seconde (bps). Les protocoles(comme OSPF) qui utilisent cette métrique, considère la capacité totale des liensqui composent le chemin de bout en bout. Le chemin avec la plus grande capacitéest le meilleur.
— Le délai: c’est le temps nécessaire pour envoyer un paquet d’une source versune destination. Il dépend de plusieurs facteurs, comme la bande passante desliens, la file d’attente au niveau des ports des routeurs tout au long du chemin de
1.4 Applications Multimédia 24
communication, la congestion du réseau, ainsi que la distance physique parcourue.Les protocoles de routage qui utilisent cette métrique doivent avoir les valeursdu délai des différents liens tout au long du chemin. Plus la somme de ces délaisest faible, meilleur est le chemin.
— La charge: Elle représente le degré d’occupation d’une ressource réseau. Lacharge est une valeur variable, elle est généralement mesurée sur une périodede temps en indiquant la charge du trafic sur un lien donné. L’administrateurréseau peut configurer une valeur statique pour cette métrique, ou la mesurerdynamiquement, ce qui lui permet d’ajuster la matrice de flux selon le changementdu réseau. Plus le lien est moins congestionné, plus il est privilégié lors du routage.
— La fiabilité: Dans le contexte des algorithmes de routage, elle concerne les liensdu réseau. En effet, il y a des liens qui deviennent hors service plus fréquemmentque d’autres, et après une coupure, certains liens se rétablissent plus facilementet plus rapidement que d’autres. Les valeurs affectées à cette métrique parl’administrateur sont arbitraires, et selon les coupures, les erreurs, et les pertesde paquets observés sur les interfaces. Généralement, la valeur de la fiabilité estcomprise entre 1 et 255, plus la valeur est grande, plus la fiabilité du liens estmeilleure.
1.4 Applications Multimédiala variété des types de médias est une caractéristique importante des systèmes
d’information modernes, ces derniers ont reçu beaucoup d’attention récemment, d’oùleur développement sans cesse et avec succès. Il est nécessaire qu’un système multimédiaprenne en charge divers types de médias, simple qu’ils soient, tels que le texte et lesgraphiques ou riche tels que l’animation, l’audio et la vidéo. Nous citons dans ce quisuit des exemples d’application multimédia.
1.4.1 La vidéo conférence
Ce type d’application multimédia deviens de plus en plus populaire et plus fiable entant qu’outil qui permet de réduire les distances lorsque les déplacements ne sont paspossibles, peu pratiques ou non souhaités. La vidéo conférence utilise les infrastructuresdes télécommunications qui permettent de véhiculer l’audio et la vidéo pour réunir despersonnes se trouvant sur des sites différents. Elle est devenue récemment de plus enplus populaire et s’est répandue dans le sillage des connexions internet plus rapides
1.4 Applications Multimédia 25
et moins chères en utilisant les meilleures technologies. Vue la criticité des flux émiset reçue par ce types d’application, une mise en oeuvre d’une stratégie de QoS estindispensable dans les réseaux où les ressources sont limitées.
1.4.2 La télésurveillance
La télésurveillance est une application qui nous permet de surveiller en tempsréel des sites distants pour des raisons de sécurité. Vue son importance, elle estdevenue pratiquement omniprésente et indispensable pour de nombreuses organisations,entreprises et utilisateurs. Son principal objectif est d’assurer la sécurité physique,d’accroître la sûreté et de prévenir la criminalité. Selon le besoin, cette application estappelée à utiliser la vidéo ainsi que l’audio à la fois, ou uniquement la vidéo. Commepour le cas de la vidéo conférence, la télésurveillance nécessite une mise en oeuvred’une politique de QoS, de ce fait, beaucoup de travaux ont été proposés dans ce sens,comme celui discuté dans [22].
1.4.3 La vidéo à la demande
La vidéo à la demande est une application multimédia populaire sur Internet.Elle fournit le mécanisme permettant de diffuser des contenus multimédias tels quel’audio ou la vidéo au grand public en utilisant l’infrastructure du réseau Internet [23].Cependant, les services basés sur Internet sont confrontés au problème de la QoS enraison de l’instabilité des réseaux et de leur congestion. En effet, les performances sedégradent lorsque le contenu est diffusé à un grand nombre de consommateurs. De cefait, des mécanismes de mise en oeuvre de la QoS sont primordiales.
Ces quelques exemples d’application multimédia permettent d’illustrer les multiplescontraintes auxquelles est soumis ce type d’applications, notamment, le devoir derespecter les paramètres de la QoS, tels que la latence, la gigue ainsi que la perte depaquets du moment où ces applications manipulent et transmettent des flux composésessentiellement de l’audio, de la vidéo ou des deux, conjointement. Dans le cas où le ré-seau présente des insuffisances en termes de ressources (bande passante, non respect dudimensionnement des équipements réseaux, congestion réseau, perte de paquets...etc),ces applications ne parviendront pas à offrir un service de qualité satisfaisante auxutilisateurs finaux et deviennent par conséquence inexploitables. Il est donc impératifde mettre en place des mécanismes nous permettant de gérer la QoS du réseau qui va
1.4 Applications Multimédia 26
véhiculer les flux générés.
Afin de stocker ou de transférer des données multimédia, deux types de médiassont utilisés: les médias continus et les médias discrets. Les premiers sont ceux qui ontune dimension temporelle implicite, dans ce cas les données doivent être présentées enfonction des contraintes particulières en temps réel pendant une durée déterminée, dece fait, le temps joue un rôle cruciale dans ce type de média (comme par exemple, lareconstitution correcte des échantillons codés). L’audio, la vidéo et l’animation appar-tiennent à ce type de média, ces derniers se composent d’une séquence d’échantillonscontinue où chaque échantillon décrit une partie de l’information, selon le codageutilisé. Cette information est obtenue suite à un échantillonnage périodique des donnéescaptées par des sources d’acquisition comme les caméras ou les microphones [24]. Cetype de média présente donc une sensibilité au temps et à la synchronisation. Au niveaude la réception, un décodage rythmé devra être mené pour une meilleur intelligibilité del’information transporté par ce type de média. La figure 1.10 montre les caractéristiquestemporelles d’un flux vidéo, où nous notons qu’une image est acquise toutes les 40millisecondes pour donner l’illusion parfaite du mouvement, à la réception, la restitutiondes images devra se faire d’une manière périodique afin d’éviter toute dégradation dela lecture de la vidéo.
Les médias discrets par contre, n’ont aucun rapport avec la limitation temporelle.Cependant, la présence de toute les donnée qui compose le média lors de la restitutionde l’information est primordiale, ce qui les rend sensibles à la perte de paquets. Letexte et les graphiques sont des exemples de ce type de médias. La figure 1.11 est unexemple d’une page web utilisant différents médias discrets.
Figure 1.10 Caractéristiques Temporelles d’un Flux Vidéo
Vue la variété des types d’informations contenues dans les applications multimédiaainsi que leur caractéristiques, cela n’empêche pas de trouver des médias totalementdiscrets, ou totalement continus. En effet, si on prend l’exemple d’une vidéo sous titrée,cette dernière contient un média continu et un autre discret (qui est le texte du sous
1.4 Applications Multimédia 27
Figure 1.11 Une page Web qui utilise des médias discrets
titrage), d’autre part, nous avons l’affichage d’un diapo où les images sont affichéestoutes les 10 secondes par exemple, dans ce cas la gigue n’a pas vraiment un impactsur la qualité d’expérience, par contre lorsqu’il s’agit d’une vidéo où les images défilentplus rapidement, dans ce cas, la gigue possède un impact plus important sur la qualitéd’expérience.
1.4.4 Synchronisation des médias
Le mot synchronisation fait référence au temps. La synchronisation dans un systèmemultimédia fait référence à la relation temporelle entre les médias. Dans un sens plusgénéral et plus largement utilisé, on note que la synchronisation dans les systèmesmultimédias concerne le contenu, les relations spatiales et temporelles entre les objetsqui composent les médias. Si ces derniers sont dépendants du temps, ils sont représentéscomme un flux de médias. Si les durées de présentation de toutes les unités d’un objetmédia dépendant du temps sont égales, on parle alors, comme nous l’avons vue, d’unmédia continu. Par contre, si la dépendance au temps est inexistante, nous parlonsalors dans ce cas, de médias discrets. Un exemple de synchronisation entre les médiascontinus et que nous rencontrons quotidiennement est la synchronisation entre lesinformations visuelles et acoustiques à la télévision. Dans un système multimédia,la même synchronisation doit être assurée pour le son et les images animées. Un
1.4 Applications Multimédia 28
exemple de relations temporelles entre les médias dépendant du temps et les médiasindépendants du temps est le diaporama, dont la présentation des diapositives estsynchronisée avec le flux audio des commentaires. Pour réaliser un bon diaporamadans un système multimédia, la présentation des graphiques doit être synchroniséeavec les unités appropriées d’un flux audio. Les relations spatiales quand à elles, ellesdéfinissent l’espace utilisé pour la présentation d’un objet média sur un périphériquede sortie à un moment donné, dans une présentation multimédia. Si le périphérique desortie est bidimensionnel (par exemple, un écran 2D ou du papier), la mise en pagespécifie la zone bidimensionnelle à utiliser. La synchronisation du contenu peut êtrepar exemple faite entre un tableau et une image représentant le contenu du tableau.La figure 1.12 résume les différents type de synchronisation.
Médias
Synchronisation de Contenu
Synchronisation Spatiale
Synchronisation Temporelle
Directe
Synthétique
Figure 1.12 Les différents types de synchronisation [24]
Lors de la restitution des médias, il est recommandé de respecter les relations desynchronisation dans les applications multimédia. Dans le cas contraire, la qualitéd’expérience va être dégradée, et le contenu des médias sera à ce moment là, incompré-hensible. Le décalage entre le son et la vidéo, d’un match de football pourrait être unbon exemple des résultats de la désynchronisation entre les objets du flux multimédia.Dans ce sens, plusieurs travaux de recherche ont été menées, comme celles effectuée àIBM [25].
1.5 Codage et structure des médias continus 29
1.5 Codage et structure des médias continusVue la taille de l’information que contiennent les médias continus, leur débit généré
sera très important si nous n’utiliserons pas des techniques de compression. En effet,beaucoup de travaux sur le codage et la compression de données ont été menées avecpour objectif de réduire ce volume (important) sans pour autant perdre trop de qualité(perte de l’information), donc un compromis entre la compression et la perte de qualitédevra être fait.
1.5.1 Le codage audio
Le signal audio est un signal dont la plage de fréquence est comprise entre 20 Hzet 20 KHz. La parole des humains ainsi que d’autres sons comme ceux de la musiquesont des exemples de signaux audio. Afin de convertir un signal audio analogiqueen un autre numérique, on utilise ce qu’on appelle des convertisseurs ConvertisseurAnalogique Numérique (CAN), le résultat de la conversion représente un mot binairepouvant être stocké dans des support de stockage numérique tels que les CD, clés USB,ou transmis à l’aide des protocoles réseaux. Au niveau de la réception, l’opérationinverse est faite (conversion du mot binaire en un signal analogique) est faite à l’aided’un Convertisseur Numérique Analogique (CNA), puis envoyer le résultat (signalanalogique) à un périphérique de sortie comme le haut parleur [26]. Le théorème deShannon-Nyquist stipule que pour restituer un signal échantillonné, il faut que lafréquence d’échantillonage soit supérieure ou égale à deux fois la fréquence maximaledu signale en question. En conséquence, il faut choisir une fréquence d’échantillonnagefe respectant la propriété suivante : fe > 2.fmax où fmax représente la plus hautefréquence contenue dans le signal qu’on veut échantillonner.
1.5.2 Le codage vidéo
La représentation numérique efficace des signaux d’image et de vidéo a fait l’objetde recherches considérables au cours des 20 dernières années. En effet, lorsque nousvoyant plusieurs images en un temps réduit, nous avons l’impression que nous sommesen train de regarder une animation, de ce fait, et à fin de donner cette impression, unecaméra capture un grand nombre d’image en un temps réduit (pour donner l’impressiond’un mouvement) puis les convertie en signaux électriques [27]. Chaque image capturéeest représentée par une grille rectangulaire d’éléments appelés pixels. Chacun de ces
1.6 Conclusion 30
derniers est codé par la suite par un mot binaire qui représentera l’information véhiculée,notamment celle de la couleur et de la luminance.
1.5.3 Compression des médias
Afin de pouvoir représenter certains médias volumineux, des recherches sur lacompression de ce type de données dont le principal objectif est de réduire de manièresignificative le volume d’information nécessaire à leur représentation ont été menées.Les techniques employées sont basées sur des paramètres psychosensorielles de l’êtrehumains. La réduction de ce volume peut se faire avec ou sans perte de qualité sachantqu’il s’avère que les compressions les plus efficaces s’effectuent en dégradant la qualitédes données. La norme MPEG [28] permet de compresser des signaux vidéo et audio(analogiques ou numériques) pour une meilleur transmission sur un réseau IP. Enutilisant ce standard, la synchronisation inter-médias est assurée. En effet, dans laplupart des séquences vidéos, la majorité des scènes sont fixes ou bien changent trèspeu, c’est ce qu’on appelle une redondance temporelle, d’où la possibilité de ne recoderuniquement les différences entre les images successives tout en introduisant la notiond’interpolation et de prédiction pour réduire au maximum les redondance d’informationà compresser, la méthode MPEG, est l’une des compression qui utilise ce principe lorsde la compression vidéo.
1.6 ConclusionDans ce chapitre, nous avons vu la QoS en général, sa définition, son besoin, la
définition de ses métriques (disponibilité de la bande passante, taux de perte de paquets,et la latence), nous avons vu aussi les différentes architectures de mise en oeuvre dela QoS, les applications multimédia, leurs types, leurs synchronisations, leurs codagesainsi que leur compression. Nous allons présenter dans le chapitre suivant un état del’art sur le concept des réseaux SDN et la prise en charge de la QoS par les protocolesainsi que les équipements qui interviennent dans ce type de réseau.
Chapitre 2
Etat de l’art sur les Réseaux SDNet QoS
2.1 IntroductionLe système de contrôle des réseaux IP traditionnels que nous utilisons de nos jours
est distribué, chaque équipement du réseau représente une entité avec ses propres plansde contrôle et de transmission. Le plan de contrôle est responsable de la configura-tion de l’équipement réseau ainsi que du calcul des chemins de communication desflux de données. Par la suite, les décisions prises par ce plan sont utilisées par celuide transmission, en choisissant les ports de sortie spécifiés Le plan de transmissionmanipule aussi le lissage des flux lorsque cela est nécessaire. En effet, étant donné queles noeuds du réseau possèdent leurs propres plan de contrôle et de transmission, ilsprennent des décisions locales en se basant sur des informations partagées entre eux.Le système de contrôle distribué a sûrement des avantages puisque chaque équipementest autonome et il n’existe pas des points uniques de rupture, d’autre part, c’est unsystème qui a fait ses preuves et qui a été utilisé pendant plusieurs décennies où lesadministrateurs réseaux se sont familiarisés avec. Cependant, dans un réseau large avecplusieurs équipement réseaux, les administrateurs réseaux devraient configurer chaqueéquipement individuellement (routeurs, commutateurs), l’opération est fastidieuse etsujette à l’erreur humaine [29]. Aussi, chaque constructeur possède sa propre interfacede configuration, Cisco [30] utilise l’Internetwork Operating System (IOS), alors queJuniper [31] utilise Juniper Operating System (JOS), et les administrateurs doiventapprendre à les utiliser. Tous ces inconvénients des réseaux traditionnels ont mené àla séparation du plan de contrôle de celui des données et à la naissance des réseauxprogrammables (Software-Defined Networks (SDN)). Dans de tels réseaux, les équipe-
2.2 Le concept SDN 32
ments ont été dépourvus de la partie contrôle et effectuent uniquement l’acheminementdes données. La fonction de contrôle est réalisée par une seule entité, appelée toutsimplement le Contrôleur.
Dans la plus part des cas, le contrôleur est hébergé dans un serveur. Pour desraisons de monté en échelle (scalability) et de fiabilité, on peut déployer plusieurscontrôleurs [32]. Les équipements réseaux sont moins spécifiques, un équipement réseaun’aura comme tâche, que la transmission des données selon les instructions reçuesdu contrôleur. Et du moment où le système d’exploitation (partie intelligente) deséquipements réseaux est propriétaire dans les réseaux traditionnels, elle a été extraitesur le contrôleur, ce qui donne la possibilité aux opérateurs réseaux d’utiliser n’importequel équipement supportant le concept SDN, disponible dans le marché, et l’intégrerdans leur propre réseau sans aucun problème. D’autre part, la possibilité de programmerle contrôleur selon les besoins, rendra plus efficaces les opérations liées au réseau tellesque le routage. Ainsi, de nouvelles politiques de routage, ou même un nouvel algorithmede routage, peuvent être facilement déployés sur le réseau. Cela augmente aussi le tauxd’innovation dans le domaine des réseaux.
2.2 Le concept SDN
2.2.1 Définition
Ce concept décrit une architecture de réseau permettant une gestion purementlogicielle du réseau. Pour cela, le plan de contrôle est séparé de celui des données, entermes plus simples, le concept SDN correspond à la séparation de l’infrastructureréseau de sa configuration. Le plan de données, par conséquent, reste une partie deséquipements réseaux individuels (c’est-à-dire tous les routeurs, commutateurs et pare-feu intégrés dans le réseau). Cependant, leurs tâches dans ces réseaux programmables estexclusivement de transférer les paquets, c’est pourquoi ils nécessitent peu de puissancede calcul. Le plan de contrôle, quant à lui, est assuré par un logiciel, hébergé dans unéquipement centralisé appelé le contrôleur. La communication entre les deux plansest assurée en utilisant des protocoles, comme OpenFlow, ForCES, SoftRouter...etc.Les Application Programming Interface (API) assurent le lien entre les applications etle contrôleur. Les applications peuvent exprimer leurs besoins en terme de stockage,bande passante, délai...etc, et le contrôleur peut les mettre à leur disposition. La figure2.1 illustre les composants de base d’une architecture SDN.
2.2 Le concept SDN 33
Figure 2.1 Architecture d’un réseau SDN [21]
2.2.2 Le protocole OpenFlow
2.2.2.1 Définition
Le protocole OpenFlow est sans doute la première et la plus populaire implémenta-tion du concept SDN. Il définit un ensemble de messages permettant au contrôleur SDNde communiquer directement avec le plan de transfert (acheminement) des équipementsréseaux. Le projet de développement de ce protocole a commencé à l’université deStandford en 2008, l’idée était de fournir une méthode permettant de faire des expéri-mentations dans un réseau de production sans affecter le comportement de ce dernier.La première version des spécifications de ce protocole (version 1.0), a été faite en 2009.Actuellement, le protocole OpenFlow est géré par l’Open Networking Foundation (ONF)[33]. A partir de là, il s’est répandu, non seulement dans la communauté académiquemais aussi dans le monde de l’industrie des réseaux. L’un des déploiements les plusréussis d’OpenFlow à grande échelle est celui du géant Google [34] en 2013. Dans ceprojet, Google a implémenté ce protocole dans son réseau étendu pour interconnecterses salles des serveurs (data centers) du monde entier. La figure 2.2 illustre commentle contrôleur peut créer, supprimer, et modifier le contenu de la table de flux du
2.2 Le concept SDN 34
commutateur en utilisant ce protocole. Il devrait y avoir, au minimum une table deflux par commutateur. La figure 2.3 montre la composition d’une entrée de flux, cettedernière est constituée de zones d’en-tête (par exemple, adresse IP source/destination,ports) pour identifier de façon unique chaque flux, les compteurs sont utilisés pourrecueillir les statistiques sur le nombre de fois qu’une entrée de flux a été utiliséeavec succès, les cookies sont utilisés pour l’annotation par le contrôleur SDN...etc.Les temps de séjour sont utilisés pour déterminer la durée de validité d’une entrée deflux. La priorité aide le commutateur à choisir l’entrée dans le cas où plusieurs d’entreelles existent. Les actions déterminent ce que doit faire le contrôleur pour les paquetsidentifiés. Lorsqu’un paquet arrive au commutateur, ce dernier consulte sa table de fluxpour trouver une entrée qui lui correspond et détermine l’action, comme par exemple,acheminer le paquet sur un port spécifique.
Commutateur
Canal Sécurisé
Table de Flux 0
Table de Flux 1
Table de Flux n
…..
OpenFlow
Figure 2.2 Fonctionnement du protocole OpenFlow
Header Fields
Counters Actions
IngressPort
Ether Src
Ether Dst
Ether Type
VLAN id
VLAN Prio
IP Src IP DstIP
ProtoToSBits
Port Src
Port Dst
Figure 2.3 En tête d’une entrée de flux
2.2 Le concept SDN 35
Lorsqu’un commutateur reçoit un paquet, il scanne les tables de flux, en com-mençant par la première table de flux numéro 0 (la principale), afin de chercher unecorrespondance, dans le cas où il n’y a pas de correspondance dans cette table, ilcherchera au niveau de la table de flux numéro 1. Le processus continuera jusqu’àl’obtention d’une correspondance et l’acheminement du paquet. Il existe aussi uneentrée de flux spéciale avec une priorité nulle qui correspond à tous les paquets, elleinstruit le commutateur à supprimer les paquets inconnus ou les envoyer au contrôleur,ce dernier peut installer une nouvelle entrée de flux ou supprime le paquet [35].
2.2.2.2 Les messages du protocole OpenFlow
Le protocole OpenFlow a standardisé les messages échangés entre le contrôleur etles équipements réseaux [36]. En général, ces messages contiennent des instructionset des réponses échangées entre le contrôleur et les équipements afin de manipuler lesflux et faire la collecte de leurs statistiques. Un équipement qui supporte le protocoleOpenFlow possède une ou plusieurs tables de flux pour déterminer comment transmettreles paquets ou les trames (commutation ou routage). Lorsqu’un nouveau flux arrivepour la première fois au commutateur, ce dernier consulte sa table de flux, s’il n’existeaucune entrée dans la table, il envoie un message au contrôleur (Packet_in). En sebasant sur son application, le contrôleur décidera ce que le commutateur pourraientfaire pour ce flux (l’acheminer vers un port de sortie, le supprimer, le renvoyer àla source...etc.). En effet, le contrôleur informe les équipements réseaux à proposdes décisions prises en installant des entrées de flux dans les tables de flux de ceséquipements. En attendant la décision du contrôleur, les paquets qui ne correspondentà aucune entrée dans la table de flux sont mis dans des mémoires tampons (buffers), sielles sont saturées, les nouveaux paquets seront envoyés au contrôleur, si le lien entrele contrôleur et l’équipement est saturé ou le contrôleur lui même est dans la mêmesituation, les paquets seront supprimés.
2.2.3 Le commutateur Open vSwitch
Dans la couche infrastructure, le commutateur représente l’élément de base. Ce der-nier possède des tables de flux qu’il utilise pour acheminer le trafic. Comme nous l’avonsstipulé, une fois les trames reçues par le commutateur, il cherche la correspondancedes informations de l’entête des trames avec les entrées des tables de flux par ordrede priorité. Une fois la correspondance trouvée, l’action associé au flux est exécutée.Dans le cas contraire, le paquet sera supprimé ou transmis au contrôleur, selon la
2.2 Le concept SDN 36
configuration de l’entrée des flux. En effet, le protocole OpenFlow pourrait être déployélogiquement ou physiquement sur des équipements responsable de l’acheminementdes données. Aussi, plusieurs constructeurs connus, comme Cisco, Juniper, IBM, etHP, supporte actuellement ce protocole, soit sur un équipement dédié, ou à traversun commutateur sous forme de logiciel. Open vSwitch est l’un des commutateurslogique implémentant le protocole OpenFlow [37]. La figure 2.4 illustre la compositiond’un commutateur logique, ce dernier est composé d’une multitude de couches pourfonctionner en tant qu’un commutateur virtuel, il supporte les différentes versions duprotocole OpenFlow (1.0 à 1.6), les tunnels Generic Routing Encapsulation (GRE),les files d’attente...etc. Pour des raisons de gestion et de configuration, en parallèleavec la connectivité au contrôleur, il est possible de contrôler et de configurer l’OpenvSwitch à travers l’ovs-vsctl et l’ovs-ofctl. l’ovs-vsctl est un outil en ligne de commandenous permettant de configurer l’Open vSwitch en fournissant une interface à sa basede données, alors que l’ovs-ofctl est un outil en ligne de commande qui nous permet desuperviser le commutateur.
2.2.4 Le protocole Forwarding and Control Element Separa-tion (ForCES)
ForCES [38][39] est un autre protocole pouvant être utilisé entre la couche contrôleet la couche infrastructure, qui a été standardisé par l’IETF depuis 2004 avec unensemble de RFCs (3654, 3746, 5810...). Les équipements responsables du transfert desdonnées sont modélisés en utilisant des fonctions logiques par blocs (Logical FunctionBlocs (LFBs)) qui peuvent être composées d’une façon modulaire afin de mener destâches de transfert plus complexes. Chaque LFB fournie une fonctionnalité donnée,tel que le routage par exemple. Les LFBs modélisent un équipement de transfert etcoopèrent pour former des équipements réseaux encore plus complexes. Les éléments decontrôle utilisent le protocole ForCES pour configurer les LFBs interconnectés afin demodifier le comportement de l’équipement de transfert. ForCES est considéré comme unprotocole plus flexible et plus performant par rapport à OpenFlow [40], cependant, il estmoins connu, dû au manque de l’adoption de l’industrie et au manque des moyens opensource dans le monde de la recherche universitaire. Le protocole ForCES fournie auxéléments de contrôle les moyens de communication avec les équipements de transfertquelque soit leur modélisation [41]. En utilisant ce protocole, les éléments de contrôlepeuvent:
— S’associer avec un élément de transfert.
2.2 Le concept SDN 37
— Envoyer des requêtes à une ou plusieurs LFBs d’un élément de transfert.
— Rediriger les messages aux éléments de transfert, et à partir de ces derniers.
— S’enregistrer et recevoir des événements auprès des LFBs.
L’architecture ForCES offre aussi plusieurs mécanismes:
— Découverte de capacités.
— Capacités de transaction.
— Détection des mises en offline des éléments de transfert.
— Commande des pipelines.
Le principal avantage de l’architecture ForCES réside dans le fait que le protocoleForCES est agnostique par rapport au modèle. Tout élément de transfert décrit avec lemodèle ForCES est gérable par le protocole ForCES.
2.2.5 Prérequis des éléments de transfert pour le support deForCES
La variation des fonctionnalités des éléments de transfert permise par l’architectureForCES pose un problème potentiel aux contrôleurs. En effet, pour qu’un contrôleurpuisse effectivement contrôler un élément de transfert, il doit comprendre commentl’élément de transfert traite les paquets. De ce fait, un modèle de cet élément de transfertdevrait être créé pour qu’il puisse exprimer les capacités de traitement logique despaquets par l’élément de transfert. Ce modèle devrait aussi exprimer la configurationactuelle de l’équipement et supporter plusieurs éléments de transfert dans l’architecture.
2.2.5.1 Types des fonctions logiques
Le modèle de l’élément de transfert doit exprimer quelles fonctions logiques pour-raient être appliquées aux paquets lors de leurs passage par l’élément de transfert. Lesfonctions de traitement des paquets font partie des fonctions logiques, de même pourles fonctions de routage, de Network Address Translation (NAT), de lissage (dans laQoS), de sécurité, ...etc.
2.2.5.2 Variation des fonctions logiques
Le modèle de l’élément de transfert doit être capable de supporter et de permettreune multitude de manières dont les fonctions logiques sont implémentées sur un élémentde transfert. Par exemple, pour un certain élément de transfert, la fonction logique
2.2 Le concept SDN 38
de transfert devrait avoir des informations sur l’adresse IP ainsi que l’adresse MACdu prochain saut, alors que dans un autre élément de transfert ceci devrait êtreimplémenté en tant qu’une fonction logique séparée. Nous pouvons prendre un autreexemple, comme le NAT (traditionnel, bi-directionnel, multihomed (RFC2663)). Lemodèle devrait être très flexible afin de permettre une telle variation dans les fonctions.
2.2.5.3 Ordre des fonctions logiques
Le modèle doit être capable de décrire l’ordre dans lequel ces fonctions logiquessont appliquées sur l’élément de transfert. La mise en ordre des fonctions logiquesest important dans plusieurs cas. Par exemple, une fonction de NAT, devrait changerl’adresse IP source ou destination. Tout autre numéro de fonction logique (routage,lissage, sécurité ou autre), pourrait utiliser l’adresse IP source ou destination lorsde la prise de décision. Le contrôleur a besoin de connaître s’il doit configurer cesfonctions logiques avec les adresses IP pre-NAT ou post-NAT. Aussi, le modèle doit êtrecapable d’exprimer plusieurs instances de la même fonction logique dans un chemin detraitement des éléments de transfert. Concernant le NAT aussi, une fonction NAT esteffectuée avant la décision de transfert du paquet (les paquets qui arrivent de l’extérieuront leurs adresse IP publique remplacée par les adresses privées) et une autre fonctionest effectuée après la décision de transfert (les paquets qui sortent du domaine, leursadresses privées sont remplacées par d’autres publiques).
2.2.5.4 Flexibilité
Le modèle devrait aussi fournir une infrastructure flexible dans laquelle les nouvellesfonctions logiques et la nouvelle classification, action, ainsi que les données de paramé-trage peuvent être ajoutées facilement. De plus, le modèle de l’élément de transfert doitêtre capable de décrire les types de statistiques collectés par chaque fonction logique.
2.2.5.5 Un ensemble minimal de fonctions logiques
En effet, cet ensemble minimal n’implique pas que tous les éléments de transfertdoivent fournir cette fonctionnalité. Au lieu de cela, ces exigences spécifient uniquementque le modèle doit pouvoir exprimer les capacités que les éléments peuvent choisir defournir.
— Fonctions de port: Le modèle doit être capable d’exprimer le nombre de portssur l’équipement, les attributs statiques de chaque port (type de port, vitesse),ainsi que les attributs configurables de chaque port (adresse IP, état administratif).
2.2 Le concept SDN 39
— Fonctions de transfert: Le modèle doit être capable d’exprimer les donnéesqui peuvent être utilisées par la fonction de transfert pour prendre une décisionde transfert. Le support des fonction de transfert en unicast et multicast (IPv4et l’IPv6) doit être aussi fourni par le modèle.
— Fonctions de QoS: Le modèle doit permettre à un élément de transfert d’ex-primer ses capacités de QoS en termes de fonctions de mesure, de lissage, demise en file d’attente...etc. Le modèle doit être capable d’exprimer l’utilisation deces fonctions pour fournir les fonctionnalité qu’offrent les architectures IntServet DiffServ comme décrites dans (RFC2211, RFC2212, RFC2215, RFC2475, etRFC3290)
— Fonctions spécifiques aux constructeurs: Le modèle devrait être extensiblede telle sorte qu’une nouvelle fonctionnalité d’un élément de transfert inconnupeut être exprimée. Le modèle ne devrait pas être étendu afin d’exprimer desfonctions communes ou standards d’une manière propriétaire. Cela ne serait pasconforme à ForCES.
— Fonctions de modification: Le modèle doit être capable d’exprimer les capa-cités d’un élément de transfert en termes d’encapsulation et de mise en tunneldes paquets. Le modèle doit supporter les fonctions de marquage de la classede service qu’un paquet devrait recevoir (ToS ou l’octet de classe de trafic del’IPv6). Le modèle pourrait supporter d’autres fonctions de modification commele NAT par example.
— Fonctions de sécurité: Le modèle doit être capable d’exprimer les types decryptage qui pourraient être appliqués sur les paquets tout au long du chemin detransfert.
— Fonctions de décharge des paquets: Le modèle peut garder des états detraitement des paquets pour que les fonctions logiques opèrent d’une manièreconsistante. De plus, le modèle doit permettre aux fonctions logiques de s’exécuterd’une manière asynchrone lors du traitement des paquets afin d’effectuer lestâches déchargées du contrôleur. Ce modèle doit aussi être capable d’exprimerces fonctions asynchrones telles que la fin d’une session TCP, traitement desmessages "hello" du protocole OSPF, déclenchement des événements (par rapportaux paquets et au temps).
— Fonctions de supervision: plusieurs applications telles que, la mesure del’utilisation, l’ingénierie de trafic...etc, requièrent la mesure du trafic IP à partirdes noeuds du réseau. Dans [42], une architecture pour la supervision du trafic
2.2 Le concept SDN 40
réseau a été définie, la mesure ainsi que l’exportation des informations de mesure.Le modèle de l’élément de transfert devrait donc être capable d’exprimer lesfonctions de mesure du trafic, ces dernières sont importantes pour l’exportationdes informations sur les flux. Similairement, afin de supporter les applications demesure, dans [43], les auteurs ont décrit une approche qui définit un ensemble decapacités standards des noeuds réseaux, pour échantillonner des sous-ensemble depaquets par des méthodes statistiques. Le modèle devrait être capable d’exprimerles fonctions statistiques de filtrage de paquets et d’information des paquets, cesfonctions sont requises pour les applications d’échantillonage de paquets.
2.2.6 Comparaison entre OpenFlow et ForCES
Les protocoles OpenFlow et ForCES partagent les mêmes objectifs (la séparationdu plan de contrôle de celui des données) sur la base d’un système sur lequel lesdéveloppeurs ainsi que les constructeurs peuvent réaliser leur propres équipements etlogiciels de contrôle. La comparaison entre ces deux protocole peut être faite sur deuxcatégories, le modèle de l’élément de transfert et le protocole.
2.2.6.1 Comparaison en terme d’élément de transfert
L’élément de transfert OpenFlow est restreint au commutateur OpenFlow quispécifie en détail, les composants du commutateur, les actions disponibles pour chaqueflux ainsi que le rôle de chaque fonction. De plus, les spécifications du commutateurOpenFlow décrivent un ensemble de fonctionnalités prédéfinies. D’autre part, ForCESne défini pas comment un élément de transfert est implémenté, il n’est pas limitéaux commutateurs uniquement, et ce qui est décrit dépendra du développeur, parexemple, un routeur peut être décrit, les actions peuvent être spécifiées comme desblocs logiques de fonctions mais pas comment la fonctionnalité est implémentée [41].ForCES fourni le modèle, et le développeur fourni simplement la description descomposants ainsi que les capacités de l’élément de transfert. Avec le modèle ForCES,un développeur peut spécifier des capacités personnalisés pour l’élément de transfert.ForCES peut aussi modéliser le traitement par pipeline d’OpenFlow en utilisant lesblocs de fonctions logiques connectées dans un graphe. Avec le protocole ForCES, unutilisateur peut demander la connectivité des blocs de fonctions logiques et connaîtredonc, la configuration interne de l’élément de transfert. De plus, si ce dernier supporteune topologie dynamique de ces blocs de fonctions, le contrôleur peut changer le graphe
2.2 Le concept SDN 41
de connection des blocs de fonctions logiques en temps réel en utilisant le protocoleForCES.
2.2.6.2 Comparaison du point de vue protocole
Les protocoles OpenFlow et ForCES offrent un ensemble de fonctionnalités avecdes noms différents [41], telles que:
— Configuration et demande de valeurs des équipements de transfert.
— Notification d’évènements.
— Établissement des associations entre le contrôleur et le commutateur.
— Détection de la mise en offline des équipements réseaux.
— Sécurisation des canaux de communication.
— Redirection de paquets (entrant et sortant du commutateur vers le contrôleur)
Les messages de barrières OpenFlow, qui représentent des messages de contrôlespécifiques devant être exécutés selon une séquence spécifique, sans le traitement d’unautre message en parallèle, sont équivalents aux messages de transaction de ForCES.Le tableau 2.1, résume les similarités entre le protocole OpenFlow et ForCES en termesde concepts et opérations [41].
OpenFlow ForCESActions LFBsPipeline graphe des LFBs
Modèle fini du commutateur illimitéListe de capacité finie illimitée
Correspondance des champs Composants des LFBsTable 2.1 Comparaison entre OpenFlow et ForCES en terme d’élément de transfert
Le protocole ForCES a été doté de plusieurs fonctionnalités que le protocoleOpenFlow ne fournit pas. Dans un message ForCES, le contrôleur peut demander unaccusé de réception à partir d’une commande de configuration, dans OpenFlow, il y auniquement un retour d’erreur. Aussi, avec ForCES, plusieurs commandes peuvent êtreregroupées et envoyées dans un seul message au lieu d’en utiliser plusieurs. D’autre part,un contrôleur ForCES peut se souscrire auprès des événements fournis par les élémentsde transfert alors que dans OpenFlow, les événement sont prespécifiés. De plus, dans leprotocole ForCES, il y a une sélection de mode d’exécution pour chaque message, et lecontrôleur peut ordonner l’élément de transfert d’exécuter toutes les requêtes ou aucune
2.2 Le concept SDN 42
d’entre elles, les exécuter jusqu’à l’échec ou même après l’échec. Concernant le contrôlede l’existence ou non des éléments de transfert, OpenFlow fournie dans ce sens, unmécanisme de contrôle basé sur l’envoie et la réception périodique des messages "echo",par contre, le protocole ForCES peut contrôler le fonctionnement du mécanisme, ilpeut arrêter les messages "Heartbeat" originaires du contrôleur. Le tableau 2.2, résumeles similarités entre OpenFlow et ForCES du point de vue protocole.
OpenFlow ForCESSécurise le canal TLS ForCES opère sur IPSec
Découverte des fonctionnalités Découverte des capacité des LFBsConfiguration, modification et lecture des états Configuration et envoie des requêtes
Paquet sortant ou entrant Redirection de paquetsBarrières Transaction
Flux retiré, état de port, état des erreurs messages de notification des erreurshello Messages d’associationEcho Messages (Heartbeat)
Identifiant de transaction CorrelateurTable 2.2 Comparaison entre OpenFlow et ForCES du point de vue protocole
2.2.7 Le contrôleur SDN
Le contrôleur est l’élément de base de la couche contrôle. Dans une architecture SDN,cette couche peut être composée d’un ou de plusieurs contrôleurs [44]. Le contrôleurreprésente le cerveau de l’architecture, sa fonction principale est de mettre à jour lestables de flux des commutateurs (en ajoutant, supprimant ou modifiant des entréesde flux) pour des raisons d’acheminement des flux (routage). Il peut être aussi appeléà superviser la topologie réseau ou à communiquer avec d’autres contrôleurs...etc. Ilexiste plusieurs contrôleurs, basé sur différents langages de programmation:
— RYU [45]: Basé sur Python.— Floodlight [46]: Basé sur le Java.— NOX [47]: C++— POX [48]: Basé sur le Python.— Beacon [49]: Basé sur le Java.— MUL [50]: C— Maestro [51]: Basé sur le Java.— Opendaylight [52]: Basé sur le Java.
2.2 Le concept SDN 43
ovsdb-server
ovs-vswitchd
Esp
ace
Uti
lisat
eur
Esp
ace
no
yau
Openvswitch.ko
Kernel Datapath
ovs-vsctl ovs-appctl ovs-dpctl
Bd distante OpenvSwitch
Contrôleur OpenFlow
ovs-ofctl
Interfaces Physiques
Gestion OVS
OpenFlow
Figure 2.4 Architecture interne du commutateur OpenvSwitch
2.2.7.1 Support de la QoS dans le contrôleur SDN
Si nous considérons le protocole OpenFlow, selon ses spécifications, ce dernierutilise des files d’attente sur les commutateurs mais ne les configure pas. Il existedeux protocoles nous permettant la configurations des file d’attente au niveau descommutateurs supportant le protocole OpenFlow, à savoir, l’OF-Config et OVSDB.D’ailleurs, il y a un standard de gestion des files d’attente, fourni, par chaque contrôleurOpenFlow [53], plusieurs d’entre eux fournissent des outils ainsi que des platformesaidant les utilisateurs dans la configuration des files d’attente. Nous allons évoquerdans ce qui suit, le support de la QoS par les contrôleurs (open source) les plus utilisés:
— Ryu, comme nous l’avons décrit ci-dessus, Ryu est un contrôleur SDN à base decomposants écrits dans le langage de programmation Python. L’un des principauxavantages de ce contrôleur, contrairement à de nombreux autres contrôleurs SDN,est qu’il supporte toutes les versions du protocole OpenFlow de 1.0 à 1.6. Deplus, en raison de sa conception basée sur les composants et de la prise en chargecomplète des versions OpenFlow, il est souvent utilisé pour le développementrapide d’un module SDN. Ryu fournit une API pour configurer et gérer les filesd’attente dans Open vSwitch en utilisant OVSDB.
— OpenDaylight, est un projet collaboratif open source de la Linux Foundation(LF), ce projet a pour but de promouvoir le concept SDN. La plupart descontrôleurs SDN propriétaires comme le contrôleur Brocade sont basés sur le
2.3 Avantages du concept SDN 44
contrôleur OpenDaylight. Comme Ryu, OpenDaylight possède également unplugin OVSDB qui aide les utilisateurs à configurer et gérer les files d’attente[53].
— Floodlight, est un contrôleur open source lancé par Big Switch Networks (BSN),il est basé, comme nous l’avons noté ci-dessus sur le langage de programmationJava. Pour la configuration et la gestion des files d’attente, un module de QoS estmis en place, prenant en compte les avantages en termes de support de la QoS duprotocole OpenFlow 1.0 [54]. Un autre module (QueuePusher) a été développé etmis en place, pour prendre en charge la gestion de la QoS à travers l’API de cecontrôleur.
— Open Network Operating System (ONOS) [55], est un contrôleur opensource, supporté aussi par la LF, avec le but de mettre en oeuvre un systèmed’exploitation scalable, ayant une forte disponibilité et performance. Actuellement,ce contrôleur supporte la mesure en utilisant le protocole OpenFlow. Cependant,il est moins performent en termes de prise en charge de la QoS par rapportaux contrôleur cités ci-dessus [54]. Le tableau 2.3 résume la prise en charge descontrôleurs en terme de fonctionnalités liées à la QoS.
Table 2.3 Prise en charge de la QoS par les différents contrôleurs
Contrôleur Modules et FonctionnalitésRYU API OVSDB
OpenDayLight API OVSDBFloodlight modules QoS/QueuePusher et API CRUD
ONOS Mesures dans OpenFLow (support limité de la QoS)
2.3 Avantages du concept SDNLorsqu’il s’agit de créer ses propres réseaux, chaque entreprise doit peser le pour
et le contre des différents types de réseaux à mettre en oeuvre. Les clients exigeantde plus en plus de performances et de flexibilité, certains inconvénients deviennentrapidement plus lourds que d’autres. Parallèlement aux besoins croissants des réseauxmodernes, les plus grands inconvénients de la maintenance des réseaux traditionnels ontrenforcé l’ascension des réseaux définis par logiciel. D’ailleurs, l’infrastructure physique,en particulier les équipements réseaux qui nécessitent des configurations manuelles,n’a tout simplement pas pu suivre le rythme de la technologie moderne. Les exigences
2.3 Avantages du concept SDN 45
croissantes des entreprises modernes sont trop élevées pour la plupart des réseauxtraditionnels, celles qui cherchent à faire évoluer leurs infrastructures de réseau avecle moins de perturbations possible se tournent rapidement vers les réseaux SDN. Letableau 2.4 compare un réseau traditionnel à un autre basée sur le concept SDN.
2.3.1 Plans de Contrôle et Plan de Données
Le concept des réseaux programmables a permis de séparer les plans contrôle etdonnées comme suit:
— Le plan de contrôle offre comme son nom l’indique, la possibilité de contrôlerles comportements du réseau, il est utilisé pour gérer les configurations deséquipements réseaux. Ces derniers se contenteront à acheminer les données selonles instructions du contrôleur.
— Le plan de donnée achemine le trafic vers sa destination souhaitée. Avant que letrafic n’atteigne le plan de données, le plan de contrôle dicte le chemin établi.
2.3.2 Réseaux traditionnels
Un réseau traditionnelle présente les caractéristiques suivantes:
— Les fonctions des réseaux traditionnels sont principalement mises en œuvre àpartir de dispositifs dédiés, utilisant un ou plusieurs commutateurs, routeurs oudes par feu pour une meilleure sécurité.
— La fonctionnalité des réseaux traditionnels est largement mise en œuvre dansdu matériel spécialisé, tel que les circuits intégrés spécifiques aux applications(Application-Specific Integrated Circuit (ASIC)). L’un des aspects négatifs decette mise en réseau traditionnelle centrée sur le matériel, est ses limites detraitement.
Table 2.4 Comparaison entre un réseau SDN et un réseau traditionnel
Fonctionnalité Classique SDNGestion du réseau Difficile Facile
Vue globale du réseau Difficile Vue centrale du contrôleurCoût de maintenance Élevé Moins Élevé
Utilisation des ressources Faible ImportanteDisponibilité du contrôleur Non applicable Importante
Intégrité et consistance des tables Importante Importante
2.4 Prise en charge de la QoS dans les réseaux SDN 46
2.4 Prise en charge de la QoS dans les réseaux SDNLors de l’apparition du protocole OpenFlow (version 1.0), la prise en charge de la
QoS par les réseaux SDN en utilisant ce protocole était limité à l’utilisation des filesd’attente. Cette version du protocole OpenFlow (introduite en 2009) prenait en chargedonc la mise en files d’attente des paquets selon leur criticité [37]. Afin de fournir unegarantie sur la bande passante pour chaque flux, chaque file d’attente est associée àun débit minimum et à un débit maximum. Pour fournir différents niveaux de bandepassante, chaque port du commutateur se voit associé plus d’une file d’attente, selon lebesoin. D’autre part, cette version supporte les VLAN (Virtual Local Area Network(VLAN)), le ToS (Type Of Service (TOS)) de l’entête IP ainsi que le protocole MPLS.
Comme de nouvelles versions d’OpenFlow sont arrivées au fil des années, chaquenouvelle version a apporté de nouvelles fonctionnalités ou une mis à jour des fonc-tionnalités existantes. L’apparition de la version 1.3 du protocole OpenFlow a permisl’utilisation des tables de compteur (meter table), qui est combinée avec le mécanismede mise en file d’attente pour limiter le débit entrant minimal, maximal ou les deux,pour une entrée de flux spécifique pour gérer l’utilisation des bandes passante des liens,elle permet aussi au contrôleur d’envoyer des requêtes au commutateurs concernantles files d’attente. De plus, la supervision du trafic réseau a été rendu possible grâceà l’introduction de cette fonctionnalité. Même avec l’apparition de cette version etles nouveautés qu’elle a apportées, la prise en charge de la QoS est restée limitée.Cependant, la flexibilité du concept SDN a permis aux administrateurs réseaux d’im-plémenter leurs propres algorithmes qui permettent la mise en place de différentespolitiques de QoS. Aussi, le manque de modèle de QoS dans le protocole OpenFlowa inspiré beaucoup de chercheurs à proposer de tels modèles. Parmi ces propositions,celles qui couvrent une prise en charge complète de la QoS, alors que d’autres couvrentune partie bien spécifique comme la garantie des bandes passante, l’automatisation ducontrôle de la QoS, le routage avec QoS...etc. Les travaux dans [56][57] proposent uneprise en charge complète de la QoS dans les réseaux SDN mais d’une façon très vaste(high-level) sans donner des détails, comme par exemple dans [57] sur la façon dontla bande passante est garantie. Le tableau 2.5 résume la prise en charge de la QoS àtravers les différentes version du protocole OpenFlow.
En effet, Il existe plusieurs volets de la QoS dans les réseaux, et vue l’importancedu routage avec QoS, nous nous sommes intéressés dans notre thèse à l’étudier, à faireun état de l’art sur les différentes techniques, et proposer de nouvelles approches. Eneffet, Plusieurs travaux ont traité la prise en charge de la QoS lors de l’acheminementdes paquets (routage) pour garantir la QoS des flux critiques en utilisant le concept
2.4 Prise en charge de la QoS dans les réseaux SDN 47
Table 2.5 Prise en charge de la QoS dans les différentes version du protocole OpenFlow
Vesrion d’OpenFlow Mise à jour introduites1.0 Action de mise en files d’attente1.1 Plus de contrôle sur les VLANs et MPLS1.2 Mise à jour des files d’attente par le contrôleur1.3 Introduction de la table de mesure1.4 Introduction de plusieurs aspects de supervision1.5 Remplacement de l’action de mesure par une instruction
SDN, cependant, peu d’entre eux ont traité la problématique de la consistance desstatistiques de l’état du réseau, du routage ainsi que celle des prises de décisions.
Durant plusieurs années, le routage avec QoS a été une préoccupation majeure dansplusieurs études. L’objectif principal de ces recherches est de proposer des algorithmesde routage qui permettent d’offrir les meilleurs chemins pour satisfaire le contrat deniveau de service (Service Level Agreement (SLA)) entre le client et le fournisseur deservice. Afin d’atteindre cet objectif, deux tâches principales devraient être accomplies,la première consiste à avoir une vue globale de la topologie du réseau et la maintenir àjour (bande passante disponible des liens, latence, gigues...etc), et la deuxième est dechoisir le meilleur chemin sur la base des résultats de la première tâche. Par conséquent,le meilleur algorithme de routage prenant en charge le SLA est celui qui exécute demanière optimale ces deux tâches.
Les réseaux MPLS ont évolué durant les dernières années et sont devenus trèsimportants pour les fournisseurs de services réseaux. Comme nous l’avons vu dans lechapitre précédent, MPLS est utilisé pour assurer l’ingénierie du trafic dans les réseauxIP en fournissant un plus grand déterminisme et une utilisation plus efficace des bandespassantes, il est aussi utilisé dans la mise en oeuvre des réseaux privés virtuels (VirtualPrivates Networks (VPN)) de couche 2 et 3, d’ailleurs, c’est l’un des services offertspar les FAI les plus rentables. En effet, dans tout réseau MPLS, il existe de simplesmécanismes de plan de données permettant d’insérer, de permuter et de supprimerdes étiquettes MPLS dans un LSP. Ces mécanismes sont contrôlés par un certainnombre de protocoles du plan de contrôle, qui aident à fournir les fonctionnalités et lesservices. Cependant, toute modification apportée à ces services ou à la création d’unnouveau service implique, dans la plupart des cas, des modifications de ces protocolesou la création d’un protocole entièrement nouveau, ce qui prend énormément de temps.Dans [58], les auteurs ont présenté un état de l’art sur l’utilisation du concept SDNdans la mise en oeuvre des VPN, ils ont aussi présenté le design et un prototyped’implémentation d’un contrôleur SDN qui, à partir d’une spécification centralisée deparamètres VPN, exprimée dans un langage simple et flexible de haut niveau, remplitautomatiquement les table de flux des commutateurs afin de mettre en œuvre les
2.4 Prise en charge de la QoS dans les réseaux SDN 48
VPN demandés. l’implémentation du VPN avec SDN proposée, réagit rapidement àla dynamique du réseau (par exemple, des liens récemment apparus, ou éliminés) etsimplifie de façon significative la gestion. Dans [59], Chang et al, ont proposé uneapproche de commutation des étiquettes où le commutateur du coeur du réseau utiliseun seul champ lors de la recherche, et afin de réduire le nombre de règles dans lescommutateurs de périphérie, le numéro de port de sortie du dernier saut est codéedans le champ MPLS. Ils ont proposé aussi un mécanisme ayant pour but de minimiserle nombre de règles dans une topologie en arbre pour une commutation plus rapidedes étiquettes. Dans [60], Husni et al ont proposé la conception et l’implémentationd’un contrôleur SDN dans une architecture MPLS dans le but d’améliorer le calculdes LSP. Dans cette réalisation, les auteurs ont exploité l’avantage de la centralisationdu contrôleur par rapport à sa vue globale du réseau ainsi que de son état en tempsréel. Dans [61], Hasan et al ont proposé d’utiliser le concept SDN pour créer et gérerdes tunnels MPLS, en offrant une grande flexibilité en termes de nombre de saut etd’allocation des ressources réseaux. Le chemin du tunnel peut être modifié de manièredynamique en fonction de l’état actuel du réseau (disponibilité des bandes passante desliens, CPU des routeurs, latence des liens...etc), cet état peut être modifié en fonctiondu débit des flux de données appliqués. Cela permet en effet, une restauration plusrapide des chemins présentant une coupure ou une congestion dans un lien donné, etpermet d’une autre part, une meilleure utilisation des ressources du réseau. En outre,l’approche proposée améliore l’ingénierie du trafic ainsi que la QoS tout en ayant unréseau plus fiable.
Vue l’importance du routage avec QoS, plusieurs études ont été réalisées dans lecadre des réseaux SDN. Dans [62], Eglimez et al, ont proposé une approche utilisantun plan de contrôle distribué, composé de plusieurs contrôleurs, chacun d’eux calculeles meilleurs chemins dans son domaine de fonctionnement, puis partage un résuméde ce calcul avec les autres contrôleurs afin de faire un routage inter-domaine tout enréduisant le problème de monté en échelle.
Dans [63], Cello et al, ont présenté une solution prenant en considération la pertede paquets ainsi que le contrôle de file d’attente au niveau des commutateurs. Cestâches sont menées en implémentant un réseau de neurones dans le contrôleur SDNpour faire la prédiction des futurs chemins.
Dans [64], Eglimez et al, ont proposé une nouvelle architecture d’un contrôleurSDN qui supporte le streaming des flux multimédia avec QoS. L’approche proposéeconsiste à mettre à jour les chemins selon le taux d’utilisation global. Les auteurs ontconsidérés qu’un lien est congestionné si son taux d’utilisation est supérieur à 70%.
2.4 Prise en charge de la QoS dans les réseaux SDN 49
Dans ce cas, si tous les liens sont dans cette situation, le contrôleur sera obligé deles utiliser pour véhiculer les flux multimédia au détriment d’une dégradation de leurqualité dû au manque de la bande passante.
Dans [65], Eglimez et al, ont proposé une application qui prend en considération laQoS du streaming vidéo adaptatif en utilisant le concept SDN basé sur le protocoleOpenFlow. Les auteurs ont utilisé différentes stratégies de routage pour les couchesde bases et d’amélioration de la vidéo, où les meilleurs chemins ont été utilisées pourvéhiculer les couches de bases de la vidéo, alors que les couches d’amélioration ont étévéhiculées sur les autres chemins. Les résultats de leurs expérimentations ont montréque l’approche proposée a amélioré d’une façon significative la qualité des flux vidéo. Dela même façon, les auteurs dans [66] ont proposé de traiter différemment les couches debase et celles d’amélioration mais avec une stratégie un peu différente, avec différentesmétriques. Les auteurs ont utilisé la variation du délai (la gigue) et la perte de paquetscomme des métriques de routage pour résoudre le problème du Constrained ShortestPath (CSP) en utilisant l’algorithme Lagrange Relaxation based Aggregated Cost(LARAC). Si la valeur de la variation du délai n’est pas satisfaite, les paquets de lacouche de base sont les premiers à être ré-acheminés sur d’autres chemins, mais s’ily a un manque de la bande passante, les paquets de la couche d’amélioration serontré-acheminés en gardant les paquets de la couche de base sur leur chemin d’origine.Les résultats de la simulation ont montré qu’une réduction de 77.3% du taux de pertedes paquets de la couche de base a été atteinte par rapport à [65].
Dans [67], Slavica et al ont présenté une approche de contrôle dans les réseaux SDN.La solution proposée utilise la bande passante disponible ainsi que des techniques degestion des files d’attente lors des calculs des chemins optimaux au lieu de l’algorithmedu plus court chemin traditionnel afin de fournir une garantie sur la bande passantepour les flux prioritaires tout en protégeant les flux moins critiques autant que possible.
Dans [68], vue la consommation énergétique ainsi que le coût élevé des mémoires Ter-nary Content Addressable Memory (TCAM) qui sont utilisées dans des commutateursSDN pour le stockage des entrées d’acheminement des flux, les auteurs ont proposéune utilisation plus efficace de telles mémoires. Pour ce faire, une étude conjointe surl’ingénierie du trafic et le placement des règles a été menée.
Dans [22], Mohammadi et Javidan ont proposé une stratégie de routage avec QoSafin d’améliorer la qualité de la vidéo surveillance dans un réseau SDN. Les auteursont utilisé la logique floue de type 2 pour chercher des liens pertinents, et résoudre leproblème du CSP en utilisant l’algorithme LARAC pour trouver des chemins optimaux.
2.4 Prise en charge de la QoS dans les réseaux SDN 50
En effet, cette approche convient particulièrement à un réseau de vidéo surveillancedédié, pour lequel on ne considère pas les flux de meilleur effort.
Dans [69], Korhan et al, ont proposé une architecture utilisant le Multi PathTransmission Control Protocol (MPTCP) dans les réseaux SDN afin de garantir leSLA pour les clients qui utilisent le service de streaming vidéo. Dans cette étude, lemodèle d’optimisation Mixed Integer Linear Programming (MILP) a été utilisé pourdéterminer les chemins optimaux, et pour réduire la complexité du calcul, les auteursont conçu un algorithme heuristique fonctionnant en temps polynomial. Les résultatsobtenus ont montré que l’approche proposée a amélioré la qualité du streaming vidéojusqu’à 25% par rapport aux approches générales d’amélioration du débit des fluxvidéo.
Dans [70], une étude récente et approfondie de l’existant sur le routage prenanten charge la QoS dans les réseaux SDN a été menée. Les auteurs ont ré-implémentéet évalué tous les algorithmes étudiés. Ils ont classifié les approches de routage avecQoS unicast en différentes classes, en inculant la gestion des files d’attente, l’utilisationdes algorithmes LARAC et Bellman-Ford, ainsi que celles qui considèrent la latence etle coût minimal des chemins. Afin d’évaluer les algorithmes étudiés, les auteurs ontproposé l’utilisation d’une solution utilisant les types de topologies et l’évolutivité, ainsique la contrainte du délai. Ils ont conclu que la performance de chaque algorithme deroutage avec QoS dépend su scénario utilisé. De ce fait, le choix du meilleur algorithmeest lié au scénario ainsi qu’à la plate-forme.
Dans [71], une autre étude sur la gestion de la QoS en utilisant le concept des réseauxprogrammables par logiciel a été proposé. Dans cette étude, les approches pertinentesayant une relation avec la gestion de la QoS ont été organisées et classées dans plusieurscatégories selon les mécanismes qu’elles utilisent, comme la supervision du réseau(network monitoring), la gestion des files d’attente/ordonnancement, la réservation desressources, la considération de la QoE...etc. D’autre part, les auteurs ont présenté lesprincipaux défis et problématiques en suspens, à résoudre afin d’améliorer la gestionde la QoS dans les réseau SDN.
Les solutions proposées et discutées dans [61], [62] et [63], ont considéré uniquementl’amélioration des flux vidéo en utilisant différentes stratégies de routage avec QoSsans le support d’un mécanisme les protégeant des rafales de flux moins critiques dela classe meilleur-effort. Aussi, partager la bande passante avec ce genre de flux, vacertainement dégrader la qualité de la vidéo. De ce fait, un mécanisme de protectiondes flux vidéo est primordial, tout en évitant au mieux, leur concentration au niveau
2.5 Conclusion 51
des liens de transmission. Il faut également acheminer le trafic moins critique sur leschemins moins congestionnés lorsque la bande passante est suffisante.
2.5 ConclusionLe concept des réseaux SDN nous permet de séparer le plan de contrôle de celui
des données lors de leur acheminement, et de créer de ce fait un réseau plus scalable,dynamique et dont la gestion est plus facile. La QoS dans les réseaux SDN peut êtreutilisée afin de contrôler la bande passante du réseau, de la latence ainsi que le débit. Ceconcept est apparu en réponse aux limites des architectures de réseau traditionnelles,ses principaux avantages sont la vue centralisée de la topologie réseau ainsi que laprogrammabilité du comportement des équipements réseaux de niveau 2 et 3. Lechapitre suivant présentera les solutions proposées aussi bien dans le contexte de lasupervision que celui du routage avec QoS pour palier aux faiblesses discutées ci-dessus.
Chapitre 3
Solutions proposées dans laSupervision et le Routage avec QoSbasées sur le concept SDN
3.1 IntroductionSi nous considérons dans ce qui suit, une topologie basée sur le concept SDN,
illustrée dans la figure 3.1, et l’utilisation d’une technique de routage traditionnellecomme celle basée sur le protocole Open Shortest Path First (OSPF) [72], qui utilise lacapacité globale du lien comme métrique de routage. Dans ce cas, si l’hôte H2 consulteune vidéo à partir du serveur vidéo (VS), le flux empruntera le chemin s4-s1-s8-s2,si, à ce moment, un trafic (de classe meilleur-effort) avec un débit élevé est envoyé del’hôte H1 à l’hôte H5, ce flux sera acheminé sur le chemin s1-s8-s2. Dans ce cas, laqualité de la vidéo sera dégradée car le chemin s1-s8-s2 est commun entre les deuxflux. Afin de résoudre cette problématique, plusieurs études ont été proposées commecelles discutées dans [65], [66] et [67]. En effet, lorsque nous considérons ces approches,deux problèmes majeurs apparaissent, le premier est la difficulté de contrôler les fluxmeilleur-effort avec un débit important tandis que le deuxième apparaît lorsque lecontrôleur est obligé de mettre les flux prioritaires (vidéo) sur des liens identiques dûau manque de ressources réseaux forçant ainsi de tels flux de se partager le reste desressources (bande passante) au détriment de leur qualité.
La notion de contrôleur SDN telle qu’elle est conçue aujourd’hui, essentiellementautour du protocole OpenFlow, s’apparente à un simple transducteur ou à un pilotepermettant d’accéder aux ressources réseaux via divers protocoles. En effet, le protocole
3.1 Introduction 54
H2
H1
H3
H4
Video Server
5Mbps
s1
s2
s3
s4
s5s6
s7
s8
H5
H6
SDNController
Figure 3.1 Une topologie réseau basée sur le concept SDN
Openflow est utilisé pour écrire des règles dans les tables de flux des commutateurs et laconsistance des données n’est donc pas garantie par le contrôleur. De plus, les règles sontdirectement mises en œuvre par des applications pouvant dans certains cas avoir desbesoins contradictoires, ce qui pourrait avoir un effet néfaste sur le bon fonctionnementdu réseau. Par exemple, il est plus efficace d’éviter de concentrer les flux qui exigentun certain niveau de fiabilité sur les mêmes liens car, en cas d’encombrement, ces fluxsubiront une perte de paquets.
Aussi, Le contrôleur ne doit pas assurer seulement l’interface entre les applicationset le réseau sous-jacent, il doit également garantir la consistance des décisions prises.Cet objectif pourrait être atteint en l’enrichissant de fonctions qui permettent degarantir un fonctionnement plus large du système.
Le problème de consistance est généralement une conséquence de la distribution.Dans les réseaux traditionnels, elle concerne principalement la vue abstraite du réseau,qui est construite localement au niveau de chaque nœud (c’est-à-dire un routeur, uncommutateur, un pare-feu...etc) en utilisant des protocoles distribués. Avec le conceptSDN, la simplicité de l’architecture cache une réalité complexe. En effet, outre leproblème de consistance lié à la création d’une vue abstraite du réseau, nous avons leproblème de consistance dans les décisions prises à distance par les contrôleurs.
3.2 ARCSDN: Architecture de Routage Consistante dans les Réseaux SDN 55
Pour ces raisons, nous proposons dans ce qui suit, une architecture réseau (ARCSDN),illustrée dans la figure 3.2 qui prend en considération les faiblesses citées ci-dessus afinde garantir la QoS/QoE aux flux multimédia (vidéo/audio) tout en préservant les fluxmoins critiques au mieux.
3.2 ARCSDN: Architecture de Routage Consistantedans les Réseaux SDN
442233
4411
423
41
5555221111
55211
5544115522
54152
442233
4411
423
41
44223344
114
2341 1122
55441112
541
442233441142341
55223344
555234
5
222255442222542
SDN controller
Live abstract view(s)
Data processing
Decision making
Rules enforcement
OF switch
DB
Users requests
Monitoring
Figure 3.2 Architecture consistante globale d’un réseau
Il est à noter que nous ne pouvons pas mettre en oeuvre un routage avec QoSsans avoir une vue globale et en temps réel de la topologie réseau. La nécessité de lasupervision du réseau reste, en effet, importante et continue de jouer un rôle crucialdans l’optimisation de l’utilisation des ressources réseaux tout en évitant les menacesgraves liées aux défaillances de l’infrastructure réseau.
3.2 ARCSDN: Architecture de Routage Consistante dans les Réseaux SDN 56
3.2.1 Création d’une vue abstraite consistante
En découplant le plan de donnée de celui du contrôle, le concept SDN offre auxopérateurs de réseau (Network Operators (NO)) la possibilité d’intégrer de nouvelleslogiques sans devoir modifier l’infrastructure existante. De plus, la centralisation duplan de contrôle 1 réduit considérablement la complexité des services car elle nousévite les inconvénients des applications distribuées. La flexibilité et la programmabilitédes réseaux SDN représentent certainement les atouts les plus importants pour leuradoption généralisée. Cependant, le succès de ces réseaux est étroitement lié à leurcapacité à assurer, outre la flexibilité de l’adoption de nouveaux services, la QoS, quiest plus ou moins garantie dans les réseaux traditionnels. Cela implique de prendre encharge de nombreux mécanismes allant de la supervision à l’ingénierie du trafic, enpassant par l’analyse des données.
En déplaçant la fonctionnalité de contrôle dans une entité distante, la précisiondes mesures (c’est-à-dire la surveillance du réseau) de l’utilisation des ressourcesdevient encore plus importante dans les réseaux SDN. En effet, un contrôle optimalnécessite une connaissance précise du réseau et en temps réel. Cela serait excessivementcoûteux en termes de surcharge (dû aux requêtes introduites dans le réseau pour desfin de supervision), ce qui affecterait l’efficacité du réseau. En ce sens, le traitementet l’analyse des données constituent certainement une étape importante pour unemeilleure caractérisation du réseau [74]. Cela aide à aborder les points suivants:
— Correction des erreurs de mesure à l’aide des techniques de filtrage ou d’outils deprédiction.
— Identification et diagnostique des origines des défaillances du réseau et la plupartdes éléments prédisposés aux défaillances.
— Analyse de l’efficacité des stratégies déterminées.
D’autre part, l’abstraction des ressources par un découpage classique du réseau enzones plus petite, comme proposé dans FlowVisor [75], contribuera certainement demanière significative à la réduction de la complexité de la gestion, mais elle aurait uneffet néfaste sur les ressources car elle pourrait induire à leurs sous-utilisation. Dansun tel contexte, nous avons proposé, comme nous allons le voir dans la sous section3.3, une méthode de supervision plus flexible, qui effectue une surveillance intelligenteet dynamique des réseaux SDN afin de construire une vue consistante, qui prend encompte la variabilité de la disponibilité des ressources. En ayant une vue consistante
1. On entend par la centralisation du plan de contrôle, la centralisation logique ou physique.
3.2 ARCSDN: Architecture de Routage Consistante dans les Réseaux SDN 57
du réseau, on pourrait agir efficacement sur les ressources (c’est-à-dire l’allocation desressources).
3.2.2 Contrôle du réseau
Avoir des décisions ainsi que des vues du réseau consistantes ne suffit pas pourgarantir la consistance du réseau. En effet, la stratégie d’application des règles est unproblème majeur, qui devrait être pris en considération pour éviter des comportementsinattendus. Généralement, le concept des contrôleurs SDN, tel qu’il est conçu aujour-d’hui, s’apparente davantage à un simple transducteur ou à un pilote qu’à un véritablecontrôleur de ressources. D’ailleurs, dans le cas des contrôleurs SDN actuels, il s’agitd’écrire des règles dans les tables de flux des commutateurs, via le protocole OpenFlow,ou tout autre protocole équivalent. Et la consistance n’est donc pas garantie par lecontrôleur. De plus, les règles sont mises en œuvre directement par des applicationspouvant, dans certains cas, avoir des besoins différents, ce qui pourrait avoir un effetnéfaste sur le fonctionnement du réseau [86]. Plusieurs études récentes commencentmaintenant à aborder cette question clé. Pour plus de détails, on peut se référer à[87], aussi, cette architecture pourrait également s’interfacer et même s’intégrer à laplate-forme ONAP (Open Network Automation) [88].
3.2.3 Caractérisation de la topologie réseau
La caractérisation du réseau implique nécessairement une phase de surveillance del’état du réseau en termes de débit et de disponibilité de la bande passante des différentsliens de la topologie. Différentes plates-formes de mesure peuvent être considéréesdans ce sens. Dans notre approche, nous avons considéré l’utilisation des messages duprotocole OpenFlow version 1.3 qui ne différent pas trop de ceux que nous avons cités.
Afin de mettre en œuvre la stratégie d’acheminement des flux proposée, qui consisteà disperser le trafic prioritaire selon son taux de présence au niveau des liens, nousproposons de mesurer le Prioritized Flows Presence Ratio (PFPR) au niveau desdifférents liens à l’aide de l’équation (3.1).
PFPR(k) =∑n
i=1 PFT(k)i
TLB (3.1)
où PFT(k)i et TLB représentent, respectivement, le débit du flux prioritaire i et la
bande passante totale du lien à l’étape k. La valeur PFT(k)i est obtenue en utilisant
3.3 Optimisation de la Supervision dans les réseaux SDN 58
l’équation (3.2).
PFT(k)i =
B(k)PFTi
−B(k−1)PFTi
t(k)− t(k−1) (3.2)
où B(k)PFTi
et t(k) représentent, respectivement, le nombre d’octets du flux temps réel i
et le temps universel à l’étape k. Afin de protéger les flux non prioritaires (meilleureffort) au mieux, nous avons proposé de les acheminer sur les liens avec les bandespassante les plus élevée. Pour ce faire, nous devions mesurer le Link Free Bandwidth(LFB) en utilisant l’équation (3.3).
LFB(k) = TLB−n∑
i=1PFT(k)
i −BT(k) (3.3)
où BT(k) représente le débit du trafic meilleur-effort à l’étape k, qui est obtenu enutilisant l’équation (3.4).
BT(k) = B(k)BT−B
(k−1)BT
t(k)− t(k−1) (3.4)
où B(k)BT représente le nombre d’octets du flux meilleur-effort à l’étape k.
La différenciation des flux est effectuée à l’aide des spécifications classiques duprotocole Openflow, dans lesquelles nous identifions les flux en fonction de l’en-têtedes paquets tels que le champ de type de service (Type Of Service (TOS)) de l’IPv4ou la classe de trafic dans l’IPv6, ou le champ de classe de trafic dans MPLS. Nouspouvons également utiliser les informations d’adresses du flux lorsque l’adresse:portsource et/ou de destination sont connus.
3.3 Optimisation de la Supervision dans les réseauxSDN
La supervision du réseau consiste à inspecter et à surveiller en permanence ladisponibilité des services en ligne telle que la bande passante, la sécurité, les ports...etc.Dans les réseaux des fournisseurs de services, la mesure du trafic joue un rôle importantpour assurer une allocation optimisée des ressources, afin d’éviter des baisses deperformances des serveurs, de réduire les coûts en achetant de la bande passante etdu matériel en fonction de l’utilisation des ressources et de rendre le réseau proactifen fournissant une meilleure QoS aux utilisateurs finaux. Une collecte des statistiquesprécise et rapide est donc essentielle pour de nombreuses tâches de gestion du réseau
3.3 Optimisation de la Supervision dans les réseaux SDN 59
[73]. En effet dans le contexte de la supervision des réseaux programmables, plusieursrecherches ont été faites, mais peu d’entre elles ont évoqué la problématique de surchargedu réseau pour des fins de supervision. Dans [76], les auteurs ont proposé une méthodede supervision avec deux objectifs majeurs, le premier est de fournir une vue globalede la topologie en envoyant des requêtes de demande des statistiques réseaux (nombrede flux, d’octets, de paquets...etc) d’une façon uniforme, alors que le deuxième est ledéveloppement d’une application composée de plusieurs modules, structurés et définiesà l’aide d’interfaces. Les auteurs ont aussi étudié le compromis à faire entre la fréquencede demandes des statistiques et la précision des mesures. Dans [77], les auteurs ontproposé une méthode permettant de calculer la bande passante disponible de chaquelien de la topologie en temps réel, pour ce faire, ils ont profité des avantages qu’offre leprotocole OpenFlow 1.3 en terme de caractéristiques dédiées à la supervision et auxmesures. Dans [78], les auteurs ont utilisé les informations de routage fournies par lecontrôleur intelligemment afin de mieux choisir les commutateurs à partir desquels lesstatistiques seront obtenues alors que dans [79], afin d’analyser le taux d’utilisation desliens, les auteurs ont utilisé une méthode passive à l’aide de la mise en place des sondesau niveau des commutateurs. L’inconvénient majeur de cette méthode est le délai trèslarge entre les mesures obtenues ainsi que la perte de précision lors des piques. Cetteproblématique a été pris en charge dans [80] où on propose de mesurer les paramètresde la QoS pour chaque flux. Cette proposition est basée sur l’échange des messagesOpenFlow (PacketIn, FlowMod, FlowRemoved) entre le contrôleur POX [81] et lescommutateurs, le délai est quand à lui obtenu en injectant des paquets "probes".
Une solution de supervision doit être bien conçue et devrait fournir un large éventailde métriques réseaux à surveiller, à différents niveaux d’agrégation, de précision et derapidité [82] [83]. Aussi, elle doit traiter et fournir les données supervisées à la fréquencedemandée [84]. Bien que des travaux antérieurs aient été consacrés au problème degestion et de mesure des statistiques réseaux en utilisant le concept SDN, seules quelquessolutions proposées ont pris en compte le compromis existant entre la fréquence dedemandes des statistiques (c’est à dire le flux généré pour la collecte des statistiques)et l’exactitude des résultats obtenus (précision des résultats).
De ce fait, et afin d’optimiser la supervision, nous proposons dans ce qui suit,une approche de supervision utilisant le concept SDN ([85]), qui calcule le tauxd’utilisation de la bande passante des liens de transmission avec précision tout enadaptant la fréquence d’interrogation des statistiques des commutateurs selon l’activitéde leurs ports en utilisant la moyenne exponentiel glissante afin de réduire l’effetdes fluctuations brusques et maintenir la précision des mesures. En effet, nous avons
3.3 Optimisation de la Supervision dans les réseaux SDN 60
enrichi une architecture SDN classique avec de nouveaux modules, elle nous permet deconstruire une vue précise et dynamique de l’utilisation des ressources, contrairementaux approches existantes, qui considèrent un état statique du réseau, la figure 3.3illustre cette architecture.
Figure 3.3 Architecture de supervision globale
3.3.1 Composant de l’architecture de supervision optimisée
Les composants de l’architecture de supervision sont détaillés ci-dessous:
— Module de supervision: Ce module est responsable de la demande des mé-triques, en utilisant des requêtes spécifiques ou implicites (avec des traps). Sur labase de la stabilité des mesures et de la précision du résultat de la vue, le modulede supervision réduit ou augmente dynamiquement la période de supervision.Cette dernière est spécifique pour chaque équipement supervisé, mais elle peutêtre aussi spécifique aux métriques supervisées.
— Module de traitement des données: Ce module collecte et filtre les donnéesreçues, qui sont analysées en utilisant des techniques d’apprentissage et des outilsutilisés dans les statistiques. Dans ce qui suit, nous ferons une mise au point surces outils.
— Création d’une vue abstraite en temps réel: En utilisant les données trai-tées, ce module crée une vue sur la topologie en considérant l’état de l’utilisationdes ressources réseaux.
— Le contrôleur SDN: En se basant sur la vue obtenu, le contrôleur est en mesurede renforcer les décisions prises sur les noeuds d’interconnexion. Cela permet
3.3 Optimisation de la Supervision dans les réseaux SDN 61
également d’optimiser de manière dynamique la précision de la vue du réseautout en réduisant la signalisation.
Le principal objectif que nous considérons consiste à proposer une nouvelle approchede supervision avec le moindre coût afin d’optimiser ladite supervision, qui nouspermettra ainsi de construire une vue abstraite des ressources réseaux.
3.3.2 Un modèle de supervision adaptatif
Dans cette sous-section, nous présentons la stratégie de supervision que nousproposons, et qui a pour but de minimiser la signalisation introduite pour des raisonsde supervision tout en gardant la précision des mesures obtenues. L’objectif derrièrecette méthode est de faire la collecte des statistiques du réseau pour concevoir une vueabstraite du réseau tout en réduisant le coût de la signalisation.
Afin de construire une telle vue, nous avons besoin de faire la mesure des indicateursde performance (Key Performance Indicator (KPI)) en utilisant les statistiques. Labande passante représente l’une des métriques la plus importante pouvant être utiliséepar le contrôleur afin d’acheminer efficacement les flux. Pour cette raison, nous noussommes intéressés à la mesure des débits, cependant, nous pourrons généraliser cetteméthode de mesure à d’autres KPI.
A une étape donnée k, le débit du port i d’un switch peut être calculé comme suit:
T ik =
Bik−Bi
k−1tk− tk−1
. (3.5)
Où T ik, Bi
k et tk représentent, respectivement, le débit du port i mesuré à l’étape k,le nombre d’octets mesurés dans le port i durant la période k, et le temps universelà l’étape k. La soustraction Bi
k −Bik−1 est représentée comme "ByteCount" dans
l’algorithme 1.Sur la base de l’équation (3.5), le contrôleur est en mesure de calculer la moyenne
du débit T ia,k et sa variance T i
v,k sur les N dernières valeurs reçues:
T ia,k = 1
N
k∑l=k−N+1
T il . (3.6)
T iv,k = 1
N
k∑l=k−N+1
(T ia,k−T i
l )2. (3.7)
Si cette variance est plus petite par rapport à un seuil (Vmin) ou la moyenneexponentielle glissante Exponential Weighted Moving Average (EWMA) de la différence
3.3 Optimisation de la Supervision dans les réseaux SDN 62
absolue entre deux débits successif (Davg) est plus petite par rapport à un seuil (Dmin),le contrôleur diminuera la fréquence de demande des statistiques DS graduellementjusqu’à fmin. Mais si cette moyenne est supérieur par rapport à un seuil (Dmax), lecontrôleur augmentera ladite fréquence jusqu’à fmax, alternativement, le contrôleurajustera la fréquence DS en utilisant les formules 3.8 et 3.9.
Davg = αDavg +(1−α)(T ik−T i
k−1) (3.8)
DS = tmax−tmax− tmin
Dmax−Dmin(Davg−Dmin) (3.9)
La raison de cet ajustement est de maintenir une fréquence plus élevée pour lescommutateurs dont les ports sont actifs et contribuent de manière significative àl’utilisation des liens, en fonction de l’historique des changements survenus dans le fluxtout en accordant une plus grande importance aux dernières variations. D’autre part,nous maintenons une fréquence inférieure pour les commutateurs dont les ports sontmoins actifs et ne contribuent pas de manière significative à l’utilisation des liens, sileur contribution augmente, le contrôleur augmentera la fréquence de leur interrogation.L’algorithme 1 résume ces opérations.
Ci-dessous, quelques messages OpenFlow que nous avons utilisés pour la réalisationde cette approche de supervision:
— PacketIn: Ce message est envoyé du commutateur au contrôleur lorsque le com-mutateur reçoit un flux qui ne correspond à aucune entrée de la table de flux.
— FlowMod: Ce message est envoyé du contrôleur au commutateur afin d’installerles règles d’acheminement nécessaires au niveau de la table de flux. Le contrôleurpeut spécifier les temps de séjours de ces règles. En effet, il existe deux type detemps, le idle_time et le hard_time, le premier correspond au temps d’inactivitédu flux, une fois écoulé, le contrôleur supprime la règle de la table de flux, tandisque le deuxième correspond au temps de séjours de la règle, une fois écoulé, lecontrôleur enlève la règle même si le flux est toujours actif, cela permettra demettre en oeuvre des politiques d’ingénierie de trafic.
— FlowRemove: Ce message est envoyé du commutateur au contrôleur lors del’éviction de la règle d’acheminement.
— StatReq: Ce message est envoyé du contrôleur au commutateur pour l’interrogersur l’état des statistiques des flux (nombre d’octets émis et reçus, nombre depaquets émis et reçus, nombre d’erreurs...etc.).
3.3 Optimisation de la Supervision dans les réseaux SDN 63
Algorithm 1 Polling Timeout Calculation (Event e)1: Input:2: T i,j [n] // Last n calculated Throughput table3: Di,j [n] // Last n Arithmetic Difference between4: two successive throughput table5: Main () {6: T i,j [n]←{}, Di,j [n]←{}, PT ← tmax
10: Case TimeOut : StatReq (e.Switch)11: Case StatResp : PT ← ComputeTimeOut12: (e.Switch , e.ByteCount , PT)13: Schedule (e.Switch , PT)14: }15: ComputeTimeOut (Switch , ByteCount , PT) {16: for port in Switch.Ports17: T i
— StatRes: Ce message est envoyé du commutateur au contrôleur en réponse à sarequête.
3.4 Routage avec QoS dans les réseaux SDN 64
3.4 Routage avec QoS dans les réseaux SDNLe routage avec prise en charge de la QoS, est un mécanisme qui permet de faire la
recherche et la sélection des meilleurs chemins afin d’assurer le niveau de service requispar les flux critiques en se basant sur les informations relatives à la disponibilité desressources du réseau. Dans ce contexte, nous proposons dans ce qui suit, deux approchesprenant en charge la QoS des flux vidéo lors de leur acheminement en utilisant leconcept SDN. La première est décrite dans la sous section 3.4.1 alors que la deuxièmeest décrite dans 3.4.2
3.4.1 Stratégie de Routage Consistante (SRC) dans les ré-seaux SDN
L’objectif principal de la SRC est de protéger les flux prioritaires, tout en préservantau mieux les flux non prioritaires (best-effort flows). Pour cela, nous avons proposéla dispersion des flux prioritaires sur les k chemins les plus courts afin d’éviter aumieux toute concurrence entre eux, ce qui serait important en termes de QoS/QoE.En effet, la dispersion des flux, telle que proposée (voir Algorithme 2), garantit nonseulement des délais raisonnables pour les flux, mais également leur protection en cas decongestion, car dans ce cas, seuls les flux non prioritaires subiront les pertes de paquetsdu moment où ils sont majoritaires sur le lien. Une stratégie de routage optimale doitprendre en compte, comme nous l’avons noté, deux aspects principaux. Un premieraspect concerne l’obtention d’une vue précise de l’état de la topologie du réseau. Undeuxième aspect concerne l’algorithme de routage, qui devrait non seulement prendreen compte les services pris en charge, en termes de SLA, mais également la variabilitéintrinsèque des ressources, pour permettre une utilisation optimale du réseau.
3.4.1.1 L’algorithme SRC
Dans notre formulation, un réseau est représenté comme un graphe simple directG = (V,E), où V est l’ensemble des noeuds et E est l’ensemble des liens. Dans une telletopologie, l’établissement du chemin d’un flux f dans le graphe G passe par le calcul desk chemins les plus courts en utilisant la fonction getKShortestPaths(). Cette dernièreest basée sur l’algorithme de Yen [101] et a une complexité de l’ordre de O(K×n3).Même si nous avons considéré, comme stipulé dans ce qui suit, le nombre de sauts pourles calculs des chemins les plus courts, d’autres métriques peuvent être considérées.
3.4 Routage avec QoS dans les réseaux SDN 65
Une fois les chemins déterminés, nous avons proposé d’éliminer ceux qui ne satisfontpas le SLA requis par le client, en utilisant la fonction getSubCompliantPaths().
Algorithm 2 L’algorithme SRC1: Input: Flow f to place, topology G, hard timeout HT []2: Output: Placement’s proposition, hard timeout3: Paths = getKShortestPaths(f.src,f.dst)4: cPaths = getSubCompliantPaths(Paths, f.SLA)5: if cPaths = {Φ} then6: return Null7: if f.Prioritized then8: for all p in cPaths do9: p.PFPR = max getTopologyInfo(G,p,metric = PFPR)
10: p∗ = arg minp
{p.PFPR, ∀ p ∈ cPaths}
11: f.hard_timeout = random(HT )12: return p∗, f.hard_timeout13: else14: for all p in cPaths do15: p.LFB = min getTopologyInfo(G,p,metric = LFB)16: p∗ = arg max
La solution de routage proposée agit comme un contrôle d’admission de connexioncar aucun placement n’est accepté si le SLA ne peut pas être respecté (voir lignes5−7).
Contrairement aux approches traditionnelles qui placent les flux prioritaires etnon prioritaires uniquement en fonction de la bande passante disponible, nous avonsproposé différentes approches pour ces flux. En effet, nous avons proposé de placerle trafic prioritaire en fonction du PFPR, qui reflète le taux de présence de ce traficsur chaque lien. La valeur la plus élevée pour un chemin est prise en compte car lelien ayant le plus grand PFPR est celui qui transfère de nombreux flux prioritaires,et afin de garantir une dispersion optimisée de ces flux et réduire ainsi leur taux deperte de paquets en cas de congestion, nous sélectionnons le chemin p∗ qui a le plusfaible PFPR. En conséquence, nous sélectionnons le chemin p dans P minimisant lemaximum PFPR dans ses liens, voir l’équation (3.10) ci-dessous.
p∗ = arg minp
{max PFPR(lpi )}, ∀p ∈ Ps,d (3.10)
3.4 Routage avec QoS dans les réseaux SDN 66
où lpi , P , PFPR représentent, respectivement, le lien i du chemin p, l’ensemble des k
chemins les plus courts entre la source s et la destination d, et la fonction qui renvoie lavaleur PFPR du lien, qui est fournie par la fonction getTopologyInfo() de l’algorithme2.
Le routage des flux non prioritaires est basé sur la disponibilité de la bande passanteafin de les préserver au mieux. Cette fois, la valeur la plus faible est prise en considérationcar le lien qui possède la plus faible LFB représente le goulot d’étranglement du chemin,donc, pour optimiser l’utilisation de la bande passante tout en réduisant la perte depaquets, nous sélectionnons le chemin qui possède la valeur la plus élevée de la LFB.Ainsi, la formule suivante est appliquée pour la sélection du meilleur chemin p∗, voirl’équation (3.11) suivante:
p∗ = arg maxp
{min LFB(lpi )}, ∀p ∈ Ps,d (3.11)
où la fonction LFB calcule la bande passante disponible du lien.
3.4.1.2 Allocation dynamique des temps de séjours
Afin d’assurer une opération de réacheminenemt des flux sur les meilleurs cheminscalculés, nous devions assigner des valeurs différentes de temps de séjour des entréesde flux dans les tables de flux des commutateurs pour chaque flux. En effet, si nousutilisons la même valeur pour les différents flux, l’opération de réacheminenemt des fluxpar le contrôleur se fera en même temps, et de ce fait, nous aurons de l’inconsistancedans les décisions. En réalité, lorsque le contrôleur effectue les opération de supervision,il envoie les messages FlowStatReq périodiquement (chaque seconde dans la plus partdes cas) afin d’avoir une image précise des statistiques du réseau 2. Ainsi, lorsque lecontrôleur effectue les opérations de réacheminement, il y a un risque que les fluxprioritaires se partagerons un ensemble de liens, car leur opération d’acheminement aété faite en même temps. Pour éviter cette situation, nous avons proposé d’utiliser unestratégie d’allocation dynamique des temps de séjours pour les différents flux sur labase d’une fonction, qui fournie des valeurs aléatoires des temps de séjours des fluxcomme indiqué dans l’algorithme 2. Le tableau 3.1 illustre une comparaison entrel’ARCSDN que nous proposons (Figure 3.2) et quelques travaux connexes en termes degestion de la topologie réseau et calcule des chemins, routage avec QoS, lissage du fluxmeilleur-effort, dispersion des flux critiques (multimédia) selon leur taux de présence
2. Notez que le trafic internet possède une distribution qui correspond à une loi poissonniennepour les échelles de temps inférieures à la seconde [89]
3.4 Routage avec QoS dans les réseaux SDN 67
(Prioritized Flows Presence Ratio (PFPR)), et l’allocation dynamique des temps deséjour des entrées de flux dans la table de flux des équipements réseaux.
3.4.2 Stratégie de routage avec QoS pour la vidéo conférence
Vue la croissance du nombre d’appareils connectés et du volume de trafic provenantdes applications multimédias distribuées, telles que la vidéo conférence et le streamingvidéo, il est nécessaire de passer d’une gestion du réseau distribuée à une gestioncentralisée. En effet, la centralisation du contrôle du réseau nous offre un moyen efficaceet attractif afin de relever le défi contre une gestion de réseau complexe. Afin defournir les prérequis en termes de paramètres de QoS pour ce genre de flux, nous avonsproposé une solution prenant en charge la QoS lors de l’acheminement des flux de vidéoconférence en posant ce problème d’acheminement comme étant une recherche du pluscourt chemin avec contraintes et le résoudre avec l’algorithme (Delay Constraint LeastCost (DCLC)) [90].
3.4.2.1 Prérequis d’un flux de vidéo conférence
Afin d’implémenter un mécanisme de QoS, nous devrons définir les métriques quiseront utilisées ainsi que les prérequis de l’application en terme de ces métriques. Commenous l’avons noté auparavant, la vidéo conférence permet d’avoir des communicationstemps réel en permettant aux personnes de deux sites ou plus de communiquer entreelles. Lors d’une vidéo conférence, outre les canaux vocaux, comme dans le réseautéléphonique public commuté (Réseau Téléphonique Commuté Publique (RTPC))classique, des canaux vidéo sont également mis en oeuvre depuis les différents sites.Chaque site possède une ou plusieurs caméras, microphones, haut-parleurs et moniteurs,ainsi qu’une liste des codecs supportés. Le tableau 3.2 résume les prérequis d’unecommunication de type vidéo conférence.
Comme nous l’avons stipulé ci-dessus, nous avons formulé le problème de routagedynamique avec prise en charge de la QoS comme étant un problème de recherche duplus court chemin avec contraintes. En effet, comme expliqué, la vidéo conférence estune application interactive qui possède des prérequis strictes en termes de délai debout en bout et de perte de paquets. Dans notre proposition, un réseau est formulécomme étant un graphe directe (G(N,L)) où N est l’ensemble des noeuds et L estl’ensemble des liens, tel que le lien (i, j) est une paire allant du noeud i au noeud j.Nous avons considéré que Rxy est l’ensemble de tous les chemins possibles de la source
3.4 Routage avec QoS dans les réseaux SDN 68
Tab
le3.
1C
ompa
raiso
nen
tre
notr
ear
chite
ctur
ede
rout
age
etqu
elqu
estr
avau
xco
nnex
es.
Solu
tions
(cita
tions
)[6
9][6
4][2
2][6
6][6
3][6
2][6
5][6
7][6
8]Pr
opos
edFr
amew
ork
Topo
logy
Man
agem
ent
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
Rou
teM
anag
emen
tO
KO
KO
KO
KO
KO
KO
KO
KO
KO
KR
oute
Cal
cula
tion
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
QoS
Rou
ting
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
Cro
ssTr
affic
Shap
ing
NO
KN
OK
NO
KN
OK
NO
KN
OK
NO
KO
KN
OK
OK
PFPR
Base
dD
isper
sion
NO
KN
OK
NO
KN
OK
NO
KN
OK
NO
KN
OK
NO
KO
KD
ynam
icT
imeo
utA
lloca
tion
NO
KN
OK
NO
KN
OK
NO
KN
OK
NO
KN
OK
NO
KO
K
3.4 Routage avec QoS dans les réseaux SDN 69
Response time (ms) delay (ms) Jitter (ms) Loss Rate Error Rate< 100 < 200 < 400 < 0.01% < 0.01%
Table 3.2 Pré-requis d’une communication de type vidéo conférence
x à la destination y. Pour chaque chemin r ∈Rxy nous avons définis une fonction decoût fC(r) et une fonction de délai fD(r), qui est calculé comme suit:
fC(r) = ∑(i,j)∈r
cij , fD(r) = ∑(i,j)∈r
dij (1)
Où les coefficients cij et dij représentent, respectivement, le coût en terme de perte depaquets et le délai pour le lien (i, j). Le meilleur chemin est celui dont le coût est leplus faible (celui qui minimise la fonction fC(r)) sujette à la fonction fD(r), qui de-vrait être inférieur ou égale à une valeur spécifique Dmax. Le coût est calculé comme suit:
cij = (1−α)dij +αpij for 0≤ α≤ 1, ∀(i, j) ∈ L (2)
Où pij représente la mesure du taux de perte de paquets des flux avec contrainteset ceux du meilleur effort sur le lien (i, j), et α est le facteur d’échelle qui déterminel’importance relative du délai et la charge du réseau en terme de flux. La sélectiondu chemin serait plus critique à la perte de paquets pour des réseaux plus large etplus critique au délai pour les réseaux de petite taille. En effet, sur un large réseau lenombre de sauts augmente, et par conséquent le nombre des goulots d’étranglementaugmente aussi, ce qui fait croître le taux de perte de paquets. Par contre, dans unpetit réseau, il y a moins de sauts donc moins de perte, ce qui fait que le délai primedans la formule de calcul du coût. La formule pour pij est définie comme suit:
pij =
Qij+Tij−Bij
Qij+Tij,Bij < Qij +Tij (3)
0, Bij ≥Qij +Tij
Où Bij est la bande passante du lien (i, j), Qij et Tij représentent, respectivement, letaux des flux avec contraintes (flux vidéo) et ceux du meilleur effort. La fonction degestion du routage du contrôleur collecte les données des commutateurs (pij , dij) etles envoie à la fonction responsable du calcul des routes (chemins). Au niveau de lacouche (acheminement des données), les paramètres considérés sont estimés comme suit:
3.4 Routage avec QoS dans les réseaux SDN 70
— Mesure du taux de perte de paquets: (pij), qui est calculé en utilisant la formule(3) où Bij , Qij et Tij sont des paramètres requis pour le calcul. La supervision destaux de trafic (Qij et Tij) sur chaque lien est assurée par le protocole OpenFlowqui maintient l’état des compteurs sur les commutateurs.
— La mesure du délai peut être obtenue en estimant la moyenne du délai observésur l’horodatage comme cela se fait dans le protocole [91].
Par la suite, nous avons résolu le problème du plus court chemin en utilisantl’algorithme proposé dans [61] et illustré dans 3. Lorsque la fonction de gestion duroutage met à jour les indicateurs ou la fonction gérant la topologie détecte unchangement, la fonction responsable du calcul des chemins exécute l’algorithme DCLCpour résoudre le problème du CSP (Trouver le meilleur chemin minimisant la fonctiondu coût fC(r) sujette à la fonction qui calcule le délai fD(r) devant être inférieur ouégale à Dmax). Par la suite, le contrôleur met à jour les table de flux des commutateursselon le résultat obtenu en terme de routage des flux de vidéo conférence.
3.4.2.2 L’Algorithme DCLC
Étape 0: Début.Étape 1: S’il y a plus d’un chemin avec un coût minimum, trouver le chemin de faiblecoût entre la source s et la destination d avec le délai minimum, supposant que cechemin est q.Étape 2: Vérifier si la valeur du délai du chemin de l’Étape 1 est inférieur ou égale audélai requis.Étape 3: Si le résultat de l’Étape 2 est correcte alors le chemin convenable est q.Étape 4: Sinon, supposant que p est le chemin le plus court pour un délai minimum.Étape 5: Vérifier si la valeur de ce délai est supérieur par rapport à celui requis.Étape 6: Si le résultat de l’Étape 5 est positif alors il n’y pas un retour de chemin(return NULL).Étape 7: Création d’une variable booléene "Continue" ayant comme valeur initiale"True".Étape 8: Mettre en oeuvre une boucle tant que la condition est vérifiée et sortir de laboucle une fois la valeur de la variable booléenne devienne "false".Étape 9: Si le résultat de l’Étape 5 est "false", alors, calculer le paramètre α, où:α = Cd−d(p)
c(p)−c(q) . Cd est le délai requis, et d(p) est le délai du chemin p, c(p) est le coûtdu chemin et c(q) le coût du chemin q.Étape 10: Convertir chaque chemin à un paramètre (w), où w = delay + α * costpour chaque chemin, puis, si r est le chemin dont w est le plus faible.
3.5 Conclusion 71
Étape 11: Si le coût du chemin (r) est égal au coût du chemin (q) ou du chemin (p)Étape 12: Si le résultat de la condition 11 est correcte alors Continue = false afin desortir de la boucle.Étape 13: Si le résultat de la condition (Étape 11) est ’False’ alors (Étape 14), sinon(Étape 16)Étape 14: Soit p = Le chemin le plus court (r).Étape 15: p est le chemin convenable choisi par l’algorithme. renvoie de p .(Étape 16) 16: Fin.
Algorithm 3 L’algorithme DCLC1: Algorithm DCLC (G,s,t,c,d,Cd)2: q←ModiDijk(c,d)3: If d(q)≤ Cd then return q4: p←Dijk(d)5: If d(p) > Cd then return Null6: Continue=TRUE7: While Continue=TRUE8: α← Cd−d(p)
c(p)−c(q)9: w=delay+α*cost for each path
10: r←Dijk(d+αc)11: If (c(r) = c(q)) or (c(r) = c(p)) then Continue=False12: Return p13: p← r
3.5 ConclusionNous avons vu dans ce chapitre les différentes propositions que nous avons faites
pour palier aux problèmes de QoS, notamment dans le contexte de la supervision, quiest devenu, de nos jours cruciale pour les opérateurs réseaux, ainsi que dans le voletacheminement des données temps réel telles que la vidéo adaptative et celle de vidéoconférence (routage avec QoS). L’implémentation, l’évaluation, et la comparaison dela stratégie d’optimisation de la supervision proposée ainsi que celles du routage avecQoS discutées ci-dessus seront abordée dans le chapitre suivant.
Chapitre 4
Implémentation, Expérimentation,Evaluation et Comparaison desSolutions Proposées
4.1 IntroductionAfin de valider les approches proposées dans le chapitre ci-dessus, nous les avons
comparées à d’autres travaux connexes discutés dans l’état de l’art comme suit:
— Comparaison de la solution d’optimisation de la supervision à la solution Payless[76] et celle basée sur un envoi périodique des requêtes de demande des statistiquesréseaux.
— Comparaison de la stratégie de routage consistente (SRC) avec OpenQoS [64],SSPR [72] et LFBMR 1.
— Comparaison de la stratégie de routage avec QoS pour les flux de vidéo conférenceen mettant en place deux contrôleurs, un hébergeant ladite stratégie et un autreordinaire, qui ne prend pas en charge le routage avec QoS.
1. Afin d’implémenter ce modèle de routage, nous avons considéré uniquement le routage des fluxbest effort (basé sur la disponibilité de la bande passante) aussi bien pour les flux vidéo que les fluxmoins critiques
4.2 Implémentation et évaluation de l’approche de supervision proposée 74
4.2 Implémentation et évaluation de l’approche desupervision proposée
Afin d’implémenter et d’évaluer l’approche de supervision proposée, nous avonsutilisé l’émulateur Mininet [92]. L’application proposée a été intégrée dans le contrôleurRYU [45]. La topologie sur laquelle nous avons effectué les expérimentations a étéobtenue de [93] et a été convertie en utilisant le Python en une topologie utilisable surMininet tout en gardant ses paramètres réels en termes du nombre de commutateurs,d’hôtes, de bande passante des liens...etc.
4.2.1 Modèles de flux utilisés
La matrice de flux que nous avons utilisée dans les expérimentations est composéede flux UDP poissonniens. En effet, nous avons utilisé deux scénarios avec deux modèlesde flux différents afin de tester et comparer notre approche avec celle de payless [76] etl’approche de demande des statistiques périodiques en terme de précision des mesureset d’overhead dûs aux mesures. Les figures 4.1 et 4.2 représentent respectivement lesdeux matrices de flux utilisées. Afin de générer les flux, nous avons utilisé le générateurde flux MGEN [94]. Pour les entrées de l’algorithme, nous avons fixé les valeurs destemps de demande des statistiques minimum et maximum à 1s et 6s respectivement,D_max et D_min ont été fixées à 1500 Kbps et 400 Kbps pour le scénario 1 et à 500Kbps et 100 Kbps dans le scénario 2. Le choix de ces seuils a été fait sur la base desdébits moyens des liens. Pour l’approche de payless, nous avons fixé la valeur de γ etde β à 2 et à 6 respectivement en utilisant les mêmes valeurs des temps de demandedes statistiques que celles de notre approche. Pour l’approche périodique, le temps dedemande des statistiques a été fixé à 1s. Nous avons aussi utilisé différentes valeurs duparamètre α de la formule 3.8 pour montrer son influence sur le compromis entre laprécision et l’overhead obtenus.
Figure 4.1 Matrice de flux utilisée dans le scénario 1
4.2 Implémentation et évaluation de l’approche de supervision proposée 75
Figure 4.2 Matrice de flux utilisée dans le scénario 2
Figure 4.3 Mesure du débit dans le scénario 1
Figure 4.4 Mesure du débit dans le scénario 2
4.2 Implémentation et évaluation de l’approche de supervision proposée 76
Table 4.1 Overhead Obtenus en terme de nombre de requêtes
Figure 4.5 Influence de la valeur de α sur la mesure des débits
Dans le premier scénario, nous avons mesuré le débit du port 1 du commutateur7 du fait que l’hôte qui génère le flux est connecté sur ce port, par contre dans ledeuxième scénario, nous avons mesuré le débit du port 1 du commutateur 3 du fait que
4.2 Implémentation et évaluation de l’approche de supervision proposée 77
l’hôte 3 reçoit tout le flux. Nous avons mesuré les débits en utilisant les trois méthodes:mesure périodique, qui reflète pratiquement les modèle de flux de la figure 4.1 et dela figure 4.2, Payless ainsi que notre approche de mesure intelligente. Le résultat deces mesures sont montrées dans les figures 4.3 et 4.4. D’autre part, nous avons calculél’overhead généré en terme de nombre de requêtes envoyées par le contrôleur tout aulong de la période de simulation. Les tableaux 4.1 et 4.2 résument les résultats obtenusen terme d’ovrehead obtenu ainsi que l’erreur par rapport à l’approche qui consiste àenvoyer périodiquement des requêtes.
4.2.2 Discussion des résultats obtenus
Il est clair qu’en terme de mesure du débit, en utilisant la méthode d’envoie derequêtes périodique, nous obtenons un graphe pratiquement similaire à celui du modèlede trafic que nous avons utilisé pour générer les flux, les figures 4.1 et 4.2 illustrent cerésultat, mais au détriment de la surcharge (overhead) générée dans le réseau (dû àl’envoie continu des requêtes). En effet, l’approche que nous avons proposée a réduit lenombre de requêtes envoyées jusqu’à 63% et 46% dans le premier et le second scénariorespectivement par rapport à la méthode d’envoie de requêtes périodique et jusqu’à 30%par rapport à l’approche proposée dans [76] tout en gardant une certaine précision, letableau 4.2 ainsi que les figures 4.3 et 4.4 illustrent ce résultat. En effet, cette réductionest dû principalement à la considération du contrôleur des anciennes mesures, ce qui luipermet d’ajuster plus efficacement la fréquence de demandes des statistiques commedécrit dans l’algorithme 1. Concernant l’effet de la valeur de α sur la précision desmesures, la figure 4.5 présente les résultats obtenus. Plus nous donnons de l’importanceaux valeurs récentes (α petit), plus la précision des mesures augmente avec une légèreaugmentation de la surcharge dans le réseau. Le choix de la valeur de α ainsi que celuides valeurs des seuils utilisées dans l’approche que nous avons proposée peuvent êtreajustées afin de faire un compromis entre la précision désirée et la surcharge tolérée.
Dans cette approche, nous avons évoqué l’utilisation d’une supervision adaptativequi a pour but de réduire le nombre de messages générés dans le cadre de la demandedes statistiques réseaux tout en maintenant la précision des mesures effectuées ainsique l’état du réseau. Nous avons évalué et comparé notre approche avec celle proposéedans [76] et celle utilisant des demandes de statistiques réseaux périodiques. Nousavons remarqué que nous arrivons avec notre approche d’atteindre une précision desstatistiques acceptable comme celle obtenu avec [76] mais avec une réduction du nombrede messages allant jusqu’à 63 % et 30% par rapport à Payless et celle utilisant desdemandes de statistiques réseaux périodiques respectivement.
4.3 Implémentation et évaluation de la SRC 78
4.3 Implémentation et évaluation de la SRCAfin d’évaluer la performance de la SRC proposée, nous avons utilisé l’émulateur
Mininet. Tous les modules décrits lors de la description de cette approche ont étéintégré dans le contrôleur RYU et programmés en utilisant le Python. Aussi, nousavons enrichi la topologie Abilene avec d’autres équipements afin de créer un grapheavec plus de liens. La topologie finale contient 12 commutateurs et 11 terminaux ainsique deux serveurs vidéo (voir figure 4.7). La topologie de base (Abilene) a été obtenu àpartir de [93] et a été convertie en une topologie utilisable dans Mininet, en utilisant unoutil décrit dans [94]. L’émulation a été faite avec une machine dotée d’un processeurIntel Core i5-6500-3.20 Ghz avec 8GB de RAM et un système d’exploitation Linux.Le tableau 4.3 résume les délais des différents liens de la topologie. Ces derniers sontobtenus à partir de la vitesse de la lumière dans un canal optique ainsi que la positiongéographiques des noeuds.
Table 4.3 Abilene topology links’ delay
Link Delay (ms)NewYork (S1)- Chicago (S2) 0.806374975652
Houston (S9) - Atlanta (S10) 1.34344500256Atlanta (S10) - Indianapolis (S11) 0.544962634977
Chicago (S2) - Virginia (S12) 1WashingtonDC (S3) - Virginia (S12) 1
NewYork (S1) - Virginia (S12) 1Atlanta (S10) - Virginia (S12) 1
Indianapolis (S11) - Virginia (S12) 1
4.3 Implémentation et évaluation de la SRC 79
4.3.1 Modèle de flux utilisé
Le modèle de flux que nous avons utilisé est composé des flux Transmission ControlProtocol (TCP) best-effort que nous avons généré avec l’outil MGEN [95] ainsi que deflux vidéo adaptative (Dynamic Adaptive Streaming over HTTP (DASH)). Ces fluxsont donc disponibles avec une variété de débits et de qualités (128 Kbps, 256 Kbps,512 Kbps, 1024 Kbps, 2048 Kbps et 4096 Kbps). Le contenu de la vidéo diffusée a étéobtenu de [96]. Le choix des terminaux qui participent à l’expérimentation a été faitde telle sorte que les flux empruntent le maximum de liens de la topologie. Le tableau4.4 résume le modèle de flux utilisé. BT dénote flux best-effort. La figure 4.6 illustre lamoyenne du débits des flux best-effort dans chaque intervalle de temps (en bleu) ainsique sa moyenne tout au long de l’émulation (en rouge).
Table 4.4 Modèle de Flux utilisé dans l’expérimentation
Hosts Traffic TypeH5 to H1 BT (Fig. 4.6)H5 to H12 BT (Fig. 4.6)H10 to H4 BT (Fig. 4.6)H10 to H11 BT (Fig. 4.6)VS1 to H3 DASHVS2 to H2 DASHVS1 to H6 DASHVS2 to H7 DASH
Afin d’évaluer et valider la performance de l’approche de routage proposée, nousl’avons comparée à trois autres modèles de routage, à savoir, le Single Shortest Path ba-sed Routing (SSPR) [72], le Link Free Bandwidth Multipath based Routing (LFBMR) 2
ainsi que OpenQoS [64]. Nous avons mesuré pour chaque stratégie, le débit moyen reçupour les deux types de trafic (vidéo et best effort), ainsi que la QoE de la vidéo enterme de Mean Opinion Score (MOS). Ce dernier est obtenu à l’aide d’un outil ayantété développé dans [97].
4.3.2 Résultats Obtenus
Débit moyen des flux best effortLa figure 4.8 illustre les résultats obtenus en termes de débits moyens reçus en utilisant
2. Afin d’implémenter ce modèle de routage, nous avons considéré uniquement le routage des fluxbest effort (basé sur la disponibilité de la bande passante) aussi bien pour les flux vidéo que les fluxmoins critiques
4.3 Implémentation et évaluation de la SRC 80
0 60 120 180 240 300 360 420 480 540 6000
1
2
3
4
5
-Average in time unit
-Average throughput
Time (s)
Through
put(M
bps)
Figure 4.6 Débit des flux Best-effort utilisé
Figure 4.7 Topologie Abilene enrichie avec d’autres noeuds
4.3 Implémentation et évaluation de la SRC 81
les différentes stratégies de routage. En comparant ces approches, nous remarquonsque l’utilisation du modèle de routage LFBMR permet d’obtenir le débit moyen leplus élevé. Ceci est dû à la stratégie de routage qu’il utilise, il permet de choisir lesmeilleurs chemins (ayant le plus de bande passante disponible) pour l’ensemble desflux sans considérer leur criticité. Parmi les autres techniques restantes, la stratégie deroutage que nous avons proposée (SRC) présente le débit moyen le plus élevé puisqu’elleconsidère d’abord l’emplacement stratégique des flux vidéo, puis l’installation du traficbest effort en considérant la bande passante disponible. OpenQoS et SSPR ont à peuprès les mêmes performances vis à vis des flux best effort car les deux stratégies neprennent en compte que les chemins les plus courts traditionnels pour ce type de flux,avec une légère performance pour OpenQoS, car elle considère le routage dynamiquedes flux prioritaires (vidéo), ce qui améliore la gestion de bande passante, au bénéficedes flux best effort.
Débit moyen des flux vidéos et QoEEn analysant les figures 4.9 et 4.10, nous remarquons que le débit moyen des flux vidéoainsi que la QoE les plus élevés ont été obtenu avec l’approche que nous avons proposée,car le modèle LFBMR ne prend pas en considération les flux vidéo et route tous les fluxindifféremment selon la disponibilité de la bande passante, permettant ainsi au flux besteffort de dominer la bande passante des liens au détriment de la qualité des flux vidéo(dû à l’adaptation de débit des flux vidéo (DASH)), ce qui explique aussi l’augmentationdu débit moyen des flux best effort comme indiqué précédemment. Nous avons aussiobtenu de meilleurs résultats avec l’approche OpenQoS par rapport à LFBMR, vueque OpenQoS considère le placement des flux vidéo sur les meilleurs chemins (ayant leplus de bande passante) et le placement des flux best effort traditionnellement (selonle chemin le plus court). D’autre part, nous avons obtenu de meilleurs résultats avecl’approche proposée par rapport à OpenQoS, car notre stratégie de routage considèreen premier, le taux de présence des flux vidéo au niveau de chaque lien, ce qui évitela concentration de tels flux et réduit le risque de perte de paquets pour ce genrede flux en cas de congestion. Aussi, l’approche que nous avons proposée permet defaire un lissage des flux best effort ainsi qu’une allocation dynamique des temps deséjour des entrées de flux dans les tables de flux des commutateurs, ce qui amélioreconsidérablement l’utilisation de la bande passante.
le débit moyen des flux vidéo ainsi que la QoE les plus faibles ont été obtenuavec l’approche SSPR car cette stratégie considère uniquement un chemin lors del’acheminement des flux (vidéo et best effort) en se basant sur la bande passante totale
4.3 Implémentation et évaluation de la SRC 82
SSPR LFBMR OpenQoS CRS0
1
2
3
4
5
Average
Through
put(M
bps)
h5-h1 h5-h12h10-h4 h10-h11
Figure 4.8 Débit Moyen des Flux Best Effort en Utilisant Différentes Stratégies deRoutage
SSPR LFBMR OpenQoS CRS0
1,000
2,000
3,000
4,000
5,000
Average
received
video
bitrate
(Kbps) VS1-H3 VS1-H6
VS2-H2 VS2-H7
Figure 4.9 Débit Moyen des flux vidéo en utilisant Différentes Stratégies de Routage
4.4 Implémentation de la stratégie de routage avec QoS pour les flux de vidéoconférence 83
des liens sans prendre en considération les contraintes de la QoS. Cette stratégie estbonne pour les flux best effort, mais au détriment d’une mauvaise qualité des fluxvidéo.
4.4 Implémentation de la stratégie de routage avecQoS pour les flux de vidéo conférence
Afin d’évaluer l’approche d’acheminement des flux de vidéo conférence, que nousproposons, nous avons utilisé le contrôleur Floodlight [46], Mininet ainsi que la topologiede la figure 4.11.
Les deux machines (h1 et h2) sont séparées par cinq routeurs. Nous avons simulétrois scénarios dans lesquels, des flux TCP et UDP ont été générés avec différentsdébits (faire en sorte d’avoir trois niveaux de qualité). Les tableaux 4.5 et 4.6 résumentles paramètres de cette expérimentation en termes de débit, temps de simulation...etc.
Parametres ValuesArchitecture Openflow
Flows TCPUDP
Simulation Time 240sTCP Rate 800 Kbps
Bandwidth (R1-R5) 1MbpsBandwidth (R1-R2-R5) 2Mbps
Bandwidth (R1-R3-R4-R5) 3MbpsTable 4.5 Paramètres de simulation
Scenario Udp Rate (Kbps)First 384
Second 512Third 784
Table 4.6 UDP rates
Les flux UDP représentent une communication de vidéo conférence entre h1 et h2(Flux prioritaire ayant besoin de la QoS), alors que les flux TCP sont présents afin decongestionner le réseau. Ces flux ont été générés avec le générateur de flux D-ITG [98].Dans le premier scénario, nous avons généré des flux UDP à un débit de 384 kbps entre
4.4 Implémentation de la stratégie de routage avec QoS pour les flux de vidéoconférence 84
SSPR LFBMR OpenQoS CRS
1
2
3
4
5
MeanOpinionScore
(MOS)
VS1-H3 VS1-H6VS2-H2 VS2-H7
Figure 4.10 QoE des flux vidéo en utilisant Différentes Stratégies de Routage
Figure 4.11 Topologie utilisée dans les expérimentations
h1 et h2 sans la considération d’une congestion de réseau, puis nous avons mesuré letaux de perte de paquets, la gigue ainsi que le délai. Par la suite, nous avons générédes flux TCP en considérant la même expérience sans utiliser un contrôleur assurantla QoS, et nous avons mesuré les même paramètres (le taux de perte de paquets, lagigue et le délai). Puis, nous avons refait les même simulations, mais cette fois-ci avecla présence d’un contrôleur qui prend en charge la QoS, comme proposée. Le tableau4.7 résume les résultats obtenus pour le premier scénario.
Dans le deuxième scénario, nous avons utilisé les mêmes paramètres que ceux dupremier scénario mais cette fois-ci avec un débit du flux UDP de 512 kbps. Les résultatsde ce scénario sont illustrés dans le tableau 4.8.
4.4 Implémentation de la stratégie de routage avec QoS pour les flux de vidéoconférence 85
Table 4.8 Les résultats obtenus pour un flux UDP à un débit de 512 Kbps
Dans le troisième scénario, nous avons utilisé les mêmes paramètres que ceux dupremier scénario mais cette fois-ci avec un débit du flux UDP de 784 kbps. Les résultatsde ce scénario sont représentés dans le tableau 4.9.
Table 4.9 Les résultats obtenus pour un flux UDP à un débit de 784 Kbps
Nous avons aussi utilisé Video LAN Client (VLC) pour tester le comportementde l’architecture vis à vis des flux vidéo réels. En effet, la vidéo a été généré entreh1 et h2 avec deux qualités différentes, la première avec une résolution de 320x240et la deuxième avec une résolution de 352x288. Par la suite, nous avons émulé unecongestion du réseau avec l’envoie des flux TCP et mesuré la QoE en calculant le PowerSignal to Noise Ratio (PSNR) des vidéo reçues en utilisant un contrôleur avec et sansQoS. Les figures 4.12 et 4.13 montrent les résultats obtenus.
Lorsque nous générons des flux UDP sans la considération des flux TCP, le réseauest moins saturé et la communication entre h1 et h2 est acheminée à travers le lienR1-R5, dans ce cas, quelque soit le débit des flux UDP, il est claire que nous obtenonsdes taux de perte de paquets acceptables, de même pour la gigue ainsi que le délai.Lorsque nous générons des flux TCP (afin de créer une congestion), dans le cas oùnous utilisons un contrôleur qui ne supporte pas l’approche de QoS proposée, lescommunications UDP (temps réel) partage le chemin le plus court avec les flux demeilleurs effort, ce qui engendre une dégradation de la qualité de la vidéo (dû à la
4.5 Conclusion 86
Figure 4.12 Comparaison de la qualité de la vidéo reçue (320x240) avec et sans QoS
Figure 4.13 Comparaison de la qualité de la vidéo reçue (352x288) avec et sans QoS
dégradation des paramètres de la QoS). Par contre, lorsque nous utilisons le contrôleurqui supporte l’approche de QoS proposée, nous obtenons de meilleurs résultats entermes de taux de perte de paquets, de la gigue ainsi que du délai, qui est dû à laméthode d’acheminement des flux vidéo (routage avec QoS). Dans la figure 4.12, lePSNR à une valeur moyenne de 20 db pour les flux vidéo (320x240) acheminés avecprise en charge de la QoS et une valeur moyenne de 7 db pour les flux vidéo envoyéssans prise en charge de la QoS. Dans la figure 4.13, nous avons obtenu une moyennede 13 db pour les flux vidéo (352x288) acheminés avec prise en charge de la QoS etune valeur moyenne de 5 db pour les flux vidéo envoyés sans prise en charge de la QoS.L’obtention de ces résultats est dû à la façon dont les flux vidéo sont acheminés ainsiqu’à la résolution de la vidéo utilisée, une vidéo avec une résolution plus petite n’estpas aussi gourmande en terme d’occupation de la bande passante qu’une vidéo avecune résolution plus grande.
4.5 ConclusionLa supervision réseau devient de plus en plus importante et les opérateurs doivent
avoir une vue globale sur leur réseau afin d’assurer un certain niveau de QoS pour les
4.5 Conclusion 87
différentes applications supportées. Obtenir des statistiques réseaux avec précision aideles fournisseurs de services à évaluer la santé de leur infrastructure et trouver facilementles causes de la détérioration. Les techniques de QoS permettent aux administrateursréseaux d’utiliser les ressources réseaux efficacement et d’assurer un certain niveaude service sans revoir le dimensionnement de leur infrastructure. Nous avons vu dansce chapitre, à travers les simulations effectuées, que l’acheminement des flux sur leschemins les plus courts classiques (sans prise en charge de la QoS), n’est pas toujours lameilleure solution. Le concept SDN ainsi que le protocole OpenFlow nous permettentde faire moins d’effort, avec plus de flexibilité afin d’effectuer des expérimentations etvalider des propositions comme celles présentées dans [99] et [100].
Conclusion Générale et Perspectives FuturesLa gestion de la qualité de service (QoS) est un concept important dans les réseaux
informatiques et les télécommunications, car elle est directement liée à l’expériencede l’utilisateur final, en particulier pour les applications en temps réel comme les fluxmultimédia (streaming vidéo, la ToIP, etc..). Ces applications génèrent une diversité deflux qui nécessitent des traitements différents pour chacun d’entre eux afin d’assurer leniveau de service exigé par le client. L’objectif de la mise en oeuvre de la QoS est degarantir ce niveau. Nous avons proposé dans cette thèse plusieurs approches prenanten charge la gestion de la QoS en utilisant le concept SDN, ce dernier représenteune nouvelle approche utilisée par les opérateurs de réseau afin de contrôler leurinfrastructure via un contrôleur central. Actuellement, le protocole OpenFlow est leplus utilisé entre le contrôleur et le commutateur pour échanger des informations réseau.Au cours des dernières années, le SDN est passé du domaine de la recherche pure àcelui de l’industrie. De nombreux fournisseurs ont publié leurs propres solutions SDNpour le public, ce qui indique que ce concept est entré dans l’étape de mise en œuvre.Dans notre travail de recherche, nous avons proposé et développé une architectureréseau qui a pour but de garantir la consistance des décisions à prendre dans un réseauSDN. Une stratégie d’acheminement des données avec la prise en charge de la QoSd’une façon consistante est donc mise en place de manière à éviter toute dégradationde la qualité des flux prioritaires (multimédia), tout en optimisant l’utilisation desressources. Nous avons proposé dans cette solution une stratégie de routage consistantedans les réseaux SDN prenant en charge l’acheminement des flux vidéo afin d’améliorerleur QoS/QoE ainsi que les flux moins critiques afin de maximiser au mieux leur débit.L’approche proposée a pour but d’avoir des décisions ainsi que des règles de tablesde flux cohérentes. Afin d’implémenter une telle stratégie, nous avons tout d’abord,supervisé l’état du réseau en temps réel, en utilisant les messages OpenFlow, puis nousavons proposé de réduire, dans la mesure du possible, la concentration des flux vidéoau niveau des liens afin de les protéger de la perte de paquets en cas de congestion touten améliorant leur QoE. Afin d’évaluer l’approche proposée, nous l’avons comparée àtrois autres approches existantes, celle basée sur l’OSPF, celle basée sur la disponibilitéde la bande passante ainsi qu’OpenQoS. Les résultats de la simulation ont montréque l’approche d’acheminement des paquets proposée, qui considère la concentrationdes flux prioritaires, le lissage du trafic ainsi que l’allocation dynamique des tempsde séjour des règles d’acheminement, améliore celles qui existent dans la littératurelorsque nous considérons à la fois, les flux vidéo et best effort. Nous avons également,proposé une nouvelle approche permettant de calculer précisément l’utilisation de la
4.5 Conclusion 89
bande passante tout en adaptant la fréquence de demandes des statistiques réseauxen fonction de l’activité des ports et des commutateurs pour réduire la surchargegénérée lors des opérations de supervision. Afin de valider cette solution, nous l’avonscomparée à Payless ainsi qu’à la méthode de supervision où le contrôleur demandedes informations réseaux (telles que les statistiques réseaux) d’une façon périodique.Les résultats obtenus ont montré l’efficacité de l’approche proposée où nous avonsobtenu une réduction du nombre de messages injectés dans le réseau pour des fins desupervision toute en gardant une certaine précision des mesures. Notre travail de thèseest loin d’être achevé. Pour cela, on envisage les perspectives futures suivantes:
✈ Comparer l’architecture ARCSDN proposée à d’autres benchmarks.
✈ Étendre cette architecture afin de prendre en charge d’autres métriques d’ache-minement des flux (latence, perte de paquets).
✈ Utiliser les techniques d’apprentissage approfondi (deep learning) dans les ap-proches proposées.
Nos publications
Communications dans des conférences Internationales avec co-mité de lecture (ISBN)
✍ HENNI DE, MEKKAKIA MZ, GHOMARI A. Control and marking data flows.PDPTA’13, International Conference on Parallel and Distributed ProcessingTechniques and Applications. ISBN: 1-60132-256-9, 1-60132-257-7 (1-60132-258-5). Las Vegas, USA, 2013.
✍ HENNI DE, GHOMARI A, HADJADJ-AOUL Y. Videoconferencing over Open-Flow Networks: An Optimization Framework for QoS Routing. IEEE InternationalConference on Computer and Information Technology ; Ubiquitous Computingand Communications ; Dependable, Autonomic and Secure Computing ; PervasiveIntelligence and Computing. ISBN: 978-1-5090-0154-5. Liverpool, UK, 2015. DOI:10.1109/CIT/IUCC/DASC/PICOM.2015.70
✍ HENNI DE, HADJADJ-AOUL Y, GHOMARI A. Probe-SDN: A smart monito-ring framework for SDN-based networks. Global Information Infrastructure andNetworking Symposium (GIIS). ISBN: 978-1-5090-3608-0. Porto, Portugal, 2016.DOI: 10.1109/GIIS.2016.7814940
Article de revue internationale avec comité de lecture. Indexedin: Thomson Reuters Science Citation (Impact Factor: 1.278)
✍ Henni, DE, Ghomari, A, Hadjadj-Aoul, Y. A consistent QoS routing strategy forvideo streaming services in SDN networks. Int J Commun Syst. 2020 ; 33:e4177.https://doi.org/10.1002/dac.4177
Bibliographie
[1] Cisco visual networking index: forecast and methodology, http://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-index-vni/complete-white-paper-c11-481360.html.
[2] P. Van Mieghem, F. A. Kuipers, T. Korkmaz, M. Krunz, M. Curado, E. Monteiro,X. Masip-Bruin, J. Sol´e-Pareta, and S. S´anchez-L´opez, Quality of service routing,in Proceedings of the Quality of Future Internet Services, Berlin, Heidelberg, pp.80–117, 2003.
[3] R. Braden, D. Clark, and S. Shenker, Integrated services in the internet architecture:An overview, Internet Engineering Task Force, United States, Tech. Rep. June 1994.http://www.ietf.org/rfc/rfc1633.txt
[4] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin. Resource ReSerVationProtocol (RSVP) – Version 1 Functional Specification. RFC 2205 (Proposed Stan-dard). Updated by RFCs 2750, 3936, 4495, 5946, 6437, 6780. Internet EngineeringTask Force, http://www.ietf.org/rfc/rfc2205.txt., 1997.
[5] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, An architecturefor differentiated service. United States, Tech. Rep. http://www.ietf.org/rfc/rfc2475.txt, 1998.
[6] D. Kreutz, F. M. V. Ramos, and P. E. Verissimo, C. E. Rothenberg, S. Azodolmolkyand S. Uhlig, Software-Defined Networking: A Comprehensive Survey. Proceedingsof the IEEE, 103(1), 14-76 (2015)
[7] Astuto B, Nunes A, Mendonca M, Nguyen X, Obraczka K, and Turletti T, ASurvey of Software-Defined Networking: Past, Present, and Future of ProgrammableNetworks. IEEE Communications Surveys & Tutorials journal, 16(3), 1617-1634,2014.
[9] Kyeongja L, Global QoS model in the ISP networks: DiffServ aware MPLS TrafficEngineering, Ecole Centrale de Lille, 2006.
[10] J. Vallet, Optimisation dynamique de réseaux IP/MPLS. Réseaux et télécommu-nications, INSA de Toulouse, 2015.
[11] HENNI DE, Contrôle et Marquage des Flux de Données, thèse de magister, InstitutNational des Télécommunication et de la Technologie de l’Information Oran. Juin2012.
[12] H. Krishna, Providing End-to-end Bandwidth Guarantees with OpenFlow, Masterof Science Thesis, 2016.
[13] Nichols K, Blake S, Baker F, Black D, Request for Comments: 2474, Definition ofthe Differentiated Services Field (DS Field)in the IPv4 and IPv6 Headers.https://tools.ietf.org/html/rfc2474, 1998.
[14] Abdellatif S, Juanole G. Cadre basé sur les réseaux de Petri pour l’analyse de laQualité de Service, Technical Report LAAS N° 02205, LAAS-CNRS, 2002.
[15] Abdellatif S, Juanole G. Proposition et évaluation par réseaux de Petri stochas-tiques d’une mise en oeuvre du traitement assuré DIFFSERV, 11ème Colloque Fran-cophone sur l’Ingénierie des Protocoles (CFIP’2005) pp.41-49, Bordeaux, France,Avril 2005.
[17] Sunshine C.A, Source routing in computer networks, ACM Digital Library, 1977.
[18] https://medium.com
[19] Fineberg. V, QoS Support in MPLS Networks: MPLS/Frame Relay Alliance WhitePaper, MPLS FORUM, May 2003.
[20] D. Awduche, J. Malcolm, J. Agogbua, M. O’Dell, J. McManus. Request forComments: 2702, Requirements for Traffic Engineering Over MPLS https://tools.ietf.org/html/rfc2702, 1999.
[21] Lepage F, Divoux T, Michaut F, Adaptation of control parameters based on QoSmonitoring, 17th International Symposium on Mathematical Theory of Networksand Systems, Kyoto, Japan, July, 2006.
[22] Mohammadi R, Javidan R, An adaptive type-2 fuzzy traffic engineering methodfor video surveillance systems over software defined networks, Springer MultimediaTools and Application Journal, 76(22), 23627-23642, 2016.
[23] Modestine J, Roth J, Video on demand for audio/video recording and communi-cation devices, Amazon Technologies, Inc, Application Number:16271404, 2019.
[24] Bouix E, Modèles de Flux et de Composants pour Applications MultimédiasDistribuées Dynamiquement Reconfigurables, Thèse de doctorat, Université de Pauet des Pays de l’Adour, 2007.
[25] R. Steinmetz, Human Perception of Jitter and Media Synchronization, IEEEJournal on Selected Areas in Communications, 14(1), 61-72, 1996.
[26] Dietz, Martin, Liljeryd, Lars, Kjorling, Kristofer, Kunz and Oliver, SpectralBand Replication, a Novel Approach in Audio Coding, Audio Engineering SocietyConvention 112 Book, 2002.
[27] J. Ohm, G. J. Sullivan, H. Schwarz, T. K. Tan and T. Wiegand, Comparison ofthe Coding Efficiency of Video Coding Standards—Including High Efficiency VideoCoding (HEVC), IEEE Transactions on Circuits and Systems for Video Technology,vol. 22, no. 12, pp. 1669-1684, Dec. 2012.
[28] P.V.Rangan, S.S.Kumar and S.Rajan, Continuity and Synchronization in MPEG,IEEE Journal on Selected Areas in Communications, 14(1), 52-60, 1996.
[29] C. Doerr, R. Gavrila, F. A. Kuipers, and P. Trimintzios, Good practices in resilientinternet interconnection, In: ENISA Report, 2012.
[30] https://www.cisco.com.
[31] https://www.juniper.com.
[32] B.J.Van Asten, N.L.Van Adrichem, and F.A.Kuipers, Scalability and resilience ofsoftware-defined networking: An overview, ArXiv preprint, ArXiv:1408.6760, 2014.
[33] https://www.opennetworking.org/
[34] S. Jain et al, B4: Experience with a globally-deployed software defined WAN. In:ACM SIGCOMM Computer Communication Review, 43(4), ACM, 3-14, 2013.
[35] Azevedo F.F, “A scalable architecture for openflow sdn controllers,” Master’sthesis, Tecnico Lisboa, 2015.
[38] Doria A, Salim J.H., Haas R, Khosravi H, Wang W, Dong L, Gopal R, and HalpernJ, Forwarding and Control Element Separation (ForCES) Protocol Specification,RFC 5810 (Proposed Standard), Available online: https://datatracker.ietf.org/doc/rfc5810/, 2010.
[39] Yang L, Dantu R, Anderson T, Gopal R, Forwarding and Control ElementSeparation (ForCES) Framework. RFC 3746 (Informational), Available online:https://datatracker.ietf.org/doc/rfc3746/, 2004.
[40] Hares S, Analysis of Comparisons between OpenFlow and ForCES. InternetDraft (Informational), 2012. Available online: https://datatracker.ietf.org/doc/draft-hares-forces-vs-openflow/
[41] Haleplidis E, Denazis S, Koufopavlou O, Halpern J, Salim J.H, Software-DefinedNetworking: Experimenting with the Control to Forwarding Plane Interface. InProceedings of the European Workshop on Software Defined Networks (EWSDN),pp. 91–96, Darmstadt, Germany, 25–26 October 2012.
[42] Quittek, et al, Requirements for IP Flow Information Export, Work in Progress,February 2003.
[43] Duffield, et al, A Framework for Passive Packet Measurement, Work in Progress,March 2003.
[44] Hung T, Path Computation Enhancement in SDN Networks, Master Thesis,Ryerson University, Toronto, Ontario, Canada, 2015.
[52] Azevedo F.F, “A scalable architecture for openflow sdn controllers,” Master’sthesis, Tecnico Lisboa, 2015.
[53] Karakus M and Durresi A, Quality of Service (QoS) in Software Defined Networking(SDN): A survey. Journal of Network and Computer Applications, 80, 200-218 (2017)
[54] Wallner R and Cannistra R, “An sdn approach: quality of service using big switch’sfloodlight open-source controller” in Proceedings of the Asia-Pacific AdvancedNetwork, vol. 35, Honolulu, Hawaii, 2013, pp. 14–19.
[55] https://onosproject.org, Open Networking Lab, Onos project.
[56] B. Sonkoly et al, On qos support to ofelia and openflow, Software Defined Networ-king (EWSDN), IEEE European Workshop, 109–113, 2012.
[57] K. Jeong, J. Kim, and Y. Kim, QoS-aware network operating system for softwaredefined networking with generalized OpenFlows, IEEE Network Operations andManagement Symposium (NOMS), 1167–1174, 2012.
[58] Lospoto G, Rimondini M, Vignoli BG et Di Battista G, Making MPLS VPNsManageablethrough the Adoption of SDN, IFIP/IEEE International Symposiumon Integrated Network Management (IM), Ottawa, ON, Canada, 2015
[59] Chang YK, Huang YT, Chen YT, An Efficient Label-Based Packet ForwardingScheme in Software Defined Networks, Tenth International Conference on Ubiquitousand Future Networks (ICUFN), Prague, Czech Republic, 2018.
[60] Husni E, Bramantyo A, Design and Implementation of MPLS SDN Control-ler Application based on OpenDaylight, International Symposium on Networks,Computers and Communications (ISNCC), Rome, Italy, 2019.
[61] Hasan H, Cosmas J, Zaharis Z, Lazaridis P, Khwandah S, Creating and Mana-ging Dynamic MPLS Tunnel by Using SDN Notion, International Conference onTelecommunications and Multimedia (TEMU), Heraklion, Greece, 2016.
[62] Eglimez HE and Murat Tekalp A, Distributed QoS Architectures for MultimediaStreaming Over Software Defined Networks, IEEE Transactions on Multimedia,16(6), 1597-1609, 2014.
[63] Cello M, Marchese M and Mongelli M, On the QoS Estimation in an OpenFlowNetwork: The Packet Loss Case, IEEE Communications Letters, 20(3), 554-557,2015.
[64] Eglimez HE, Dane ST, Bagci KT, Murat Tekalp A, OpenQoS: An OpenFlowController Design for Multimedia Delivery with End-to-End Quality of Serviceover Software-Defined Networks, In: Signal and Information Processing AssociationAnnual Summit Conference (APSIPA ASC), Asia-Pacific Hollywood CA USA, 3-6,2012.
[65] Eglimez HE, Murat TA and Civanlar S, An Optimization Framework for QoS-Enabled Adaptive Video Streaming Over OpenFlow Networks, IEEE transactionson Multimedia, 15(3), 711-715, 2013.
[66] Yu T, Wang K, Hsu Y, Adaptive Routing for Video Streaming with QoS Supportover SDN Networks, In: International Conference On Information Networking(ICOIN), Cambodia Cambodia, 12-14, 2015.
[67] Slavica T, Neeli P, Igor R, SDN control framework for QoS provisioning, In: 22ndTelecommunications Forum (TELFOR), Belgrade Serbia, 25-27, 2014.
[68] Huang H, Guo S, Li P, Ye B, Stojmenvic I, Joint Optimization of Rule Placementand Traffic Engineering for QoS Provisioning in Software Defined Network, IEEETransactions on Computers journal, 64(12), 3488 - 3499, 2015.
[69] Korhan H, Reza Shokri K, Cihat C, Muge S, Towards QoS-aware Routing forDASH Utilizing MPTCP over SDN. In: IEEE Conference On Network Function Vir-tualization and Software Defined Networks (NFV-SDN), Berlin Germany (November6-8 2017)
[70] W. Guck J, Van Bemten A, Reisslein M, Kellerer W, Unicast QoS RoutingAlgorithms for SDN: A Comprehensive Survey and Performance Evaluation, IEEECommunications Surveys & Tutorials journal, 20(1), 388-415 (2018)
[71] Karakus M and Durresi A, Quality of Service (QoS) in Software Defined Networking(SDN): A survey. Journal of Network and Computer Applications, 80, 200-218 (2017)
[72] J. Moy, Request for Comments: 2328, OSPF Version 2, https://tools.ietf.org/html/rfc2328, 1998.
[73] Diyar J.H, Khirota. G.Y and Ibrahim.T.O, Getting traffic statistics from networkdevices in an SDN environment using OpenFlow, ITaS, 978-5-901158-28-9, 951-956,2015.
[74] Phillipa G, Navendu J and Nachiappan N, Understanding Network Failures in DataCenters: Measurement, Analysis, and Implications, ACM SIGCOMM ComputerCommunication Review, 41(4), 350-361, 2011.
[75] Sherwood R, Gibb G, Yap K, and al, FlowVisor: A Network Virtualization Layer,Deutsche Telekom, Inc. R&D Lab, Stanford Nicira Networks, 2009.
[76] S. Rahman Chowdhury, Md. Faizul Bari, R. Ahmed, and Raouf Boutaba, PayLess:A Low Cost Network Monitoring Framework for Software Defined Networks, IEEENetwork Operations and Management Symposium, May 2014.
[77] Hamad DJ, Yalda KG, Okumus IT, Getting traffic statistics from network devicesin an SDN environment using OpenFlow, ITaS Journal, 2015.
[78] Tootoonchian A, Ghobadi M, Ganjali Y, OpenTM: Traffic Matrix Estimator forOpenFlow Networks, Springer Link, 2010.
[79] Yu C, Lumezanu C, Zhang Y, Singh V, Jiang G, Madhyastha H.V, FlowSense:Monitoring Network Utilization with Zero Measurement Cost, Springer Link, 2013.
[80] Van A, Niels L.M, Doerr C, Kuipers F.A, OpenNetMon: Network Monitoring inOpenFlow Software-Defined Networks, IEEE Network Operations and ManagementSymposium (NOMS), 2014.
[81] https://github.com/noxrepo/pox.
[82] Chowdhury.R.S, Faizul Bari. M, Ahmed. R and Boutaba. R,PayLess: A Low CostNetwork Monitoring Framework for Software Defined Network, IEEE, 1-9, 2014.
[83] Van. A, Niels. L.M, Doerr. C, and Kuipers. F.A,OpenNetMon: Network Monitoringin OpenFlow Software-Defined Networks, IEEE, 1-8, 2014.
[84] Yu. C, Lumezanu. C, Zhang. Y, Singh. V, Jiang. G, and Madhyastha.H.V, Flow-Sense: Monitoring Network Utilization with Zero Measurement Cost, SpringerLink,31-41, 2013.
[85] Henni DE, Hadjadj-Aoul Y and Ghomari A, Probe-SDN: a smart monitoringframework for SDN-based networks, In: Global Information Infrastructure andNetworking Symposium (GIIS), Porto, Portugal, 2016.
[86] Perešíni P, Kuzniar M, Vasić N, Canini M and Kostiu D, Consistent PacketProcessing for Openflow. In: The Second ACM SIGCOMM Workshop on HotTopics in Software Defined Networking, Hong Kong China, 2013.
[87] Astuto B, Nunes A, Mendonca M, Nguyen X, Obraczka K, and Turletti T, ASurvey of Software-Defined Networking: Past, Present, and Future of ProgrammableNetworks. IEEE Communications Surveys & Tutorials journal, 16(3), 1617-1634,2014.
[88] Slim F, Guillemin F, Gravey A, Hadjadj-Aoul Y, Towards a Dynamic AdaptivePlacement of Virtual Network Functions under ONAP. In: IEEE Conference OnNetwork Function Virtualization and Software Defined Networks (NFV-SDN),Berlin, Germany, 2017.
[89] Frost V and Melamed B, Traffic modeling for telecommunications networks. IEEECommunications Magazine, 32(3), 70-81, 1994.
[90] Waleed A. Mahmoud and Dheyaa J. Kadhim. ”A Proposal Algorithm to SolveDelay Constraint Least Cost Optimization Problem ”. Journal of Engineering.
[91] H. Schulzrinne, R. Frederick, V. Jacobson, Request for Comments: 3550, RTP: ATransport Protocol for Real-Time Applications https://tools.ietf.org/html/rfc3550,2003.
[92] Lantz B, Heller B and McKeown N, A network in a laptop: Rapid Prototyping forSoftware-Defined Networks. In: Hotnets-IX Proceedings of the 9th ACM SIGCOMMWorkshop on Hot Topics in Networks, Monterey California (October 20-21 2010).
[97] Singh K, Hadjadj-Aoul Y, Rubino G, Quality of Experience estimation for adaptiveHTTP/TCP video streaming using H.264/AVC, 9th Annual IEEE ConsumerCommunications and Networking Conference - Multimedia and EntertainmentNetworking and Services, CCNC, Las Vegas NV USA, 2012.
[98] http://www.grid.unina.it/software/ITG/
[99] Henni DE, Ghomari A, Hadjadj-Aoul Y, Videoconferencing over OpenFlow Net-works: An Optimization Framework for QoS Routing, In: Communication andInformation Technology (CIT) Conference, Liverpool UK, 2015.
[100] Henni DE, Ghomari A, Hadjadj-Aoul Y, A consistent QoS routing strategy forvideo streaming services in SDN networks. International Journal of CommunicationSystems. 10.1002/dac.4177. 2019.
[101] Yen JY. Finding the k shortest loopless paths in a network.Manag Sci.1971 ;17:712–716
