La garantie de la qualité de service dans réseau ip
Dans nos jours, les opérateurs, les intégrateurs et les ISP, quelque soit leur taille, font constamment face à des défis d’adaptation de leurs réseaux afin de répondre aux besoins de plus en plus accrus de leurs clients. La maîtrise de la QoS revêt alors une importance capitale. L’assurance de cette maîtrise passe par une évolution aussi bien par une garantie au niveau des moyens de transport, notamment en augmentant les débits des liens, qu’au niveau de la mise en place des protocoles de communication adéquats. Un des protocoles de communication les plus promettant pour aider à la maîtrise de la QoS est le Multi Protocol Label Switching (MPLS) qui offre des mécanismes simples pour l’acheminement des flux dans les réseaux orientés paquets. Un autre mécanisme prometteur est DiffServ (Differentiated Services). Après classification des flux en plusieurs classes, il traite les classes présentes différemment. C’est en fonction de ce traitement distinct sur chaque nœud DiffServ, que la QoS des trafics prioritaires sera améliorée et la QoS des trafics moins prioritaires sera obtenue. Le protocole RSVP (Resource ReserVation Protocol) met en place des réservations de ressources pour chaque flux au niveau de chaque routeur capable du réseau afin de garantir la QoS de bout en bout. Or plusieurs études ont montré que le facteur d’échelle de RSVP est très pénalisant. De plus, un nombre réduit de classes de service suffit pour donner la QoS recherchée à l’ensemble des applications existantes. Ces deux observations nous ont contraints à étudier uniquement le mécanisme DiffServ dans cette thèse. Ce chapitre présente 5 grands axes de recherche. Le paragraphe 2 décrit les aspects les plus importants de MPLS. Comme la normalisation de ce dernier n’est pas encore achevée, nous nous contenterons de présenter les volets complétés et nous indiquerons ensuite les orientations en cours de normalisation. Le troisième paragraphe présente les différentes possibilités d’utilisation de DiffServ. Dans le paragraphe quatre, nous résumerons la normalisation de l’interaction entre DiffServ et MPLS. Le cinquième paragraphe décrit quelques algorithmes d’ordonnancement de file d’attente, avec lesquels sera réalisée la différenciation de service de chaque nœud du réseau.
Le protocole MPLS
Dans le but de construire les tables de routages, les routeurs présents dans un réseau IP communiquent entre eux à travers des protocoles de routage. Les entrées de ces tables changent selon la technique de routage utilisée. Par exemple, pour la technique « Next Hop Routing », les entrées sont : l’adresse de destination, l’adresse du prochain routeur et le port de sortie. Le premier protocole de routage utilisé sur Internet était le protocole RIP (Routing Information Protocol) (RFC 2453). Celui-ci ne permet la synchronisation que de 16 routeurs à la fois. L’amélioration de RIP conduit au protocole OSPF (Open Shortest Path First) (RFC 2328) qui tient compte de la charge des liaisons. Un protocole concurrent de OSPF est IS-IS (Intermediate System-Intermediate System), une norme de l’OSI (norme de l’ISO 10589 et les RFC: RFC 1195, RFC 3719, RFC 3787 et RFC 3784). Il est possible de définir et d’administrer plusieurs domaines de routage. Chaque domaine de routage est appelé systèmes autonomes (AS). Le routage inter AS se fait via des routeurs passerelles qui communiquent entre eux par le protocole BGP (Border Gateway Protocol) (RFC 1771), selon des accords conclus entre les opérateurs qui gèrent les AS. Pour faciliter la gestion, plusieurs AS peuvent être gérés par le même opérateur. Le protocole de routage utilisé est alors le BGP intérieur. A la fin des années 1990, l’infrastructure a été revue suite à l’apparition de l’ATM (Asynchronous Transfer Mode): les routeurs IP sont désormais aux bordures des réseaux et raccordés entre eux au cœur par des commutateurs ATM. Bien que l’ingénierie du trafic s’est beaucoup développée grâce à ATM par l’introduction des circuits virtuels ainsi que par la possibilité de réaliser des statistiques par circuit et d’équilibrer la charge entre différentes liaisons, des limitations subsistent. D’une part, il fallait gérer simultanément deux types de réseaux (IP et ATM) et d’autre part, les entêtes de ses cellules ATM introduisent une perte de 10% de la bande passante. Lorsque le trafic dépasse un certain seuil, le fonctionnement dans le réseau IP se dégrade compte tenu de la capacité limitée des routeurs. Les files d’attente se remplissent et conduisent les flux à un délai supplémentaire à la transmission. De plus, des paquets se voient rejeter lorsqu’il y a débordement des files d’attente dans les routeurs. Pour pallier à ces problèmes, l’ingénierie du trafic Internet a eu longtemps recours au surdimensionnement avec une utilisation des métriques afin de favoriser le routage sur des liens particuliers. Cependant, cette méthode admet des limitations du fait qu’elle sur-utilise certains liens et sous-utilise d’autres. De même, c’est une approche empirique qui n’est pas garantie à long terme. A partir des ces différentes constatations, nous pouvons tirer plusieurs objectifs recherchés qu’il faudra satisfaire: • L’amélioration des performances de routage IP et de son expansion. • L’ingénierie du trafic IP: faciliter le routage explicite et garantir des contraintes sur les routes empruntées. • L’introduction des VPN (Virtual Private Network) et des mécanismes de contrôles des tunnels. • Le contrôle de la QoS (délai de transmission, débit, …) pour les applications du type voix ou vidéo sur IP. • Développer un algorithme unique de commutation capable de supporter différents algorithmes de routage. Ces différentes contraintes ont amené l’IETF à la normalisation et le développement de MPLS. C’est un protocole qui répond largement aux différentes contraintes citées plus haut grâce notamment à son facteur d’échelle favorable et ses possibilités d’interagir avec IP. Deux applications principales ont favorisé le déploiement de MPLS. D’une part ce sont ses différentes capacités d’ingénierie de trafic. C’est un aspect souhaité par les fournisseurs de réseau qui veulent optimiser les coûts de leur investissement. D’autre part, c’est sa facilité de création des VPN. Cet aspect est plus recherché par les entreprises pour pouvoir relier plusieurs sites distants et autonomes.
Entête MPLS
L’entête MPLS, noté parfois entête « shim », se situe entre les entêtes des couches 2 et 3 (c.f. Figure 1). Figure 1: Place de l’entête MPLS Schématisée à la Figure 2, l’entête MPLS dispose d’une longueur de 32 bits formée des champs suivants [18]: • Un Label de 20 bits. Cette étiquette courte de longueur fixe marque les paquets à transférer sur le même chemin. Le contenu d’un label n’est pas structuré et n’a de signification que localement, entre les deux nœuds qui l’utilisent. • Le champ Exp (expérimental) de 3 bits, connu sous le nom CoS. Il peut affecter les algorithmes d’ordonnancement (Scheduling) et/ou de la gestion de la file (Queue Management). Il peut être exploité aussi lors de l’utilisation combinée de DiffServ et MPLS. • Un bit S d’empilement (stack) pour supporter une hiérarchisation des entêtes. • Un champ TTL (Time To Live) de 8 bits indiquant la durée de vie. Figure 2: Entête MPLS Le champ TTL est copié du champ TTL du paquet IP quand celui-ci vient d’être labellisé. Quand le paquet quitte le réseau MPLS, le champ TTL de l’entête MPLS remplace le TTL du paquet IP. Le label MPLS est ajouté au paquet au niveau du LER (Label Edge Router) d’entrée (Ingress LER) et retiré (désencapsulé) par le LER de sortie (Egress LER). Le LER pourra chercher des informations dans le numéro de port d’application, l’interface d’entrée, etc… pour allouer un Label.
Label Switch Path
(LSP) Sans aucune information supplémentaire, chaque LSP crée, qui est un chemin unidirectionnel entre deux paires de nœud, suit l’itinéraire indiqué par le protocole de routage déployé dans le réseau. Ainsi, si aucune contrainte n’est imposée, les LSP passeront par la même route comme si un routage normal avait été utilisé. Cependant, avec MPLS, les LSP peuvent être créés à des fins précis. Dans ce dernier cas, les LSP devront être bien contrôlés, vu qu’ils doivent répondre à des besoins spécifiques du réseau. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1 2 3 Label Exp S TTL Entête Donnée MPLS Entête Entête IP Niveau 2 La garantie de la qualité de service dans un réseau IP
La création des LSP
La création des LSP peut être faite de deux manières différentes: soit manuellement soit en utilisant une signalisation. La création manuelle crée des LSP statiques, inadaptable en cas de panne d’une connexion. De plus, les différents Labels utilisés devront être attribués manuellement sur chaque LSR. Par contre, la création par la signalisation ne nécessite pas d’intervention sur chaque nœud et s’adapte en cas d’une chute d’une liaison. Deux protocoles sont utilisés pour créer les LSP: RSVP-TE (une extension de RSVP) (RFC 3209) et LDP (RFC 3036). Dans le cas de l’utilisation de la signalisation pour créer les LSP, deux types de LSP peuvent exister: d’une part les LSP sans contrainte de passage par des nœuds et d’autre part les LSP qui devront passer par des LSR particuliers. L’arbre des LSP des premiers est construite à partir des tables de routage, via les protocoles IGP (Interior Gateway Protocol) tels SPF, ISIS, RIP… Le second type de LSP noté ER-LSP (Explicite Routed LSP) suit le chemin que le LSR source a choisi. Il s’agit d’un routage de source où l’acheminement est déterminé par l’émetteur. Ces LSR sont synonymes des Permanant Virtual Chanel (PVC) de Frame Relay ou ATM. Dans le cas où tout le chemin est spécifié, nous parlerons de routage strict. Néanmoins, MPLS propose plus de flexibilité: uniquement une partie du chemin d’un LSP peut être constitué de LSR prédéfinis. Le reste du chemin empruntera la route qui liera ces LSR pour former le LSP noté lâche. Il est à noter que le routage de source lâche nécessite moins de configuration qu’un routage de source stricte. De plus, s’il est nécessaire, la route découverte par le routage intrinsèque au réseau pourrait être figée. Ce dernier schéma est noté par le « route pinning ». Pour une flexibilité de l’ingénierie de trafic, il est possible de construire des ER-LSP en plus des LSP automatiquement construits. Un autre type de signalisation porte des informations concernant les caractéristiques de QoS des LSP. Si ces conditions sont définies, chaque LSR du réseau devra s’assurer que les caractéristiques sont maintenues. Ainsi, ce sera possible de garantir les performances de bout en bout. Les caractéristiques définies pour les LSP peuvent englober : • La bande passante, incluant la BP soutenue, maximale, et la taille maximale du burst. • Le délai et la gigue. • La sélection du lien. Ces caractéristiques sont implémentables grâce à l’extension du protocole LDP en CR-LDP [RFC 3212 et 3214] et à l’ajout de nouvelles extensions à RSVP-TE [RFC 3473].
Les méthodes de distribution de label
Il existe deux méthodes de distribution d’association FEC-Label : • La première est « Downstream unsolicited » Figure 3: Downstream Unsolicited LSR1 et LSR2 sont deux LSR adjacents. Afin de découvrir le « next hop » pour un FEC donné, LSR2 crée un label pour cette FEC et communique par LDP l’association à LSR1. LSR1 LSR2 Association: label – FEC La garantie de la qualité de ser 10 vice dans un réseau IP LSR1 insère l’association dans sa table de commutation. Si pour une demande de connexion donnée, LSR2 est le « next hop » pour ce FEC, LSR1 peut alors utiliser le label. • La seconde est la distribution « Downstream on demand » Figure 4: Downstream on demand LSR1 reconnaît LSR2 comme son « next hop » pour un FEC donné. Une demande est alors faite à LSR2 par LSR1 pour créer un label pour ce FEC. Si LSR2 reconnaît le FEC et a lui-même un « next hop », il crée alors un label et le communique à LSR1. Ces deux méthodes peuvent être présentes dans un réseau, voir en même temps entre deux LSR. La première méthode utilise beaucoup de signalisations en créant toutes les associations possibles entre LSR adjacents avec toutes les FEC possibles. Mais l’avantage est que si un flux arrive, il sera immédiatement acheminé. Par contre, dans la seconde méthode, la réservation des Labels est effectuée quand un flux demande à être acheminé. Donc, elle consomme moins de ressources pour les réservations mais admet un temps de latence plus grand pour le premier paquet de la connexion.