Fonctionnalités logicielles légères dans les réseaux de communications. Rapport de stage de DEA Informatique fondamentale CORVO Jean-Paul RESO/LIP

Transcription

1 Fonctionnalités logicielles légères dans les réseaux de communications Rapport de stage de DEA Informatique fondamentale CORVO Jean-Paul RESO/LIP 30 Juin

2 Table des matières 1 Introduction 3 2 Solutions dynamisant le réseau Les réseaux actifs Définition ANTS : A toolkit for building and dynamically deploying network porocols Network processor Solutions en marge des réseaux actifs TAMANOIR : un nœud actif supportant les débits des réseaux gigabits OPES : Open Pluggable Edge Services Fonctionnalités logicielles légères (FLL) Définition Caracéristiques Urbanisation : Localisation : Types de services : Développement d un environement pour les FLL Plateforme matérielle - switch Myrinet Plateforme logicielle - gestionnaire de FLL dans un noyau linux Description de l environement Description de Netfilter Description du gestionnaire de FLL Architecture : Conclusion 17 7 Perspectives 17 2

3 1 Introduction La grande majorité des protocoles de l internet tentent d améliorer certaines caractéristiques du réseau (débit, latences, etc...), en applicant des solutions de bout en bout ("end to end"). Ces protocoles sont ainsi déployés sur les machines terminales sans remettre en cause le fonctionnement passif du réseau (simple transimission de paquets ("forwarding"). Le résaux actifs vont à l opposé de cette logique, en demandant au réseau d accomplir des tâches dont ont besoin les protocoles de plus haut niveau, afin de les rendre plus simples et plus efficaces. Cette approche doit aboutir à une meilleure utilisation de la ressource réseau. C est le cas par exemple du protocole de transport XCP [1] qui profite des informations retournées par le réseau (les routeurs spécifiques) pour améliorer les fenêtres de congestions des émetteurs et destinataires, afin d obtenir une plus grande bande passante que TCP, et réagir plus finement aux congestions dans le réseau. Les réseaux actifs opitimistes ne sont pas réalisables dans l Internet à court terme. En effet, les services déployés sont en générale consomateur de ressources (compression, cryptographie, etc...), et introduisent de ce fait une diminution de certaines caractéristiques du réseau (en particulier la latence). Bien que des solutions puissent être implantées en dur pour supporter les débits actuels, le coût de fabrication restera toujours un frein. C est ainsi qu une vision plus pragmatique et plus réaliste, serait d avoir des services légers dans les routeurs par exemple, afin de faire remonter aux protocoles ce dont il est nécessaire pour améliorer les performances du réseau. Les fonctionalités logicielles légères dans les réseaux ont pour but d aider de façon "best-effort" les protocoles de plus haut niveau, en leur fournissant des services adaptables à leurs besoins : on peut penser à un service de dégradation de flux, ou à un service aidant un middleware de grille, ou servant de point de peering. Un élément clef de ces fonctionalités est leur possibilité à être localisées ou non sur le chemin des données, fragmentées, répliquées, persistantes ou non, donnant ainsi une souplesse d utilisation et un caractère "best-effort" des services, et permettant d être intégrées partiellement dans l Internet actuel. De plus, elles se logent essentiellement dans les équipements de routage, en leur demandant un coût très faible dû à leur légèreté (processeur/mémoire). Plusieurs solutions ont été proposées afin de rendre le réseau plus dynamique, sans pour autant y mettre toute l intelligence que l on retrouve dans les machines. Ces solutions, tout comme les fonctionalités logicielles légères, visent à fournir des services que peuvent utiliser les applications, et permettent aussi d optimiser les communications, mais également de pouvoir supporter les nouvelles applications et les nouveaux besoins. Le chapitre 2 présente différentes solutions proposées en alternatives aux réseaux actifs, tout en gardant la dynamicité et en enlevant la lourdeur. Le chapitre 4 défini en détail les points clefs des fonctionalités logicielles légères : l urbanisation, la localisation, et les types de services associés. Le chapitre 5 présente les différents environements qui ont été mise en place au cours du stage : une plateforme matérielle (switch Myrinet), embarquant des processeurs dédiés pour l application de services logiciels sur les flux ; et une solution logicielle implantée dans un noyau linux. Dans les chapitres 6 et 7 nous allons conclure par les apports de ce stage, et en présentant les perspectives de développement et de tests sur ces travaux. 3

4 2 Solutions dynamisant le réseau 2.1 Les réseaux actifs Définition Les réseaux actifs sont constitués par un ensemble d équipements de routage réseau (généralement des routeurs) spécialisés offrant la possibilité d agir sur les flux de données les traversant. Cette possibilité d agir sur les flux se manifeste par l insertion des services ( qui sont en réalité de simples programmes destinés à modifier les paquets d un flux) provenant de plusieurs acteurs physiques (utilisateurs, opérateurs, etc...). L action des services présents dans les nœuds actifs peuvent être de nature différente : ces services peuvent modifier le sflux (compression à la volée, cryptage,...), meusurer certaines caractéristiques du flux (nombre de paquets), permettre de rediriger du flux (firewall ou équilibrage de charge), ou encore faire de la signalisation,... Différentes architectures de réseaux actifs ont été proposés, et se divisent en deux parties. Puisque le but est d appliquer un traitement spécifique à la volée sur les paquets, cela peut être fait soit en incorporant le code ou programme du service directement au sein du paquet, c est le domaine des paquet actifs, soit en permettant à des nœuds dédiés de pouvoir exécuter le programme du service après le lui avoir communiqué ; c est le domaine des nœuds actifs. Nous allons présenter brièvement les différentes catégories d architectures actives ANTS : A toolkit for building and dynamically deploying network porocols ANTS [2] est le cas typique d une architecture basée sur l approche paquets actifs. Il permet à une application de pouvoir déployer de nouveaux services et/ou protocoles directement dans le réseaux par le bais des paquets contenant le programme du service. ANTS met en place son architecture aux travers de trois principales compsantes : une capsule, qui n est autre chose qu un format de paquet (de transport) conteneur. Ce conteneur véhicule le code du service (et d éventuelles données). Un nœud actif permettant l exécution du service logé dans la capsule, et enfin un protocole unificateur Network processor Certaines initiatives ont été menées pour pouvoir intégrer aux routeurs de nouvelles capacités de traitements. Ceci se manifeste par des processeurs de type ARM,MIPS, RISC,... intégrant un fort parallélisme pour le traitement des paquets, et ceci sur les chouches une à sept du modèle ISO (de la couche liaison de données jusqu à la couche application). Nous allons maintenant voire une alternative aux réseaux actifs aux travers de deux exemples ; car ceci est directement en relation avec nos préocupation de fonctionalités logicielles légères trouvant leur place au sein de nœuds actifs. 4

5 3 Solutions en marge des réseaux actifs TAMANOIR : un nœud actif supportant les débits des réseaux gigabits Tamanoir [3] est une architecture de nœuds actifs supportant les débits des réseaux gigabits. Un nœud actif est traditionnellement conçu en couches. La première couche la plus basse constitue le système, puis la couche au-dessus constitue les système d exploitation sur lequel se trouve eventuellement un mécanisme choisissant le bon environnement d exécution (java par exemple), qui exécute un service actif, comme le montre la figure 1. Application active Application active Application active environement d exécution démultiplexeur Système d exploitation Système environement d exécution FIG. 1 Couche applicative d un nœud actif. Un nœud actif dans tamanoir est découpé en couche comme le montre la figure 3. Chacune des couches offre un type de service différent. FIG. 2 Architecture du nœud TAMANOIR. 5

6 C est la dernière couche de cette architecture, la couche KERNEL, qui permet de mettre en œuvre une alternative aux réseaux actifs aux travers de programmes légers. TAMANOIR propose de plus un mécanisme de sélection des services basés sur un format de paquets (paquet ANEP) ou bien à partir du port des flux de données brutes TCP/UDP. FIG. 3 Sélection de services OPES : Open Pluggable Edge Services La seule architecture proposant des points communs avec celle des fonctionnalités légères que nous verrons plus loin, est la solution des processeurs OPES [4]. L idée dans OPES est de pouvoir ajouter des services dans les réseaux de bordures de l internet, et ceci dans un équipement constitué de processeurs. Cette architecture se compose de trois entités principales que sont : Les entités OPES : processus agissant dans le réseau. Les flux OPES : flux de données entre les entités OPES Les règles OPES : ensemble de conditions-actions Deux éléments forment les entités OPES : les services applicatifs OPES, qui analysent et/ou transforment les données échangées entre clients et serveurs, et le "dispatcher", qui a pour but d appeler le service applicatif sur le bon flux de données, par le biais de règles OPES. Les flux de données OPES sont des flux echangés entre les différentes entités OPES, ainsi que le client et le serveur. Les règles OPES sont des ensembles de règles associant une condition à une action en permetant de déterminer quel service applicatif sera appliqué sur quel flux. D autres entités interviennent de cette architecture. Ce sont les "Callout Servers" qui sont utilisés par les "dispatcher" pour exécuter un service applicatif. Un exemple de service [5] réalisé par les processeurs OPES concerne les flux du protocole http : les services agissant sur les requêtes, comprenant des services modifiant les requêtes (restriction d accès à un site web) et d autres ne modifiant pas les requêtes (pour faire du contrôle de connexions par exemple). D autre services agissent sur les réponses, et sont formés de services modifiant les 6

7 réponses (pour de l adaptation de contenu) et de services ne modifiant pas (pour faire du "monitoring" par exemple). Un dernier service est possible, il s agit des services créant des réponses (pour de l aggrégation/fusion de flux). 4 Fonctionnalités logicielles légères (FLL) 4.1 Définition On désire prendre une approche plus pragmatique que celle des réseaux actifs, basée sur des fonctionnalités logicielles légères. L idée est d avoir un réseau où certains nœuds sont programmables dynamiquement par l ajout de fonctionnalités logicielles nécessitant peu de ressources (CPU, mémoire,...), et permetant ainsi d optimiser les flux de données le traversant. Cette optimisation sera validable et exploitable, dès lors que le surcoût introduit par ces fonctionnalités dans les nœuds actifs, supportent les débits actuels sans trop augmenter la latence. On conçoit alors que pour bénéficier d un tel apport d intelligence dans le réseau, sans entraver ses performances, on doit définir ce que l on entend pas légerèté. Par exemple un service de compression de données est lourd face à un service de marquage de paquets pour faire de la qualité de service. Il s agit ainsi de limiter les services embarqués dans les noeuds du réseau à ce qui est strictement nécessaire pour l optimisation des flux. Une telle approche nécessite des équipements réseaux ayant une ouverture limitée et déployant dynamiquement des fonctions. De plus on se place dans un cadre "best-effort". Si les fonctionnalités sont présentes dans le réseau, elles améliorent la qualité du transport. Si ces fonctionnalités ne sont pas disponibles (équipement en panne, données déroutées...), le transport doit néanmoins s effectuer sans bénéficier des services à valeur ajoutée. 4.2 Caracéristiques Urbanisation : Les services légers doivent permettent une meilleure utilisation du réseau, mais dans un cadre "best-effort". De ce fait, il n est pas indispensable que tous les nœuds du réseau soient dotés de telles fonctionnalités, il suffit en effet qu une partie bien définit du réseau le soit, afin d apporter une valeur ajoutée. C est l urbanisation de ces fonctionnalités dans le réseau qui répond à cette problématique. Le cœur de l internet est optique, et a comme objectif un routage optimisé, simple, et surtout le plus rapide possible, et est donc de ce fait peu concerné par de nouveaux services. Ce sont donc à d autres endroits de l Internet que doivent se placer ces services. On pense donc aux réseaux d accès, aux sorties de réseaux optiques, et aux points de peering (points du réseau reliant des opérateurs différents), comme le montre la figure 4, car ce sont à ces endroits que le réseau est le plus hétérogène en bande passante, en latence, etc..., et donc le plus assujétti à des services. Un exemple de services possible aux points de peering serait la réservation de bande passante, ou une conversion de protocoles. D autres endroits du réseau pourraient bénéficier de services offrant de la différenciation de services, de la qualité de service (QoS), ou améliorant des protocoles de transport multicast, etc... 7

8 FIG. 4 urbanisation Localisation : Comme on vient de le voir, les services légers trouvent leur place à des endroits préférentiels dans le réseau. L inconvénient est que certains flux ne pourront pas bénéficier de ces services si le routage actuel de l internet n est pas en partie modifié. Il convient alors de définir une autre flexibilité des services légers relatif à leur localisation. Trois éléments principaux sont mis en jeu dans les services suivants : une machine standard (PC) en figure 5 (A), une routeur disposant de capacités logicielles en figure 5 (B), et enfin, une routeur classique en figure 5 (C). FIG. 5 Equipements de l architecture. 8

9 Services localisés sur le chemin de données. C est le cas où un point particulier du réseau fournit un service qui se situe entre la source et la destination. L effet négatif peut être un goulot d étranglement si tout les flux nécessitent le service. En revanche, si le service s applique à la vitesse du lien, en plus du routage de base, on gagnera une valeur ajoutée dû à l application d un service. FIG. 6 Service localisé sur le chemin des données. Services repliqués sur le chemin de données. Les flux de données peuvent alors bénéficier du même service tout le long de son parcours dans le réseau. FIG. 7 Services repliqués sur le chemin de données. Services partitionnés sur le chemin de données. Dans cette configuration, le service est éclaté sur le parcours du flux, et celui-ci est complètement appliqué si le flux traverse tous les nœuds assurant chaque bout du service. FIG. 8 Services partitionnés sur le chemin de données. 9

10 Services localisés hors du chemin de données. Dans ce cas, un mécanisme de redirection est mis en œuvre afin d aller appliquer les services demandés. Cela peut évidement engendrer un coût lié à la redirection des paquets et à leur récupération avant le routage proprement dit. Cette redirection peut-être faite via un service comme le montre la figure 9 ou, dans le cas de routeurs plus intelligents sur la figure 10. FIG. 9 Services localisés hors du chemin de données - Par logiciel FIG. 10 Services localisés hors du chemin de données - Par matériel Services repliqués hors du chemin de données. Ici, un mécanisme de redirection déroute le flux afin d aller appliquer les services demandés présents sur certains points du réseau, et ceci, tout le long du parcours du flux dans le réseau. Le cas du déroutement par logiciel ou matériel est présenté dans les deux figures suivantes. FIG. 11 Services repliqués hors du chemin de données - Par logiciel 10

11 FIG. 12 Services repliqués hors du chemin de données - Par matériel Services partitionnés hors du chemin de données. Cette configuration présente un service eclaté, mais cette fois-ci hors du parcours du flux. Le déroutement logiciel ou matériel permet d atteindre les nœuds du réseaux fournissant les services. Le caractère partitionné du service implique que celui-ci ne sera appliqué que si tout les fragments du service rencontre le flux. Ceci peut permettre de mettre en place des services de dégradation de flux multimédias incrémentals fournis par des points spécialisés dans le réseaux (routeurs spécifiques, passerelles applicatives dédiées, etc..). FIG. 13 Services partitionnés hors du chemin de données - Par logiciel FIG. 14 Services partitionnés hors du chemin de données - Par matériel 11

12 4.2.3 Types de services : Les services actifs proposés sont légers et "best-effort" afin d être envisageable dans les réseaux actuels ou dans des éventuelles solutions matérielles. Pour une plus grande flexibilité, ont peut définir d autres catégories de services : Services best-effort Le service peut être disponible, auquel cas il est effectué sur le flux. Services garantis Il s agit ici de garantir sa disponibilité et sont exécution. Services génériques Le service est le même sur certains nœuds actifs du réseau. Services personnalisés Le service peut être déployé dans les réseaux par des applications, des utilisateurs, des flux, etc... Services jetables Le service déployé à une durée de vie limitée à celle du flux, à une opération de monitoring, etc... Services persistants. Le service est une version de production et est déployé jusqu à une prochaine version. 12

13 5 Développement d un environement pour les FLL. 5.1 Plateforme matérielle - switch Myrinet La première étape pour valider l approche des FLL avait pour but d implanter un certain nombre de services sur un switch Myrinet [6] composé d une carte de huit ports GigaEthernet, liés chacun à un processeur dédié (Lanai XP) permettant l exécution de services applicatifs. La figure refmyri.ps montre le schéma de la carte GigaEthernet. Cette plateforme matérielle est composée en plus du switch Myrinet, de trois PC bi-processeurs Pentium III, tous reliés au switch. FIG. 15 Architecture Netfilter L intégration des FLL au plus prés du processeur sur un tel plateforme aurait permi une validation sur les hauts débits actuels, mais certains problèmes de compilations a freiner cette approche. Cependant, le switch Myrinet ayant été conçu pour fonctionnér dans un réseau totalement Myrinet, donc avec une conception différente de la couche physique Ethernet, convertit les trames Ethernet en trames Myrinet. Cette conversion est réalisée par chaque processeurs constituant le switch. Ceci représente bien un service léger implanteé au sein du processeur Lanai XM. Selon les sources fourni par Myricom, des tests sur la bande passante et sur le délai ont été meusurés sur des PC bi-processeurs de 2.0Ghz Intel Pentium-4 Xeon, équipés de chipsets Serverworks Grand Champion. Le système d exploitation choisi est la Redhat 7.3 avec le noyau Linux Redhat smp. La version du gestionnaire logiciel de l infrastructure Myrinet est GM La figure 16 (A) montre la bande passante résultante et la figure 16 (B) montre le délai obtenu, avec le pourcentage CPU qui mobilise cette fonctionnalité de conversion de protocle. 13

14 FIG. 16 Architecture Netfilter 5.2 Plateforme logicielle - gestionnaire de FLL dans un noyau linux Description de l environement L implantation des FLL devait se faire à l origine dans un environement comportant un switch Mirinet, constitué d une carte de huit ports GigaEthernet, dont chacun d eux reliés à un processeur dédié (Lanai XM), et de machines standards. L intégration des FLL au plus près du processeur aurait permis une validation sur les très hauts débits actuels, mais certains problèmes de compilation ont freiné cette approche. Une alternative logicielle a été réalisé sous Linux. L architecture choisie se compose de trois machines standard, deux représentent deux points du réseaux, et la troisième servant de routeur intégrant un gestionnaire de fonctionnalités logicielles. Celle-ci est constituée d un module implantant un gestionnaire de FLL, dont le but est de charger dynamiquement en mémoire le code des FLL, de transmettre les paquets entrants au bon service (FLL), et d enlever le code des FLL qui ne sont plus utilisés en mémoire, soit définitivement (cas de services jetables), soit temporairement (interne au gestionnaire). Cette approche permet un déploiement de FLL simple, car s effectuant en plaçant le code (module) du service directement au sein du nœud via une ligne spécialisée, ou par connexion TCP à un port donné (ssh, ftp, telnet, etc...), ou bien encore, par un protocole de transport spécifique. 14

15 5.2.2 Description de Netfilter Le gestionnaire est basé sur Netfilter [7], la partie du noyau linux s occupant de la pile TCP/IP. Au sein de Netfilter, ont été définis cinq points d entrées dans le parcours d un paquet à destination de la machine hôte, ou à destination d autres machines via la machine hôte, comme le montre la figure??. Ces points d entrées sont : PREROUTING : permet d intercepter les paquets avant le routage. POSTROUTING : permet d intercepter les paquets après le routage. INPUT : permet d intercepter les paquets à destination de la machine locale. OUTPUT : permet d intercepter les paquets sortant de la machine locale (avant routage). FORWARD : permet d intercepter les paquets qui ne sont pas pour la machine locale mais qui la traverse. FIG. 17 Architecture Netfilter Description du gestionnaire de FLL C est le point d entrée FORWARD qui est utile ici, car il permet de capturer des paquets traversant la machine locale qui agit ici en tant que routeur. Le gestionnaire de FLL définit une accroche (hook) sur le point d entrée FORWARD de Netfilter, et pointe sur une table de multiplexage, constituée de fonctions de filtrage de paquets, afin de rediriger les paquets vers le code des FLL Architecture : On décrit ici le parcours d un paquet vers le code implantant un service léger. La première implantation du gestionnaire de FLL à été de faire parcourir le paquet dans toute la table de pointeurs vers les codes des FLL, et le code de chaque FLL se chargeant d indentifier si le paquet correspond à un flux qu il souhaite traiter, puis remet le paquet au gestionnaire. Ce dernier réinjecte le paquet dans l architecture Netfilter et poursuit son parcours jusqu au réseau comme l illustre la figure 18. On obtient ainsi une pile de FLL que traversera chaque paquet. 15

16 FLL 1 FLL 2... FLL n ROUTING FORWARD ROUTING NETWORK FIG. 18 Gestionnaire de FLL version 1 Une amélioration peut-être faite en permettant au gestionnaire de reconnaître les paquets et de l envoyer directement au code d un FLL donné, sans avoir à parcourir la table entière. Le gestionnaire de FLL se charge donc de trouver le bon pointeur sur le code du service à exécuter. La figure 19 illustre ce principe. Multiplexage FLL 1 FLL 2... FLL n ROUTING FORWARD ROUTING NETWORK FIG. 19 Gestionnaire de FLL version 2 16

17 6 Conclusion Les réseaux actifs offrent la possibilité de dépoyer dynamiquement des services dans le réseau. Ces services vont appliquer d eventuelles modifications à la volée sur les flux traversant les équipements hébergant ces services. Les fonctionnalités logicielles légères remettent en cause les réseaux actifs optimistes, dans lesquels les nœuds actifs (routeurs dotés de capacités logicielles) sont sollicités pour accomplir des services généralement lourds, comme la cryptographie ou la compression de donnée. De plus elles permettent de bénéficier de l apport des réseaux actifs, sans ajouter un coût de traitement trop élevé. Leurs caractéristiques concernant la localisation et l urbanisation, amplifient leurs flexibilités, en leur permetant d être large d utilisation. L approche des fonctionnalitées logicielles légères factorise de par sa conception un grand nombre de services de types différents dans les réseaux. Il en résulte une autre vision sur la manière d obtenir un réseau plus dynamique, et plus adaptables pour de nouveaux besoins. 7 Perspectives Il y a bon nombre détudes complémentaires à poursuivre ces les fonctionnalités logicielles légères. L implantation sous forme logiciel des fonctionnalités logicilles légères devra être plus poussée et plus variée. Il faudra par la suite envisager de eéaliser une architecture de FLL sur une plateforme matérielle, avec des validations. Pour une validation à plus grande echelle, et un cas réel de déploiement devra être fais sur une très grande architecture, comme Grid5000 [8] par exemple. 17

18 Références [1] Katabi D., Handley M. Tellabs Charlie R., "Congestion Control for High Bandwidth-Delay Product Networks" [2] David Wetherall, John Guttag, an David Tennenhouse. Ants : A toolkit for building and dynamically deploying network porocols. In IEEE OPENARCH 98, April [3] Jean-Patrick Gelas, "Vers la conception d une architecture de réseaux actifs apte à supporter les débits des réseaux gigabits", Thèse, 2003 [4] Barbir, A., "An Architecture for Open Pluggable Edge Services (OPES)", draft-ietf-opesarchitecture-04 (work in progress), December [5] Barbir, A., "Open Pluggable Edge Services (OPES) : Use Cases and Deployment Scenarios",Request for Comments : 3752, April 2004 [6] http :// [7] http :// [8] http :// [9] Eddie Kohler, "Datagram Congestion Control Protocol (DCCP)",draft-ietf-dccp-spec-06, February 2004 [10] Michael Welzl, "The Performance Transparency Protocol (PTP)",draft-welzl-ptp-05, June 2001 [11] Roland Westrelin, "Proposition autour de l architecture logicielle des interfaces réseau programmables", Thèse, 2001 [12] Robert Love, "Linux Kernel Developement", ISBN [13] Rubini A., Corbet J., "Linux device drivers", ISBN [14] Bovet Daniel P., CESATI M., "le noyau linux", ISBN