HAL Id: tel-00340507
https://tel.archives-ouvertes.fr/tel-00340507
Submitted on 21 Nov 2008
HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.
signalisation pour la garantie de qualité de service dans l’Internet multi-domaine, multi-technologie et
multi-service
Stelian-Florin Racaru
To cite this version:
Stelian-Florin Racaru. Conception et validation d’une architecture de signalisation pour la garantie de qualité de service dans l’Internet multi-domaine, multi-technologie et multi-service. Réseaux et télécommunications [cs.NI]. INSA de Toulouse, 2008. Français. �tel-00340507�
T T H H È È S S E E
En vue de l'obtention du
DO D OC C TO T OR RA AT T DE D E L L’ ’U U NI N IV VE E RS R SI IT TÉ É D DE E T T OU O UL L OU O U SE S E
Délivré parl'Institut National des Sciences Appliquées Toulouse Discipline ou spécialité :Informatique et Télécommunications
JURY
Christian FRABOUL - Président Francis LEPAGE - Rapporteur Abdelhamid MELLOUK - Rapporteur
Olivier DUGEON - Examinateur Michel DIAZ - Examinateur Christophe CHASSOT -Examinateur
Laurent BARESSE - Invité
Ecole doctorale :Mathématiques Informatique Télécommunication de Toulouse Unité de recherche : Laboratoire d’Analyse et d’Architecture des Systèmes
Directeur(s) de Thèse :Michel DIAZ et Christophe CHASSOT Présentée et soutenue par Stelian Florin RACARU
Le 14 octobre 2008
Titre :
Conception et validation d'une architecture de signalisation pour la garantie de qualité de service dans l'Internet
multi-domaine, multi-technologie et multi-service
A tous qui ont contribué à l'aboutissement de ces travaux
To all those who made this work possible
Ce n'est pas la fin.
Ce n'est même pas le commencement de la fin Mais, c'est peut-être la fin du commencement.
Winston Churchill
Les travaux présentés dans ce mémoire ont été effectués au Laboratoire d'Analyse et d'Architecture des Systèmes du Centre National de la Recherche Scientifique (LAAS- CNRS), dirigé successivement depuis mon entrée par Messieurs Malik GHALLAB et Raja CHATILA, à qui je souhaite exprimer mes remerciements pour leur accueil.
Je tiens à remercier également Monsieur Jean-Pierre COURTIAT et Monsieur François VERNADAT responsables du groupe Outils et Logiciels pour la Communication (OLC), pour m’avoir permis de réaliser ces travaux au sein de leur équipe.
Je suis également très reconnaissant pour le temps accordé par l'ensemble des membres du jury de ma thèse et pour leurs remarques constructives :
• Monsieur Christian FRABOUL, Professeur à l’Institut National Polytechnique de Toulouse
• Monsieur Francis LEPAGE, Professeur à l'Université Henri Poincaré, Nancy
• Abdelhamid MELLOUK, Maître des Conférences à l'Université de Paris 12
• Olivier DUGEON, Chercheur Expert Senior à France Telecom R&D, Lannion
• Michel DIAZ, Directeur de Recherche au LAAS-CNRS, Toulouse
• Christophe CHASSOT, Professeur à l’Institut National des Sciences Appliquées, Toulouse
• Laurent BARESSE, Chef de projet – Architecte, à AKKA Informatique & Systèmes Sud, Toulouse
Je tiens également à témoigner toute ma gratitude à Messieurs Francis LEPAGE et Abdelhamid MELLOUK qui m’ont fait l’honneur d’accepter la tâche de rapporter sur ces travaux. Je remercie tout particulièrement à Christian FRABOUL, président du jury, pour ses commentaires ainsi que son soutien pendant les années passées à l’ENSEEIHT en tant qu’élève ingénieur au Département des Télécommunications et Réseaux et Mastère Recherche (DEA Réseaux et Télécommunications).
J’exprime ma profonde reconnaissance à Monsieur Michel DIAZ, qui a dirigé cette thèse, pour m’avoir fait profiter de son expérience, pour ses conseils avisés et les réflexions que nous avons pu mener tout au long de ces années. Je lui suis également reconnaissant pour la confiance qu’il m’a témoignée et l’apport tant sur le plan professionnel que sur le plan personnel.
Je souhaite aussi vivement remercier Christophe CHASSOT, codirecteur de thèse, pour ses remarques pertinentes sur mon travail, ses nombreux encouragements et sa relecture de ce mémoire. Je lui remercie également de m’avoir offert l’opportunité de découvrir le monde de la recherche à travers mon stage de DEA.
Les travaux développés dans cette thèse ont effectués essentiellement dans le cadre du projet
européen EuQoS (End-to-end Quality of Service support over heterogeneous networks). Je
tiens à remercier l’ensemble des acteurs du projet, avec qui j’ai réellement apprécié
CORDEIRO), Telefonica I&D (Marian CALLEJO), Silogic-groupe AKKA (Laurent BARESSE et Jean-Philippe DARMET), l’Université de Varsovie (Jarek SLIWINSKI) et l’Université de Bern (Marc BROGLE). Je remercie également Roberto WILIRICH, chercheur à l’Université Fédérale de Santa Catarina (Brésil) et Mathieu GINESTE (doctorant au LAAS-CNRS) pour leur support dans la réalisation des expérimentations du projet.
Je remercie vivement les personnes qui ont contribué directement à l’aboutissement de ces travaux. Tout d’abord, je tiens à remercier Guillaume AURIOL (ancien doctorant du groupe OLC du LAAS-CNRS), pour ses conseils et son support au début de mon séjour au LAAS.
Je remercie Philippe OWEZARSKI pour son soutien, en particulier pour la mise en place de la plate-forme d’expérimentation utilisée pour la validation des propositions apportées par cette thèse. Je tiens à remercier Nicolas Van WAMBEKE (aussi appelé Agent 19.17) et Eraldo DA SILVA pour les travaux menés conjointement. Je remercie également les stagiaires que j’ai co-encadrés avec mes directeurs de thèse : Frederic FOK et Vincent GONIN.
Mes remerciements vont également à tous les membres du groupe OLC, permanents, doctorants et stagiaires pour leur accueil et bonne humeur. En particulier, je remercie mes collègues avec qui j’ai partagé un bureau (Khalil, André, Guillaume, Francesco, Nicolas, Ion, Silvia, Najla) pour l’ambiance amicale et les discutions eues (d’un niveau intellectuel élevé
« en fait ») et dont un tableau blanc garde les traces. Merci également à la XB-Team (Fred, Baptiste, Pascal, Thierry, Momo, Ihsane) pour les moments de détente partagés dans les après-midi de travail, à Slim, Karim, Momo, Jorge, François pour les activités sportives effectuées ensemble.
Mes remerciements s’adressent également à Gina pour sa disponibilité, sa gentillesse et son aide précieux dans les préparatifs des tâches administratives.
Je remercie également les doctorants et autres membres des différents services techniques et administratifs (en particulier le service Informatique et Instrumentation) du LAAS-CNRS et les collègues de l’ENSICA qui m’ont permis de travailler dans d’excellentes conditions. Je salue en particulier les membres de l’équipe de football du LAAS-CNRS et les amis du groupe Tolérance aux fautes et Sûreté de Fonctionnement informatique. Merci encore à tous ceux qui m’ont accompagné et soutenu au cours de ces dernières années : ma famille, mes nombreux amis de Toulouse et d’ailleurs.
Enfin je pense très fort à une personne qui m’est très chère et qui a partagé avec moi ces
dernières années étant mon soutien le plus efficace, Ana. Je ne lui remercierai jamais assez
pour son soutien sans faille, sa patience et sa compréhension.
Table de matières
INTRODUCTION ... XVII
C
ONTEXTE...
XVIIP
ROBLEMATIQUE...
XVIIC
ONTRIBUTIONS...
XVIIIP
LAN DU MEMOIRE...
XIX1. ETAT DE L’ART SUR LA GESTION DE LA QUALITE DE
SERVICE DANS LES RESEAUX DE NOUVELLE GENERATION ... 1
1.1. C
ONCEPTS FONDAMENTAUX SUR LAQ
OS ... 1
1.1.1. Evolutions de l’Internet... 1
1.1.2. Qualité de service (QoS) : définitions et terminologie ... 2
1.1.3. Paramètres et métriques de QoS... 3
1.2. C
ARACTERISTIQUES DE L’I
NTERNET MULTI-
DOMAINE... 5
1.2.1. Introduction... 5
1.2.2. Notion de domaine et de système autonome (AS) ... 5
1.2.3. Technologies sous-jacentes ... 5
1.2.4. Le routage dans l’Internet ... 6
1.2.5. Les protocoles de Transport dans l’Internet ... 9
1.3. M
ODELES PRECURSEURS POUR LA GARANTIE DE LAQ
OS ... 10
1.3.1. IntServ ... 10
1.3.2. DiffServ ... 12
1.4. P
ROVISIONNEMENT ET CONTROLE D’
ADMISSION POUR LAQ
OS ... 16
1.4.1. Provisionnement des ressources pour la QoS ... 16
1.4.2. Contrôle d’admission ... 18
1.5. S
IGNALISATION POUR LAQ
OS ... 20
1.5.1. Introduction... 20
1.5.2. Protocoles de signalisation de niveau applicatif ... 21
1.5.3. Protocoles de signalisation de niveau réseau ... 22
1.5.4. Signalisation générique – NSIS ... 25
1.6.1. Les réseaux de nouvelle génération (NGN) ... 28
1.6.2. Projets de recherche ... 30
1.7. C
ONCLUSION... 33
2. CONTRIBUTIONS A LA SIGNALISATION POUR LA QUALITE DE SERVICE DANS L’INTERNET MULTI-DOMAINE ... 37
2.1. C
ONTEXTE DES TRAVAUX... 37
2.1.1. Définitions ... 38
2.1.2. Internet multi-domaine à base de Bandwidth Broker ... 39
2.1.3. Représentation de la topologie sous-jacente ... 39
2.1.4. Contrôle d’admission ... 41
2.2. S
IGNALISATION DECOUPLEE DU CHEMIN DE DONNEES... 42
2.2.1. Concepts généraux ... 42
2.2.2. Découverte du prochain Bandwidth Broker ... 43
2.2.3. Spécification et modélisation UML ... 44
2.2.4. Prise en compte des domaines surprovisionnés... 53
2.3. S
ELECTION DYNAMIQUE DES CLASSES DE SERVICES... 54
2.3.1. Introduction... 54
2.3.2. Formalisation ... 55
2.3.3. Exemple ... 57
2.3.4. Signalisation associée ... 58
2.3.5. Evaluation des bénéfices du provisionnement dynamique ... 60
2.3.6. Conclusion ... 63
2.4. H
YP
ATH(H
YBRID ON-
PATH OFF-
PATH FOR END-
TO-
END SIGNALING ACROSSNSIS
AND NON-NSIS
DOMAINS) ... 63
2.4.1. Introduction... 63
2.4.2. Proposition HyPath ... 65
2.4.3. Fonctionnement dans les domaines NSIS ... 66
2.4.4. Extension pour l’intégration des domaines non-NSIS ... 67
2.4.5. Prise en compte de domaines surprovisionnés ... 68
2.4.6. Conclusions ... 68
2.5. S
IGNALISATION ET MOBILITE... 69
2.5.1. Contexte de mobilité considéré ... 69
2.5.2. Scénarios de mobilité examinés ... 69
2.6. C
ONCLUSIONS... 73
3.1. A
RCHITECTUREE
UQ
OS
POUR LA GARANTIE DEQ
OS ... 75
3.1.1. Présentation du projet... 75
3.1.2. Architecture générale... 77
3.1.3. Provisionnement ... 83
3.1.4. Contrôle d’admission (CAC) dans EuQoS ... 84
3.1.5. Principe de signalisation dans EuQoS ... 86
3.2. D
EFINITION DES INTERFACES ENTRE LES COMPOSANTESE
UQ
OS ... 87
3.2.1. Concepts généraux ... 87
3.2.2. Description des interfaces entre les modules EuQoS ... 88
3.3. L
A SIGNALISATION DANSE
UQ
OS ... 94
3.3.1. Architecture du Resource Manager (RM)... 94
3.3.2. CallController ... 95
3.3.3. Spécification de la signalisation ... 98
3.4. C
ONCLUSIONS... 102
4. SIMULATIONS, DEPLOIEMENT ET EXPERIMENTATIONS .... 105
4.1. S
IMULATIONS... 105
4.1.1. Le logiciel Tau ... 105
4.1.2. Spécification ... 106
4.1.3. Résultats ... 108
4.1.4. Conclusions ... 110
4.2. I
MPLEMENTATION... 111
4.2.1. Introduction... 111
4.2.2. CallController ... 112
4.2.3. Format des PDUs ... 113
4.3. E
XPERIMENTATIONS... 117
4.3.1. Plate-forme LAAS ... 117
4.3.2. Plate-forme européenne du projet EuQoS ... 119
4.3.3. Tests fonctionnels ... 121
4.3.4. Tests de garantie de QoS ... 123
4.3.5. Tests de performance (avec NSIS) ... 125
4.3.6. Test de performance (sans NSIS) ... 128
4.3.7. Tests de performance CallController seul ... 130
4.3.8. Conclusion sur l’ensemble des tests ... 133
CONCLUSION GENERALE ... 135
I. B
ILAN... 135
II. P
ERSPECTIVES... 136
BIBLIOGRAPHIE ... 139
BIBLIOGRAPHIE DE L’AUTEUR ... 149
Contexte
Ces dernières années, les évolutions technologiques conjointes de l’informatique et des télécommunications ont conduit à une modification profonde du paysage de la communication sur Internet :
• Les types de trafic et d’applications distribuées ont évolué passant d’applications textuelles de type transfert de fichiers ou échange de mail entre utilisateurs et serveurs fixes, à des applications multimédia (audio, vidéo) temps-réel, distribuées, coopératives ou mobiles (voix sur IP, vidéo à la demande, visioconférence, jeux interactifs, etc.). Ces applications présentent de nouveaux besoins en qualités de service (QoS) exprimables notamment en termes de bande passante garantie ou de délai de transit borné.
• Parallèlement, l’Internet est devenu la solution d’interconnexion de toutes les technologies réseaux (fixes ou mobiles, à échelle locale ou grande distance), et sa gestion est désormais assurée par de nombreux opérateurs appliquant de façon indépendante des politiques de routage, de sécurité ou de gestion des ressources.
L’Internet apparaît donc aujourd’hui comme une interconnexion réseaux multiples qui s’appuient sur des technologies hétérogènes. Ces réseaux sont gérés dans le cadre de domaines indépendants vis à vis (en particulier) de la gestion de la qualité de service offerte sur les transferts des données de leurs clients.
Problématique
Conçu à la base pour des applications sans contraintes de débit ni de délai sur le transfert des données, le service offert par l’Internet (au niveau IP), connu sous le nom de best-effort, ne permet pas de prendre en compte la QoS requise par les nouvelles applications. Deux modèles précurseurs (IntServ et DiffServ) ont été proposés par l’IETF pour que de nouveaux services soient offerts.
Le modèle DiffServ, seul envisageable à grande échelle, laisse cependant ouverts deux problèmes importants, qu’il est nécessaire de résoudre pour offrir des garanties de QoS de bout en bout :
• le premier problème, qui concerne le provisionnement, est relatif au dimensionnement des ressources de chaque domaine, qu’il s’agit d’adapter aux besoins des clients potentiels.
• le second problème est relatif à la disponibilité des ressources sur le chemin de donnée ; sa solution nécessite qu’un contrôle d’admission (CAC) soit mis en place au sein de chaque domaine.
A l’échelle de plusieurs domaines, le provisionnement et le CAC sont plus difficiles à mettre en œuvre car :
• les domaines traversés par les données n’offrent pas les mêmes performances et le
provisionnement doit tenir compte des caractéristiques des services sur chaque
domaine ;
• le CAC doit être effectué sur chaque domaine et sur les liens inter-domaine pour assurer la disponibilité des ressources de bout en bout ;
• enfin, provisionnement et CAC nécessitent l’échange de données de contrôle tout au long du chemin emprunté par les données. Il est donc nécessaire de définir les protocoles d’échanges de ces données définissant ce qu’on appelle la signalisation intra ou inter-domaines.
Contributions
Les travaux décrits dans ce mémoire s’inscrivent dans cette problématique de la gestion de la QoS dans l’Internet multi-domaine et multi-technologie. Ils visent à répondre au besoin de maîtrise de la QoS, incluant la signalisation inter-domaine, qui couplée au provisionnement et au CAC permettent d’offrir des garanties de QoS de bout en bout aux nouvelles applications distribuées dans l’Internet.
Nous détaillons la conception, la spécification, l’implémentation et la validation d’une architecture de signalisation pour la QoS dans un environnement Internet multi-domaine hétérogène. Plus précisément, nos contributions portent sur :
• la proposition d’une architecture de signalisation inter-domaine qui a pour objectif d’installer et maitriser une QoS de bout-en-bout ; ;
• la proposition d’un modèle de provisionnement à la demande basé sur la signalisation précédente qui vise la découverte et la sélection automatique des services disponibles le long du chemin de données ;
• une étude pour l’extension de notre signalisation dans un environnement mobile ;
• l’adaptation et l’intégration de nos propositions dans le cadre défini par le groupe NSIS (Next Step In Signaling) de l’IETF;
• l’intégration de nos propositions dans l’architecture générale proposée dans le cadre du projet européen EuQoS ;
• l’implémentation et le déploiement de nos propositions sur des plateformes réelles, en particulier à échelle européenne dans le cadre du projet EuQoS ;
• des expérimentations et des mesures de performances visant à valider le bien fondé de nos propositions.
La solution soutenue repose sur l’hypothèse de l’existence de plusieurs classes de services (au sens DiffServ) en plus du service best-effort traditionnel sur chaque domaine. A l’intérieur de chaque domaine, les ressources sont supposées être gérées de manière indépendante et l’administration est déléguée à une entité logique, qui possède la connaissance des politiques internes, de la disponibilité des ressources, et qui réalise un contrôle d’admission basé sur ces politiques.
La maitrise de la QoS de bout en bout s’appuie sur un protocole de signalisation inter-
domaine, laissant libre aux administrateurs le choix de l’implémentation d’une solution intra-
domaine. Par ailleurs, nous prenons en compte un principe fondamental des réseaux de
nouvelle génération, consistant en la séparation du plan de service (description des services
en termes de composants logiciels, de leur composition et de leur représentation) du plan de
contrôle (signalisation mise en place pour la gestion et la maintenance du réseau).
Plan du mémoire
Outre l’introduction, ce mémoire s’articule autour de quatre chapitres :
• Le chapitre 1 présente un état de l’art des propositions récentes qui visent à garantir une QoS dans l’Internet. Il donne un aperçu des difficultés liées à l’hétérogénéité d’un environnement multi-domaine. Nous introduisons les notions essentielles liées à la QoS ainsi que les perspectives des réseaux de nouvelle génération. Un état de l’art détaillé de la signalisation dans l’Internet est finalement fourni ainsi que le positionnement de nos travaux.
• Le chapitre 2 développe les contributions principales de cette thèse à savoir : une architecture de signalisation inter-domaine pour la QoS intégrée dans une architecture de communication, une proposition d’adaptation du protocole NSIS standardisé à l’IETF pour les domaines à QoS administrés par des entités spécifiques et une proposition de provisionnement dynamique des ressources qui repose sur la signalisation précédente.
• Dans le chapitre 3, nous présentons l’instanciation de notre proposition dans le cadre du projet européen EuQoS. Nous décrivons l’architecture générale du projet, l’implémentation des protocoles que nous avons effectuée, ainsi que leur intégration à cette architecture.
• Le chapitre 4 décrit les tests et les mesures de validation. Ces tests ont été réalisés d’une part sur une plate-forme d’expérimentation du LAAS-CNRS, et d’autre part sur un réseau de test européen (via le réseau GEANT) impliquant les différents partenaires du projet EuQoS.
• En conclusion générale, nous résumons les contributions de nos travaux et nous
dégageons les perspectives de cette thèse.
1. Etat de l’art sur la gestion de la qualité de service dans les réseaux de nouvelle génération
Dans un premier temps, ce chapitre introduit les concepts généraux liés à la qualité de service (section 1.1). Nous présentons ensuite les caractéristiques relatives à la technologie sous jacente, au routage et au niveau transport de l’Internet (1.2). La section 1.3 présente les modèles précurseurs conçus pour offrir des garanties de QoS, à savoir IntServ et DiffServ. Par la suite (sections 1.4 et 1.5), nous décrivons les mécanismes associés à la QoS : le provisionnement des ressources, le contrôle d’admission, en détaillant la signalisation. La section 1.6 illustre les propositions d’architectures conceptuelles pour la mise en place de la QoS dans les réseaux de nouvelle génération ainsi que les projets de recherche internationaux menés ces dernières années.
1.1. Concepts fondamentaux sur la QoS
1.1.1. Evolutions de l’Internet
Ces dernières années, les évolutions conjointes dans les domaines de l’informatique et des télécommunications ont conduit à une transformation substantielle du monde des communications et par conséquence de l’Internet.
Le trafic Internet a profondément changé, passant de données essentiellement textuelles à des données qui manipulent plusieurs médias (texte, audio, vidéo). Ainsi, de nouveaux types d’applications, à la fois multimédia, multi utilisateurs et coopératives se sont développés. Ces applications présentent des caractéristiques et des contraintes nouvelles et de ce fait, elles demandent des services de communication autres que ceux offerts par l’Internet actuel.
Comparativement aux applications classiques, ces nouvelles applications présentent des besoins exprimables en termes de délai borné ou de bande passante garantie, mais peuvent parfois tolérer des pertes de part la nature continue des média qu’elles manipulent. En quelques années, l’Internet, multi-technologie et multi-domaine (au sens opérateur du terme), est devenu une plate-forme incontournable pour le transfert de l’information. A titre illustratif, la Figure 1 montre l’évolution de l’Internet dans la dernière décennie, en nombre d’utilisateurs et en quantité du trafic véhiculé.
Figure 1 : Croissance de l’Internet
Cependant, l’architecture de l’Internet (TCP/IP), initialement conçue pour assurer le transfert fiable des données et sans déséquencement pour des applications sans contraintes particulières de délai ni de débit (transfert de fichiers, web statique, messagerie électronique), présente clairement une inadéquation au nouveau contexte applicatif. La volonté d’offrir de nouveaux services de communication et d’optimiser l’utilisation des ressources des réseaux sous jacents a motivé nombreux travaux de recherche, dont ceux présentés dans ce mémoire, dans le but d’offrir de nouvelles garanties de QoS.
1.1.2. Qualité de service (QoS) : définitions et terminologie
Différentes propositions ont été apportées pour définir la notion de QoS offerte par un réseau.
La QoS peut être définie selon plusieurs critères : performance, disponibilité, fiabilité, sécurité, etc. Plusieurs définitions de la QoS ont été proposées par les divers organismes de standardisation ainsi que par la communauté Internet. La QoS a été définie par le standard ISO- 9000 [ISO9000-00] comme « le degré pour lequel un ensemble de caractéristiques inhérentes satisfont les exigences». Un autre standard, ISO 8402 [ISO8402-00], définit la QoS comme
« la totalité des caractéristiques d’une entité qui portent sur ses aptitudes à satisfaire les besoins applicatifs fixés ou implicites». La recommandation ITU-T X.902 [ITU-T-Rec.X.902-95] la définit comme « l’ensemble des qualités liées au comportement collectif d’un ou plusieurs objets ». La recommandation ITU-T E.800 [ITU-T-Rec.E.800-93] introduit le concept utilisateur / service par « l’effet collectif de la performance du service qui détermine le degré de satisfaction de l’utilisateur de service ». Particulièrement dans le domaine de l’informatique et des systèmes de communication, la QoS est définie comme « l’ensemble des caractéristiques qualitatives et quantitatives d’un système multimédia distribué nécessaires pour accomplir les fonctionnalités requises par une application » [Vogel95].
Par ailleurs, une grande majorité de la communauté scientifique définit la QoS suivant deux points de vue :
• le point de vue utilisateur : les caractéristiques quantitatives et qualitatives attendues et perçues d’un service ;
• le point de vue fournisseur : la qualité prévue et effectivement fournie.
Dans [Gozdecki03], les auteurs donnent une vue d’ensemble sur la terminologie QoS dans les réseaux IP et rappellent les définitions les plus utilisées dans la littérature, notamment les standards ITU (International Telecommunications Union), ETSI (European Telecommunications Standard Institute) et IETF (Internet Engineering Task Force). Le modèle général adopté de la terminologie est celui de [Hardy01] qui propose trois notions de QoS : intrinsèque, perçue et évaluée.
• la QoS intrinsèque résulte des choix techniques effectués dans le réseau ;
• la QoS perçue résulte de l’expérience des utilisateurs. Elle reflète donc une composante subjective. Une QoS avec les mêmes paramètres intrinsèques peut être perçue différemment par les divers utilisateurs.
• la QoS évaluée apparait quand le client continue ou non d’utiliser un service, ce qui dépend de plusieurs facteurs (prix, relation avec le fournisseur, service après vente etc.). Aucun des organismes ITU, ETSI ou IETF ne s’intéressent à ce type de QoS.
L’ITU et l’ETSI se focalisent principalement sur la QoS perçue, en introduisent la notion de
« performance réseau » pour la partie technique. Les travaux de l’IETF visent la QoS
intrinsèque, résultant de ses objectifs de développement de l’architecture Internet. La notion de
QoS considérée par l’IETF est similaire à celle de performance réseau définie par l’ITU et
l’ETSI.
1.1.3. Paramètres et métriques de QoS
Lorsque les besoins en QoS des utilisateurs sont exprimés dans un langage non-technique, la QoS intrinsèque est représentée par l’intermédiaire de paramètres. Dans les réseaux de paquets (notamment IP), les paramètres suivants sont les plus répandus :
• la bande passante, terme du domaine électronique utilisé par abus de langage, qui indique le débit d’information, exprimé généralement en octets par seconde (B/s) ou en bits par seconde (bit/s ou bps) ;
• le délai subi par les paquets, de bout en bout ou sur une portion du réseau, exprimé en millisecondes ;
• la gigue, qui exprime la variation du délai de transfert des paquets ;
• le taux de pertes, défini généralement comme le rapport entre le nombre de paquets perdus et le nombre total de paquets émis.
Les exigences des applications multimédia peuvent être spécifiées en termes de ces paramètres de base. Le Tableau 1 décrit les exigences proposées par la recommandation ITU-T G1010 [ITU-T-Rec.G.1000-01] pour les principaux types de données.
Medium Application Degree of symmetry
Typical amount of
data
Key performance parameters and target values
One-way delay (Note)
Delay variation
Information loss Data Web-browsing
– HTML
Primarily one-way
~10 KB Preferred < 2 s /page Acceptable < 4 s
/page
N.A. Zero
Data Bulk data transfer/retrieval
Primarily one-way
10 KB-10 MB
Preferred < 15 s Acceptable < 60 s
N.A. Zero
Data Transaction services – high
priority e.g.
e-commerce, ATM
Two-way < 10 KB Preferred < 2 s Acceptable < 4 s
N.A. Zero
Data Command/contro l
Two-way ~ 1 KB < 250 ms N.A. Zero
Data Still image One-way < 100 KB Preferred < 15 s Acceptable < 60 s
N.A. Zero
Data Interactive games
Two-way < 1 KB < 200 ms N.A. Zero
Data Telnet Two-way
(asymmetric)
< 1 KB < 200 ms N.A. Zero
Data
E-mail (server access)
Primarily one-way
< 10 KB Preferred < 2 s Acceptable < 4 s
N.A. Zero
Data E-mail (server to server transfer)
Primarily one-way
< 10 KB Can be several minutes
N.A. Zero
Data Fax ("real-time") Primarily one-way
~ 10 KB < 30 s/page N.A. <10-6 BER Data Fax (store &
forward)
Primarily one-way
~ 10 KB Can be several minutes
N.A. <10-6 BER
Data Low priority Primarily < 10 KB < 30 s N.A. Zero
transactions one-way
Data Usenet Primarily
one-way
Can be 1 MB or more
Can be several minutes
N.A. Zero
Tableau 1 : Cibles de performance pour les applications
D’autres caractéristiques peuvent être associées aux paramètres de QoS :
• la portée : de bout-en-bout ou locale ;
• la granularité : par flux, par session, par agrégat ;
• la direction : unidirectionnelle, bidirectionnelle ;
• la garantie : absolue, statistique.
Les paramètres de la QoS perçue sont plus difficiles à exprimer et quantifier. Nous pouvons en citer : le support pour le service, la sécurité, la disponibilité, le temps de connexion etc.
Les Classes de Service (Class of Service - CoS) représentent une modalité de gestion du trafic dans un réseau en regroupant les types de flux similaires. Les classes ainsi considérées seront traitées de manière unique en termes de paramètres de service. Les classes de services constituent une manière simple et évolutive pour gérer le trafic. Divers types de classes de services sont définis à différents niveaux de l’architecture Internet : application, réseau, etc.
Le groupe de travail « IP Performance Metrics » de l’IETF vise à définir des métriques standard de QoS, performance, fiabilité dans le transfert de données sur Internet. Ces métriques sont la connectivité, le délai et les pertes dans un seul sens et aller-retour, la variation du délai, les pertes, la réorganisation des paquets, la capacité des liens, etc.
La recommandation ITU-T Y.1541 [ITU-T-Rec.Y.1541-06] définit des paramètres similaires à ceux décrits par IETF, dont les principaux sont :
• IPTD (IP Packet Transfert Delay) : le délai de transfert d’un paquet ;
• IPDV (IP Packet Delay Variation) : la variation du délai entre deux paquets consécutifs;
• IPLR (IP Packet Loss Ratio): le rapport entre le nombre de paquets perdus sur l’ensemble des paquets transmis ;
• IPER (IP Packet Error Rate) : le rapport entre le nombre de paquets erronés sur le nombre total de paquets transmis.
La recommandation ITU-T Y.1541 défini les objectifs de performances réseaux pour différentes classes (Tableau 2).
Network performance
parameter
Nature of network performance
objective
QoS Classes
Class 0 Class 1 Class 2 Class 3 Class 4 Class 5 Unspecified IPTD Upper bound on
the mean IPTD 100 ms 400 ms 100 ms 400 ms 1 s U
IPDV Upper bound on the 1 − 10–3 quantile of IPTD minus the minimum IPTD)
50 ms 50 ms U U U U
IPLR Upper bound on the packet loss probability
1 × 10–3 1 × 10–3 1 × 10–3 1 × 10–3 1 × 10–3 U
IPER Upper bound 1 × 10–4 U Tableau 2 : Les performances des classes réseau Y.1541
1.2. Caractéristiques de l’Internet multi-domaine
1.2.1. Introduction
Par définition multi-technologie, l’Internet est aujourd’hui de fait multi-domaine, chaque fournisseur et administrateur assurant chacun de façon autonome la gestion de leur réseau et de leurs services. Cette indépendance renforce le caractère hétérogène de l’Internet, et accroit la difficulté de maîtriser la QoS pour des communications traversant plusieurs domaines.
Après avoir précisé la notion de domaine, cette section présente les caractéristiques de l’Internet multi-domaine relatives à ses technologies réseau support ainsi qu’à ses principaux protocoles de niveaux réseau et transport de l’architecture OSI
1.
1.2.2. Notion de domaine et de système autonome (AS)
Un domaine représente un ensemble d’ordinateurs et équipements dans un réseau gérés de manière unique par une seule entité administrative. La RFC 1136 [Hares89] définit un domaine administratif comme un groupement d’hôtes, routeurs et réseaux dans l’Internet gérés par une seule organisation.
Un système autonome (AS : Autonomous System) est un ensemble de réseaux sous l’administration d’une seule entité qui a une politique de gestion (notamment de routage) commune et spécifique. Cette notion est donc administrative et l’indépendance de gestion concerne en premier lieu la politique de routage [Hawkinson96], mais s’applique aussi aux politiques de sécurité ou de gestion de la QoS. Notons qu’un numéro d’AS unique est attribué par l’IANA (Internet Assigned Numbers Authority) à chaque AS, son utilisation principale étant dans la mise en œuvre du routage inter-domaine.
Les systèmes autonomes se classent en trois catégories suivant leurs interconnexions et leurs opérations :
• Un AS Multihome est un AS qui a des connexions avec plusieurs autres AS, mais ne permet pas de transférer de trafic entre ces AS ;
• Un AS stub est un AS qui n’est connecté qu’à un seul autre AS. Le trafic est soit généré, soit terminé dans un tel AS ;
• Un AS de transit est un AS qui fournit des connexions aux différents réseaux séparés.
Dans la suite de ce mémoire, nous utiliserons de façon équivalente, les termes de « système autonome » et de « domaine ».
1.2.3. Technologies sous-jacentes
Pour mettre en place l’infrastructure nécessaire, les opérateurs s’appuient sur différentes technologies filaires et sans fil. Nous décrivons brièvement dans les paragraphes suivants celles que nous avons utilisées dans nos travaux.
1 Modèle OSI («Interconnexion de systèmes ouverts») d'interconnexion en réseau des systèmes ouverts est un modèle de communications entre ordinateurs proposé par l'ISO (Organisation internationale de normalisation)
1.2.3.1. LAN, Ethernet
Ethernet est un standard de transmission de données pour un réseau local, normalisé sous le nom d’IEEE 802.3 et classé dans la couche liaison de données du modèle OSI (bien qu’il implémente des fonctionnalités de la couche physique). Toutes les machines du réseau Ethernet sont connectées à une même ligne logique de communication, toute information envoyée par un équipement étant reçue par tous les autres, même si cette information était destinée à une seule machine. Les postes connectés sur un réseau Ethernet doivent donc filtrer ce qui leur est destiné ou non.
1.2.3.2. xDSL
Le terme DSL signifie Digital Subscriber Line (ligne numérique d’abonné) et regroupe l’ensemble des technologies mises en place pour un transport numérique de l’information sur une simple ligne de raccordement téléphonique. L’idée est de mettre à profit la partie non utilisée du spectre d’une ligne téléphonique (dont la voix n’utilise qu’une partie) pour transporter des données. Les technologies xDSL sont divisées en deux grandes familles, suivant le rapport entre bande passante ascendante, de l'utilisateur vers le réseau, (upload) et bande passante descendante, du réseau vers l'utilisateur, (download) : celle utilisant une transmission symétrique (SDSL) et celle utilisant une transmission asymétrique (ADSL).
1.2.3.3. Wi-Fi
Wi-Fi est une technologie sans fil normalisé IEEE 802.11 dont le nom est promulgué par Wi-Fi Alliance qui veille à l’interopérabilité des équipements certifiés. La norme définit les deux couches basses du modèle OSI (physique et liaison de données) en utilisant des ondes radio sur la fréquence de 2.4 GHz. Conçu pour les réseaux locaux sans fil (WLAN), cette norme permet des communications entre différents dispositifs en hauts débits (de 11 Mbit/s en 802.11b à 54 Mbit/s en 802.11a/g et jusqu’à 540 Mbit/s théoriques pour le futur 802.11n). Il existe deux modes de connexion et d’exploitation dans un réseau local sans fil : le mode infrastructure (les postes équipés d'une carte Wi-Fi sont connectés entre eux via un ou plusieurs Points d'Accès - AP- ou hotspots qui agissent comme des concentrateurs), et le mode ad-hoc (connexion directe entre les équipements Wi-Fi, sans utiliser un matériel tiers).
1.2.3.4. Satellite
Les systèmes satellitaires sont déployés de plus en plus dans des zones ou l’infrastructure de communication est peu développée, peu habitées ou bien difficile à couvrir par les autres technologies. Grace à ses avantages (couverture globale, flexibilité d’utilisation de la bande passante, déploiement pratique des services), l’intégration du satellite comme composant d’un Internet s’appuyant sur des réseaux physiques hétérogènes a une légitimité. Les inconvénients principaux sont le coût de départ relativement élevé, la fiabilité réduite en cas de contexte exceptionnel (interférences, conditions climatiques) et le délai de propagation de l’ordre de 600 ms aller-retour. Les débits sur un lien satellitaire peuvent aller jusqu’à 100 Mbps en réception et 2 Mbps en émission.
1.2.4. Le routage dans l’Internet
Le routage représente le processus qui permet de trouver le chemin que doit emprunter une
information sur un réseau afin de parvenir à sa destination. Le routage est un mécanisme vital
pour Internet car il permet de passer les paquets de proche en proche pour arriver à la
destination. Chaque dispositif intermédiaire, appelé routeur, possède une table de routage
(remplie statiquement ou le plus souvent dynamiquement) qui est utilisée pour retrouver le
meilleur chemin vers la destination. Nous distinguons deux types de protocoles de routage :
• Interior Gateway Protocol (IGP), utilisé à l’intérieur d’un système autonome ;
• Exterior Gateway Protocol (EGP), utilisé pour échanger des informations de routage entre systèmes autonomes.
1.2.4.1. Routage intra-domaine
Les protocoles de type IGP se divisent en deux catégories : à vecteur de distance (distance- vector) et à état de lien (link-state). Les protocoles à vecteur de distance utilisent l’algorithme de Bellman-Ford ([Bellman58] et [Ford62]) et les routeurs n’ont pas la connaissance de la topologie complète du réseau. D’autre part, pour les protocoles à état de lien, chaque routeur possède la cartographie complète du réseau, la meilleure route étant calculée localement.
1.2.4.1.1. RIP
Routing Information Protocol (RIP) est un protocole à vecteur de distance qui utilise comme métrique le nombre de sauts. Défini initialement au sein de l’IETF dans la [Hedrick88], il a été redéfini dans les nouvelles versions : RIPv2 [Malkin98] ou RIPng [Malkin97]. Il présente quelques inconvénients (temps de convergence, passage à l’échelle, nombre maximal de saut) qui font que RIP est remplacé soit par EIGRP (Enhanced Interior Gateway Routing Protocol, propriétaire CISCO), soit par des protocoles à état de lien (OSPF ou IS-IS).
1.2.4.1.2. OSPF
OSPF (Open Shortest Path First) est un protocole de routage pour IP issu des travaux du groupe IGP de l’IETF (la version standardisé la plus récente est RFC 2328 [Moy98]). Un réseau OSPF est hiérarchique et il peut être divisé en zones, connectées à une zone centrale (Area 0). Il utilise une variante de l’algorithme de Dijkstra [Dijkstra59] pour calculer la route optimale à partir de l’arbre de plus court chemin. Chaque routeur garde une base de données, mise à jour périodiquement, qui contient la topologie du réseau. Cette base, appelée LSDB (Link State DataBase) est mise à jour périodiquement sur tous les routeurs. La dernière version d’OSPF est OSPFv3 [Coltun99] et présente la compatibilité avec IPv6.
1.2.4.1.3. IS-IS
IS-IS (Intermediate System to Intermediate System), développé par Digital Equipement Corporation, est également un protocole IGP à état de lien standardisé par l’OSI [ISO10589].
Etendu pour l’Internet IP, il a été intégré par l’IETF [Oran90] et [Callon90]. Plusieurs entités coexistent dans un réseau IS-IS : les systèmes terminaux (End System), les systèmes intermédiaires (Intermediate System – les routeurs), les zones (ensemble de routeurs) et les domaines (ensemble de zones). Par rapport à l’OSPF qui est utilisé plutôt dans les réseaux des grandes entreprises, IS-IS est adopté particulièrement par les fournisseurs.
1.2.4.2. Routage inter-domaine
Les protocoles de type EGP permettent d’échanger des informations de connectivité et d’accessibilité des réseaux dans l’Internet entre systèmes autonomes (AS). Actuellement, le seul représentant réellement déployé de cette famille est le protocole BGP (Border Gateway Protocol).
1.2.4.2.1. BGP
BGP est le protocole utilisé pour échanger des informations de routage entre les systèmes
autonomes. La version actuellement standardisé par l’IETF ([Perkins07]) est BGPv4. BGP
supporte l’agrégation pour limiter les tables de routage et aussi le routage sans classe (Classless
Inter-Domain Routing - CIDR). Les métriques ne sont pas les mêmes que celles utilisée en IGP, mais elles dépendent de la route, des politiques des opérateurs ou bien des diverses règles réseau.
Les voisins BGP sont les routeurs avec lesquels une session BGP est établie. Ils sont configurés manuellement et la connexion utilise le protocole TCP sur le numéro de port 179. Deux entités BGP échangent des messages pour ouvrir et maintenir les paramètres d’une session. BGP ne nécessite pas de mise à jour périodique des tables de routage ; des messages sont envoyés lorsque la table de routage change. En revanche, un routeur BGP doit retenir la totalité des tables de routage courantes de tous ses pairs durant le temps de la connexion. BGP est constitué de deux parties : quand il est exécuté entre deux routeurs au sein du même système autonome, il s’agit d’IBGP (Interior BGP) ; d’autre part, EBGP (Exterior BGP) est le nom donné quand la session est établie entre système autonomes différents (voir Figure 3).
Figure 2 : Protocole BGP
Les paragraphes précédents permettent de souligner un point important du déploiement des protocoles adaptés au multi-domaine. En effet, BGP est déployé indépendamment de l’IGP choisi au niveau des domaines.
1.2.4.3. Routage à QoS
Le routage à QoS (QoS Routing) est une des pistes de recherche dans le cadre de l’IETF.
L’objectif principal ce ces travaux et d'intégrer les métriques de la QoS et les critères de choix d'un chemin dans les différents protocoles de routage existants. La RFC 2386 [Crawley98]
évoque trois évolutions envisageables des protocoles de routage : (1) supporter différentes classes de service, (2) éviter les changements fréquents de routes et (3) profiter de l’existence de routes alternatives.
Le routage à QoS détermine les routes à la fois par la connaissance des ressources disponibles dans le réseau et les demandes en QoS d’un flux. Les protocoles de routage à QoS présentent des mécanismes dynamiques qui ajoutent des critères de QoS au processus de choix des routes.
Les techniques de routage à QoS sont utilisées conjointement avec des mécanismes de réservation de ressources, contrôle d’admission ou ingénierie de trafic.
[Boucadair05] présente une proposition de routage inter-domaine à QoS, Q-BGP (QoS
Enhanced BGP). Ce protocole repose sur la version de base de BGP pour échanger des
informations sur les performances relatives à la QoS. C’est une version enrichie de ce protocole
qui a été retenue dans l’architecture du projet EuQoS présenté dans le chapitre 3, dans lequel
nous la présentons plus en détail.
1.2.4.4. MPLS et Traffic Engineering
L’acheminement traditionnel des paquets dans les routeurs s’effectue suivant l’adresse IP de destination contenue dans l’entête des paquets IP. Dans un souci de simplification et de rapidité du routage, un groupe de travail à l’IETF a proposé un nouveau protocole : MPLS (Multi Protocol Label Switching) [Rosen01]. MPLS est un protocole de commutation des paquets (basé sur un protocole CISCO de commutation de tags), qui utilise des labels (étiquettes) pour acheminer les paquets.
Un label de 20 octets identifie le trafic à l’intérieur d’un réseau MPLS. Ce label est associé à un groupe de paquets acheminés de la même manière, sur le même chemin et qui suivent le même traitement, ce qui constitue une classe spécifique de trafic appelé « Forwarding Equivalence Class » (FEC). Une FEC correspond à une plage d’adresses destination, à un certain type de trafic, une priorité etc. Le mécanisme de commutation de labels doit être associé à un contrôle d’admission pour garantir un niveau de qualité bien défini. Les frontières d’un réseau MPLS sont régies par des routeurs spéciaux appelés Label Edge Routers (LER). Les LERs appliquent un label aux paquets entrants dans le réseau et l’enlèvent à la sortie. Les routeurs du cœur d’un réseau MPLS, appelés Label Switch Routers (LSR) commutent les paquets suivant les labels et le chemin ainsi suivi porte le nom de Label Switched Path (LSP). La Figure 4 présente un exemple de domaine MPLS :
Figure 3 : Réseau MPLS
MPLS présente l’avantage de différencier les divers flux de données (association des étiquettes différentes) ce qui le rend très attractif pour les fournisseurs et son utilisation est répandue principalement dans le cœur du réseau.
MPLS est utilisé conjointement avec des mécanismes d’ingénierie de trafic (Traffic Engineering - TE). L’ingénierie de trafic définit l'ensemble des techniques appliquées afin de contrôler et de réguler la distribution du trafic dans un réseau. L’objectif des opérateurs est d’optimiser l’utilisation des ressources (bande passante) afin de mieux dimensionner le réseau, d’éviter les congestions, de récupérer après une disfonctionnement etc.
1.2.5. Les protocoles de Transport dans l’Internet
Pour répondre aux exigences des nouvelles applications (ex. multimédia et temps réel), deux
approches d’optimisation des protocoles sont envisagées dans les différents travaux de
recherche :
• la première approche consiste à s’adapter, au niveau des couches hautes (Transport, Application) de l’architecture TCP/IP, à la variabilité des ressources du réseau ;
• la deuxième approche propose une révision de l’architecture TCP/IP en vue de maîtriser les problèmes de bande-passante et de délai.
Une des pistes de recherche explorées a été de repousser la complexité vers les extrémités de la communication (terminaux utilisateurs) et par conséquent d’introduire des mécanismes d’adaptation dans les couches hautes de l’architecture Internet : application et transport. Ces solutions visent à répondre aux exigences des applications et à s’adapter aux caractéristiques (type des flux, contraintes temporelles, fiabilité). Notons que ces solutions n’offrent aucune garantie, ni temporelle ni de débit, sur le transfert de données.
De nombreux travaux se sont attachés à proposer de nouveaux protocoles et mécanismes de niveau transport. Les protocoles initiales (Transmission Control Protocol - TCP et User Datagram Protocol - UDP) présentent des limites conceptuelles qui les rendent inadéquats aux applications temps réel. Les mécanismes de reprise de perte et le contrôle de congestion de TCP engendrent une augmentation non maitrisée du délai et aussi une variation importante du débit d’émission. D’autre part, UDP ne met en œuvre ni des mécanismes de gestion de l’ordre ni de la fiabilité et de ce fait ne répond pas aux besoins des applications multimédia.
SCTP (Stream Control Transmission Protocol [Stewart07] et DCCP (Datagram Congestion Control Protocol [Kohler06]) sont actuellement développés à l’IETF, pour répondre aux limitations ou enrichir les fonctionnalités des protocoles UDP et TCP.
Le protocole ETP (Enhanced Transport Protocol [Exposito03]), conçu au LAAS-CNRS, vise à permettre l’assemblage dynamique de micro-protocoles, dédiés chacun à une fonction spécifique (contrôle des pertes partiellement fiable, contrôle de congestion TCP-friendly [Floyd06], …). Il permet ainsi d’offrir les services de transport les plus adaptés aux besoins des applications et au contexte réseau sous-jacent. ETP a été instancié dans EuQoS de sorte à fournir un ensemble de services EQ-ETP adaptés aux classes de services réseau considérées dans EuQoS, dans le but d’optimiser la QoS des transferts de données.
Sur ces bases, la section suivante présente les modèles précurseurs de gestion de la QoS qui ont été proposés pour l’Internet, en soulignant les limites et les problèmes ouverts.
1.3. Modèles précurseurs pour la garantie de la QoS
L’IETF (Internet Engineering Task Force) a créé successivement deux groupes de travail, IntServ et DiffServ pour l’étude et la proposition des nouveaux services IP. Ces propositions essayent de répondre (en tout ou partie) aux principaux problèmes comme le provisionnement des services, la signalisation nécessaire, etc.
1.3.1. IntServ
1.3.1.1. Présentation générale
L’IETF a d’abord créé le groupe de travail « Integrated Services » (IntServ). Ce groupe a
introduit une extension de l’architecture Internet composée d’une part d’un modèle de service,
appelé modèle IS (Integrated Services) et d’autre part d’un cadre d’implémentation pour la
mise en œuvre de ce modèle [Braden94]. Deux types de service ont été proposés pour répondre
aux besoins des applications temps réel (garanti et assuré).
Pour la mise en place de ces services, une réservation des ressources est nécessaire dans tous les routeurs au long du chemin de données. Cette procédure est réalisée par l’intermédiaire d’un protocole de signalisation appelé RSVP (Resource ReSerVation Protocol), présenté dans la section 1.5.3.1.1.
T
Le modèle IntServ définit une architecture capable de prendre en charge la qualité de service sans toucher au protocole IP. Dans un réseau IntServ, un flux de données identifie un ensemble de paquets qui reçoivent une certaine qualité de service et qui est défini par une « session » déterminée par les adresses IP destination, le protocole de transport et les numéros de port.
Chaque flux peut être servi par différentes classes de service implantées dans les routeurs traversés. Le trafic best-effort ne reçoit aucun traitement spécifique dans les routeurs, et les paquets sont acheminés suivant la disponibilité des ressources.
Le cadre d’implémentation proposé par le groupe IntServ repose sur quatre fonctions principales, l’ordonnancement des paquets, le contrôle d’admission, la classification des paquets et la signalisation :
• l’ordonnanceur est en charge de l’acheminement des différents paquets ;
• le « classifieur » réalise une correspondance avec le niveau de QoS requis pour les paquets appartenant à différents flux ayant comme objectif le contrôle de trafic ;
• le contrôle d’admission comprend la décision d’accepter ou de rejeter un nouveau flux par rapport à la QoS demandée. Cette QoS est spécifiée par un ensemble de paramètres appelés FlowSpec. On distingue deux parties dans le FlowSpec : le TSPEC (spécification du trafic) et le RSPEC (spécification de la requête, les garanties nécessaires pour le flux). Ces informations sont transportées par le protocole de réservation RSVP qui a pour but de créer et maintenir les états spécifiques pour chaque flux dans les hôtes terminaux et dans tous les routeurs au long du chemin ;
• la signalisation mise en place permet de réserver les ressources le long du chemin de données dans les routeurs.
Dans le cadre d’IntServ, deux nouvelles classes de service en plus du best-effort ont été définies : Guaranteed Service (GS) [Shenker02] et Controlled Load (CL) [Wroklawski97a].
• GS propose un service exprimable de manière quantitative en termes de bande passante et de délai maximal. Il garantit que tous les paquets arriveront avec un délai maximal et ils ne sont pas perdus dans les files d’attentes en cas de congestion (si le flux respecte les paramètres réservés). Il est à remarquer que GS n’offre aucune garantie sur le délai moyen, mais seulement sur le délai maximal. Ce type de service se prête à des applications temps réel avec des contraintes fortes sur le délai de transmission.
• CL propose un service de bout-en-bout exprimable de manière qualitative en terme de bande passante : il garantit un transfert de données équivalent à un réseau peu chargé, non-congestionné. Les garanties offertes par le CL sont d’ordre statistique et les applications qui utilisent ce service doivent fournir une estimation du trafic qu’elles vont générer (dans le TSPEC). Les applications susceptibles d’utiliser ce service sont sensibles aux conditions de surcharge du réseau qui entraine une dégradation sensible de la qualité.
Le niveau de QoS fourni par les classes de service est programmable pour chaque flux (per- flow) suivant les requêtes des applications. Ces requêtes sont passées aux routeurs en utilisant un protocole de réservation tel que RSVP. L’API
TP2PTRSVP [Braden97] permet de préciser le
TP
2
PT Application Programming Interface (Interface de Programmation Applicative)
profil de trafic qui nécessite la réservation des ressources ainsi que le service IP requis (GS ou CL).
1.3.1.2. Limites des propositions IntServ L’approche IntServ présente plusieurs limites importantes.
• Tous les routeurs au long du chemin ainsi que les systèmes terminaux doivent être capables de fournir des requêtes de QoS en utilisant le protocole RSVP. L’inconvénient principal de RSVP provient du fait qu’il oblige à maintenir des informations d'état sur chaque flux dans chaque nœud du chemin liant l'émetteur au récepteur. Lorsque le nombre d'usagers (flux) augmente, le nombre d'états devient conséquent, et le trafic est d'autant plus saturé que les rafraîchissements entre routeurs deviennent importants. Le maintien des états dans les routeurs ainsi que le contrôle d’admission augmentent les besoins en ressources et rajoutent de la complexité dans les nœuds du réseau. Cela nuit aux performances du système dans son ensemble. C'est pourquoi IntServ est plus adapté à des réseaux de petite taille comme les réseaux locaux (LAN).
• D’autre part, IntServ ignore la structure multi-domaine de l’Internet. L’existence de plusieurs domaines administrés indépendamment les uns des autres, impose une gestion locale de manière autonome vis-à-vis de leurs politiques internes, du routage, de la sécurité et bien sûr de la qualité de service différente qui devient difficile à déployer.
1.3.2. DiffServ
1.3.2.1. Présentation générale
Le modèle DiffServ [Blake98] a été conçu pour répondre aux limites d’IntServ. L’idée de base est de fournir une qualité de service non par flux, mais par classe de paquets IP tout en repoussant (le plus possible) la complexité du traitement en bordure du réseau afin de ne pas en surcharger le cœur. DiffServ définit la notion de « classe » comme un ensemble de paquets identiquement marqués. Afin d’éviter le problème du passage à l’échelle inhérent aux solutions IntServ, le choix a été fait de traiter un nombre limité de classes (agrégats).
Pour l’identification des classes, DiffServ définit un champ de remplacement dans l’en-tête IP, champ appelé DiffServ Code Point (DSCP) qui remplace les champs déjà existants : Type of Service (TOS) dans l’en-tête IP version 4 ou Traffic Class dans l’en-tête IP version 6. Plus exactement, seulement six bits sur 8 sont utilisés. Les deux autres bits (réservés) sont utilisés pour la notification explicite de la congestion.
Dans les paragraphes suivants, nous présentons d’abord deux autres notions importantes de la proposition DiffServ : la notion de domaine et la notion de contrat de service (SLA). Nous décrivons ensuite les principes généraux, de l’architecture DiffServ.
1.3.2.2. La notion de domaine DiffServ
Par définition, l’Internet est constitué d’une interconnexion de réseaux. Cependant, plusieurs de ces réseaux sont souvent rassemblés sous une même autorité administrative (par exemple dans les grandes entreprises, les centres de recherches, les universités, ...) et constituent un domaine.
[Nichols98] désigne par domaine, un ensemble de nœuds (hôtes et routeurs) administrés de façon homogène.
Dans un domaine, on distingue les nœuds internes et les nœuds frontières : les premiers ne sont
entourés que de nœuds appartenant au domaine alors que les seconds sont connectés à des
nœuds frontières d’autres domaines (Figure 4). Si on considère le sens de communication de la source vers la destination, les nœuds de frontières peuvent être d’entrée (ingress) dans le domaine ou de sortie (egress).
Figure 4 : Distinction des nœuds d’un domaine DiffServ
