Soutenance mémoire
Télécharger le fichier pdf d’un mémoire de fin d’études
Caractéristiques de l’Internet multi-domaine
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 technologi es réseau support ainsi qu’à ses principaux protocoles de niveaux réseau et transport de l’architecture OSI1 .
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-domain e.
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 ».
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 estun modèle de communications entre ordinateurs proposépar l’ISO (Organisation internationale de normalisation)
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êmesi 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.
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 (dontla voix n’utilise qu’une partie) pour transporter des données. Les technologies xDSL sontdivisé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).
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).
Satellite
Les systèmes satellitaires sont déployés de plus enplus dans des zones ou l’infrastructure de communication est peu développée, peu habitées ou ienb difficile à couvrir par les autres technologies. Grace à ses avantages (couverture glo bale, 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.
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.
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.
RIP
Routing Information Protocol (RIP) est un protocole à vecteur de distance qui utilise comme métrique le nombre de sauts. Défini initialement ausein 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 à étatde lien (OSPF ou IS-IS).
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,onnecté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é avecIPv6.
IS-IS
IS-IS (Intermediate System to Intermediate System), développé par Digital Equipement Corporation, est également un protocole IGP à étatde lien standardisé par l’OSI [ISO10589]. Etendu pour l’Internet IP, il a été intégré par ETFl’I [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.
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 ystèmes autonomes (AS). Actuellement, le seul représentant réellement déployé de cette famille est le protocole BGP (Border Gateway Protocol).
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 outeurs au sein du même système autonome, il s’agit d’IBGP (Interior BGP) ; d’autre part, EBG P (Exterior BGP) est le nom donné quand la session est établie entre système autonomes différents (voir Figure 3).
Les paragraphes précédents permettent de soulignerun 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.
Routage à QoS
Le routage à QoS (QoS Routing) est une des pistes d e recherche dans le cadre de l’IETF. L’objectif principal ce ces travaux et d’intégrer esl 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èresde 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 Qo S. 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.
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, surle 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’adr esses 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 LabelEdge 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 :
MPLS présente l’avantage de différencier les diversflux de données (association des étiquettes différentes) ce qui le rend très attractif pour lesfournisseurs 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 ‘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 pas sante) afin de mieux dimensionner le réseau, d’éviter les congestions, de récupérer après une sfonctionnementdi etc.
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 nivea u des couches hautes (Transport, Application) de l’architecture TCP/IP, à la variabi lité 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’architect ure 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 reprisede 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 auxbesoins 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 service s 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.
Modèles précurseurs pour la garantie de la QoS
L’IETF (Internet Engineering Task Force) a créé sucessivement 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.
IntServ
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 d e service ont été proposés pour répondre aux besoins des applications temps réel (garanti etassuré).
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
Le modèle IntServ définit une architecture capablede 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 classesde 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é desressources.
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’acce pter 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 rout eurs 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 GSn’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 fortessur 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 quientraine 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’API2 RSVP [Braden97] permet de préciser le profil de trafic qui nécessite la réservation des essources ainsi que le service IP requis (GS ou CL).
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 utilisan le protocole RSVP. L’inconvénient principal de RSVP provient du fait qu’il oblige à m aintenir 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’étatsdevient conséquent, et le trafic est d’autant plus saturé que les rafraîchissements entr 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 nsu 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 servicedifférente qui devient difficile à déployer.
DiffServ
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 dupassage à l’échelle inhérent aux solutions IntServ, le choix a été fait de traiter un nombreimitél 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.
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êmeutoritéa 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œu ds (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 o n 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).
La notion de SLA (Service Level Agreement)
L’utilisation des services DiffServ implique pour le client la souscription d’un contrat avec le fournisseur des services : ce contrat s’appelle un Service Level Agreement (SLA).
Contrairement à ce qui se passe avec RSVP, ce contr at est signé avant toute connexion au réseau, et non à l’établissement d’une session (établir une session RSVP revient en effet à passer un contrat avec les routeurs intermédiaires, qui garantissent certaines propriétés du transport de données tant que le trafic respecte uncertain profil). Les spécifications techniques du SLA sont contenues dans le SLS (Service Level Specification). Le SLA contient les informations suivantes :
· le trafic que l’utilisateur peut injecter dans le réseau fournisseur (en termes de volume de données, de débit moyen, d’hôtes source ou destination, …) ;
· les actions entreprises par le réseau en cas de dépassement de trafic (rejet, surtaxe, remise en forme du trafic) ;
· la QoS que le fournisseur s’engage à offrir au traf ic généré ou reçu par l’utilisateur (ou les deux). Celle-ci peut s’exprimer notamment en termes de délai, de bande passante, de fiabilité ou de sécurité.
Pour le moment, seuls des contrats statiques, c’est-à-dire peu susceptibles de changer dans le temps, sont établis, la gestion des contrats dynamiques dont les caractéristiques varient rapidement étant plus complexe.
La notion de comportement (PHB : Per Hop Behavior)
Au sein d’un domaine DiffServ, tous les nœuds (hôte s et routeurs) d’un domaine implémentent les mêmes classes de service et les mêmes comportements ou Per Hop Behavior: PHB vis-à-vis des paquets des différentes classes. Un comportemen inclut le routage, les politiques de service des paquets (notamment la priorité de passage ou de rejet en cas de congestion) et éventuellement la mise en forme du trafic entrant dans le domaine. Les nœuds internes ne doivent pas conserver d’états en mémoire (contrairement à la proposition IntServ) ; ils ne font que transmettre les paquets selon le comportement défini pour leur classe. Nous verrons dans les chapitres suivants qu’il est possible, sous couvert de certaines hypothèses concernant le trafic global, de caractériser (au moins statistiquement) les services obtenus entre deux nœuds frontières. Les nœuds frontières se chargent de mar quer les paquets selon le code réservé à chaque classe, comme nous allons le voir dans la partie suivante.
La RFC 2475 [Blake98] définit le PHB comme le comportement d’acheminement observable de l’extérieur qui s’applique aux données dans un nœud DiffServ. Le système marque les paquets conformément aux codes DSCP et tous les paquets ayant le même code seront agrégés et soumis au même traitement particulier.
Plusieurs PHB standard ont été définis :
· Le PHB par default (default PHB, défini en [Nichols98]) : spécifie que les paquets marqués avec la valeur DSCP « 000000 » utilisent leservice « traditionnel » best-effort dans un nœud DiffServ. De plus, si un paquet arrive dans un nœud et son code DSCP ne correspond à aucun PHB, ce paquet recevra le PHB par default
· Assured Forwarding (AF) PHB (défini en [Heinanen99]) : établit une méthode pour laquelle l’agrégation détermine différents niveauxd’assurances sur l’acheminement des paquets. Quatre classes AF1, AF2, AF3, et AF4 ont été ainsi définies avec des différents niveaux de traitement (rejet) en cas decongestion du réseau.
· Expedited Forwarding (EF) PHB (défini en [Jacobson99]) : a pour but d’offrir un service robuste avec peu de pertes, avec gigue et délai petits et une bande passante garantie (service premium). Pour assurer l’efficacité du système, ce service devrait être réservé pour un certain type d’applications (critiques, multimédia, temps réel). La valeur recommandée pour le code DSCP EF PHB est ‘101110’.
La notion de Bandwidth Broker
La RFC 2638 [Nichols99] introduit la notion de Bandwidth Broker (BB), entité définie comme ayant la connaissance des politiques et de la disponibilité des ressources d’un domaine. De plus, il alloue la bande passante en tenant compte d’un ensemble de règles et stratégies. Il est à noter qu’un BB est en charge d’un seul domaine admi nistratif (ou d’une portion de domaine). Pour avoir des garanties de QoS au long du chemin de données qui traverse plusieurs domaines, il est nécessaire d’avoir une communication entre les BBs adjacents ce qui permet de construire le chemin de bout-en-bout sur la base des SLA établis entre les domaines.
Plusieurs types d’architectures de déploiement ont été proposés pour les BBs [Schelen98], [Nichols99], [Terzis99], [Qbone01]. Elles peuvent être classées de la façon suivante :
· une seule entité est en charge de la gestion du domaine ;
· un BB est distribué entre plusieurs entités. Les tâches effectuées par ces entités peuvent être identiques ou hiérarchisée ;
· une structure hybride est également envisagée qui ombinec les avantages des deux architectures précédentes.
L’efficacité d’un BB dépend de l’interopérabilité ed ses composants. Les fonctions sont distribuées horizontalement (entre tous les domaines impliqués sur le chemin de données) et verticalement (au sein de chaque domaine). A titre d’exemple, la Figure 5 illustre les principaux composants du BB proposé pour le QBone [QBone01] ; elle comporte :
· une interface d’accès pour les utilisateurs et l’administrateur, afin de gérer les différentes requêtes provenant de l’intérieur du domaine;
· un module qui réalise le contrôle d’admission ;
· des composants pour la communication intra et inter-domaine ;
|
Table des matières
INTRODUCTION
CONTEXTE
PROBLEMATIQUE
CONTRIBUTIONS
PLAN DU MEMOIRE
1. ETAT DE L’ART SUR LA GESTION DE LA QUALITE DE SERVICE DANS LES RESEAUX DE NOUVELLE GENERATION
1.1. CONCEPTS FONDAMENTAUX SUR LA QOS
1.1.1. Evolutions de l’Internet
1.1.2. Qualité de service (QoS) : définitions et terminologie
1.1.3. Paramètres et métriques de QoS
1.2. CARACTERISTIQUES DE L’INTERNET MULTI-DOMAINE
1.2.1. Introduction
1.2.2. Notion de domaine et de système autonome (AS)
1.2.3. Technologies sous-jacentes
1.2.4. Le routage dans l’Internet
1.2.5. Les protocoles de Transport dans l’Internet
1.3. MODELES PRECURSEURS POUR LA GARANTIE DE LA QOS
1.3.1. IntServ
1.3.2. DiffServ
1.4. PROVISIONNEMENT ET CONTROLE D’ADMISSION POUR LA QOS
1.4.1. Provisionnement des ressources pour la QoS
1.4.2. Contrôle d’admission
1.5. SIGNALISATION POUR LA QOS
1.5.1. Introduction
1.5.2. Protocoles de signalisation de niveau applicatif
1.5.3. Protocoles de signalisation de niveau réseau
1.5.4. Signalisation générique – NSIS
1.6. ARCHITECTURES CONCEPTUELLES
1.6.1. Les réseaux de nouvelle génération (NGN)
1.6.2. Projets de recherche
1.7. CONCLUSION
2. CONTRIBUTIONS A LA SIGNALISATION POUR LA QUALITE DE SERVICE DANS L’INTERNET MULTI-DOMAINE
2.1. CONTEXTE DES TRAVAUX
2.1.1. Définitions
2.1.2. Internet multi-domaine à base de Bandwidth Broker
2.1.3. Représentation de la topologie sous-jacente
2.1.4. Contrôle d’admission
2.2. SIGNALISATION DECOUPLEE DU CHEMIN DE DONNEES
2.2.1. Concepts généraux
2.2.2. Découverte du prochain Bandwidth Broker
2.2.3. Spécification et modélisation UML
2.2.4. Prise en compte des domaines surprovisionnés
2.3. SELECTION DYNAMIQUE DES CLASSES DE SERVICES
2.3.1. Introduction
2.3.2. Formalisation
2.3.3. Exemple
2.3.4. Signalisation associée
2.3.5. Evaluation des bénéfices du provisionnement dynamique
2.3.6. Conclusion
2.4. HYPATH (HYBRID ON-PATH OFF-PATH FOR END-TO-END SIGNALING ACROSS NSIS AND NON-NSIS DOMAINS)
2.4.1. Introduction
2.4.2. Proposition HyPath
2.4.3. Fonctionnement dans les domaines NSIS
2.4.4. Extension pour l’intégration des domaines non-NSIS
2.4.5. Prise en compte de domaines surprovisionnés
2.4.6. Conclusions
2.5. SIGNALISATION ET MOBILITE
2.5.1. Contexte de mobilité considéré
2.5.2. Scénarios de mobilité examinés
2.6. CONCLUSIONS
3. LA SIGNALISATION DANS LE PROJET EUQOS
3.1. ARCHITECTURE EUQOS POUR LA GARANTIE DE QOS
3.1.1. Présentation du projet
3.1.2. Architecture générale
3.1.3. Provisionnement
3.1.4. Contrôle d’admission (CAC) dans EuQoS
3.1.5. Principe de signalisation dans EuQoS
3.2. DEFINITION DES INTERFACES ENTRE LES COMPOSANTES EUQOS
3.2.1. Concepts généraux
3.2.2. Description des interfaces entre les modules EuQoS
3.3. LA SIGNALISATION DANS EUQOS
3.3.1. Architecture du Resource Manager (RM)
3.3.2. CallController
3.3.3. Spécification de la signalisation
3.4. CONCLUSIONS
4. SIMULATIONS, DEPLOIEMENT ET EXPERIMENTATIONS
4.1. SIMULATIONS
4.1.1. Le logiciel Tau
4.1.2. Spécification
4.1.3. Résultats
4.1.4. Conclusions
4.2. IMPLEMENTATION
4.2.1. Introduction
4.2.2. CallController
4.2.3. Format des PDUs
4.3. EXPERIMENTATIONS
4.3.1. Plate-forme LAAS
4.3.2. Plate-forme européenne du projet EuQoS
4.3.3. Tests fonctionnels
4.3.4. Tests de garantie de QoS
4.3.5. Tests de performance (avec NSIS)
4.3.6. Test de performance (sans NSIS)
4.3.7. Tests de performance CallController seul
4.3.8. Conclusion sur l’ensemble des tests
4.4. CONCLUSION
CONCLUSION GENERALE
I. BILAN
II. PERSPECTIVES
BIBLIOGRAPHIE
BIBLIOGRAPHIE DE L’AUTEUR
Télécharger le rapport complet
