Modélisation d’une architecture orientée service

L’évolution du paysage numérique au cours de la dernière décennie a été radicale à différents niveaux. L’ouverture au grand public de l’Internet et l’explosion de son utilisation qui a suivi, ont ainsi considérablement modifié l’utilisation qui est faite du réseau. Les applications multimédia et interactives sont aujourd’hui plébiscitées et ajoutent aux transferts de fichiers classiques ceux de flux audio et vidéo et plus généralement des échanges de données possédant des contraintes temporelles fortes comme les jeux en ligne. Ces nouvelles applications créent de nouveaux besoins sur le transfert des flux d’informations échangés qui ne sont plus correctement pris en compte par les solutions protocolaires traditionnelles. Parallèlement les terminaux ont également suivi une évolution drastique, multipliant en leur sein les interfaces d’accès au réseau et donnant accès à de grandes capacités de stockage ou de puissance de calcul, y compris sur des machines nomades ou mobiles. Les parcs de serveurs (ou datacenters) sont devenus communs et permettent aux utilisateurs humains un accès continu et en tout lieu à leurs données personnelles. Ces machines et les communications qu’elles établissent offrent de nouvelles perspectives et créent ainsi de nouveaux contextes de besoins (en de débit ou de temps de transfert par exemple) pour lesquelles les protocoles actuels ne sont pas prévus.

Enfin, les réseaux eux-mêmes ont profondément évolué, et permettent dorénavant le nomadisme et la mobilité des terminaux de façon généralisée. Dans tous les domaines, que les réseaux soient locaux ou longue distance, avec ou sans fil, les capacités ont été décuplées. De nouveaux types de systèmes intermédiaires, appelés middleboxes, ont également été introduits, créant des situations inédites (le blocage de protocoles non reconnus par exemple) auxquelles ont à faire face les développeurs de solutions protocolaires. Dans ce contexte et historiquement, les protocoles de Transport traditionnels de l’Internet, tels que TCP et UDP, ont connu plusieurs évolutions et adaptations et de nouvelles solutions ont vu le jour comme DCCP, SCTP at plus récemment MPTCP. Le paysage des solutions protocolaires s’est donc densifié et complexifié, contribuant à créer un nouveau contexte auquel il s’agit aujourd’hui de faire face.

Contexte, Problématique, État de l’art et Positionnement

Contexte

Les réseaux informatiques ont pris une place prépondérante dans notre société, notamment Internet qui a profondément modifié, et modifie encore, le tissu économique et social à un niveau mondial. Tout ceci repose aujourd’hui sur des échanges de données à très grande vitesse, sur des distances de plusieurs centaines de kilomètres, très souvent traversant plusieurs continents, connectant des terminaux très divers.

L’évolution observée depuis l’ouverture d’Internet au grand public a considérablement changé les usages qui sont faits du réseau. Le web notamment, a évolué de manière à permettre un accès simple à de nombreux usages encore trop méconnus ou complexes et leur démocratisation a permis leur utilisation aujourd’hui massive. Ainsi, à l’utilisation des mails et de l’échange de fichiers, est venue s’additionner celle de l’audio, la vidéo ou les applications interactives, comme les jeux multi-joueurs en ligne ou les vidéoconférences. Les besoins d’hébergement liés au grand nombre d’utilisateurs ont entraîné la création de datacenters. Au sein de ces structures, des centaines de serveurs topologiquement proches doivent communiquer à très grande vitesse, organisés en grille. Le monde de la finance a automatisé certains de ses processus, créant le high frequency trading, des transactions financières à raison de plusieurs milliers par secondes. Ces situations sont des exemples d’une évolution qui a emmené le réseau bien loin de ce à quoi il ressemblait quelques dizaines d’années auparavant. La diversité des technologies réseaux, des terminaux et des types d’applications n’a jamais été aussi grande. Dans la suite de cette section, nous voyons l’évolution de ces trois domaines et nous évoquons comment les protocoles de Transport ont tenté de s’adapter à cette évolution.

Évolution des réseaux

Le contexte traditionnel et historique des réseaux est bien évidemment celui des réseaux filaires. Les différentes machines sont reliées ensemble par des câbles sur lesquels transitent les signaux électriques représentant les données à transmettre. De nombreux protocoles se sont développés suivant ce principe. Dans le domaine des réseaux locaux, ou LAN (Local Area Network) le protocole Ethernet [IEE12a], qui s’est imposé comme incontournable, permettait initialement des capacités de 10 Mbps, permet aujourd’hui des capacités de 10 Gbps et cette capacité continue de croître. De plus, des déclinaisons de ce protocole ont été avancées afin de l’utiliser sur des réseaux métropolitains ou MAN (Metropolitan Area Network) et sur des réseaux longue distance ou WAN (Wide Area Network). En MAN ou en WAN, les technologies xDSL (Digital Subscriber Line), connues en France pour l’ADSL (Asynchronous DSL) [ITU99a] et l’ADSL2 [ITU99b] et bientôt l’arrivée du VDSL (Very high bit-rate DSL) [ITU11b] ont permis l’accès à haut débit à la majorité des foyers, cette augmentation étant supportée dans les cœurs de réseaux par l’utilisation de protocoles comme SDH [ITU07]. L’évolution des réseaux filaires a donc été caractérisée par une augmentation des débits et un nombre croissants d’utilisateurs. Tous les types de réseaux ont également connus des évolutions via des accès sans fil. Le WiFi [IEE12b], en constante évolution et permettant déjà des débits de plusieurs dizaines voire centaines de Mbps, en accès WLAN comme WMAN, est utilisé par de plus en plus d’appareils, fixes, nomades ou mobiles. Les réseaux WMAN et WWAN ont également eu leur lot de nouveautés, grâce au WiMaX ou aux évolutions toujours constantes des réseaux mobiles, comme la 3G (UMTS et HSPA), et déjà 4G (LTE), et bien sûr les réseaux satellites [ETS13].

Ces réseaux sans-fil introduisent de nouveaux défis, le médium étant partagé entre tous les utilisateurs et sensible au bruit électromagnétique, les causes de pertes de données seront plus diverses et certaines hypothèses valables sur les réseaux filaires deviennent caduques. Ce type de support permet également à l’utilisateur de devenir nomade ou mobile. Il peut alors se connecter au réseau successivement depuis des localisations géographiques différentes, voire se déplacer en cours de communication. Chacun se voit connecté de manière permanente et non plus ponctuelle, via un terminal ou un autre.

Au fil du temps, différents éléments ont été introduits au sein du réseau afin d’en améliorer les performances ou de pallier des problèmes de sécurité. Certains de ces éléments brisent une notion capitale dans le modèle classique de la pile OSI : le caractère de bout en bout de la couche Transport. En effet, celle-ci est supposée n’être implémentée que sur les hôtes terminaux de la communication et non sur les éléments intermédiaires, ces derniers n’implémentant que les niveaux suivants : physique, liaison de données et réseau. Certains éléments intermédiaires, nommés middleboxes [Car02], rompent cette règle. En effet, celles-ci vont intervenir sur l’entête de niveau Transport, que ce soit de manière passive, en lecture uniquement, ou active, en la modifiant.

Par exemple, les Network Address Translator (NAT) ont besoin d’utiliser le numéro de port pour fonctionner, et doivent donc avoir une compréhension des différents protocoles de Transport utilisés afin d’aller lire les valeurs dont ils ont besoin dans l’en-tête de Transport. Bien qu’intervenant de manière uniquement passive sur le niveau Transport, si le NAT n’implémente pas le protocole utilisé, la communication risque d’être rompue.

De la même manière, les Performance Enhancement Proxies (PEP) interrompent, de manière transparente pour les hôtes d’extrémité, la communication. Dans le cas de TCP par exemple, ceux-ci répondent à la demande de connexion à la place de l’hôte terminal visé, se faisant passer pour celui-ci, coupant ainsi la connexion de niveau Transport en deux ou plusieurs tronçons distincts quand celle-ci n’est censée être composée que d’un seul. Comme pour les NAT, si un PEP n’a pas implémenté un certain protocole de Transport, tout trafic véhiculé par celui-ci sera interrompu par le PEP.

Évolution des terminaux

Parallèlement aux réseaux les terminaux ont également subi une forte évolution ces dernières décennies. L’arrivée des réseaux nomades et mobiles a permis la création de terminaux portables et transportables, dont les smartphones et tablettes sont les plus récents exemples. Les stations de travail ont disparu au profit d’une convergence avec les ordinateurs personnels, permettant à tous d’avoir accès à une puissance de traitement honorable. Les capacités de stockage ont également fortement évolué. L’accessibilité accrue à ces ressources a créé une explosion de la demande en terme de contenus. Ainsi, afin d’y subvenir, de nombreux datacenters ont vu le jour à travers le monde, créant des organisations topologiques de machines inédites, véritables concentrations de serveurs aux capacités de stockage se comptant parfois en exaoctets, et aux capacités de calcul de plusieurs teraflops. Tout ceci crée un environnement aux caractéristiques très hétérogènes, certains terminaux possédant des débits plus importants que d’autres, des ressources en terme d’énergie, de stockage ou de puissance de calcul différentes. Un même terminal peut également voir ses caractéristiques changer en cours de communication, à cause de la charge de la batterie des terminaux mobiles, ou lorsque l’interface réseau utilisée change, la plupart des systèmes possédants aujourd’hui plusieurs interfaces, de nature différentes ou non. En effet, la plupart des smartphones possèdent au moins aujourd’hui des interfaces WiFi, Bluetooth et USB en plus de leur antenne téléphonique, celle-ci implémentant la plupart du temps des technologies 2G et 3G, voire 4G, quand ceux-ci ne disposent pas en plus du WiMaX. Les ordinateurs portables disposent presque tous d’une interface Ethernet et WiFi. La plupart des serveurs disposent aujourd’hui de plusieurs interfaces Ethernet.

Évolution des applications 

L’augmentation des performances des machines et des réseaux a permis l’avènement de nouvelles applications et l’amélioration des applications existantes. Cellesci font parfois preuve de besoins radicalement différents de ce que l’on connaissait. Aux applications traditionnelles sont en effet venues s’ajouter les applications multimédia et interactives. Les applications traditionnelles, principalement basées sur l’échange de fichiers, présentaient toutes les mêmes besoins d’ordre et fiabilité totaux dans le transfert de leur données. En effet, chaque octet doit arriver intact et dans l’ordre d’émission à l’application réceptrice afin que celle-ci puisse reconstituer à l’identique le fichier d’origine, qu’il s’agisse d’un envoi de mail, d’une page web, ou d’un transfert de fichier quelconque. Les applications multimédia quant à elles présentent des besoins différents. Par exemple, un streaming vidéo aura besoin d’ordre, mais la fiabilité n’a plus à être totale. Il n’y a en effet aucun besoin de retransmettre une image dont la date d’affichage est dépassée. Certaines données deviennent donc obsolètes avec le temps. De plus, les méthodes de compression actuelles différencient les images leur attribuant des importances différentes. Il est donc possible d’appliquer un traitement discriminant à l’intérieur d’un flux de données, contrairement à un transfert de fichier, où chaque octet a la même importance que les autres. Les applications interactives, mettant en relation plusieurs personnes, réagissant les unes par rapport aux actions des autres, créent encore plus de besoins inédits. Afin que les interactions entre les participants soient fluides, qu’il s’agisse de jeu vidéo ou de vidéoconférence, le délai de transit d’un participant à l’autre doit être suffisamment court pour qu’il ne soit pas perceptible. En effet, pour un jeu vidéo de tir par exemple, type FPS, l’expérience jeu serait ruinée si lorsque vous tirez sur votre adversaire, celui-ci est en réalité à un endroit différent de celui où vous le voyez sur votre écran. Dans une communication, les délais trop longs risquent, en plus de saccader la conversation, de créer des échos très désagréables. Dans [ITU11a], l’Union Internationale des Télécommunications (ITU-T) établit une classification générale et non exhaustive des applications de types audio, vidéo et données existantes en fonction de leur tolérance aux pertes de données lors des transmissions, et des délais de transmission admissibles. Celles-ci sont réparties selon :
– leur tolérance ou intolérance aux pertes ;
– les délais qu’elles peuvent supporter, et sont alors subdivisées en quatre catégories :
– interactivité,
– réactivité,
– ponctualité,
– non criticité du délai.

Notons que certaines catégories sont apparues grâce à l’émergence des applications audio et vidéo, et que d’autres, telle la télécopie, plus tolérante par exemple qu’un transfert de fichiers, peut être satisfaite avec l’utilisation d’un service de Transport plus stricte que ce qu’elle requiert. On observe ainsi une évolution des catégories due non seulement à l’apparition de nouveaux types d’application, mais également à la précision de certaines distinctions qui pouvaient auparavant sembler superflues.

Table des matières

Introduction générale
Contexte
Problématique
Structure du document
1 Contexte, Problématique, État de l’art et Positionnement
1.1 Contexte et Problématique
1.1.1 Contexte
1.1.1.1 Évolution des réseaux
1.1.1.2 Évolution des terminaux
1.1.1.3 Évolution des applications
1.1.1.4 Évolution des protocoles de Transport
1.1.2 Problématique
1.1.2.1 Acteurs concernés
1.1.2.2 Problèmes soulevés
1.2 État de l’art
1.2.1 Protocoles de Transport
1.2.1.1 TCP
1.2.1.2 UDP
1.2.1.3 DCCP
1.2.1.4 SCTP
1.2.1.5 MPTCP
1.2.1.6 CTP
1.2.1.7 ETP
1.2.2 En résumé
1.3 Positionnement de la proposition
1.3.1 Approche
1.3.2 Exigences générales de conception de l’ATL
1.3.3 Paradigmes de conception relatifs à l’architecture de l’ATL
1.3.3.1 Conception logicielle basée composants
1.3.3.2 Conception logicielle orientée service
1.3.3.3 Autonomic Computing
1.4 Conclusion
2 Architecture de l’ATL
2.1 Exigences de conception et principes l’ATL
2.1.1 Exigences de conception de l’ATL
2.1.2 Principes des solutions proposées en réponse aux exigences de conception de l’ATL
2.1.3 Approches d’implantation de ces principes
2.1.3.1 Approche orientée services
2.1.3.2 Approche basée composants
2.1.3.3 Approche autonomique
2.1.3.4 Synthèse
2.1.4 Fonctionnalités de l’ATL
2.1.4.1 Fonction de gestion des services
2.1.4.2 Fonction de gestion autonomique de la communication
2.1.4.3 Fonction d’accueil, d’assemblage et de mise en œuvre des compositions
2.2 Architecture de l’ATL
2.2.1 Cas d’utilisation
2.2.2 Modèle d’architecture de l’ATL
2.2.2.1 Modèle général
2.2.3 Composants de base de l’ATL
2.2.3.1 Le Flow
2.2.3.2 L’Autonomic Manager
2.2.3.3 Le Data Plan
2.2.3.4 Intégrateur des services et base de connaissances
2.2.4 Composants secondaires
2.2.4.1 Flow Creator
2.2.4.2 Signalization Message Controler
2.2.4.3 Multiplexage-démultiplexage entre couche réseau et Flow
2.3 Conclusion
3 Description comportementale de l’ATL
3.1 Création d’un point d’accès au service de Transport
3.1.1 Instanciation d’un Flow
3.1.2 Application cliente
3.1.2.1 Application legacy
3.1.2.2 Application ATL-aware
3.1.2.3 Application smart
3.1.3 Application serveur
3.1.3.1 Application legacy
3.1.3.2 Application ATL-aware
3.1.3.3 Application smart
3.1.4 Synthèse
3.2 Reconfiguration d’un Flow
3.2.1 Déroulement d’une reconfiguration
3.2.1.1 Classification des cas de reconfiguration possibles
3.2.1.2 Suivi du plan de reconfiguration
3.2.1.3 Déroulement selon les cas
3.3 Traitement des retransmissions lors des transitions
3.4 Conclusion
4 Expérimentations et mesures
4.1 De la composabilité des protocoles
4.1.1 But de l’expérience
4.1.2 Description de l’expérience
4.1.2.1 Choix de l’application
4.1.2.2 Micro-protocoles utilisés
4.1.2.3 Simulation
4.1.3 Analyse des résultats
4.1.3.1 Comparaison des performances de MPTCP avec TCP et UDP
4.1.3.2 Comparaison de MPTCP avec et sans mécanismes couplés
4.1.4 Conclusion
4.2 De l’intérêt de l’adaptation dynamique
4.2.1 But de l’expérience
4.2.2 Description de l’expérience
4.2.2.1 Choix de l’application
4.2.2.2 Micro-protocoles
4.2.2.3 Simulation
4.2.3 Analyse des résultats
4.2.4 Conclusion
Conclusion générale

Lire le rapport complet