Qualité de service dans les réseaux actifs

Numéro d ordre 2552 Année 23/4 Laboratoire d Informatique de Besançon Université de Franche-Comté 16 route de Gray 253 Besançon cedex Mémoire de D.E.A. Informatique, Automatique et Productique Filière Informatique Qualité de service dans les réseaux actifs Par Emmanuel JEANVOINE Stage encadré par David FUIN, Eric GARCIA et Hervé GUYENNET Soutenance prévue le 25 juin 24, devant le jury : Hervé GUYENNET Professeur au LIFC Pascal LORENZ Professeur au GRTC Eric GARCIA Maître de conférences au LIFC David FUIN Doctorant au LIFC

Remerciements Le travail que j ai réalisé au cours de ce stage de DEA a été possible grâce au soutien d un certain nombre de personnes que je tiens à remercier ici : David FUIN, doctorant au LIFC, qui m a donné un grand nombre de conseils théoriques et techniques et qui a toujours mis à disposition les moyens nécessaires pour que je puisse réaliser mes expérimentations. Eric GARCIA, maître de conférences au LIFC, pour son encadrement tout au long du stage, sa participation pour la relecture de ce mémoire et son appui lors de mes candidatures de thèse. Hervé GUYENNET, professeur au LIFC, pour ses conseils quant à mon orientation universitaire et son appui lors de mes candidatures de thèse. Jean-Christophe LAPAYRE, professeur au LIFC, pour m avoir fait confiance en me chargeant de cours d algorithmique (TD et TP) aux étudiants de première année. Pascal LORENZ, professeur à l Université de Haute-Alsace, pour avoir accepté de participer à mon jury de DEA. Mes collègues de promotion, dont Julien Groslambert, Bertrand Herard, Noureddine Kettaf, Florian Litot, Marc Sauget et Lei Yu, pour la bonne ambiance qu ils ont apportée cette année et grâce à qui le stage s est déroulé très agréablement. 3

Table des matières Remerciements 3 Introduction 13 I Etat de l art 15 1 La qualité de service 17 1.1 La qualité de service sur IP................... 18 1.1.1 Classification....................... 19 1.1.2 Architecture d un routeur supportant de la QoS... 2 1.1.3 Gestion des files d attente................ 21 1.1.4 Modèles IntServ et DiffServ............... 23 1.1.5 Conclusion sur la QoS dans les réseaux IP....... 24 1.2 Le besoin de QoS dans les applications multimédia...... 24 1.2.1 Contraintes communes aux applications multimédia. 25 1.2.2 La téléphonie sur IP................... 25 1.2.3 La vidéoconférence.................... 25 1.2.4 Les applications coopératives.............. 25 1.2.5 Conclusion sur la QoS dans les applications multimédia 25 2 Les réseaux actifs 27 2.1 Introduction............................ 27 2.2 Classification des réseaux.................... 28 2.2.1 Les réseaux traditionnels................ 28 2.2.2 Les réseaux programmables............... 28 2.3 Fonctionnement des réseaux actifs............... 3 2.3.1 L approche intégrée................... 3 2.3.2 L approche discrète.................... 3 2.3.3 Comparaison des approches............... 3 2.3.4 L approche hybride.................... 31 2.4 Comparaison avec les routeurs classiques............ 32 2.5 Standardisation.......................... 33 2.5.1 ANEP........................... 33 5

TABLE DES MATIÈRES 2.5.2 SAPF........................... 35 2.6 Intérêt des réseaux actifs..................... 35 2.7 Travaux existants......................... 36 2.7.1 ANTS........................... 36 2.7.2 Autres travaux...................... 38 3 La qualité de service dans les réseaux actifs 41 3.1 QoS niveau application...................... 41 3.2 QoS utilisant le réseau sous-jacent............... 42 3.3 QoS sur un noeud actif...................... 44 3.3.1 Contrôle de flux..................... 44 3.3.2 Load Balancing...................... 44 3.4 Bilan sur les différentes approches de QoS sur les réseaux actifs 46 II Contribution 47 4 Développement 49 4.1 Objectifs.............................. 49 4.2 Présentation de l idée générale................. 5 4.2.1 Approche avec des threads............... 5 4.2.2 Approche avec un ordonnanceur............ 51 4.3 Travaux sur ANTS........................ 52 4.3.1 Pourquoi ANTS?..................... 52 4.3.2 Architecture détaillée d ANTS............. 53 4.3.3 Modification des applications.............. 57 4.3.4 Modification des nœuds................. 6 4.4 Travaux sur Tamanoir...................... 62 4.4.1 Pourquoi Tamanoir?................... 62 4.4.2 Architecture détaillée de Tamanoir........... 63 4.4.3 Modification des nœuds................. 68 4.4.4 Discussion sur le choix de l architecture........ 71 4.5 Bénéfices de la QoS au niveau actif............... 72 4.6 Conclusion sur le développement................ 73 5 Expérimentations 75 5.1 Mesure des résultats....................... 75 5.2 Expérimentations sur ANTS................... 78 5.2.1 Configuration des tests.................. 78 5.2.2 Analyse.......................... 8 5.2.3 Conclusion sur les tests avec ANTS.......... 81 5.3 Expérimentations sur Tamanoir................. 82 5.3.1 Configuration des tests.................. 82 5.3.2 Analyse.......................... 83 6

TABLE DES MATIÈRES 5.3.3 Conclusion sur les tests avec Tamanoir......... 88 5.4 Expérimentations sur le délai.................. 88 5.5 Conclusion sur les expérimentations.............. 92 Conclusion 95 Bibliographie 97 A Résultats des tests sur ANTS 11 A.1 Algorithme Priority Queuing.................. 12 A.1.1 Limitation à 1 Mbps.................. 12 A.1.2 Limitation à 4 Mbps................... 13 A.1.3 Limitation à 1 Mbps................... 14 A.2 Algorithme Fair Queuing.................... 15 A.2.1 Limitation à 1 Mbps.................. 15 A.2.2 Limitation à 4 Mbps................... 16 A.2.3 Limitation à 1 Mbps................... 17 A.3 Algorithme Weighted Fair Queuing............... 18 A.3.1 Limitation à 1 Mbps.................. 18 A.3.2 Limitation à 4 Mbps................... 19 A.3.3 Limitation à 1 Mbps................... 11 B Résultats des tests sur Tamanoir 111 B.1 Algorithme Priority Queuing.................. 112 B.1.1 Limitation à 1 Mbps.................. 112 B.1.2 Limitation à 7 Mbps.................. 113 B.1.3 Limitation à 1 Mbps.................. 114 B.1.4 Limitation à 4 Mbps................... 115 B.2 Algorithme Fair Queuing.................... 116 B.2.1 Limitation à 1 Mbps.................. 116 B.2.2 Limitation à 7 Mbps.................. 117 B.2.3 Limitation à 1 Mbps.................. 118 B.2.4 Limitation à 4 Mbps................... 119 B.3 Algorithme Weighted Fair Queuing............... 12 B.3.1 Limitation à 1 Mbps.................. 12 B.3.2 Limitation à 7 Mbps.................. 121 B.3.3 Limitation à 1 Mbps.................. 122 B.3.4 Limitation à 4 Mbps................... 123 B.4 MPEG + FIFO.......................... 124 B.4.1 Limitation à 1 Mbps.................. 124 B.4.2 Limitation à 7 Mbps.................. 125 B.4.3 Limitation à 1 Mbps.................. 126 B.4.4 Limitation à 4 Mbps................... 127 B.5 MPEG + PQ........................... 128 7

TABLE DES MATIÈRES B.5.1 Limitation à 1 Mbps.................. 128 B.5.2 Limitation à 7 Mbps.................. 129 B.5.3 Limitation à 1 Mbps.................. 13 B.5.4 Limitation à 4 Mbps................... 131 B.6 Service long + FIFO....................... 132 B.6.1 Limitation à 1 Mbps.................. 132 B.7 Service long + PQ........................ 133 B.7.1 Limitation à 1 Mbps.................. 133 8

Table des figures 1.1 Structure du champ TOS d IPv4 et signification dans DiffServ..... 19 1.2 Architecture d un routeur supportant la QoS.............. 2 2.1 Réseaux programmables....................... 29 2.2 Routage classique........................... 32 2.3 Routage dans un réseau actif..................... 32 2.4 Format d un paquet ANEP...................... 34 2.5 Format d un paquet SAPF...................... 35 2.6 Hiérarchie des composants d un protocole............... 37 2.7 Demande de chargement d un code group............... 38 3.1 Exemple de séquence et dépendances des images I, P et B d un flux MPEG................................ 42 4.1 Architecture simplifiée d un routeur actif gérant la QoS avant le traitement des paquets........................... 51 4.2 Architecture simplifiée d un routeur actif gérant la QoS après le traitement des paquets........................... 52 4.3 Architecture d ANTS......................... 53 4.4 Code du protocole ping dans ANTS.................. 56 4.5 Architecture d ANTS modifiée pour supporter la QoS au niveau des applications utilisateur......................... 58 4.6 Code simplifié du classifier implanté dans ANTS............ 59 4.7 Méthode evaluate() d une capsule ANTS pour le passage à l application................................. 6 4.8 Méthode evaluate() standard d une capsule ANTS.......... 6 4.9 Méthode evaluate() gérant la QoS d une capsule ANTS........ 61 4.1 Architecture de Tamanoir....................... 63 4.11 Architecture détaillée d un nœud Tamanoir.............. 64 4.12 Service Ping dans Tamanoir...................... 67 4.13 Architecture version 1 du nœud Tamanoir pour le support de la QoS.. 69 4.14 Architecture version 2 du nœud Tamanoir pour le support de la QoS.. 69 4.15 Méthode schedule() dans Tamanoir................. 7 9

TABLE DES FIGURES 5.1 Code de la classe LogCapsule..................... 76 5.2 Code de méthode d écriture des logs dans un fichier.......... 77 5.3 Exemple de script Gnuplot...................... 78 5.4 Topologie des tests avec ANTS.................... 79 5.5 Algorithme Priority Queing dans ANTS................ 8 5.6 Topologie des tests avec Tamanoir................... 83 5.7 Algorithme WFQ dans Tamanoir................... 85 5.8 Comparaison du débit sur un flux MPEG avec une QoS PQ et avec une QoS FIFO.............................. 86 5.9 Topologie de test des délais...................... 89 5.1 de latence sur ANTS et Tamnoir................ 92 A.1 ANTS, algorithme PQ, 1 Mbps................... 12 A.2 ANTS, algorithme PQ, 4 Mbps.................... 13 A.3 ANTS, algorithme PQ, 1 Mbps.................... 14 A.4 ANTS, algorithme FQ, 1 Mbps.................... 15 A.5 ANTS, algorithme FQ, 4 Mbps.................... 16 A.6 ANTS, algorithme FQ, 1 Mbps.................... 17 A.7 ANTS, algorithme WFQ, 1 Mbps.................. 18 A.8 ANTS, algorithme WFQ, 4 Mbps................... 19 A.9 ANTS, algorithme WFQ, 1 Mbps................... 11 B.1 Tamanoir, algorithme PQ, 1 Mbps................. 112 B.2 Tamanoir, algorithme PQ, 7 Mbps.................. 113 B.3 Tamanoir, algorithme PQ, 1 Mbps.................. 114 B.4 Tamanoir, algorithme PQ, 4 Mbps................... 115 B.5 Tamanoir, algorithme FQ, 1 Mbps................. 116 B.6 Tamanoir, algorithme FQ, 7 Mbps.................. 117 B.7 Tamanoir, algorithme FQ, 1 Mbps.................. 118 B.8 Tamanoir, algorithme FQ, 4 Mbps................... 119 B.9 Tamanoir, algorithme WFQ, 1 Mbps................ 12 B.1 Tamanoir, algorithme WFQ, 7 Mbps................. 121 B.11 Tamanoir, algorithme WFQ, 1 Mbps................. 122 B.12 Tamanoir, algorithme WFQ, 4 Mbps................. 123 B.13 Tamanoir, MPEG + FIFO, 1 Mbps................. 124 B.14 Tamanoir, MPEG + FIFO, 7 Mbps................. 125 B.15 Tamanoir, MPEG + FIFO, 1 Mbps................. 126 B.16 Tamanoir, MPEG + FIFO, 4 Mbps.................. 127 B.17 Tamanoir, MPEG + PQ, 1 Mbps.................. 128 B.18 Tamanoir, MPEG + PQ, 7 Mbps................... 129 B.19 Tamanoir, MPEG + PQ, 1 Mbps................... 13 B.2 Tamanoir, MPEG + PQ, 4 Mbps................... 131 B.21 Tamanoir, service long + FIFO, 1 Mbps............... 132 B.22 Tamanoir, service long + PQ, 1 Mbps................ 133 1

Liste des tableaux 1.1 Utilisation du champ TOS.................... 19 2.1 Solutions actuelles à quelques applications évoluées de l Internet............................... 36 4.1 Méthodes autorisées dans le code des protocoles........ 54 4.2 Méthodes disponibles dans la classe Capsule.......... 55 4.3 Méthodes à surcharger pour créer un nouveau type de capsules................................ 55 4.4 Méthodes génériques d une application............. 57 4.5 Méthodes de la classe TANet................... 65 4.6 Méthodes de la classe Service.................. 66 5.1 Délais dans ANTS........................ 9 5.2 Délais dans Tamanoir....................... 9 11

Introduction A l heure actuelle, les technologies informatiques subissent une croissance exponentielle. Le coût des composants baisse sans cesse alors qu ils sont de plus en plus performants, ce qui permet aux technologies du multimédia d être en perpétuel développement et de faire de plus en plus de choses, que ce soit dans le domaine de la musique, de la vidéo, des jeux ou encore des applications utilisées au quotidien. Les technologies d accès hauts débits à Internet se déploient rapidement et deviennent relativement abordables. Cela permet aux utilisateurs de tirer pleinement parti des nouvelles technologies en leur permettant d interconnecter leurs machines. Les financiers voyant un tel engouement pour l Internet et le multimédia ont décidé d exploiter ces technologies afin de faire des profits, c est ainsi que nous avons vu fleurir une quantité phénoménale de jeunes entreprises basées sur l Internet. Tous ces facteurs ont largement contribué au développement de l Internet, qui est actuellement omniprésent. Ainsi, même si les technologies de l Internet ne sont pas réellement nouvelles, les proportions dans lesquelles elles sont utilisées sont complètement différentes. En effet, il y une trentaine d années, seulement quelques machines étaient interconnectées et pour un usage purement militaire. Le développement réel d Internet en France n a commencé que depuis une dizaine d années. Les dizaines de millions de communications simultanées ont imposé une architecture très solide du réseau. L Internet tel qu on le connait est entièrement basé sur ce qu on appelle le routage. Le routage permet d acheminer les flux de données à destination, il est habituellement opposé à la commutation, technique qui est utilisée dans d autres réseaux tels qu ATM. Afin de permettre au plus grand nombre d accéder de manière conccurente aux ressources d Internet, il a été défini une politique dite Best Effort du routage des données. Cela permet de servir au mieux tout le monde en répartissant équitablement les ressources. Bien que la politique Best Effort ait fait d Internet ce qu il est actuellement, c est aussi un handicap. En effet, tous les services ne nécessitent pas les mêmes ressources sur Internet, ainsi on peut penser par exemple qu un transfert de gros fichier est moins prioritaire qu une communication 13

Introduction de vidéoconférence utilisée pour de la télémédecine. Ainsi, certains services qui pourraient voir le jour tels que la vidéoconférence ne peuvent pas être mis en place simplement puisqu ils requièrent des ressources plus importantes et le trafic Best Effort n est pas suffisant pour assurer une qualité satisfaisante. Ainsi même si les utilisateurs qui veulent faire une vidéoconférence possèdent une liaison rapide à Internet, ils seront pénalisés dès qu ils passeront par Internet pour communiquer puisque ce dernier n est pas contrôlable. C est pour ces raisons que sont apparues des techniques de qualité de service. Un autre handicap dans le monde des réseaux est que les équipements sont relativement coûteux surtout si le réseau concerné est grand. De plus, lorsque de nouvelles techniques apparaissent, il est très long, quasiment une dizaine d années, pour les voir implantées dans les équipements réseaux, notamment dans les routeurs. En plus il est totalement inconcevable de remplacer tous les routeurs d Internet simultanément puisque cela engendrerait une rupture de service relativement longue et intolérable. Pour essayer de rendre plus dynamique ce côté statique des réseaux, des technologies dites de réseaux programmables et plus précisément de réseaux actifs, sont apparues. Elles ont pour but de pouvoir déployer de manière logicielle, sur l ensemble d un réseau, de nouvelles méthodes de gestion des flux de données, plus techniquement ce que l on appelle de nouveaux protocoles. Dans ce contexte, j ai réalisé mon stage de DEA Systèmes Distribués et Communication au Laboratoire d Informatique de l Université de Franche- Comté. L objectif de mon travail dans ce stage qui s est déroulé dans l équipe d Hervé Guyennet était de réaliser un travail de recherche sur La Qualité de Service dans les Réseaux Actifs. Dans ce mémoire, je présenterai un état de l art sur la qualité de service, sur les réseaux actifs, ainsi que sur les travaux ayant déjà été effectués dans le domaine de la qualité de service dans les réseaux actifs. Je présenterai ensuite la contribution que j ai apportée avec dans un premier temps, la modification des nœuds actifs ANTS et Tamanoir pour ajouter de la qualité de service et finalement, mes résultats. 14

Première partie Etat de l art 15

Chapitre 1 La qualité de service Le terme qualité de service (QoS) est relativement difficile à définir. En effet, par QoS on peut entendre : la garantie de l intégrité des données transportées ; la garantie d un temps de latence maximum ; la garantie d un débit minimum ; la garantie d une variation de délai (gigue) maximale ; le partage équitable ou pondéré des ressources de calcul ; le bon fonctionnement d une application ; etc,... On voit à travers ces quelques exemples que les besoins en QoS peuvent être différents. Par exemple si l on veut diffuser de la vidéo à la demande, on aura besoin d un transfert quasi temp-réel avec une latence très faible et une gigue faible, en revanche il ne sera pas dramatique de perdre une image de temps en temps ou alors d avoir une qualité d image un peu dégradée. A l opposé, si l on veut transférer de gros fichiers via le protocole FTP, il est essentiel que l intégrité des données soit préservée, en revanche on peut tolérer une gigue importante. Selon l utilisation que l on aura, on s efforcera de faire le bon compromis pour assurer la meilleure QoS possible, sachant qu il n existe pas de solution qui résolve tous les problèmes à la fois. Nous nous intéresserons principalement ici à deux aspects de la QoS, à savoir : la QoS des réseaux IP et les besoins de QoS dans les applications multimédia. 17

1.1 La qualité de service sur IP 1.1 La qualité de service sur IP Au départ, le protocole IP n était pas destiné à garantir de la QoS mais offrait un service minimaliste appelé best-effort. Cela a permis d utiliser dans les réseaux IP des routeurs ne possédant pas d intelligence propre et donc très performants étant donné que leur seul travail était d acheminer des paquets à leur destination. Les ressources étant disponibles sans restrictions pour tous les utilisateurs, c est grâce à IP que l Internet a pu se développer pour devenir ce qu il est actuellement. Cela pose toutefois le problème qu un utilisateur peut utiliser toutes les ressources et ainsi pénaliser les autres utilisateurs. De plus IP ne fonctionne pas en mode connecté, le récepteur ne peut pas prévenir l émetteur si des paquets sont perdus en cas de congestion. Une prévention de congestion est donc impossible avec IP. Ceci a été pallié avec le protocole TCP qui permet une gestion de bout en bout. Le service best-effort a fonctionné pendant de longues années et n a jamais été réellement concurrencé par des technologies telles qu ATM qui elles sont totalement dédiées à la QoS. Toutefois, avec les nouveaux débits proposés, les besoins actuels ont évolué. On peut citer par exemple la voix sur IP ou encore la vidéoconférence. Ces nouveaux besoins nécessitent une réelle QoS. Une solution face à ces besoins est le surdimensionnement du réseau. L idée est d augmenter la bande passante disponible afin d éviter la congestion et la perte de paquets. Cela est d autant plus simple à mettre en œuvre que les nouvelles technologies telles que DWDM 1 permettent d atteindre des débits de 5 Tbps à un coût relativement faible. Cette solution ne remplit malheureusement pas tous les objectifs. En effet, le surdimensionnement n est réellement possible que dans le cœur du réseau, ce qu on appelle les backbones. C est même souvent au dernier kilomètre qu interviennent les problèmes de congestion, ce qui empêche une QoS de bout en bout. Des paquets provenant d applications sensibles au délai seront pénalisés par rapport aux autres puisqu ils seront supprimés des files d attente. Une discussion opposant le surdimensionnement et la QoS à été donnée dans [24]. Nous allons maintenant présenter le fonctionnement de la mise en œuvre de QoS sur les réseaux IP, nous verrons plus particulièrement : la classification des paquets, les modèles standards Intserv et Diffserv, les algorithmes de gestion des files d attente et les limitations de la QoS sur IP. 1 Dense Wavelength Division Multiplexing : cette technologie permet de multiplexer dans une même fibre optique plusieurs trains de signaux numériques à la même vitesse de modulation, mais chacun à une longueur d onde distincte. 18

Chapitre 1. La qualité de service 1.1.1 Classification Afin de pouvoir appliquer une politique de QoS spécifique à un flux de données il est nécessaire de pouvoir marquer les paquets transitant étant donné que plusieurs flux différents peuvent circuler sur un même lien. Un paquet est donc, en fonction de l adresse de destination présente, de son en-tête et de son marquage, placé dans une des files d attente du routeur. 1 2 3 4 5 6 7 IPv4 TOS byte Precedence Type of Service MBZ 1 2 3 4 5 6 7 DS-Field DSCP CU Fig. 1.1 Structure du champ TOS d IPv4 et signification dans DiffServ. Valeur du champ TOS Signification Normal 1 Minimiser le coût 1 Maximiser la fiabilité 1 Maximiser le débit 1 Minimiser le délai Tab. 1.1 Utilisation du champ TOS. Les paquets IPv4 possèdent dans leur en-tête 8 bits destinés à gérer la QoS. La RFC 1349 [6] nous précise la composition de l octet TOS comme le montre la figure 1.1 : le champ Precedence codé sur 3 bits permet de décrire 8 niveaux de priorité ; le champ Type of Service codé sur 4 bits permet de spécifier des propriétés de délai, débit, fiablitié et coût comme spécifié dans le tableau 1.1 ; le champ Must Be Zero (MBZ) qui est fixé à. 19

1.1 La qualité de service sur IP Dans un modèle DiffServ, la RFC 2474 [28] a renommé l octet TOS en Diffserv et sa composition est la suivante : le champ DSCP (Differentiated Service Code Point) codé sur 6 bits permet de décrire 64 niveaux de priorité ; le champ CU (Currently Unused) codé sur 2 bits qui reste inutilisé. Grâce à la spécification de cet octet, il est possible de classer un paquet IP en fonction : de son protocole de transport (TCP ou UDP) ; de sa source et de sa destination (adresse IP et port) ; et de son octet TOS ou DSCP. Les méthodes de classification étant posées, nous allons présenter dans la partie suivante l architecture d un routeur supportant la QoS. 1.1.2 Architecture d un routeur supportant de la QoS Files logicielles File matérielle Entrée Entrée 1 Classification Classification Routage vers une interface de sortie Gestionnaire de files d attente pour l interface de sortie Gestionnaire de files d attente pour l interface de sortie 1 Sortie Sortie 1 Files logicielles File matérielle Fig. 1.2 Architecture d un routeur supportant la QoS. La figure 1.2 présente l architecture d un routeur gérant la QoS. On peut remarquer qu en plus de router les paquets vers la bonne interface de sortie (fonction de routage), ce type de routeur comporte un système de files d attente sur chaque interface de sortie et un ordonnanceur permettant de choisir les paquets qui seront envoyés. C est grâce au marquage des paquets présenté dans la partie 1.1.1 que les paquets sont placés dans les files d attente logicielles pour finalement être placés dans une file matérielle après l ordonnancement. 2

Chapitre 1. La qualité de service Voyons maintenant les mécanismes existants pour gérer les files d attente dans les routeurs. 1.1.3 Gestion des files d attente Quelle que soit la politique de QoS mise en œuvre, c est toujours au niveau des files d attente des routeurs que cette politique est appliquée. Par défaut, dans la politique de l Internet best-effort, tous les paquets arrivant dans le routeur sont placés dans une file d attente FIFO. Cela permet de traiter tous les flux de la même manière. Il existe deux méthodes permettant de traiter les paquets d une manière plus évoluée que dans le best-effort : la prévention de la congestion et la gestion de la congestion. C est que nous allons détailler maintenant. La prévention de la congestion Afin de prévenir une éventuelle congestion, les routeurs détruisent des paquets aléatoirement, ce qui permet une régulation naturelle en profitant du mécanisme présent dans le protocole TCP. En effet, lorsqu un paquet est perdu, l émetteur ne reçoit pas d acquitement de la part du récepteur et ralentit donc son émission. Le problème est que cela produit un phénomène d oscillation étant donné que les émetteurs augmentent ou réduisent leurs débits en même temps. Pour pallier à ceci, RED [17] détecte la congestion avant que des pertes apparaissent en contrôlant le remplissage des files d attente. En effet, dès qu une file dépasse un seuil, RED rejette un paquet, ce qui a pour conséquence de faire diminuer le débit d émission. Dans RED les paquets sont détruits aléatoirement, ce qui ne permet pas de différencier les types de flux. Le mécanisme WRED de Cisco vient combler cette lacune en tenant compte de la priorité des paquets puisqu il possède un seuil pour chaque file correspondant à une classe de trafic. C est donc en fonction du champ IP Precedence que WRED pourra rejeter un type de paquet pour prévenir de la congestion. Alors que RED et WRED sont basés sur la destruction de paquets en fonction de la longueur moyenne des files d attente, le mécanisme Explicit Congestion Notification (ECN) [3] propose de marquer les paquets plutôt que de les rejeter lorsque la longueur de la file dépasse un certain seuil. Ces méthodes sont relativement satisfaisantes pour les flux TCP, cela dit tous les flux ne sont pas basés sur TCP. Ainsi, si l on met en concurrence un flux TCP et un flux UDP, le flux UDP en cas de congestion utilisera toute la bande passante disponible au détriment du flux TCP qui lui réduira toujours 21

1.1 La qualité de service sur IP plus son émission pour arriver à un débit nul. Afin de gérer d une manière plus fine la QoS dans un routeur il faut mettre en place des mécanismes de gestion de la congestion. La gestion de la congestion Lors d un fonctionnement sans congestion, la mise dans des files d attente des paquets après classification n est d aucune utilité car l ordonnanceur du routeur pourra traiter tous les paquets. Cela dit, en cas de congestion l intérêt est tout autre. En effet, en fonction de l algorithme de gestion de files d attente choisi, l ordonnanceur pourra vider préférentiellement une file et laisser une file moins prioritaire se remplir et donc rejeter des paquets. Nous allons voir ici les algorithmes de gestion de files d attente les plus courants. PQ (Priority Queueing) Cet algorithme est le plus simple à mettre en place. Il permet d affecter une priorité stricte à une file d attente. Ainsi si le routeur possède trois files A, B et C, et qu il est configuré avec un algorithme PQ spécifiant que A est prioritaire sur B qui est elle-même prioritaire sur C on aura le fonctionnement suivant : un paquet de la file B ne sera servi que si la file A est vide ; un paquet de la file C ne sera servi que si les files A et B sont vides. Cet algorithme est intéressant pour gérer le trafic critique mais ne doit pas être utilisé pour un nombre important de flux car les flux non prioritaires seraient systématiquement rejetés. FQ (Fair Queueing) Cet algorithme permet le partage équitable des ressources. Si deux files d un routeur utilisent FQ, les flux passant dans chaque file auront le même débit en cas de congestion. WFQ (Weighted Fair Queueing) WFQ est identique à FQ mais il permet de pondérer certains flux. Il est ainsi possible de diviser la bande passante entre plusieurs files. WFQ est relativement coûteux en ressources car le routeur doit calculer à chaque émission combien de paquets de chaque file seront émis. CBQ (Class Based Queueing) CBQ permet d allouer une certaine proportion de bande passante pour une classe de trafic. Il est aussi possible de spécifier combien de paquets seront émis à chaque service. CBQ est intéressant si l on souhaite réserver une partie de la bande passante à un flux spécifique. Par exemple on peut consacrer 3% de la bande passante à un flux vidéo et laisser le reste en best-effort. 22

Chapitre 1. La qualité de service Comparaison des différents algorithmes sur différents routeurs En fonction du routeur dans lequel les algorithmes ont été implémentés les réactions sont parfois un peu différentes du résultat théorique. Une comparaison entre un routeur Cisco 165-R et un routeur Linux 2.4.2 a été faite dans [19]. 1.1.4 Modèles IntServ et DiffServ Afin d avoir une gestion de la QoS de bout en bout il faut que tous les routeurs du réseaux soient paramétrés de la même façon. Dans un soucis de standardisation, deux approches ont vu le jour : Intserv et DiffServ. IntServ Integrated Services (IntServ) a été proposé dans la RFC 1633 [11]. L idée est de fournir une QoS garantie stricte sur les réseaux IP. Dans un modèle IntServ, les applications envoient une requête RSVP [38] afin de réserver les ressources réseau nécessaires. Après une négociation avec les gestionnaires de QoS déterminant si le service peut être garanti, les ressources sont réservées ou alors un message d erreur est renvoyé au demandeur. Une fois les ressources réservées, la QoS pourra être appliquée dans les routeurs avec des algorithmes de gestion de files d attente. Le but principal de IntServ est de fournir un lien de communication à qualité constante en terme de débit et de délai. La principale limitation de IntServ réside dans son passage à l échelle. En effet, les requêtes RSVP doivent être mémorisées dans tous les routeurs concernés. Or dans un réseau à large échelle tel qu Internet, il y a une quantité phénoménale de flux concurrents. Une telle quantité imposerait des stockages très conséquents dans la mémoire des routeurs, ce qui engendrerait un surcoût inconcevable. DiffServ Differentiated Services (DiffServ) a été proposé par l IETF pour résoudre les problèmes posés par IntServ. Nous avons vu qu il était possible de marquer les paquets en utilisant le champ DSCP, voyons comment il est possible d assurer une QoS en utilisant ce champ. Tout d abord, les paquets possédant le même DSCP sont agrégés pour former un Behavior Aggregate (BA). Etant donné que l on gère ici au type de flux et non au paquet par paquet, la garantie de QoS n est pas stricte mais statistique. Il est important de noter que des paquets provenant de diverses applications peuvent partager le même BA. Sur un nœud DiffServ il faudra ensuite choisir un Per Hop Behavior (PHB) qui définira en fonction du BA les règles de mise en file d attente, d ordonnancement ou de lissage. Il existe quatre PHB standards : 23

1.2 Le besoin de QoS dans les applications multimédia Default PHB ; Class-Selector PHB ; Expedited Forwarding PHB (EF) ; Assured Forwarding PHB (AF). Ces PHB, ainsi que leur implantation dans Cisco IOS, sont décrits dans [34]. On notera simplement que le PHB EF est utilisé pour implanter le service Premium et que le PHP AF est utilisé pour le service Olympic (Gold, Silver, Bronze). Complémentarité de IntServ et de DiffServ IntServ et Diffserv peuvent être utilisés d une manière complémentaire afin de bénéficier des possibilités de IntServ sur des réseaux à large échelle. L idée, présentée dans [1] est d avoir des routeurs IntServ en bordure du réseau et des routeurs DiffServ au cœur. Il faudra dans ce cas que les requêtes RSVP soient traduites pour modifier le champ DSCP des paquets. 1.1.5 Conclusion sur la QoS dans les réseaux IP Nous avons vu dans cette partie comment il était possible d installer des mécanismes de QoS dans les réseaux IP. Nous avons vu un système permettant d avoir une garantie stricte sur le débit via le modèle Intserv et la réservation des ressources RSVP, et un système donnant une garantie statistique du débit via le modèle Diffserv. Ces deux modèles utilisent un système de marquage des paquets différent mais pouvant être converti afin d utiliser les bénéfices de chacun. Ainsi, même si IP n a pas été conçu pour supporter de la QoS, il est tout de même possible de s approcher de l efficacité d ATM dans ce domaine et ce, à bien moindre coût. 1.2 Le besoin de QoS dans les applications multimédia Avec un débit toujours plus grand proposé aux utilisateurs, les applications réseau ont évolué, ou plus exactement de nouvelles applications sont apparues : les applications multimédia. On peut compter parmi ces applications : la téléphonie sur IP, la diffusion de musique, la vidéoconférence, la vidéo à la demande. Ces nouvelles applications étant gourmandes en ressources, les réseaux traditionnels doivent mettre en œuvre des mécanismes de QoS pour ces flux dits continus. Nous allons voir ici les contraintes de ces applications. 24

Chapitre 1. La qualité de service 1.2.1 Contraintes communes aux applications multimédia Dans les applications multimédia, les données sont soumises à des contraintes temporelles quasi temps réel. Cela implique qu il n est pas possible d utiliser le protocole de transport TCP puisque si des paquets sont détruits en cas de congestion, leur réémission serait pénalisante et inutile pour le flux multimédia. Il faut donc utiliser un protocole de transport non fiable tel qu UDP. Le problème est qu avec UDP il n y a pas de séquençage des paquets. Cela pose par exemple un problème si un paquet A émis après un paquet B prend une route différente de celle de B (cela est tout à fait possible sur Internet) et arrive avant B. L idéal est donc pour ces flux continus d utiliser des protocoles tels que Real Time Protocol (RTP) avec une gestion très fine de la QoS sur les flux concurrents. 1.2.2 La téléphonie sur IP La principale contrainte de la téléphonie sur IP est le délai. Pour qu une conversation puisse avoir lieu convenablement, il est nécessaire d avoir une latence inférieure à 35 milli-secondes. Pour assurer ce délai, les routeurs ne doivent pas comporter des files d attente trop longues. En effet, de longues files d attente permettent d obtenir un débit plus élevé puisque moins de paquets sont perdus mais le temps passé dans les files augmente. Dans l idéal, les routeurs doivent avoir une file prioritaire à faible latence pour les flux de voix sur IP. 1.2.3 La vidéoconférence Pour la vidéoconférence, le débit est essentiel pour que la qualité de la vidéo soit suffisante et les contraintes en terme de délais sont identiques à celles de la voix sur IP. Il est en effet très gênant que l image soit décalée du son ou que le média soit saccadé. 1.2.4 Les applications coopératives Les applications coopératives sont potentiellement les applications qui demandent le plus de QoS puisqu elles peuvent utiliser à la fois la vidéoconférence, le transfert de fichier ou encore des sytèmes de tableaux blancs. Une solution gérant la QoS dans le framework d applications coopératives Calif [22] a été proposée dans [2]. 1.2.5 Conclusion sur la QoS dans les applications multimédia Il est incontestable que les applications multimédia ont un fort besoin de QoS, ce qui n est pas envisageable sur l Internet best-effort classique. 25

1.2 Le besoin de QoS dans les applications multimédia L idéal serait de pouvoir paramétrer tous les routeurs traversés. En attendant ces applications sont encore souvent réservées aux réseaux locaux. En effet, même la téléphonie par Internet qui est actuellement en plein essort est basée sur la technologie ATM qui est utilisée chez les fournisseurs d accès. 26

Chapitre 2 Les réseaux actifs 2.1 Introduction L évolution des réseaux traditionnels est largement freinée par un certain nombre de contraintes. En effet, l instauration de nouveaux protocoles est longue et difficile. Dans un premier temps, un tel protocole doit être standardisé afin d assurer la compatibilité avec les autres systèmes. Cela implique que pour être accepté par les organismes de standardisation, plusieurs années sont déjà nécessaires. Une fois le protocole accepté, il doit être implanté par les industriels dans les routeurs. Finalement, étant donné qu il est très difficile de mettre à jour dynamiquement un composant réseau, il est fréquent que ce composant doive être changé. Cela pose un autre problème qui est que lorsqu un composant est changé, le réseau peut être rendu indisponible pendant un certain temps, ce qui n est pas tolérable sur Internet et notamment dans les backbones. Nombreux sont les protocoles et applications qui subissent ces problèmes malgré leur utilité incontestable, entre autres : RSVP, le multicast, les extensions de sécurité ou de mobilité. Pour pallier à ce manque de flexibilité sont apparus les réseaux actifs, dont une première ébauche a été présentée dans [35]. Dans les réseaux traditionnels, les routeurs ont un objectif unique : le routage des paquets qui les traversent. Dans les réseaux actifs, l approche est relativement différente puisque cette fois les éléments actifs du réseau peuvent dynamiquement se reconfigurer. On peut donc imaginer une quantité impressionnante d applications qui étaient jusqu à présent difficilement réalisables avec les réseaux traditionnels. Nous allons dans un premier temps replacer les réseaux actifs dans leur contexte en donnant une classification des réseaux. Nous présenterons le fonctionnement des réseaux actifs avec les différentes approches qui existent. Ensuite nous donnerons les différentes normes existantes dans les réseaux 27

2.2 Classification des réseaux actifs, notamment au niveau du format des capsules 1. Une fois que nous aurons vu le fonctionnement des réseaux actifs, nous verrons les intérêts qu ils peuvent présenter. Finalement nous présenterons les travaux existants dans ce domaine de recherche. 2.2 Classification des réseaux Nous allons dans cette partie définir les principales caractéristiques des deux grandes familles de réseaux (les réseaux traditionnels et les réseaux programmables) afin de clarifier la notion de réseaux actifs. 2.2.1 Les réseaux traditionnels Les réseaux traditionnels sont ceux qui sont actuellement utilisés dans la plus grande majorité des cas. L objectif des routeurs dans les réseaux traditionnels est de router les paquets qui les traversent. Ces réseaux sont figés puisqu il est impossible de modifier les services implantés ou d en ajouter de nouveaux. La seule modification que l on puisse faire est la modification des tables de routage. 2.2.2 Les réseaux programmables Les réseaux programmables quant à eux sont plus flexibles que les réseaux traditionnels puisqu ils proposent un environnement de programmation à l échelle du réseau permettant de programmer les services. Les principales motivations des réseaux programmables sont : les délais entre la spécification initiale d un nouveau service, sa normalisation, sa réalisation et son déploiement à grande échelle sont devenus gigantesques (6 à 8 ans) et ne sont plus adaptés aux besoins de réactivité des opérateurs et fournisseurs de services ; le réseau peut profiter des informations issues d applications sur la nature et la sémantique de leurs flux ; le besoin en fonctionnalités applicatives dans les composants du réseau (firewall, caches Web,...) est de plus en plus présent. Les réseaux programmables peuvent répondre à tout cela, d autant plus que les capacités de traitement et de mémoire des composants internes du réseau suivent une croissance très importante en gain de performances et que leur coût diminue. Nous présenterons tout d abord la famille des réseaux à signalisation ouverte et ensuite celle des réseaux actifs. 1 Les capsules sont l équivalent des paquets des réseaux traditionnels 28

Chapitre 2. Les réseaux actifs Les réseaux à signalisation ouverte Les réseaux à signalisation ouverte sont basés sur une architecture permettant la création et le déploiement de services sur ses entités. L inconvénient est que ces modifications ne peuvent se faire dynamiquement, c est-à-dire que les routeurs ne doivent pas être connectés au réseau ou alors qu ils doivent être redémarrés pour que le service puisse fonctionner. Les réseaux à signalisation ouverte sont en fait une ouverture des réseaux traditionnels dans lesquels les routeurs ont des interfaces de programmation. Ces routeurs fournissent en principe une interface telle que Telnet ou encore SNMP 2 pour configurer leur plan de signalisation. Les réseaux actifs Les réseaux actifs sont complètement ouverts puisque tous les éléments sont programmables dynamiquement. De plus, en fonction de l implantation du réseau actif, la reconfiguration peut se faire aussi bien par les administrateurs du réseau que par les applications ou les utilisateurs. On distinguera encore trois sous-familles dans les réseaux actifs selon le cas où le déploiement des services se fait dans le flux de données, dans un flux séparé ou de manière hybride. La figure 2.1 montre la place des réseaux actifs dans les différentes familles de réseaux. Approche Approche Approche discrète hybride intégrée Réseaux actifs Réseaux à signalisation ouverte Réseaux programmables Fig. 2.1 Réseaux programmables. 2 Simple Network Management Protocol 29

2.3 Fonctionnement des réseaux actifs 2.3 Fonctionnement des réseaux actifs Maintenant que nous avons situé les réseaux actifs, nous allons en étudier le fonctionnement. Les réseaux actifs ont un fonctionnement très différent des réseaux traditionnels. Les applications ne sont plus seulement exécutées aux extrémités du réseau, comme dans un modèle client/serveur, mais elles peuvent l être tout au long du trajet des paquets. On peut donc déployer de nouveaux protocoles dynamiquement et aussi faire du traitement sur les paquets. Les réseaux actifs permettent de développer des protocoles variés qui peuvent se déployer de deux manières. Il existe une approche dite paquets actifs (ou approche intégrée) et une approche dite routeurs actifs (ou approche discrète). 2.3.1 L approche intégrée Dans cette approche, chaque capsule contient à la fois les données qu il transporte et le code à exécuter sur chaque routeur traversé. Lorsqu une capsule arrive sur un routeur actif, elle est désencapsulée, son code est exécuté dans un environnement d exécution et elle est réencapsulée puis envoyée à une interface de sortie du routeur. Le code contenu dans une capsule peut avoir plusieurs buts : router la capsule vers la bonne interface de sortie, c est la fonctionnalité de base ; modifier le contenu de la donnée ; modifier le comportement du routeur (installation d un nouveau protocole, modification de la table de routage,...) ; exécuter n importe quel autre traitement. 2.3.2 L approche discrète Dans cette seconde approche les capsules ne contiennent plus le code à exécuter sur les routeurs mais seulement un identifiant de protocole. Lorsque la capsule arrive sur un routeur, ce dernier regarde l identifiant de la capsule. S il possède le protocole correspondant à cet identifiant, il l exécute, dans le cas contraire il le télécharge. Ce téléchargement se fait sur un serveur centralisé dédié au téléchargement des protocoles. 2.3.3 Comparaison des approches Chacune des deux approches a ses avantages et ses inconvénients, c est ce que nous allons présenter ici. 3

Chapitre 2. Les réseaux actifs Le problème de l approche intégrée est que le code inclus dans chaque capsule augmente le trafic réseau et engendre donc une perte de bande passante. Cela est d autant plus vrai que chaque capsule transporte son protocole. En effet, si un grand nombre de capsules utilisant le même protocole transitent sur le même routeur, il y a une forte redondance de code. Si l on considère le protocole ping actif : les données transportées sont très faibles alors que le code doit contenir au moins l algorithme de routage qui permet à la capsule d aller de l émetteur au récepteur, de revenir et de calculer le temps de parcours. On voit clairement ici que le code à transporter est prédominant sur les données, ce qui n est pas très intéressant. Dans ce cas le paquet non-actif homologue sera beaucoup plus petit. C est principalement pour cette raison que l approche discrète a été proposée : chaque protocole n est téléchargé qu une fois, il n y a donc pas de perte de bande passante liée au transport des protocoles. Cela dit, le déploiement d une application est plus complexe puisqu elle doit au départ envoyer les protocoles qu elle va utiliser à un serveur de protocole. L avantage dans ce cas est que les protocoles peuvent être vérifiés et signés avant d être diffusés, ce qui est particulièrement intéressant en terme de sécurité. Un avantage non négligeable pour l approche intégrée est la tolérance aux pannes. En effet une architecture centralisée est toujours plus fragile qu une architecture répartie. Pour conclure l approche intégrée est plus flexible que l approche discrète mais elle consomme plus de bande passante dans le cas où les données à transporter ne sont pas largement prédominantes sur le code à intégrer. 2.3.4 L approche hybride Les avantages de chacune des deux méthodes précédentes sont intéressants, cependant leurs limitations sont tout de même importantes. Pour cette raison des méthodes hybrides sont apparues. Une méthode intéressante de déploiement hybride à été développée dans ANTS [12]. ANTS utilise un mode de déploiement où un routeur recevant des capsules dont il ne connait pas le protocole télécharge ce protocole sur le routeur précédent. Le routeur précédent connait forcément le protocole vu qu il a déjà traité la capsule. C est un déploiement de proche en proche. Cette méthode hybride a l avantage de ne télécharger un protocole qu une seule fois et de ne pas le télécharger sur un serveur centralisé. 31

2.4 Comparaison avec les routeurs classiques 2.4 Comparaison avec les routeurs classiques Nous allons voir ici à quel niveau du modèle OSI [7] s effectuent le routage classique et le routage actif. Application Présentation Session Transport Réseau Liaison Physique Fig. 2.2 Routage classique. Dans le routage traditionnel, le flux de données doit remonter au niveau réseau (cf. figure 2.2) du modèle OSI. En effet, pour effectuer le routage il est nécessaire d avoir l adresse du destinataire qui est contenue dans l entête du paquet IP, et ce paquet IP n est reconstitué qu au niveau 3. Si le routage comporte de la qualité de service, il est possible qu il faille remonter au niveau 4 (couche transport UDP ou TCP). Application Présentation Session Transport Réseau Liaison Physique Fig. 2.3 Routage dans un réseau actif. 32

Chapitre 2. Les réseaux actifs Dans le routage actif, les données doivent remonter au niveau application (cf. figure 2.3) du modèle OSI. Ici, il est possible d utiliser les données contenues dans le paquet pour effectuer un routage adapté à la sémantique des flux de données. Il est aussi possible, puisque le routage est effectué dans la couche application, d effectuer du traitement sur les données routées. On peut par exemple, dans le cadre d une diffusion de vidéo à la demande, redimensionner un flux vidéo à la volée si le terminal destinataire possède un écran de faible qualité. L inconvénient majeur de devoir remonter au niveau application est que cela est coûteux en ressources car il faut passer par une sérialisation/désérialisation des données, cela dit les possibilités ne sont pas comparables. Ce coût peut cependant être compensé en utilisant des machines puissantes, voire des clusters de machines, pour un noeud. Un exemple d application très ambitieux utilisant les routeurs actifs est présenté dans [25]. Les auteurs ont réalisé un système permettant de faire de la diffusion de vidéo en multicast. Le système est d autant plus performant que les routeurs qui le constituent tiennent compte de la bande passante disponible du destinataire pour lui offrir un service de la qualité la meilleure possible. C est dans ce genre d application que l on voit tout l intérêt des réseaux actifs puisqu il serait très complexe de réaliser cela dans le cadre des réseaux traditionnels. 2.5 Standardisation Afin de pouvoir être utilisable par le plus grand nombre, une technologie doit être standardisée pour assurer l inter-opérabilité avec l existant. Les projets de réseaux actifs sont nombreux et pas forcément très proches, cela dit un élément tend à être standardisé : l encapsulation des données. Cela consiste à définir comment les données sont transportées dans les capsules. C est en fait le point le plus important puisque deux routeurs actifs différents peuvent router les données à leur manière mais s ils veulent inter-opérer il faut qu ils partagent le même format de données. Deux approches de capsules se dégagent : le format ANEP et le format SAPF. 2.5.1 ANEP Active Network Encapsulation Protocol (ANEP) a été défini dans [3]. Il définit le format d un paquet actif indépendament du protocole sur lequel il est véhiculé (IP, TCP, ATM,...). Un paquet ANEP, présenté dans la figure 2.4 est composé de : un identificateur de version ; 33

2.5 Standardisation 15 31 Version HeaderLength OptionType Flags TypeID PacketLength OptionLength Option Payload * Active Packet Payload Fig. 2.4 Format d un paquet ANEP. des flags indiquent au routeur le comportement à adopter si le type du paquet n est pas reconnu ( : router le paquet avec un routage par défaut ; 1 : détruire le paquet) ; un identificateur de type qui permet d indiquer l environnement d exécution, au préalable fixé par l Active Network Assigned Number Authority (ANANA), associé au paquet (par exemple : 18 pour ANTS, 19 pour PLAN ou encore 2 pour Tamanoir) ; la longueur de l entête ANEP ; la taille du paquet en octet comprenant la taille de l entête et la taille de la charge utile ; un certain nombre d options ; la charge utile. Les options sont systématiquement de la forme Type/Longueur/Valeur (TLV). Quatre options sont définies : une option d adressage de la source ; une option d adressage de la destination ; une option de checksum utilisée pour vérifer l intégrité d un paquet ANEP ; une option de certification non négociée qui permet une authentification auprès d un noeud du réseau. ANEP, même s il n a pas été encore standardisé, semble être le format le plus utilisé dans les travaux sur les réseaux actifs, entre autres ANTS [12], PLAN [23], Tamanoir [21]. 34