• Aucun résultat trouvé

La configuration des paramètres de QoS

Concernant la configuration de la QoS dans les deux scénarios et pour tous les AS, nous avons comme auparavant utilisé le modèle DiffServ pour mettre en œuvre la QoS intra-domaine. Ensuite, nous avons créé deux classes de service pour classer les deux types de trafic que nous générons : la classe « Gold » pour le trafic voix marqué avec le DSCP 46 qui correspond au PHB EF, et la classe « Bronze » pour le trafic de données marqué avec le DSCP 31 qui correspond au PHB AF33. Cependant, pour le premier scénario dans chaque AS nous attribuons aux classes de services des paramètres de QoS différents. Ainsi, nous modifions le CIR et la taille limite des files d’attente (QL), comme présentés dans le tableau 5.5.

Pour le deuxième scénario, nous avons créé quatre procédures nommées {Class_manager1} dans l’AS1, {Class_manager2} dans l’AS2, {Class_manager3} dans l’AS3 et {Class_manager4}

Figure 5.21 – Les variations du taux de pertes en fonction pour le trafic voix pour l’étude n°4

dans l’AS4, qui permettent d’assurer les fonctionnalités du serveur CM décrit dans le mé- canisme QoS-CMS. L’exécution de ces procédures nous permet de créer dans chaque AS deux classes de service qui ont les mêmes paramètres de QoS que celles crées dans l’AS1.

5.5.3 Les résultats de la simulation

Après l’exécution de la simulation des scénarios présentés ci-dessus, nous avons obtenu les résultats représentés sur les courbes suivantes qui illustrent la comparaison de la va- riation du taux de perte et du délai pour chaque type de trafic entre le premier scénario et le second.

5.5.3.1 Le trafic voix

La figure 5.21 représente la variation du taux de perte de paquets en fonction du temps pour le trafic voix.

En comparant les deux courbes, on remarque que le taux de perte dans le deuxième scénario, c-à-d après la mise en œuvre du mécanisme ne dépasse pas 0,1%, alors qu’il était égal à environ 20% dans la premier scénario, ce qui correspond à une amélioration d’environ 100%.

Concernant le délai, la figure 5.22 montre la variation en fonction du temps du délai pour le trafic voix.

Comme présenté sur la figure, les valeurs du délai dans le deuxième scénario sont plus faibles que celles dans le premier. En effet, pour le premier scénario le délai commence à 28 ms et augmente pour atteindre 61 ms à la fin de la simulation, tandis que dans le deuxième scénario il varie entre 10 ms et 22 ms. Ainsi, l’implémentation du mécanisme

Figure 5.22 – Les variations du délai en fonction pour le trafic voix pour l’étude n°4

permet d’améliorer le délai de presque 64%.

5.5.3.2 Le trafic de données

La figure 5.23 présente les variations du taux de perte dans les deux scénarios de simulation pour le trafic de données.

En analysant les deux courbes, on note que pour le premier scénario après la seconde 4 (le début de la transmission des données de trafic) la valeur du taux de perte s’élève à presque 50%. Cependant, pour le scénario 2, le taux de perte est stable autour de 10%, ce qui est très faible par rapport au scénario 1.

Concernant le délai, figure 5.24 représente la variation en fonction du temps des valeurs du délai pour le trafic de données.

Comme on peut voir sur la figure, les valeurs du délai du deuxième scénario sont inférieures à celles du premier scénario. En effet, pour le premier scénario, le délai est autour de 50 ms, alors que dans le deuxième scénario, il ne dépasse pas 25 ms. Ainsi, l’implémentation du mécanisme permet d’améliorer le délai de presque 50%.

En observant les résultats obtenus, on remarque que l’amélioration du taux de perte et du délai après la mise en œuvre du mécanisme dans l’étude n°4 cas est beaucoup plus importante que dans les études précédentes. Cela signifie que la mise en œuvre du mé- canisme dans un environnement avec plusieurs ASs, permet une amélioration importante des performances du réseau. Ceci est dû au fait que la QoS offerte au trafic se dégrade après chaque passage à un AS différent, et donc puisque le nombre d’AS dans cette étude est plus grand que dans les autres études, alors la dégradation est plus importante et l’amélioration assurée par le mécanisme QoS-CMS est également plus importante. Ainsi, l’efficacité du mécanisme QoS-CMS et l’intérêt de son déploiement deviennent plus inté-

Figure 5.23 – Les variations du taux de pertes en fonction pour le trafic de Données pour l’étude n°4

ressantes dans un tel environnement.

5.6 Conclusion

Dans ce chapitre, nous avons présenté différentes études de cas que nous avons mis en œuvre afin d’évaluer les performances du mécanisme QoS-CMS. Ainsi, nous avons varié les configurations de QoS, les types de trafic et le nombre d’ASs, et relevé à chaque fois les indices de performances du réseau. Les résultats des simulations dans les quatre études de cas ont prouvé l’efficacité de notre mécanisme, et l’importante amélioration qu’il peut apporter quel que soit le contexte, la configuration, ou le type de trafic considéré.

Intégration du QoS-CMS dans le

protocole BGP et l’architecture SDN

6.1 Introduction

Les résultats des simulations présentés dans le chapitre précédent montrent l’intérêt d’implémenter notre mécanisme QoS-CMS pour assurer la QoS inter-domaines. Ceci nous a poussé à réfléchir comment peut-on l’intégrer et l’implémenter dans les réseaux actuels et futurs. Ainsi, dans ce chapitre nous présentons dans une première partie comment le mécanisme QoS-CMS pourra être intégré dans le protocole BGP, et par la suite comment on pourra l’adapter pour fonctionner au sein d’un réseau SDN.