Cours Protocoles Com PDF

Chap5: Qualité de service dans les réseaux IP 299 Le réseau est devenu indispensable de lui dépendent : ◻ ◻ Les activités économiques (revenus des entreprises) ◻ Les activités administratives ◻ Les activités quotidiennes (téléphone ) L'utilisateur peut de...

Chap5: Qualité de service dans les réseaux IP 299 Le réseau est devenu indispensable de lui dépendent : ◻ ◻ Les activités économiques (revenus des entreprises) ◻ Les activités administratives ◻ Les activités quotidiennes (téléphone ) L'utilisateur peut de moins en moins se contenter d'un service au ◻ mieux (Best Effort) il cherche des garanties de service. 300 1. Notions de la QoS dans les réseaux IP 1.1. Définition de la QoS Utilisateur: cherche à obtenir le meilleur service au meilleur prix Administrateur de réseau: cherche à obtenir le meilleur service pour un groupe d'utilisateurs par la maîtrise de l'attribution des ressources du réseau en fonction de critères qui définiront la politique d'utilisation du réseau Exploitant de réseau: veille à ce que les ressources dont dispose (l'infrastructure, commutateurs, routeurs, liaisons, …) soient constamment utilisées au mieux Ingénieur de réseau: cherche à concevoir et offrir une meilleure QoS par la conception d'architectures et de mécanismes 301 ◻ Selon la recommandation E.800 du CCITT, la QoS (Quality of Service) correspond à l'effet général de la performance d'un service qui détermine le degré de satisfaction d'un utilisateur du service. ◻ Plus techniquement, une seconde définition de la QoS : la QoS constitue, pour un élément du réseau (une application, un hôte ou même un routeur), la capacité d'obtenir un certain niveau d'assurance de telle sorte que la fluidité du trafic et/ou les services requis soient au mieux satisfaits. ◻Une troisième définition consisterait à dire que la QoS correspond à tous les mécanismes d'un réseau qui permettent de partager équitablement et selon les besoins requis des applications, toutes les ressources offertes, de manière à offrir, autant que possible, à chaque utilisateur la qualité dont il a besoin. ◻ Généralement, cette qualité est axée sur le débit, le délai et la perte des paquets. ◻Pour un maximum de fiabilité, la QoS requiert la coopération de toutes les couches actives du réseau ainsi que celle de chaque élément du réseau, de bout en bout. 302 ◻ La Qualité de Service (QoS) est la capacité à véhiculer dans de bonnes conditions un type de trafic donné. ◻ C’est l’assurance pour un élément (application, hôte, routeur, switch) que son trafic sera acheminé dans les conditions voulues et prévisibles Le délai doit être compatible avec les besoins de l’application La bande passante doit être disponible Le taux de perte de paquets doit être compatible avec l’application La QoS se focalise sur les périodes de congestion ◻ Le trafic doit être réparti en classes de service de façon à isoler les applications qui se contrarient Cela suppose d’analyser les flux qui doivent transiter sur le réseau Chaque classe de service doit avoir les performances qui lui conviennent Performance? Classe? 303 1.2. Métriques de base Débit(s) : elle exprime la quantité de données sur le temps. Latence (délais de bout en bout): c’est le temps qui s’écoule entre l’envoi d’un mot et sa restitution côté récepteur. Gigue (variation de délais): c’est la variation des délais de transit due à la charge du réseau. Elle permet de savoir si les paquets arrivent de façon régulière. On utilise des tampons mémoire pour compenser la gigue. Taux d’erreurs: Bit Error Rate ou Packet Error Rate Taux de perte de paquets ou trames: Packet Loss Rate Disponibilité: c’est le pourcentage du temps du bon fonctionnement. Capacité de traitement (services transactionnels) Fiabilité 304 1.2. Métriques de base 1.2.a. Débit ◻Le débit (bande passante) mesure le nombre d'octets utiles (correctement arrivés destination) qui peuvent être transférés en une seconde, mesuré sur la durée du transfert de données. ◻Ce débit, qui est une moyenne, est évalué séparément dans les deux sens de transmission. Débit = Nu/Tc. Avec Nu= nombre d'octets correctement arrivés destination durant toute la connexion et Tc = durée en seconde de la connexion. 305 ◻ Garanties de débit : ◻Les applications actuelles consomment de plus en plus de débit, ce qui ralentit ou bloque le déroulement d'autres applications. ◻De même, une utilisation massive du réseau (plusieurs flots provenant de plusieurs utilisateurs traversant le réseau au même instant) entraîne des conséquences de ralentissement de traversée des flots. ◻La capacité d'un réseau doit être suffisamment importante pour pouvoir laisser passer de l'information sans pour autant qu'il y ait de retard d'acheminement, ni de distorsion des flux d'origine en matière de pertes de paquets. Le débit de transfert sur le réseau est important. Il faut traiter les flots à l'intérieur d'un réseau ◻ en fonction du débit que chaque application cliente envisage de consommer. ◻ Garanties de bande passante : ◻ La garantie d'un minimum de bande passante pour les applications favorise l'obtention d'une certaine garantie en matière de délai. Par ailleurs, les transmissions de trafic de données doivent être au maximum fiables (les pertes ne doivent pas être tolérées au niveau de la couche application) 306 1.2. b. Délai ◻ Le délai est la métrique de performance la plus importante pour les applications. Le délai est le temps écoulé entre l'envoi d'un paquet par un émetteur et sa réception par le destinataire. Il est appelé le délai de bout en bout ou délai aller simple ou latence. ◻ Le terme délai englobe en réalité trois aspects temporels différents : le délai de propagation, déterminé par la distance physique qui sépare la source de la destination le délai de transmission dépendant de la taille des flots. Ce paramètre est aussi étroitement lié à l'utilisation du réseau et au partage de la bande passante disponible le délai d'attente et de traitement des paquets à l'intérieur des dispositifs intermédiaires du réseau tels que les routeurs ou les commutateurs. Il est déterminé par la charge du réseau, ainsi que les politiques de traitement de l'information dans les routeurs pour obtenir une fluidité maximale de l'écoulement de l'information. 307 ◻En général, la majeure partie du délai est celle introduite par les files d'attente en sortie du fait que plusieurs flux en entrée se trouvent en concurrence pour accéder au médium de transmission. ◻L'exigence d'une application en terme de délai pourrait très stricte, auquel cas le réseau doit garantir une borne maximale sur le délai instantané de bout en bout, ou moyenne auquel cas le réseau offre une valeur moyenne du délai à long terme avec la possibilité de fluctuations en cas de surcharge du réseau. ◻L'analyse du délai améliore la gestion de la qualité de service et assure une meilleure efficacité dans les deux sens. ◻La notion de sens a une grande importance. La qualité de service peut varier suivant le sens que prennent les paquets au sein d'un réseau. Pour avoir des temps 308 1.2. c. Gigue ◻La gigue (jitter en anglais) est la variation de délai de bout en bout. ◻Elle nous renseigne sur l' évolution du temps du délai aller simple entre deux machines i.e. la différence entre le délai maximum et le délai minimum. ◻Considérons un émetteur E et un récepteur R et supposons que deux paquets soient mis par E destination de R aux instants a1 et a2 avec a1< a2. Soient d1 et d2 les instants où ils sont reçus par R. La gigue entre ces deux paquets est la différence, en valeur absolue, entre les temps de réponse des deux paquets |(d1-a1)- (d2-a2)|. 309 ◻Les flux temps réel tels que les flux vidéo, audio et voix sur IP sont très sensibles à la gigue. ◻La non considération de cette métrique implique une discontinuité au niveau de la restitution des données à la destination (entrainer des images saccadées aléatoirement) ◻Pour réduire l'effet et de la gigue, les paquets temps réel sont bufférisés à la destination avant leur lecture. Pour cela, la gigue doit être bornée pour prévoir la taille du tampon qui dépend principalement de la valeur de la gigue et le débit de réception des données. 310 1.2.d. Taux de perte ◻ Le taux de perte représente le pourcentage des unités de données qui ne peuvent pas atteindre leur destination dans un intervalle de temps spécifique. ◻ Cette perte peut être le résultat d'un rejet de paquets lorsque les ressources sont saturées (mémoire saturée d'un routeur) ou d'un dépassement d'échéance sachant que pour une application temps réel un paquet arrivant au delà de son échéance ne fournira aucune information utile à l'application (il se traduit par une mauvaise réactualisation de l'image vidéo, des ruptures au niveau de la conversation et une hachure possible de la parole) ◻ Le taux de perte est communément représenté par la probabilité de perte. ◻ La retransmission d'un paquet perdu ne change pas la valeur de la probabilité de perte mais fournit un moyen de recouvrement de perte. 311 1.2.e Taux d’erreurs ◻ Le taux d'erreurs est le rapport entre le nombre de paquets perdus ou mal transmis et le nombre total de paquets mis au cours d'une période considérée qui peut être la durée d'une connexion. Le taux d'erreurs = (Nt-N)/Nt = 1-N /Nt. Avec N= le nombre total de paquets correctement remis à la couche supérieure et Nt= le nombre total de paquets transférés. ◻ Il faut noter que les erreurs peuvent parvenir de paquets perdues, de paquets incorrectes et de paquets en surnombre. 312 Exercice : Un réseau est destiné à transférer un fichier texte de 1000O maximum en un temps de transmission minimal de 1ms. 1) ASCII 1) Quel est le nom du code informatique historiquement le plus ancien, servant au codage des caractères ? 2) 1 octet 2) Sur combien d’octet ce code code les caractères ? 3) Débit = Quantité de 3) Calculer le débit nécessaire pour transférer les fichiers texte, tel données / temps que défini dans l’introduction. donc Débit = (1000 x 8)/10-3 = On désire transmettre le fichier sur un réseau local à 10 Mbits/s. Le 8Mbit/s rendement du protocole utilisé est de 80 %. Rendement =nbre de bits de données/nbre de bits transmis 4) Quantité de données à Remarque: Lors d'une transmission, le protocole utilisé ajoute des transmettre= Quantité de informations pour assurer un échange correct des données. Par données utile/rendement= exemple pour un rendement de 0,8, lorsqu'on transmet 100 bits (1000 x 8)/ 0.8=104bit sur le réseau, 80 des 100 bits sont des données et donc 20 des 100 bits sont des bits dûs au protocole. 5) Temps de transmission = Quantité de données 4) Calculer, en tenant compte du rendement du protocole, la quantité de données à transmettre. /débit=104/(10x 106)= 10-3 s=1ms 5) Calculer le temps de transmission. 313 ◻ Les paramètres de performance pour le transfert de paquets IP : IP packet transfer delay (IPTD) : est le temps, (t2-t1) avec t2 > t1, qui s' écoule entre l'envoi d'un paquet IP par M1 et sa réception par M2. Mean IP packet transfer delay : c'est la moyenne arithmétique d'un ensemble d'IPTD. IP packet delay variation : Plusieurs paramètres sont utilisés pour capturer l'effet de la variance du délai : End-to-end 2-point IP packet delay variation Interval-based limits on IP packet delay variation Quantile-based limits on IP packet delay variation IP packet error ratio (IPER) : IPER est égal au nombre de paquets IP erronés sur la somme du nombre de paquets IP sans erreurs et du nombre de paquets IP erronés. IP packet loss ratio (IPLR) : IPLR est égal au nombre de paquets IP perdus sur le nombre total de paquets IP transmis. Spurious IP packet rate : Il est égal au nombre total de paquets erratiques sur un intervalle de temps donné. IP packet throughput (IPPT) : IPPT est égal au nombre total de paquet IP reçu sans erreurs sur un intervalle de temps donné. Octet based IP packet throughput (IPOT) : IPOT est égal au nombre total d'octets contenu dans des paquets IP reçu sans erreurs sur un intervalle de temps donné. 314 Résumé: ◻Les métriques sont nécessaires pour définir avec exactitude les besoins qui diffèrent entre les différents types de trafics (voix, données…) ◻Il existe deux méthodes pour évaluer les métriques: ◻La méthode dite active consiste à injecter du trafic connu sur le réseau et contrôler les paquets retournés. La méthode appelée passive consiste ◻ à analyser les paquets reçus. Cette approche nécessite de lancer les applications sur lesquelles on souhaite appliquer la QoS. 315 1.3. Classification du trafic Quels sont les différents types de service rendus par le réseau et les ◻ attentes de l'utilisateur ? ◻ Transfert de fichiers, Mail ◻ fiabilité des données, rapidité (débit) ◻ Streaming Vidéo ◻ relative fiabilité, absence de gigue ◻ Voix sur IP, Visioconférence et Chat ◻ faible délai ( temps réel ), relative fiabilité, absence de gigue ◻ Jeu en réseau / simulation distribuée interactive ◻ fiabilité des données, faible délai 316 ◻ Applications temps réel : Leur caractéristique est que les données reçues après un certain délai ne sont plus utilisables par l'application réceptrice. ◻ Applications temps réel intolérantes : pour celles-ci, lorsque des données sont perdues, le service ne peut être rendu (contrôle de procédé, vidéo haute qualité, etc.). ◻ Applications temps réel tolérantes : l'application peut supporter une perte de données au prix d'une perte de qualité. ◻ Applications temps réel adaptatives : l'application détecte la perte de données et s'adapte à celle-ci. ◻ Applications temps réel non adaptatives : l'application ne détecte pas la perte de données. ◻ Applications élastiques : Elles peuvent toujours attendre des données arrivant en retard. Elles utilisent celles-ci immédiatement. Interactif par rafales, par ex. Telnet, Interactif par trains, par ex. FTP, Asynchrone par trains, par ex. mail. 317 ◻ Les différents types d’applications induisent des flux qui se contrarient Les transferts de gros volumes (par exemple les transferts de fichiers) sont élastiques, et prennent toute la bande passante disponible Les applications interactives (question/réponse) consomment une bande passante prévisible, mais exigent des délais courts Elles sont pénalisées par les transferts de fichiers Les applications temps réel (téléphonie ou vidéo) ne sont pas élastiques (besoin borné en bande passante), mais elles doivent avoir un débit garanti, et un délai court et fixe Elles sont pénalisées par les applications de gros transferts ◻ Avoir une bande passante surdimensionnée ne suffit pas Il faut empêcher les applications élastiques de prendre toute la bande passante ◻ Avoir beaucoup de bande passante permet juste de simplifier le traitement de la qualité de service Besoin de mécanismes de QoS simples, implémentés en hardware 318 319 Dee l’application au réseau 320 Pour assurer une qualité de service sur un réseau, il faut : ◻ un protocole de transmission à performances garanties un protocole de routage réservant des ressources dans les routeurs traversés un protocole de signalisation contrôlant les performances réelles, dans le réseau et de bout en bout des routeurs mettant en œuvre ces protocoles. 321 ◻ Protocoles de transmission (niveau 2): ATM, SDH, frame Relay ◻ Protocoles de routage (niveau 3): IPv4, IPv6, ATM ◻ Protocoles de signalisation (niveau3): Integrated Services-Differentiated services Intserv - RFC1633 : définit des classes de service et propose d'assurer les qualités de service associées par la réservation de ressources dans le réseau en utilisant un protocole de réservation de ressources dynamique RSVP (Ressource ReSerVation Protocol) Guaranteed QoS in Intserv - RFC2212 Control Load QoS with Intserv - RFC2211 Difserv - RFC2474 : permet un traitement approprié dans le cœur du réseau pour assurer la qualité de service requise en définissant la façon d’identifier des flots en bordure de réseau par marquage des paquets de ces flots afin de garantir le débit 322 MultiProtocol Label Switching MPLS: Ce modèle est conçu pour permettre la construction de très vastes réseaux IP composés de routeurs et commutateurs de paquets ou cellules. Le schéma général est similaire celui de DiffServ, le but étant ici de router les paquets IP plus grande vitesse. Le principe consiste à rejeter tout le traitement associé au routage des paquets dans les routeurs d'entrée du réseau MPLS et de marquer (par un Label) ces paquets de façon ce que les routeurs et commutateurs du cœur de réseau n'aient plus qu' à considérer ce label pour retrouver la route faire suivre au paquet dans une table adéquate dite de commutation (Forwarding Table). 4 classes de service (Premium, Gold, Silver et Bronze) 323 Il existe cinq moyens complémentaires d’assurer la qualité de service ◻ Surdimensionnement de la capacité du réseau ◻ Utiliser des applications adaptatives Interpolation de données manquantes (temps réel) Émettre à débit variable en fonction de la congestion Buffers de réception pour compenser la gigue… ◻ Traitement sélectif du trafic sans réservation préalable Le trafic est classifié et le traitement différencié (DiffServ) Chaque classe a son traitement spécifique Files d’attente séparées Traitement spécifique en cas de congestion Les trafics à privilégier sont prioritaires ◻ Réservation dynamique de ressources Frame Relay, ATM, IntServ - RSVP ◻ Ingénierie de trafic Répartir le trafic dans le réseau en fonction de la bande passante disponible MPLS 324 325 2. Techniques de gestion de la QoS dans les réseaux IP ◻ Pour assurer la QoS deux approches s'affrontent. La première approche informatique propose le surdimensionnement du réseau, une solution simple et un service unique pour tous, le best effort. L’augmentation de la bande passante est nécessaire comme première étape pour répondre aux contraintes requises par les applications et assurer la QoS demandée, mais surdimensionné se traduit par un coût. Cette solution ne résout pas entièrement le problème, même si les ressources sont abondantes : les techniques de transport sur fibre optique vont libérer des dizaines de Térabits par seconde dans le cœur du réseau, et la puissance de calcul des processeurs en croissance, favorisera la mise en œuvre des algorithmes de routage des paquets des vitesses en Tbps. La deuxième approche télécoms propose la gestion de la capacité et des ressources existantes, donc une solution complexe nécessitant des mécanismes de traitement différenciés des différents types de trafics.  2.1. Surdimensionnement 326 ◻Le surdimensionnement (Over provisioning) consiste à doter le réseau d’une capacité qui dépasse largement la charge demandée. ◻Le principe est d'augmenter toujours la bande passante disponible pour éviter la congestion, les délais dans les files d'attente et les pertes de paquets. ◻Il y a toujours suffisamment de capacité réseau, les garanties de service peuvent être offertes. ◻Malgré tout, il y aura toujours quelqu'un un moment donné pour surcharger un segment ou se plaindre de performances insuffisantes sur un service important. ◻Le surdimensionnement ne fera que repousser plus tard les problèmes actuels sans pour autant garantir quoi que ce soit. ◻Cette solution n'est pas viable économiquement, car elle conduit à une mauvaise utilisation des ressources. En effet, de grandes quantités de bande passante restent sans utilisation.  2.2. Integrated services 327 ◻L'architecture IntServ propose une extension de l'architecture d'Internet pour fournir des services intégrés (supporter aussi bien les services multimédias temps réel que les services donnés). ◻Cette architecture, conçue la même époque qu'ATM, avait pour objectif d'offrir un service semblable sur la couche réseau d'Internet. Le but était donc de pouvoir améliorer le réseau Internet et d'en faire un réseau à intégration de services. ◻Les extensions qui seront ajoutées ne remplacent pas le service IP de base. De façon abstraire, l'extension de l'architecture proposée comprend deux éléments : un modèle de service étendu appelé le modèle IntServ une plateforme de référence pour l'implantation qui donne une terminologie et un programme générique d'organisation pour la réalisation du modèle IntServ. 328 Le modèle IntServ repose sur deux hypothèses : ◻ L'infrastructure Internet sera utilisée pour supporter aussi bien les communications temps réels que les communications non temps réel. En effet, il n'est pas concevable de construire une nouvelle infrastructure pour les services temps réel qui va supprimer l'avantage principal qui est le partage statistique entre les trafics temps réel et données. Par ailleurs, le modèle IntServ fonctionne avec la même pile de protocoles utilisée pour les trafics data. Le protocole IP existant sera donc utilisé. Les ressources (e.g. la bande passante) doivent être explicitement gérées pour satisfaire les exigences des applications. Ceci implique que la réservation des ressources et le contrôle d'admission sont les deux blocs principaux du modèle. Pour cela, l'émetteur envoie une requête de réservation de bande passante qui doit être acceptée par l'ensemble des équipements qui seront traversés par les flux. Le protocole utilisé est le RSVP (Ressource ReSerVation Protocol). 329 ◻Le modèle IntServ qui opère au niveau du flux (per flow) est basé sur la réservation des ressources et distingue : Les services dits élastiques (ou non temps réels) : l'application attend d'avoir reçu la totalité des paquets avant de traiter les données, le délai de transit peut largement varier, le service est de type best effort Les services temps réel sensibles au délai et surtout à la gigue : Le modèle distingue les services tolérants à une variation du délai de transit pour lesquels une classe de service contrôle de charge est dénie, et les services ne tolérants pas de variation pour lesquels une classe de service garanti est dénie. ◻ Pour son implémentation, plusieurs composantes sont nécessaires : une méthode pour traduire la demande de QoS de l'utilisateur dans le paquet IP afin que les nœuds puissent en tenir compte, une procédure de signalisation pour avertir les nœuds à traverser et des mécanismes de contrôle d'admission et de trafic pour maintenir la QoS. 330 ◻En fonctionnement classique, le routage de paquets IP est complètement égalitaire. Tous les paquets ont la même qualité de service et sont traités, dans les files d'attente, selon le principe FIFO. Avec l'adoption du modèle IntServ, le routeur doit implémenter une QoS pour chaque flux. ◻Afin de pouvoir effectuer un contrôle du trafic en identifiant chaque paquet entrant et donc pouvoir l'associer à une certaine classe (sachant que tous les paquets figurants dans une classe sont soumis au même traitement), le modèle IntServ est structuré autour de quatre composants : un classificateur ("classifier"), un ordonnanceur de paquets ("packet scheduler"), un contrôle d'admission ("admission control routine") et un protocole de réservation de ressources ("reservation setup protocol"). 331 ◻ Le classificateur ◻ Il détermine à quelle classe appartient le paquet en se basant sur le contenu de l'en-tête du paquet et/ou un numéro de classification ajouté à chaque paquet. ◻ Une classe peut correspondre à une catégorie de flux, par exemple les flux audio, ou encore les flux vidéo. D'un autre côté , une classe peut correspondre à un seul flux. Cela permet d'attribuer des caractéristiques distinctes à chaque flux. ◻ La manière dont la classification est faite, peut différer entre un routeur et un autre. 332 ◻ L'ordonnanceur de paquets : ◻ Il reçoit les paquets du module précédent et gère leur retransmission en utilisant des files d'attente. ◻ L'ordonnanceur doit être implémenté à l'endroit où les paquets sont mis en files d'attente, cela correspond souvent à l'interface de sortie et donc au protocole de niveau 2 du modèle OSI. ◻ Un autre élément peut parfois faire partie de l'ordonnanceur, il s'agit d'un estimateur ("meter"), qui mesure les propriétés du flux de l'interface de sortie. ◻ Chaque file d'attente implémente des algorithmes de gestion des paquets pour permettre un partage des ressources en fonction des besoins demandés par les utilisateurs. 333 ◻ Le contrôle d'admission : ◻ Il vérifie s'il est capable de garantir la qualité de service requise par un flot et s'il y a suffisamment de ressources disponibles au moment de l‘établissement d'une réservation. ◻ Il implémente ainsi l'algorithme qui détermine si un routeur, est à même de répondre à une nouvelle demande de QoS, sans entraver les demandes qui ont été déjà accordées. ◻ Le contrôle d'admission est invoqué dans chaque nœud afin de prendre la décision d'accepter ou de refuser une demande de service temps réel le long du chemin entre les utilisateurs finaux. ◻ Afin de pouvoir garantir que la QoS demandée est bien présente, on confie au contrôle d'admission, d'autres taches, comme l'authentification de ceux qui effectuent des réservations. ◻ Une autre fonctionnalité est le fait d' établir des rapports concernant ce qui a été fait, qui a demandé quelle réservation, cela afin d'obtenir une sorte de feedback de l'utilisation des mécanismes de QoS. 334 ◻ Le protocole de réservation de ressources : ◻ Un démon du protocole de réservation est en permanence en communication avec les différents composants du routeur. A partir de la requête formulée par une application, il crée et maintient un état décrivant les spécificités d'un flux dans chaque routeur le long du chemin, ainsi que dans les hôtes finaux. ◻ Dans le modèle IntServ, il est possible de définir plusieurs protocoles de réservation, mais cela introduit un risque de confusion élevé, il est donc préférable de s'en tenir à un seul. RSVP va donc se charger de demander quel type de réservation est désiré. ◻ De manière à pouvoir indiquer de quel type de ressources a besoin une application, elle doit spécifier la QoS désirée en utilisant une liste de paramètres appelés " flowspec". Le flowspec est transporté par RSVP et cela le long du chemin entre les utilisateurs finaux. Le flowspec est transmis au contrôle d'admission afin de vérifier l'acceptabilité, ensuite il est transmis à l'ordonnanceur afin de pouvoir paramétrer ce dernier. 335 Un routeur a deux parties fonctionnelles : ◻ ◻ une partie qui s'occupe de transmettre les paquets ◻ et une autre partie qui contient le code de l'implémentation. La partie qui s'occupe de transmettre les paquets est utilisée pour chaque paquet, elle doit de ◻ ce fait être optimisée au maximum, raison pour laquelle, cette partie est réalisée au niveau hardware, contrairement à l'autre partie qui elle est plutôt une partie de logique (partie réalisée en software). 336 ◻La partie inférieure de l'implantation du routeur qui se charge de retransmettre les paquets est divisée en trois parties : le pilote d'entrée ("Input Driver"), le pilote de sortie ("Output Driver") implante l'ordonnanceur de paquets le retransmetteur Internet ("Internet Forwarder") qui se charge pour chaque paquet d'analyser l'en-tête IP. Il contient le classificateur qui permet de classifier chaque paquet en fonction de son contenu, ainsi que de le router vers le pilote de sortie approprié. La partie supérieure de l'implantation du routeur est en réalité du code chargé en ◻ mémoire. C'est là que se trouvent les mécanismes qui ont comme fonctionnalité de vérifier l'acheminement des données. L'agent de routage implémente un protocole de routage et façonne une table de routage, c'est en fait la fonction fondamentale d'un routeur. Le "Reservation Setup Agent" implante le protocole utilisé pour réserver les ressources. Si le contrôle d'admission donne son "OK" concernant une nouvelle requête, alors les changements appropriés sont effectués dans le classificateur et dans l'ordonnanceur afin d'implémenter la QoS désirée. Le "Management Agent" est responsable de gérer le réseau. Cet agent est capable de modifier le classificateur ainsi que l'ordonnanceur afin de mettre en place le partage d'un lien (ce qu'il y a derrière une interface physique), ainsi que de définir des critères concernant la politique d'admission. 337 ◻Le groupe de travail IntServ a rendu l'Internet un réseau à intégration de services en distinguant deux classes de services supplémentaires par rapport au service traditionnel du best-effort. la classe charge contrôlée, mieux connue sous le nom controlled-Load Service, où les performances reçues sont celles d'un réseau peu chargé et la classe de service garanti, ou encore Guaranteed Service, où l'application qui demande le service possède l'assurance que les performances du réseau vont rester celles dont elle a besoin. 338 ◻ Best-Effort service : Le service dit au-mieux (Best-Effort, ou BE) ne garantit aucun critère de qualité de service: ni le délai de transmission, ni l'absence de pertes de paquets, ni l'absence de gigue ne sont considérés pour acheminer les flots de diverses natures. Ce service n'est évidemment pas approprié pour les flux multimédia qui transportent des informations à délivrer en temps réel. Il peut toutefois servir pour le transport de données. La messagerie électronique serait l'application la moins sensible à tous ces critères et supporterait donc sans trop de contraintes, le service du Best-Effort. 339 ◻ Controlled-Load Service Le service "Controlled-Load (CL)" effectue une différenciation entre les trafics et leur attribue des codes de priorité en fonction de la sensibilité des applications. Bien évidemment, ce service est plus adéquat que le Best-Effort pour les applications multimédia très sensibles à la congestion dans le réseau. Il offre un service proche de celui présenté par le Best-Effort lorsque celui-ci se trouve particulièrement dans des conditions de réseaux non congestionnés. La garantie est donc fournie pour le débit. Mais contrairement au Best-Effort, le service de charge contrôlée ne détériore pas la qualité du flot lorsque le réseau est surchargé. En effet, les applications qui demandent ce type de service doivent tenir informé le réseau du trafic qui va le traverser, de manière à obtenir une meilleure exploitation du service et du réseau lui-même. 340 ◻ Guaranteed Service Le service garanti fournit des bornes strictes, démontrables mathématiquement, sur le délai maximum d'acheminement des paquets de bout en bout. Il fait son possible pour garantir aussi bien la bande passante que le délai d'acheminement. Ce service est particulièrement adapté aux applications (voix, vidéo) ayant des exigences de qualité de service très strictes. Il permet d'apporter aux applications un contrôle considérable du point de vue délai. Le délai d'une application se subdivisant en plusieurs sous délais, seul le délai d'attente est déterminé par le service garanti. De ce fait, une application peut précisément estimer à l'avance quel délai de mise en attente le service garanti peut offrir (si le délai d'une application est supérieur à celui attendu, celle-ci peut modifier le token-bucket du trafic ainsi que le taux de données pour obtenir un plus faible délai) 341 ◻ Pour pouvoir utiliser les services définis pour les réseaux intégration de services, le groupe IntServ a dû définir et déterminer une propriété pour caractériser les trafics d'un tel réseau. La caractérisation s'effectue selon le modèle le token bucket ( seau à jetons ). ◻ Les paramètres de spécification de trafic sont contenus dans la variable de spécification TSpec (Trafic Specification). Token-Bucket (seau à jetons) caractérise un flux grâce à deux paramètres le premier terme (r) représente le débit moyen d' émission le deuxième indique la taille maximale des rafales (b) que la source peut générer. 342 Exercice: Soit un réseau avec la spécification du flux suivante: Taille max du packet M=1Ko Débit maximum d=100Mbps Débit Token Bucket r=20Mbps Taille du token Bucket b=1Mo Combien de temps dûre au maximum une rafale? Temps_rafale= b/(d-r)=0.1s 343 ◻ Avec l’outil Token Bucket, un flux est caractérisé par son débit moyen et la déviation temporaire acceptable de ce débit. A l'instant initial, le seau est rempli de jetons. A l'arrivée d'un paquet le seau est débité de L jetons, où L représente la taille en octets du paquet arrivant. Entre l'arrivée de deux paquets, le niveau du seau monte une vitesse de r jetons/seconde. Le remplissage s'arrête quand le niveau du seau atteint b. Tant qu'il y a des jetons dans le seau le flux est considéré conforme aux spécifications. Le token bucket regroupe trois paramètres parmi cinq du TSpec. ◻ La capacité (paramètre b) et le débit autorisé (paramètre r), ils permettent de contrôler le débit moyen du flot. Le paramètre p est utilisé pour limiter le débit crête. La taille maximale du paquet contenu dans le flot (notée M), La qualité de service ne sera garantie qu'aux paquets du flot n'excédant pas la taille maximale définie dans TSpec. La plus petite unité de traitement (notée m). Le paramètre m indique que tous les paquets de taille inférieure à m seront tout de même traités comme un paquet ayant la taille m. 344 ◻RSVP est un protocole de signalisation qui a pour but principal la réservation dynamique des ressources (bande passante) pour un trafic déterminé. ◻RSVP n'est pas un protocole de routage. Il est censé travailler avec les protocoles de routage unicast et multicast. RSVP travaille au dessus de IP (IPv4 ou IPv6) et occupe la place d'un protocole de transport dans la pile des protocoles mais ne transporte pas de données utilisateurs. ◻Dans les cas où le système ne permet pas l'utilisation de services réseau directement ("raw"), RSVP est encapsulé dans des paquets UDP. RSVP passe de façon transparente les routeurs non RSVP. ◻Pour assurer la qualité de service, RSVP se charge la fois de trouver le meilleur chemin pour acheminer les données, ainsi que de dialoguer avec les équipements intermédiaires. Il est évident que pour réserver des ressources il faut pouvoir dire combien et dans quelle mesure l'on nécessite des ressources. Pour ce faire, il faut obtenir des informations de plusieurs partenaires ; les intervenants, le réseau sur lequel ils se trouvent, les routeurs qu'ils doivent traverser, etc. 345 ◻RSVP établit et maintient un état logique entre les nœuds faisant partie d'un chemin réservé. Il faut comprendre qu'il ne s'agit en aucune façon de monopoliser physiquement un lien donné, ou encore d' établir un circuit virtuel. Au contraire, RSVP met jour régulièrement un chemin définit à travers l'emploi de messages de rafraichissement périodiques, envoyés le long du chemin afin de maintenir l‘état. ◻RSVP rend obligatoire la demande de QoS par le récepteur (l'application participante) plutôt que par l' émetteur (l'application source). Le récepteur apprend les spécifications du flux multimédia par un mécanisme hors bande. Le récepteur peut ainsi faire les réservations qui lui sont appropriées (certains émetteurs auraient eu tendance à toujours demander la réservation la plus importante qui aurait nui au système dans sa globalité). ◻RSVP travaille notamment avec les messages PATH et RESV. Le message PATH part de la source vers la destination et RESV emprunte le chemin inverse. PATH indique les caractéristiques du trafic, et RESV opère la réservation. 346 ◻ Inconvénients de IntServ Le Service de bout en bout est garanti si tous les routeurs sont Intserv Impraticable pour les flots de durée de vie courte (TTL