Mise en oeuvre des deux approches standard : DiffServ et

UNIVERSITE PIERRE ET MARIE CURIE ASHTARI DARIUS Master Informatique Projet LUIS GABRIEL UE PRES DiffServ et IntServ/RSVP

FOURMAUX OLIVIER et validation par la transmission de trafic Triple-Play

1/33

Rapport final

Mise en oeuvre des deux approches standard : DiffServ et IntServ/RSVP

et validation par la transmission de trafic Triple-Play entre les deux entreprises

Encadrant : FOURMAUX Olivier

Etudiants : ASHTARI Darius et LUIS Gabriel

Table des matières

1. Cahier des charges ............................................................................................................... 2

2. Plan de développement ........................................................................................................ 3

3. Contexte technologique........................................................................................................ 5

4. Analyse .................................................................................................................................. 7 4.1 DiffServ.......................................................................................................................... 7 4.2 IntServ/RSVP................................................................................................................ 9 5. Conception .......................................................................................................................... 13 5.1 Description du Testbed………………………………………………………………14 5.1 Mise en œuvre et validation de DiffServ .................................................................... 16 5.2 Mise en œuvre et validation de IntServ....................................................................... 17

6. Compte rendu ..................................................................................................................... 18 6.1 DiffServ..................................................................................................................... 18 6.1.1 Mise en œuvre de DiffServ ............................................................................ 18 6.1.2 Tests de validation de DiffServ...................................................................... 22 6.1.3 Résultats des mesures .................................................................................... 25 6.2 IntServ/RSVP............................................................................................................ 27 6.2.1 Mise en œuvre de .......................................................................................... 27 6..2.2 Validation, problèmes rencontrés.................................................................. 28 6.3 Conclusion................................................................................................................. 29

7. Annexe A ............................................................................................................................. 30

8. Annexe B... .......................................................................................................................... 31

UNIVERSITE PIERRE ET MARIE CURIE D. ASHTARI Master Informatique Projet G. LUIS UE PRES 2006-2007 DiffServ et IntServ/RSVP


2/33 Rapport final

1. Cahier des charges

Avec la démocratisation d’Internet et l’apparition de nouvelles applications nécessitant des garanties de bandes passantes, de délai de transfert et de taux de pertes, l’incorporation de mécanisme gérant la qualité de service a été nécessaire. On peut citer à titre d’exemple, le concept de Triple Play proposé par les fournisseurs d’accès qui permet d’avoir de la téléphonie IP de façon sûre, de la télévision de bonne qualité et des qualités plus ou moins bonnes pour le reste du trafic IP. Cette offre de QoS connaît deux grandes approches : DiffServ et IntServ/RSVP.

Dans notre projet nous tenterons de comparer ces deux protocoles de qualité de service

en insistant sur leurs aspects d’application au sein d’un réseau composé de plusieurs domaines.

Pour cela, nous générerons un trafic similaire à celui existant dans le Triple Play à l’aide

de logiciels. Nous implémenterons ces deux modèles de qualité de service et nous réaliserons des tests en contrôlant les différents paquets IP et les flux circulant dans le réseau. De plus, la plateforme de test que nous utiliserons est constituée de plusieurs systèmes autonomes (AS). Ainsi nous pourrons visualiser les problèmes liés à l’application de ces mécanismes de QoS inter AS.

Les équipements mis à notre disposition dans cette plateforme de test sont divers et

variés. Nous avons plusieurs routeurs, switchs et firewalls de constructeurs différents (Cisco, Juniper). Cette plateforme de test est partagée par quatre groupes afin de leur permettre d’élaborer leur projet. Chaque groupe s’occupe d’un AS particulier. Le notre est l’entreprise-1. Il est constitué d’un routeur de bordure (Cisco C2801), d’un routeur pc interne (Zebra/FreeBSD), d’un switch (Cisco C3560), d’un firewall (ASA5510) et de trois pc rackables servant à la génération de trafic.



3/33 Rapport final

2. Plan de développement

Tâche 1 : Réalisation d’une recherche documentaire sur le sujet choisi.

Sous tâche 1 : Effectuer une recherche générale sur la Qualité de Service (QoS). Responsable : Ashtari Darius.

Sous tâche 2 : Effectuer une recherche sur le modèle de QoS DiffServ. Responsable : Luis Gabriel.

Sous tâche 3 : Effectuer une recherche sur le modèle de QoS IntServ/RSVP. Responsable : Luis Gabriel.

Sous tâche 4 : Effectuer une recherche sur la problématique inter-domaine liée à la QoS. Responsable : Ashtari Darius.

Tâche 2 : Etude et conception du testbed et des scénarios de tests.

Sous tâche 1 : Réflexion sur l’architecture matériel pour la réalisation du projet. Responsable : Ashtari Darius.

Sous tâche 2 : Choisir les différents logiciels à installer (Routage, génération de trafic, monitoring…). Responsable : Luis Gabriel.

Sous tâche 3 : Elaboration de scénarios de tests principalement centrés sur la technologie du Triple Play. Responsable : Ashtari Darius.



4/33 Rapport final

Tâche 3 : Configuration et mise en œuvre des équipements de la plateforme. Sous tâche 1 : Mise en place du routage Zebra et ajout des fonctionnalités de

différenciation de paquets IP. Responsable : Luis Gabriel.

Sous tâche 2 : Installation et configuration des logiciels de génération de trafic et de monitoring. Responsable : Ashtari Darius.

Sous tâche 3 : Activation et configuration de DiffServ sur le firewall et sur les routeurs de bordure. Responsable : Luis Gabriel.

Sous tâche 4 : Activation et configuration de IntServ/RSVP sur le firewall et sur les routeurs de bordure. Responsable : Ashtari Darius.

Tâche 4 : Réalisation des tests.

Sous tâche 1 : Phase de tests du modèle de QoS DiffServ. Responsable : Luis Gabriel.

Sous tâche 2 : Phase de tests du modèle de QoS IntServ/RSVP. Responsable : Ashtari Darius.

Tâche 5 : Analyse des résultats et rédaction du rapport.

Responsable : Ashtari Darius & Luis Gabriel.



5/33 Rapport final

3. Présentation du contexte technologique

Depuis quelques années, de nouveaux besoins ont fait leur apparition chez les utilisateurs de réseaux informatiques, que ce soit dans un cadre professionnel ou dans un cadre résidentiel.

Parmi ces besoins, les applications multimédia représentent aujourd’hui un fort potentiel

de développement. Or, ces applications, telles que la téléphonie ou le streaming vidéo, imposent des contraintes fortes sur les délais de transmissions et le synchronisme. Ces contraintes n’ont pas été prises en compte dans la conception initiale des réseaux informatiques que nous utilisons aujourd’hui, qui sont majoritairement basés sur IP et donc sur un service de type « Best Effort ».

Pour remédier à cela, de nombreux groupes de travail se sont formés dès les années 90,

pour apporter des solutions techniques à ces problèmes, et tenter d’adapter les technologies existantes à ces nouveaux besoins.

Depuis le début des années 2000, les opérateurs Internet se sont mis à proposer des offres d’accès résidentiels proposant de faire transiter à la fois des donnés informatiques,mais aussi des flux de téléphonie, et de la vidéo diffusée en streaming. Ces formules sont dites « Triple-Play ».

Pour assurer un bon niveau de qualité perçue par les utilisateurs sur ces trois types de flux, il est nécessaire de respecter les contraintes imposées par ces formes de trafic. Ces opérateurs font donc appel à des techniques dites de « Qualité de service ». Deux grands standards de qualité de service se sont imposés dans l’industrie.

La première, dite « DiffServ » est une approche qualitative relative, c'est-à-dire que l’on va favoriser le traitement dans les routeurs de certain type de trafic par rapport à d’autre, mais sans assurer de garantie quantitative sur le débit, les délais, ou le synchronisme.

La seconde, appelée « Intserv », se base quand à elle sur une réservation de ressources et l’établissement d’un chemin négocié et fixé à l’avance. Cette approche permet de garantir un service précis.

Même si, sur le papier, cette dernière technique parait idéale, par les garanties qu’elle

offre, en pratique elle est très lourde à mettre en œuvre, et ne supporte pas le passage à l’échelle. En effet, IntServ nécessite de maintenir des états dans les routeurs pour chaque flot que celui-ci est censé gérer. De plus, la phase de réservation peut s’avérer complexe si le chemin comporte de nombreux nœuds, surtout ci ceux-ci appartiennent à des réseaux que l’on administre pas, car ils ne prennent pas forcement en compte le protocole de réservation, ou ne dispose pas forcement d’assez de ressources pour allouer un chemin.

DiffServ, quand à lui, pose le problème de la gestion des différents niveaux de priorité lors du passage d’un domaine à un autre. Comment savoir si les mêmes classes de service sont implémentées sur un domaine que traverse notre flux, comment passer d’une classe de service à l’autre, ou même comment savoir si DiffServ est mis en œuvre.



6/33 Rapport final

Dans le cadre de notre projet, nous disposons d’une plate-forme de test composée de matériels de différents constructeurs tels que Cisco et Juniper. Cette plateforme est divisée en 4 AS. Les deux AS d’extrémités sont des réseaux d’entreprises, entre lesquels nous voulons faire passer du trafic Triple-Play. Nous allons donc mettre en œuvre ces deux standards de la QoS, faire transiter du trafic Triple-Play, et mesurer les performances de bout en bout.

Notre AS dispose de matériel et de logiciels pour générer du trafic « Voix sur IP »

type téléphonie, du trafic « Mpeg streaming » type vidéo à la demande, et enfin du trafic de données en Tcp et en Udp. L’idée sera de générer un trafic permanent d’arrière plan de type « données » sans priorité, et de générer ensuite du trafic de premier plan prioritisé, et sur lequel nous effectuerons des mesures de débit, de délai de traversée du réseau, et de gigue.

Cette plateforme de test comportant deux réseaux d’opérateurs, qui utilisent des routeurs de constructeurs différent, et qui sont administrés par des entités différentes, de nombreux problèmes risquent de se poser. En effet, nous ne pouvons agir par exemple sur le comportement des routeurs d’opérateurs face à des flux prioritisés, et nous ne pouvons pas savoir comment ces routeurs gèrent une éventuelle réservation de ressource.

Nous allons donc devoir tenir compte de ces contraintes, et évaluer l’impact de cette

hétérogénéité.



7/33 Rapport final

4. Analyse

Ce projet met en confrontation les deux approches standard de l’application de la qualité de service dans un réseau constitué de quatre systèmes autonomes. Dans la partie d’analyse, nous allons comparer ces deux approches, DiffServ et IntServ/RSVP, selon les protocoles mis en oeuvre, la réalisation de QoS (classification, réservation,…), les mécanismes fonctionnant au niveau des routeurs… Puis nous relèverons les problèmes qui lient la qualité de services et les réseaux formés de plusieurs systèmes autonomes pour ces deux méthodes.

4.1 DiffServ

4.1.1 Principe du modèle DiffServ

Le modèle DiffServ a été défini par l’IETF dans le RFC 2475. Le principe de base de DiffServ est la création de diverses classes de services fournissant chacune d’entre elles une qualité de service différente. Ces classes se distinguent les unes des autres par la présence d’un code dans le paquet IP : le DSCP (DiffServ Code Point). Le marquage des paquets selon la qualité de service qu’il nécessite, se fait en périphérie du réseau, soit à la source directement ou soit au niveau du routeur de bordure. Ensuite, les routeurs internes du réseau déterminent la priorité du paquet et le traitent en fonction de celle-ci.

Le fait d’introduire la différenciation entre les flots de trafic dans le paquet IP à l’aide du champ DiffServ rend ce modèle scalable.

Chaque classe de service de qualité implique la création d’un contrat : le SLA (Services Level Agreement). Ce contrat précise des règles concernant le délai, la bande passante, le taux de disponibilité, la valeur du DSCP, la taille des tampons de la file d’attente pour cette classe dans les routeurs et le choix de la politique à utiliser en cas de non respect du SLA (rejet des paquets, abaissement de la priorité du paquet…).

4.1.2 Classification des services DiffServ

DiffServ est conçu pour fonctionner avec la couche IP. Il se base sur le champ TOS (Type Of Service) d'IPv4, redéfini par l’IETF en champ DS (DiffServ) pour effectuer la classification. Dans l’IPv6, le champ utilisé par DiffServ est le TC (Traffic Class). Le RFC 2475 utilise le terme de behaviour aggregate (BA) plutôt que de classe de trafic.

Les opérations de classification, contrôle et marquage, sont effectuées par les routeurs de bordure tandis que les routeurs centraux traitent les paquets en fonction de la classe codée dans l'en-tête d'IP selon un comportement spécifique: le PHB (Per Hop Behavior). Actuellement, il existe trois types de PHB :

- EF (Explicit Forwarding) : il garantie une bande passante avec taux de perte, délai et gigue faible.

- AF (Assured Forwarding) : il garantie une haute probabilité d’acheminement des paquets IP. Quatre classes et trois niveaux de priorité y sont définis.

- BE (Best Effort) : service de l’internet par défaut c'est-à-dire sans qualité.



8/33 Rapport final

4.1.3 Les routeurs DiffServ de bordure

La classification sélectionne les paquets en se basant sur une partie de l'en-tête (la

valeur du DSCP, @ source, @ destination, port...). Le Conditionnement met en oeuvre 4 composants. Tout d’abord, la métrologie (meter)

mesure le trafic pour vérifier s'il est conforme au SLA. Ensuite, le marquage (marker) affecte un DSCP au paquet IP. Celui-ci peut être différent de celui du paquet entré dans le routeur. Puis, le lissage (shaper) lisse le trafic en retardant certains paquets afin de respecter le débit contractuel. Enfin, le rejet de paquets (dropper) supprime les paquets dépassant le trafic du contrat. Ces différents mécanismes de conditionnement des paquets suivent une politique établie dans le SLA.

La gestion de la file d’attente peut se faire par RED, WRED ou RIO. Elle permet de stocker les paquets selon leur priorité lorsque le réseau est congestionné.

L’ordonnancement permet d’arbitrer la sortie sur le réseau des paquets des files d’attentes.

4.1.4 DiffServ et les domaines

Le modèle DiffServ est très efficace dans un même domaine. En effet, il n’y a pas de problème dans le domaine d’un fournisseur d’accès lorsqu’il propose de la qualité de service à ses clients car il gère tous les nœuds de son réseau. Cependant, la mise en place de qualité de service entre plusieurs domaines est très complexe due à l’hétérogénéité des équipements et aux différentes technologies existantes dans les réseaux.

L’une des solutions pour résoudre cette problématique serait la création d’une région DiffServ constituée d’un ensemble de différents domaines DiffServ. Ainsi, il suffirait que les



9/33 Rapport final

opérateurs établissent un contrat SLA entre eux pour permettre de faire de la qualité de service de bout en bout entre deux équipements séparés par des systèmes autonomes.

4.2 IntServ/RSVP

4.2.1 IntServ

Définit dans le RFC 1633, IntServ propose de réserver des ressources dans les nœuds du réseau avant de commencer à les utiliser. Il se base sur le protocole RSVP permettant de faire la réservation pour les flux QoS.

Un routeur IntServ/RSVP est composé de quatre fonctionnalités :

- Le classificateur permet de classer chaque paquet entrant dans le routeur selon sa priorité.

- L’ordonnanceur gère la sortie des paquets IP vers l’extérieur du routeur. - Le contrôle d’admission, décide lui, si la réservation d’un flux peut être acceptée en

fonction de celles déjà existantes sur le réseau. - Le processus de réservation RSVP permet de créer et de mettre à jour les états

concernant la réservation dans le routeur pour les chemins utilisant la qualité de service.

IntServ définit deux types de service :

- Guaranteed Service (GS) qui garantit la bande passante et un délai d'acheminement limité de bout en bout.



10/33 Rapport final

- Controlled Load (CL) qui est équivalent à un service Best Effort dans un environnement non surchargé et offre un contrôle sur les débits disponibles.

4.2.2 Le protocole RSVP Principe de RSVP

Défini dans le RFC 2205, RSVP est un protocole de signalisation pour allouer dynamiquement de la bande passante et garantir un délai pour des applications de l’internet. Ici, la demande de QoS ne se fait pas par la source mais par le récepteur. En effet, il apprend par un mécanisme hors bande les besoins de l’application. Cela lui permet de réaliser la réservation en fonction de ses besoins.

Les routeurs RSVP du réseau situés sur le chemin d’un flux ayant une qualité de service doivent répondre à des requêtes RSVP pour mettre en place la réservation de ce chemin. Les routeurs non RSVP sont traversés de façon transparente. Les paquets RSVP sont encapsulés dans des paquets UDP et routés via des protocoles de routages classiques comme RIP. Fonctionnement de RSVP

L'émetteur envoie un message PATH de routeur en routeur afin de dresser la liste des noeuds traversés pour déterminer le chemin qui sera emprunté par la requête RESV. Le chemin des RESV indique la réservation dans le réseau du flux QoS demandé par la source.



11/33 Rapport final

La source envoie un message PATH dans lequel elle donne les caractéristiques désirées dans un descripteur TSPEC, c'est-à-dire le débit, le délai et la taille du paquet.

Ensuite, ce message PATH est acheminé de routeur en routeur jusqu’à la destination. A chaque routeur, il y a création d’un état PATH-STATE qui permettra aux messages RESV d’être acheminés. A chaque routeur, les caractéristiques désirées par la source peuvent être modifiées selon les capacités des routeurs traversés.

Dès que la destination a reçu le message PATH, elle envoie un message RESV incluant les spécifications de la QoS demandée. Ce message RESV est à son tour acheminé jusqu’à la source. A la réception du RESV, le dernier routeur avant la source génère un message RESV-CONF qu’il envoie à la destination. Cet échange de messages permet de faire la réservation RSVP entre la source et la destination.

4.2.3 COPS-RSVP et les domaines

COPS-RSVP est décrit dans le RFC 2749. Il s’appuie sur les protocoles COPS et RSVP. Les messages RSVP supportés par COPS-RSVP sont : PATH, RESV, PATHERR et RESVERR.

Le protocole COPS met en place un échange de messages entre un PDP (Policy Decision Point) et des PEP (Policy Enforcement Point) ou LDP (Local Decision Point). Les PEP et LDP sont des routeurs. Les LDP sont plus particulièrement des routeurs de bordure. COPS utilise un transport de type TCP et est un protocole de requête-réponse entre PDP et PEP. Ainsi, quand le message RSVP est reçu, le PDP peut :

- Accepter le message (il y a donc réservation de ressources) - Rejeter le message (erreur, objets manquant, …) - Introduire une priorité

Le PDP exerce une politique de QoS à l’ensemble des PEP qu’il contrôle. En effet, il a connaissance des états de tous ces PEP et il décide si le chemin RSVP peut être réservé ou non.

De plus, le protocole COPS-RSVP permet de mettre en place une politique de qualité de service entre plusieurs domaines. En l’utilisant, pour les différents routeurs de bordures, on obtiendrait une réservation inter domaines qui permettrait la mise en place d’un service de QoS de bout en bout. Néanmoins, il ne faut pas oublier que le protocole RSVP nécessite des états dans les routeurs. Il ne peut donc pas être appliqué dans des réseaux trop denses.

L’analyse de ces deux approches de QoS, nous permet de conclure que chacune possède des qualités et défauts.

Ainsi, IntServ/RSVP devient trop lourd dans un réseau très dense à cause du grand nombre d’états à maintenir au niveau des routeurs. Il est moins efficace si le réseau contient plusieurs routeurs non RSVP. De plus, comme il ne permet pas la mise en place d’une politique de contrôle, il faut lui ajouter un protocole d’échange d’information de contrôle de type COPS-RSVP.

DiffServ quant à lui, est recommandé dans les réseaux denses car il est sans états ce qui permet un temps de traitement plus rapide des paquets IP dans un routeur. Cette qualité lui



12/33 Rapport final

permet de remporter un franc succès chez les fournisseurs d’accès. Les PHB constituent également un avantage dans l’interconnexion de domaines DiffServ car il y a une harmonisation des priorités dans ces domaines. Cependant il existe un inconvénient: la nécessité de faire un contrat (SLA) pour tous les équipements du domaine. Il est important de préciser que ce contrat n’est pas créé automatiquement : une interaction humaine est nécessaire (appel téléphonique, courrier, fax, mail etc…).

Pour conclure cette analyse, nous pouvons affirmer que l’application de la QoS entre plusieurs systèmes autonomes est complexe, mais reste possible. Dans notre environnement de test, il n’y aura vraisemblablement pas de problèmes. Néanmoins, il faut savoir que dans la réalité, les politiques de contrôle ne sont pas respectées. En effet, il y a une perte de la QoS pendant la traversé des différents systèmes autonomes du réseau. La qualité de service de bout en bout n’est pas assurée.



13/33 Rapport final

5. Conception

Pour évaluer les mécanismes de Qos, nous allons utiliser la plateforme décrite précédemment, ainsi que la suite logicielle Cosmon, qui est un ensemble de script shell utilisant le générateur Iperf et l’outil de monitoring RRDTool. Cette suite permet de générer des flots avec différentes priorités, et de tracer les graphes de variation de débit et de délai pour chacun des flots. En pratique, le client envoie des requêtes Iperf en UDP vers un serveur pour chaque classe de service. A chaque requête, Cosmon stocke les valeurs de la gigue et de la perte de paquet dans des bases de données rrd. Puis, Cosmon génère les graphes de la gigue et la perte de paquet en fonction du temps et de la classe de service.

Fig : Principe de fonctionnement de Cosmon

Nous utiliserons également le générateur « D-ITG » (Distributed Internet Traffic Generator) qui est une plateforme capable de produire du trafic répliquant précisément celui généré par des application type VoIP en RTP avec différents codecs (G.711, G.723,G.729…) en respectant des distributions statistique, pour ressembler le plus possible à du vrai trafic.

Nous utiliserons également le système de monitoring Cacti pour voir la charge globale des routeurs de la plateforme.



14/33 Rapport final

5.1 Description du Testbed

Premièrement, nous générerons un trafic de fond entre le Cors1 et le Core2 à l’aide des générateurs de trafic Iperf pour l’envoi de flux UDP et NetPerf pour le flux TCP. Ceci permettra de simuler un trafic de fond. Ensuite, nous générerons du trafic entre les deux Entreprises à l’aide de Iperf et NetPerf comme entre les deux Cores pour réaliser une monté en charge du réseau. Ce trafic sera dans un premier temps constitué que de flux sans DSCP spécifié, puis nous y ajouterons plusieurs flux avec des DSCP ayant pour valeur EF, AF41 et BE. Et, à la différence de Cores, nous utiliserons une machine dédiée à la génération ou réception du trafic de D - ITG et de Cosmon dans chaque entreprise de la plateforme et une seconde machine sur l’Entreprise2 comme serveur de Iperf et NetPerf. Ainsi, la génération de trafic sur la plateforme pour nos tests permettra de charger le cœur du réseau avec un trafic de fond et tentera de saturer les routeurs de bordure des Entreprises. En effet, il est impossible de saturer les routeurs des Cores car ils utilisent des connexions GigabitEthernet (1Gbit/s) et nos machines émettrices peuvent générées au maximum 35Mbit/s. Par contre, les routeurs de bordure des Entreprises utilisent une connexion FastEthernet (100Mbit/s) et pourront être saturés. En ce qui concerne l’outil de mesure que nous allons utiliser, il s’agit de D-ITG. En effet, il permet d’obtenir des statistiques du délai, de la gigue et du taux de pertes comme le montre le sreenshot suivant.



15/33 Rapport final

|---------------------------------------------------------- Flow number: 1

From 10.10.2.5:59348 To 10.40.0.9:10003

---------------------------------------------------------- Total time = 179.923651 s

Total packets = 8709 Minimum delay = 0.007422 s Maximum delay = 0.065551 s Average delay = 0.017895 s Average jitter = 0.002040 s

Delay standard deviation = 0.010072 s Bytes received = 975408

Average bitrate = 43.369862 Kbit/s Average packet rate = 48.403864 pkt/s Packets dropped = 291 (3.23 %)

----------------------------------------------------------

__________________________________________________________ **************** TOTAL RESULTS ***************** *

__________________________________________________________ Number of flows = 1

Total time = 179.923651 s Total packets = 8709

Minimum delay = 0.007422 s Maximum delay = 0.065551 s Average delay = 0.017895 s Average jitter = 0.002040 s

Delay standard deviation = 0.010072 s Bytes received = 975408

Average bitrate = 43.369862 Kbit/s Average packet rate = 48.403864 pkt/s Packets dropped = 291 (3.23 %)

Error lines = 0 ----------------------------------------------------------

Pour avoir des mesures précises, nous effectuerons cinq mesures à chaque fois et nous

ferons la moyenne de celle-ci. Le délai bout en bout étant mesuré avec la différence entre l’heure de l’envoi du paquet et l’heure de la réception grâce à la commande get-time-of-day(), il est impératif que les machines émettrices et réceptrices soient totalement synchronisées. Pour cela nous les synchroniserons à chaque mesure grâce à la commande ntpdate sur le serveur NTP mis à disposition sur la gateway de la plateforme. Cette série de mesures nous permettra de vérifier que la qualité de service est bien prise en compte dans la plateforme mais aussi de voir l’impact des différentes prises en charges de la qualité de service sur les Cores.



16/33 Rapport final

5.2. Mise en œuvre et validation de DiffServ

Le fonctionnement de Diffserv peut se décomposer en plusieurs opérations. D’abord, le marquage des paquets, nécessaire à la classification des flots. Dans notre

système, ce marquage sera effectué à la source, en affectant une valeur DSCP (DiffServ Code Point) au champ TOS (Type Of Service) de l’entête IP. Ce marquage est pris en charge directement par nos logiciels de génération de trafic.

Ensuite, il faut configurer le firewall et les routeurs de notre AS pour qu’ils gèrent correctement les files d’attente, et qu’il traite en priorité les paquets marqués comme appartenants à une classe de trafic prioritaire.

Enfin, il faut configurer le routeur de bordure pour qu’il conditionne le trafic de manière à respecter le SLA, contrat passé avec notre opérateur.

Le mécanisme implémenté dans notre routeur de bordure sera de type CBWFQ (Class

Based Weighted Fair Queuing), qui peut fournir une priorité stricte à certain paquet grâce à une file d’attente spéciale nommée LLQ (Low Latency Queue).

Pour coller le plus possible à la réalité, nous utiliserons plusieurs générateurs de trafic pour créer à la fois un trafic d’arrière plan, non prioritaire, en UDP et TCP, grâce au logiciel Iperf. La valeur DSCP sera alors de 0.

Un peu plus tard, une fois que ce trafic sera stabilisé (a cause du slow start et de

l’additive increase de TCP), nous lancerons la génération de trafic VoIP et vidéo à partir de deux autres PC avec respectivement D-ITG et Cosmon. Les paquets générés porterons alors un numéro DSCP 101110 qui correspond à de l’expedited forwarding avec priorité stricte. Nous mesurerons alors les débits, délais, gigues, et taux de pertes de tous ces flux.

Dans un premier temps, nous demanderons aux administrateurs des AS que nos flots traverseront, de mettre en place la prise en charge de DiffServ sur leurs équipements, en utilisant les mêmes paramètres que nous.

Puis, nous leur demanderons d’utiliser DiffServ avec des paramètres différents au niveau des classes de service et du PHB (Per Hop Boundary), et enfin nous leur demanderons de désactiver la prise en charge de DiffServ pour voir si le simple fait que leur réseau soit surdimensionné suffit à assurer une qualité de service suffisante de bout en bout. En effet, les 2 réseaux d’opérateurs traversés sont reliés par une connectivité Gigabit Ethernet, et le routage est assuré par du matériel plus haut de gamme que notre routeur de bordure, relié lui en FastEthernet.

Pour chacune de ces configurations, nous relancerons une série de mesure pour évaluer

l’impact de la traversée de plusieurs domaines sur la qualité de service.



17/33 Rapport final

5.3 Mise en œuvre et validation de IntServ/RSVP

Pour évaluer les performances d’Intserv, nous créerons des chemins pour chaque type de flot, grâce au protocole RSVP, depuis notre routeur de bordure jusqu’au routeur de bordure de l’entreprise avec laquelle nous souhaitons communiquer.

Nous utiliserons le logiciel WireShark pour sniffer en différent point du réseau les

paquets d’établissement de chemin PATH et les paquets de réservation RESV. Puis nous enverrons des données et mesureront les performances comme pour Diffserv.

Dans un second temps, nous enverrons plus de données que prévu lors de la réservation du chemin, et nous mesurerons les pertes de bout en bout, mais aussi en sniffant en plusieurs point du réseau, pour essayer d’évaluer si certain routeurs sont plus tolérants que d’autres, et jusqu'à quel point.

Et enfin, nous effectuerons des réservations sur des chemins incomplets, par exemple

jusqu’au premier réseau d’opérateur, pour encore une fois tenter de savoir si un simple surdimensionnement du réseau d’opérateur suffit a maintenir la qualité de service voulue aux extrémités.



18/33 Rapport final

6. Compte Rendu

6.1 DiffServ

6.1.1 Mise en œuvre de DiffServ 6.1.1.1 Matériel Cisco

a. Marquage des paquets

Dans notre mise en œuvre de la qualité de service DiffServ, nous avons fait du marquage à la source, c'est-à-dire que nous avons envoyé du trafic à l’aide de nos générateurs (Iperf, Netperf et D-ITG) en y insérant un numéro de DSCP spécifique directement. La rfc décrivant DiffServ suggère que le marquage puisse être fait sur le routeur de bordure.

Ainsi, le routeur de bordure de l’AS1 permet classer les paquets entrants de différentes façons. Selon le DSCP de celui-ci, c’est la technique qui nous intéresse dans notre étude. Mais aussi selon le protocole utilisé dans le paquet, ainsi à l’aide du protocole NBAR (Network Based Application Recognition) il distingue les paquets SSH, ICMP, RTP audio,etc… et leur attribue un DSCP en fonction de leur priorité. Il peut également le faire en fonction de l’adresse source ou destination ou du port source ou destination.

Exemple : Ici un paquet SSH capturé en sortie de notre AS, on voit son dscp af21 L’inconvénient du protocole NBAR est d’obliger le routeur à décapsuler le paquet jusqu’à

la couche transport voir la couche application dans certain cas. Et, l’inconvénient de la classification des paquets en fonction des adresses et des ports est qu’elle nécessite une énorme configuration « en dur » au niveau des routeurs ce qui rend DiffServ peu flexible et peu scalable. C’est pour cela que nous avons décidé de faire du marquage de paquets à la source.

b. La gestion des files d’attente Les routeurs Cisco proposent deux types de files d’attente pour gérer la qualité de service :

les Class-BasedWeighted Fair Queuing (CBWFQ) et la Low Latency Queuing (LLQ). Les flux arrivant sur le routeur avec un DSCP Expedited Forwarding (EF) et ceux qui



19/33 Rapport final

utilise le protocole RTP audio sont mis dans la file LLQ. Tandis que les autres flux sont mis dans des files CBWFQ. Il y a une file CBWFQ différente pour chaque DSCP de type Assured Forwarding (AF) et Best Effort (BE).

Fig. : Représentation schématique des fils LLQ et CBWFQ

c. Application pour nos tests

Pour les besoins de nos tests, nous avons configuré tous les routeurs Cisco avec le même service de DiffServ tout au long du chemin entre les différents AS. Ils réalisent tous de la différenciation de paquets suivant leur DSCP. Les routeurs Cisco du cœur du réseau choisissent le PHB selon le DSCP (EF, AF41 BE). Dans un second temps, le routeur de sortie du cœur du réseau Core1 sera configuré pour transformer les paquets entrant avec un DSCP EF en DSCP AF41. Extrait de la configuration des routeurs Cisco : … class-map match-any SDMVoice-FastEthernet0/0 match protocol rtp audio /* reconnaît le rtp au dio match ip dscp ef /* reconnaît le dscp ef … policy-map SDM-Pol-FastEthernet0/1 /* configure l e traitement … /* des paquets selon class SDMVoice-FastEthernet0/1 /* leur classe de trafic set dscp ef /* tag les paquets priority percent 75 /* file LLQ priorité haute … class SDMSVideo-FastEthernet0/1 set dscp af41 /* tag les paquets bandwidth remaining 40 /* file cbwfq bande passa nte restante … interface FastEthernet0/1 service-policy output SDM-Pol-FastEthernet0/1 /* applique le traitement à /* l’interface de sortie



20/33 Rapport final

6.1.1.2 Matériel Juniper

a. Classification et gestion des files d’attente

Les routeurs Juniper sont configurés pour reconnaître les DSCP de paquets entrants pour leur attribués une classe via le classificateur. Les DSCP reconnus sont EF, AF41 et BE.

Les paquets classés sont ensuite mis dans différentes queues auxquelles ont été attribuées des priorités de traitement pour l’ordonnanceur. Et finalement, nous avons attribué ces files d’attente aux différentes interfaces du routeur.

b. Configuration Pour ce faire, nous avons entré les instructions suivantes dans la configuration des routeurs Juniper : class-of-service { /* classifie les paquets en 3 classes classifiers { selon leur code dscp */ dscp testG1 { import default; forwarding-class best-effort { loss-priority medium-high code-poin ts be; } forwarding-class assured-forwarding2 { loss-priority low code-points af41; } forwarding-class expedited-forwarding { loss-priority medium-low code-point s ef; } } } forwarding-classes { /* attribue une file a chaque classe */ queue 0 expedited-forwarding; queue 1 assured-forwarding2; queue 3 best-effort; } interfaces { /* attribue les classifiers aux i nterfaces */ /* vers Serveur.ent2 */ fe-0/0/0 { unit 0 { classifiers { dscp testG1; } } } /* vers Core2 */



21/33 Rapport final

fe-0/0/1 { unit 0 { classifiers { dscp testG1; } } } } scheduler-maps { /* configure l’ordonnanceur p our le cbwfq */ testG1 { forwarding-class best-effort scheduler best-effort-scheduler; forwarding-class expedited-forwarding s cheduler expedited-forwarding-scheduler; forwarding-class assured-forwarding2 sc heduler assured-forwarding-scheduler; } } schedulers { best-effort-scheduler { priority low; } assured-forwarding-scheduler { priority medium-high; } expedited-forwarding-scheduler { priority high; } } }



22/33 Rapport final

6.1.2 Tests de validation de DiffServ

Notre plateforme de test est composée d’une partie Cisco et d’une autre Juniper. La génération de trafic se fait entre l’AS1 vers l’AS4, de l’AS2 vers l’AS3 et de l’AS3 vers l’AS2 et AS4 pour assurer un traffic de fond mixte avec du TCP, et de l’UDP Les mesures que nous avons réalisées se font d’un bout à l’autre de la plateforme c'est-à-dire entre une machine de l’AS1 et une machine de l’AS4. Les machines qui servent aux mesures ne générent pas de traffic de fond, elle ne génerent que les paquets nécessaires aux mesures. Cela dans le but que les mesures ne soient pas faussées par une saturation des interfaces des PC par le traffic de fond.

Nous avons attribués un DSCP caractéristiques aux différents flux générés. Ainsi, le DSCP AF41 correspond au flux vidéo, le DSCP EF au flux téléphonie sur IP et le DSCP BE au flux Web ou internet en général.

Nous avons réalisé des mesures des différences de délai, de gigue et des taux de pertes entre les trafics EF et BE selon trois mises en places différentes de la classification des paquets à l’aide des DSCP. La première consiste à mettre en place sur tous les routeurs du chemin une prise en compte de la priorité des paquets ayant un DSCP EF. Donc il y aura la même qualité de service DiffServ sur les différents routeurs. La seconde consiste à transformer le DSCP des paquets entrants EF en AF41 entre les cœurs c'est-à-dire l’AS2 et l’AS3. Ce changement est vérifié par une capture de trame avec Wireshark dans le Core2 : (page suivante)



23/33 Rapport final

La troisième consiste à enlever tous les mécanismes de qualité de service dans le cœur du réseau (AS2 et AS3) afin de savoir si le simple fait de surdimensionner les réseaux d’opérateurs suffit à conserver la qualité de service. Les mesures du délai, de la gigue et du taux de pertes sont en effet celles qui évaluent la qualité de service.

Pour chacun des trois tests, nous avons effectué cinq séries de mesures pour chaque classe de trafic, c'est-à-dire EF et BE, pendant 3 minutes, et moyenné ces résultats pour avoir des mesures les plus réalistes possibles.

Ces flux ayant un DSCP EF ou BE ont été générés à l’aide de D-ITG. En effet, D-ITG permet d’obtenir les mesures énoncées précédemment. Néanmoins, pour la mesure du délai, D-ITG nécessite une synchronisation optimale entre la machine émettrice et la machine réceptrice, car celui-ci est calculé en faisant appel à la fonction système « get_time_of_day » sur les machines sources et destinataires. Un serveur NTP étant disponible sur la gate de la plateforme, nous faisons un appel à la commande ntpdate avant chaque mesure, pour éviter les imprécisions liées aux dérives d’horloges. Toutes ces mesures sont effectuées dans deux conditions :

- Avec deux machines qui génèrent un trafic comprenant différents flux de types donnée avec un DSCP BE, vidéo avec un DSCP AF41 et Téléphonie sur IP avec un DSCP EF (grâce à un script Perl qui lance plusieurs clients Iperf, voir annexe)

- Avec trois machines qui génèrent du trafic dans le but de créer une charge très importante de notre routeur de bordure pour voir l’effet de DiffServ sur un routeur congestionné.

Le graphique suivant permet de voir la charge des cœurs de réseaux lors de nos mesures, entre 14h et 18h :



24/33 Rapport final



25/33 Rapport final

6.1.3 Résultats des mesures

Délai moyen (ms)

Gigue moyenne (ms)

Taux de pertes (%)

EF 11 1,9 3 Même Classe de service et PHB sur tout le chemin BE 28 2,2 7

EF 17 2 5 Les paquets EF sont déclassés en AF41 dans Core1 BE 25 2 8

EF 12 2 4 Pas de Qos dans les réseaux Core

BE 27 2 8

Fig1 : Mesures lorsque 2 machines génèrent du trafic de fond ( ~60 Mbit/s) de bout en bout

depuis notre réseau d’entreprise Délai moyen

(ms) Gigue moyenne

(ms) Taux de pertes

(%) EF 28 2,2 15 Même Classe de

service et PHB sur tout le chemin BE 68 2,3 12

EF 58 2,3 10 Les paquets EF sont déclassés en AF41 dans Core1 BE 70 2,2 12

EF 27 2,2 14 Pas de Qos dans les réseaux Core

BE 70 2,2 13

Fig2 : Mesures lorsque 3 machines génèrent du trafic de fond ( ~90 Mbit/s) de bout en bout

depuis notre réseau d’entreprise

Ces mesures nous permettent tout d’abord d’observer qu’il y a bien une différence de délai de bout en bout entre les flots classés « Expedited Forwarding » et les flots classés « Best Effort » , ce qui permet de penser que DiffServ fonctionne correctement sur notre plateforme. Ensuite, on constate que la non prise en charge de la Qos dans les réseaux d’opérateurs (Core 1 et 2) n’a pas d’impact significatif sur les performances, probablement grâce au surdimensionnement des liens par rapport au trafic que l’on envoie (trafic de fond compris). Par contre, si un réseau Core utilise un marquage dscp différent pour la classe de service EF,



26/33 Rapport final

par exemple s’il ne propose pas de classe EF et que les paquets sont marqués en AF41 à l’entrée de son réseau, cela tend à faire augmenter les délais vers des valeurs plus proches de la classe Best Effort que de la classe EF, avec cependant moins de pertes. L’observation précédente, à propos de l’inconséquence de la non prise en charge de DiffServ sur un réseau Core suffisamment dimensionné, laisse penser que ces délais ne sont pas à imputer aux routeurs des cœurs de réseaux dont les capacités sont surdimensionnées, mais au routeur edge de l’entreprise vers laquelle nous envoyons les données. Enfin, on constate que, quand le réseau est plus fortement chargé, les performances globales s’en ressentent, y compris pour les flots prioritaires. En effet, le délai moyen de transmission des paquets du flot EF a plus que doublé avec l’augmentation de la charge, mais il reste cependant beaucoup plus faible que celui du flot BE. De plus, le taux de pertes est devenu plus important en EF qu’en BE. On peut penser que cela est du au mécanisme WRED implémenté sur notre routeur edge, et qui choisit de dropper de préférence les données de la file LLQ , pour éviter les congestion, et ne pas défavoriser les délais sur les flots EF, au détriment de quelques pertes de paquets. Au vu de ces observations, on peut conclure que DiffServ est bien mis en œuvre sur notre plateforme, mais que celui-ci offre uniquement une qualité de service relative et non absolue, dans le sens où il n’y a pas de réservation de ressources et donc pas de garanties fixes. On peut également conclure que DiffServ peut être remplacé, dans les réseaux d’opérateurs, par un surdimensionnement des ressources (capacités des liens, et des routeurs). Enfin, on a vu que l’hétérogénéité dans le traitement des classes de service doit être géré correctement, le changement de dscp pouvant avoir des conséquences néfastes sur le reste du trajet. Il est préférable, dans ce cas, de ne pas toucher au dscp, quitte à traiter ce paquet comme du trafic non différencié, à condition que le réseau soit surdimensionné.



27/33 Rapport final

6.2 IntServ/RSVP

6.2.1 Mise en œuvre 6.2.1.1 Sur les routeurs

a. Sur les Cisco

En ligne de commandes, dans le menu de configuration globale, on choisi l’interface sur laquelle on veut activer la prise en compte de la signalisation RSVP : interface FastEthernet0/1 Puis on autorise les reservation sur 50000 Kilobit/s dans la limite de 2000 Kilobit/s par flot : ip rsvp bandwidth 50000 2000 (Le fait de n’autoriser les réservations que jusqu’à 50Mbit/s permet d’éviter que des utilisateurs malintentionnés puisse réserver toute la bande passante de l’interface et ainsi créer un déni de service). Pour vérifier que rsvp est bien activé, on peut tapper : Show ip rsvp interface detail Qui nous renvoie : Fa0/1: Interface State: Up Bandwidth: Curr allocated: 0 bits/sec Max. allowed (total): 50M bits/sec Max. allowed (per flow): 2M bits/sec Max. allowed for LSP tunnels using sub-pools: 0 bits/sec b. Sur les Juniper Dans le fichier de configuration des routeurs Juniper, on rajoute les lignes suivantes: Protocols{ Rsvp{ Interface all ; Bandwidth 50000 ; }



28/33 Rapport final

6.2.1.2 Mise en œuvre sur les machines Il faut installer un démon RSVP sur les machines source et destinataire pour qu’elles puissent envoyer la signalisation nécessaire à la réservation de ressources. Les deux implémentations que l’on a trouvées sont celle de l’ISI (University of Southern California) et celle de KOM (Technische Universität Darmstadt). Il faut également utiliser un programme capable de faire appel à ce démon avec les paramètres TSpec correspondant à la réservation que l’on souhaite effectuer. Ce sera le générateur MGEN dans sa version 3. (Le support de RSVP ayant été supprimé de la version 4)

6.2.2 Validation, problèmes rencontrés Il nous a été impossible d’installer un démon RSVP, que ce soit KOM ou ISI, sur les machines de la plateforme, tournant sous FreeBSD 6.2, ainsi que sur nos pc portables, et sur les machines de la salle 747. Après renseignement sur le web, nous nous sommes rendu compte que ces programmes étaient relativement vieux et que les derniers exemples de mise en œuvres trouvés l’étaient sous FreeBSD 3.x. Nous ne pouvions pas toucher aux systèmes d’exploitation des pc de la plateforme, chacun ayant déjà un rôle pour les 4 projets en cours. Nous avons donc installé FreeBSD, que nous avons trouvé dans sa version 3.5, sur une machine personnelle, amenée pour l’occasion. L’installation du démon RSVP ISI s’est passée correctement, mais cette fois c’est MGEN qui refusait de compiler, ou de s’exécuter lorsqu’on essayait de lancer le binaire pré compilé sur une autre machine. Après renseignement, nous avons appris que le logiciel NetMeeting de Microsoft, dans ses anciennes versions, était capable de réserver des ressources en utilisant RSVP. Nous avons donc relié un pc portable sous Windows XP à la plateforme, et lancé Netmeeting, puis sniffé les paquets qui en sortaient. Cette tentative a été vaine. Il semblerait, d’après le site de Microsoft, que le support de RSVP ait été supprimé dans les versions postérieures à Windows 2000. En dernier recours, nous avons cherché à savoir si notre routeur de bordure Cisco était capable de générer cette signalisation, et cela ne semble pas être le cas. Nous avons juste réussi à placer une reservation de ressource « en dur » grâce à la commande : ip rsvp reservation session-ip-address sender-ip-ad dress {tcp | udp | ip-protocol} session-dport sender-sport next-hop-ip-address next-hop-interface {ff | se | wf} {rate | load} bandwidth burst-size Par manque de temps, nous n’avons pas pu déployer de réservation en dur sur tous les routeurs du chemin (surtout sur les Juniper), et effectuer de mesures.



29/33 Rapport final

6.3 Conclusion

DiffServ a été mis en œuvre et testé sur notre plateforme. Cette approche est facilement déployable, flexible, mais n’offre pas de garanties précises, uniquement un traitement préférentiel. Les performances globales du réseau impactent donc les performances de flots traités avec DiffServ, notamment en cas de congestion des routeurs. IntServ semble plus difficile à mettre en oeuvre, car il nécessite l’installation de démons sur les machines clientes. Il offre par contre des garanties précises grâce à la réservation de ressources.



30/33 Rapport final

Annexe A

Bibliographie et références

[1] Les Réseaux – Edition 2003 – Eyrolles – Guy Pujolle [2] Contrôle dans les réseaux IP – Hermès Lavoisier – Guy Pujolle [3] Intelligence dans les réseaux – Hermès Lavoisier – Dominique Gaïti [4] http://www.itcal.com/analyses/19991216.pdf [5] http://fr.wikipedia.org/wiki/Triple_Play [6] http://en.wikipedia.org/wiki/Quality_of_service [7] http://www.cisco.com [8] http://www.juniper.net [9] http://www.grid.unina.it/software/ITG/



31/33 Rapport final

Annexe B Fiche descriptive de D-ITG :



32/33 Rapport final



33/33 Rapport final

Script Perl utilisé pour la génération de trafic : (extrait) #!/usr/bin/env perl my $adr = $ARGV[0]; print "serveur de test: $adr\n"; if (fork){ while(1){ my $tps1 = int(rand(10)) * 60; my $att1 = int(rand(10)) * 60; sleep($att1); ìperf -u -c $adr -p10986 -t$tps1 -b2M -S0x B8`; //trafic ef } }else{ if (fork){ while(1){ my $tps2 = int(rand(10)) * 60; my $att2 = int(rand(10)) * 60; sleep($att2); ìperf -u -c $adr -p10986 -t$tps2 -b2M -S0xB8`; } }else{ if (fork){ while(1){ my $tps3 = int(rand(10)) * 60; my $att3 = int(rand(10)) * 60; sleep($att3); ìperf -u -c $adr -p10986 -t$tps3 - b1M -S0xB8`; } }else{ if (fork){ while(1){ my $tps4 = int(rand(10)) * 60; my $att4 = int(rand(10)) * 60; sleep($att4); ìperf -u -c $adr -p10986 -t$tp s4 -b2M -S0x88`; //trafic af41 } }else{ if (fork){ while(1){ my $tps5 = int(rand(10)) * 60; my $att5 = int(rand(10)) * 60; sleep($att5); ìperf -u -c $adr -p10986 - t$tps5 -b2M -S0x88`; } }else{ if (fork){ while(1){ my $tps6 = int(rand(10) ) * 60; my $att6 = int(rand(10) ) * 60; sleep($att6); ìperf -u -c $adr -p109 86 -t$tps6 -b2M -S0x88`; } }else{ if (fork){ while(1){ my $tps7 = int(rand (10)) * 60; my $att7 = int(rand (10)) * 60; sleep($att7); ìperf -u -c $adr - p10986 -t$tps7 -b2M -S0x88`; } }else{ if (fork){ while(1){ my $tps8 = int( rand(10)) * 60;



34/33 Rapport final

my $att8 = int( rand(10)) * 60; sleep($att8); ìperf -u -c $a dr -p10986 -t$tps8 -b2M -S0x88`; } else{ [.....] //traffic BE tcp if (f ork){ while(1){ my $tps17 = int(rand(10)) * 60; my $att17 = int(rand(10)) * 60; sleep($att17); `netperf -l $tps17 -H $adr`; } }else{ if (fork){ while(1){ my $tps18 = int(rand(10)) * 60; my $att18 = int(rand(10)) * 60; sleep($att18); `netperf -H $adr -l $tps18`; } }else{ if (fork){ while(1){ my $tps19 = int(rand(10)) * 60; my $att19 = int(rand(10)) * 60; sleep($att19); print "qqlechose"; } }else{ if (fork){ while(1){ my $tps20 = int(rand(10)) * 60; my $att20 = int(rand(10)); sleep($att20); `netperf -H $adr -l $tps20`; } }else{ } } } } } } } } } } }

Documents

Mise en oeuvre des deux approches standard : DiffServ et