La gestion de l’attribut SLA

Au niveau des nœuds de transfert

La gestion des messages du sous-type SLA de l’attribut QoS se fait selon trois situations relatives au nœud BGP :

— Quand le nœud BGP est capable de traiter l’attribut QoS : si un nœud BGP est capable de traiter l’attribut QoS , il peut éventuellement traiter le message. Si le SLA annoncé a une liste de destinations ASs, il peut réduire la liste et ainsi compter les ASs de destination pour exclure ceux qui ne sont pas nécessaires dans d’autres annonces de mises à jour BGP. Si aucun AS de la liste des ASs destination ne figure dans le chemin de transmission, le nœud BGP doit supprimer les sous-type SLA

de l’attribut QoS, le reste du contenu de l’attribut peut être transféré. Alors, s’il n’y a pas d’autres sous-types dans l’attribut QoS, alors, le nœud doit supprimer l’ensemble de l’attribut. Si le bit de poids fort dans le flag de l’attribut QoS est mis à 1, alors l’ensemble du message de mise à jour BGP doit être supprimé s’il ne reste pas de destinations dans la liste à annoncer.

— Quand le nœud BGP n’est pas capable de traiter l’attribut QoS : si le nœud BGP

n’est pas capable de traiter l’attribut QoS , alors il doit transmettre le message de l’attribut sans le modifier.

— Quand le nœud est agrégateur : il est recommandé de ne pas agréger les préfixes

de deux ou plusieurs messages de mise à jour BGP, lorsque les messages originaux contiennent un attribut QoS avec un sous-type SLA. Si l’agrégateur doit les agréger, alors il doit copier l’ensemble des paramètres du sous-type SLA dans le nouveau message de mise à jour BGP agrégé.

Au niveau du récepteur

Si le noeud récepteur reçoit une annonce de SLA qui a le même id et le même AS source que des annonces précédentes, alors il doit, d’abord invalider les paramètres SLA annoncés précédemment, avant d’installer la nouvelle mise à jour. Aussi, si le champ « Traffic Class » de la nouvelle mise à jour SLA annoncée est non nul, alors le nouveau SLA annoncé doit être installé. Ensuite, si le flag de l’attribut Qos inclut dans le message de mise à jour indique que ce dernier doit être supprimé, alors le récepteur doit supprimer le message seulement s’il est le dernier récepteur indiqué dans le chemin.

Pour conclure, on peut noter que la solution propose un nouveau mécanisme intéressant pour échanger les SLA entre les différents domaines, ce qui peut aider à garantir la QoS en inter-domaines. Cependant, d’autres points doivent être discutés, notamment la garantie et la négociation des SLAs, également la solution ne présente pas une approche pour assurer la sécurité des échanges de SLA pour permettre de garantir la QoS aux trafics qui traversent plusieurs domaines.

3.4 Conclusion

Dans ce chapitre, nous avons donné une vue d’ensemble sur les travaux de recherches qui ont traité le problème d’assurer la QoS, pour les trafics clients qui traversent plusieurs domaines ou AS. L’étude que nous avons accomplie a donné lieu a une publication dans « Research Journal of Applied Sciences, Engineering and Technology » [9]. D’après cette étude, les solutions présentées dans ces différents travaux peuvent être classées en deux catégories.

La première catégorie regroupe les solutions analytiques qui reposent sur des modéli- sations analytiques et des algorithmes de calcul de chemins. Comme exemple de ces so- lutions, nous avons présenté l’approche de routage fiable avec des garanties de QoS pour

les réseaux multi-domaines, l’approche hybride pour le calcul de chemins inter-domaines multi-contraintes et une nouvelle méthode pour le calcul de chemin multi- contraintes optimal en explorant plusieurs routes inter-domaines.

La deuxième catégorie englobe les solutions techniques qui sont les solutions qui pro- posent des extensions de technologies et de protocoles dèjà fonctionnels, ou bien celles qui introduisent de nouvelles techniques pour assurer la QoS dans des réseaux multi-domaines. Parmi ces solutions, nous avons présenté une extension de l’ingénierie de trafic de MPLS dans le cas inter-domaines, et une amélioration du protocole BGP présentée dans [98], nous avons, également, présenté d’autres solutions qui introduisent de nouveaux principes, comme l’approche du projet MESCAL décrite dans [46], et le nouveau mécanisme pour l’échange de SLA présenté dans [85].

Cependant, chacune des solutions que nous avons citées présente une limite soit concer- nant la complexité des calculs et la nécessité de réservation de ressources pour les solutions analytiques, soit concernant d’autres aspects comme l’absence de sécurité ou l’efficacité à grande échelle pour les solutions techniques. Pour cela, jusqu’à présent aucune solution n’a été standardisée et implémentée pour garantir la QoS en inter-domaines notamment dans Internet et les recherches continuent encore afin de résoudre ce problème. Dans ce cadre, nous avons choisi de participer à ces efforts en proposant un nouveau mécanisme pour la gestion de QoS en inter-domaines qu’on va présenter dans le chapitre suivant.

Mécanisme pour la gestion de la QoS

en inter-domaines

4.1 Introduction

Comme nous l’avons mentionné dans les chapitres précédents, l’utilisation d’Internet est en évolution permanente, le trafic Internet est devenu de plus en plus diversifié, et chaque type de trafic exige ses propres contraintes de QoS. Différents problèmes se posent avec cette diversité. Un des principaux problèmes est la difficulté d’assurer la QoS pour les trafics qui traversent plusieurs domaines ou systèmes autonomes (ASs). Pour résoudre ce problème plusieurs solutions ont été proposées, notamment celles que nous avons présenté dans le chapitre 2 ([88, 39, 28, 38, 35, 98, 46, 85]). Cependant, ces solutions inter-domaines ne permettent pas de fournir aux trafics clients la même qualité de service requise offerte par le domaine source. Dans ce cadre, nous présentons dans ce chapitre un nouveau mécanisme, appelé QoS-CMS, pour assurer la QoS dans un environnement inter-domaines. Cette proposition a donné lieu a une publication à « The Inernational Conference on NETworked Systems (NETYS) 2013, Springer’s LNCS 7853 » [10].

Notre nouveau mécanisme se base sur l’introduction dans chaque AS d’un serveur nommé serveur CM (Class Manager) qui va permettre aux différents domaines d’échanger toutes les informations relatives à la QoS offerte à leurs trafics, et va ainsi assurer une certaine continuité des services QoS offerts aux trafics clients qui traversent plusieurs AS. Les serveurs CM récoltent les différents informations sur la QoS définie en intra-domaine des différents routeurs du domaine, et ensuite stockent ces informations dans des tables nommées tables CT (Class Table), les différents champs constituants la table CT seront décrits dans ce chapitre. En outre, la communication entre les serveurs CM voisins est assurée via un ensemble de messages, les formats des différents types de ces messages seront présentés dans le reste de ce chapitre. Nous présentons également dans ce chapitre, une proposition qui permet d’assurer la sécurité des communications, d’une part, entre les routeurs du domaine et le serveur CM, et d’autre part, entre les serveurs CM voisins. Dans ce chapitre, nous décrivons tout d’abord le principe de fonctionnement de notre mécanisme, ainsi que les principales phases de son déroulement, et les propositions intro-

duites afin de sécuriser les échanges entre les différentes entités de notre mécanisme.