Composant d’intégration et base locale des composants

Télécharger le fichier pdf d’un mémoire de fin d’études

Evolution des protocoles de Transport

L’orientation des évolutions au niveau Transport a été guidée par plusieurs facteurs e plusieurs classifications peuvent ainsi être établies. Selon le champ d’application de la solution, on distingue des solutions : 1) spécifiques à un domaine particulier, 2) géné- rales au domaine Internet notamment, ou 3) hybrides, c’est à dire combinant les deux approches. Selon la nature de l’évolution elle-même, on distingue des propositions de nouveaux protocoles, de nouveaux mécanismes pour des protocoles existants ou des améliorations à des mécanismes déjà existants. Enfin, selon la couche ciblée, les évolutions peuvent concerner les applications, les réseaux ou les deux à la fois. Les travaux sur le Transport se comptent par plusieurs centaines et il n’est donc pas possible de tous les référencer. A titre illustratif, nous en citerons les principaux en essayant de couvrir l’ensemble de la période d’évolution. Nous décrivons dans la suite de cette section les travaux sur le Transport selon les trois angles introduits ci-avant.

Approche générales et approches spécifiques

Les champs d’utilisation des solutions de Transport varient en fonction du besoin en termes de communication ou des avantages qu’il est possible d’obtenir en élargissant ou en restreignant ces champs d’utilisation. La majorité des travaux concernent des champs d’utilisation spécifiques. Il s’agit notamment de contextes applicatifs ou réseaux présentant certaines particularités qui rendent les protocoles classiques inefficaces. D’autres solutions tentent de couvrir un champ d’utilisation plus large (à l’échelle de l’Internet notamment) à la façon des protocoles classiques tels que TCP. Enfin, un dernier type propose une combinaison des deux aspects par le biais de protocoles « adaptatifs » adoptant des comportements différents selon le contexte. Nous étudions ci-après les trois approches.
Approche spécifique
Les évolutions des besoins des applications et des technologies réseaux rendent leurs particularités de plus en plus courantes. Les réseaux sans fil présentent des taux de pertes plus élevés que les réseaux filaires, les réseaux satellites présentent des délais plus élevés que les réseaux locaux, les réseaux ad-hoc de type « pair à pair » ou « machine à machine » présentent des variations importantes dans les délais, etc. De la même fa- çon, les applications multimédias et de transfert ont besoin de débits de plus en plus importants, pendant que des applications interactives et critiques ont besoin d’un minimum de délai, ou encore n’ont plus besoin de certains services, tels que ceux concourant à une garantie de fiabilité totale.
La plupart des travaux proposent donc de nouvelles solutions dont chacune est adaptée à un champ d’utilisation spécifique. Les solutions spécifiques ciblent un type particulier d’applications afin de lui offrir un meilleur service ou un type particulier de réseau afin d’en optimiser l’utilisation. Par conséquent, les solutions spécifiques pré-sentent naturellement de hautes performances (relativement ou dans l’absolu) étant donné leur connaissance préalable des aspects de leurs contextes d’utilisation.
Les performances de ce type de solutions ne sont cependant pas équivalentes et varient selon le degré de spécificité du contexte ciblé. Cette variation de spécificité vient du fait que pour chaque groupe d’application ou de technologie réseaux ayant des besoins et des caractéristiques relativement similaires, il est possible de trouver un sous-groupe plus distinctif. On peut à ce titre trouver des solutions spécifiques à l’ensemble des réseaux sans fil, caractérisés par d’important délais et taux de pertes, comme les deux versions de contrôle de congestion proposées pour TCP dans [1][2] afin d’adapter le protocole à des liaisons sans fil. On peut néanmoins trouver des solutions, toujoursspécifiques pour des liaisons sans fil, avec davantage de précision. A titre d’exemple, des solutions ont été proposées pour des réseaux satellitaires, comme dans [3][4], ou pour des réseaux locaux sans fil, comme dans [5][6], dont les différences entre les délais et les taux de pertes sont importantes. D’autres protocoles ont été proposés pour tenir compte de besoins particuliers, comme pour l’économie d’énergie dans [7][8]. Il en est de même pour les applications. Plusieurs solutions ont été proposées pour des applications gérant des flux vidéo, et présentant des besoins en délai et en débit. Toutefois, ces applications multimédias sont de différents types. On trouve donc des solutions générales, comme dans [9][10] qui proposent deux versions de TCP pour les applications multimédias. On trouve également d’autres solutions plus spécifiques traitant des applications multimédia interactives qui présentent des besoins en délai [11], à l’exemple des vidéo-conférences, ou encore des solutions pour des applications de streaming vidéo ayant plus de besoin en débit [12].
La spécificité d’une solution joue considérablement sur ses performances. En effet, c’est pour obtenir de meilleures performances que des solutions plus spécifiques ont été créées. Cependant, plus la solution est spécifique et plus son champ d’application se restreint, ce qui réduit ainsi ses possibilités de déploiement.

Solutions pour les applications et solutions pour les réseaux

Depuis l’apparition des réseaux locaux à haut débit à la fin des années 80, les solutions de base développées au niveau Transport de l’Internet (TCP notamment) sont rapidement devenues insuffisantes et inadaptées aux nouvelles technologies [16]. Cette difficulté d’adaptation résulte de l’ensemble des hypothèses sur lesquelles une solution donnée se base pour détecter les événements et effectuer les traitements associés. Ces hypothèses dépendent de la nature des flux applicatifs et des caractéristiques des réseaux sous-jacents, et il est très difficile d’aboutir à une caractérisation commune tenant compte de l’ensemble des aspects [17][18]. Plusieurs études ont été menées afin de mesurer l’efficacité des protocoles de Transport dans ces nouveaux environnements et en quelques années, des dizaines de solutions ont déjà été proposées comme alternatives à TCP dans les environnements où il n’était plus adapté. [19][20][21] sont parmi les tous premiers travaux en rapport avec les réseaux locaux, optiques et satellites. D’autres travaux ont suivi depuis l’époque jusqu’à nos jours. Parmi les derniers travaux, on peut citer [22][23][24], en rapport avec les nouvelles tendances concernant l’Internet des objets, le Cloud et l’Internet mobile. De nombreux autres exemples peuvent être trouvés dans la littérature.
De la même façon, les besoins classiques des applications utilisant ces protocoles, qui se résumaient initialement à un transfert de donnée fiable (i.e. sans perte ni erreur) et ordonné (i.e. sans déséquencement), ont évolué avec l’apparition d’applications multimédias, distribuées en temps réel, et plus généralement avec l’émergence de systèmes distribués critiques, notamment vis-à-vis du respect de contraintes temporelles. De nouvelles solutions de Transport sont aussitôt apparues pour offrir des services plus adaptés à ces nouveaux besoins. [25] fut l’un des premiers travaux à proposer un protocole de Transport pour la diffusion de télévision en haute définition. Plus récemment, de nouveaux travaux ont proposé des versions adaptées aux trafic http dans les centre de données (data centers) [26] et sur la qualité de service pour les flux multimédiastemps-réel [27].
Enfin, il est possible que ces nouvelles solutions prennent en compte à la fois des types d’applications spécifiques et des contextes réseaux particuliers. Ceci vient en général en réponse à des dysfonctionnements qui peuvent se produire dans des solutions traitant uniquement d’un seul aspect (applicatif ou réseau). On trouve par exemple des versions de TCP pour les applications multimédia dans les réseaux sans fil, comme dans [28]. Un autre exemple est une version de TCP qui a été proposée dans [29] pour les applications interactives dans les réseaux satellites. Ici encore, plus la solution prend en compte davantage d’aspects et plus ses performances sont meilleures.

Nouveaux protocoles et nouvelles versions

Les propositions n’aboutissent pas toutes à de nouveaux protocoles. En fait, une grande partie des travaux sur le Transport ont conduit soit à des versions des protocoles existants incluant de nouveaux mécanismes, soit à la proposition de nouvelles versions des mécanismes existants. Les nouveaux protocoles ont notamment marqué les premiers travaux durant la fin des années 1980 et la première partie des années 1990. Plusieurs protocoles, spécifiques notamment, ont été proposés comme LNTP [30] pour les ré- seaux locaux à haut débit, et MHTP [31] pour les applications multimédias. Depuis, les propositions de nouveaux protocoles sont de moins en moins répandues, probablement en raison du large déploiement du protocole TCP et de la non évolution de la couche Transport. Il en existe tout de même de très récents, tels que MPMTP pour les applications multimédia multi-paths [32], ou encore OverUDP pour les réseaux pair-à- pair [33]. En revanche, pour les solutions générales et hybrides, la plupart des solutions ont été proposées sous la formes de nouveaux protocoles, bien qu’il ne s’agisse, pour quelquesunes, que de simples ajouts ou de combinaisons de protocoles existants, tels que MPTCP qui n’est qu’une combinaison de flux TCP. La Figure 1.1 ci-dessous illustre une classification des solutions de Transport.

Limites de la couche Transport

Tel que mentionné précédemment, le problème au niveau de la couche Transport n’est pas dans la disponibilité de solutions efficaces mais plutôt dans leur (faible) déploiement. Le problème du déploiement est dû à plusieurs limites architecturales de l couche Transport telle qu’elle a été conçue initialement. Nous présentons dans cette section un état de l’art sur les limites qui ont été soulevées dans les différents travaux sur les architectures des protocoles de Transport face au déploiement des nouvelles solutions. Nous présenterons une étude plus approfondie sur ces limites au chapitre II.
Quatre obstacles ont été identifiés : la configurabilité, l’adaptabilité, la flexibilité et la complexité [34].

Configurabilité

La configurabilité est la première limite soulevée dans les travaux sur le Transport. Les premiers protocoles ont été conçus de sorte à offrir un certain nombre de services de base liés aux besoins initiaux, sous forme d’un ensemble non séparable (protocoles qualifiables de « monolithiques »). L’utilisateur se voit donc offrir l’ensemble de ces services sans avoir la possibilité d’en choisir un sous ensemble. Cette politique n’a pas posé de problème jusqu’à la venue de nouvelles applications ayant d’autres besoins qu’un transfert (fiable ou non fiable) de leurs données. Pour ces nouveaux besoins comme le délai ou la gigue, une telle politique ne peut être adaptée, dans la mesure où des services non nécessaires pourraient nuire à des services plus importants. A titre d’exemple, pour des flux vidéo où une fiabilité partielle est suffisante et un délai très court est nécessaire, un service offrant une fiabilité totale nuira considérablement au délai à cause du coût temporel des retransmissions.
Dans ADAPTIVE [35][36], le manque de configurabilité est décrit comme un obstacle du fait de l’important surplus de données ou de calculs qu’il engendre, notamment dans la gestion de l’établissement de connexion dans le modèle requête/réponse. Dans CTP [37], le problème de configurabilité est décrit comme le fait d’appliquer le même traitement à l’ensemble des paquets et des flux d’un protocole. Dans Coyot [38] et Appia [39][40], la configurabilité consiste à instancier des services personnalisés spécifiques à chaque type d’applications.
Quel que soit l’angle sous lequel est traité le problème de configurabilité, l’idée de base est d’avoir un ensemble de services instanciables à la demande dans un même protocole, et ce, au lieu d’avoir un protocole spécifique à chaque type d’application ou de réseau par la réutilisation des services, et au lieu d’obliger l’application à utiliser des services non nécessaires au prix d’une diminution de performances.

Évolutions architecturales au niveau Transport

En réponse aux limites présentées dans la section précédente, certains travaux ont proposé de  nouvelles approches de conception de l’architecture des protocoles de Transport, visant à faciliter l’intégration de nouveaux services et mécanismes. Elles ont suivi l’approche hybride présentée en amont, combinant l’efficacité des solutions spécifiques adoptant un comportement adapté à chaque environnement, et la facilité de déploiement en ne présentant qu’une seule interface aux applications, et en évitant d’encombrer les systèmes d’exploitation par une multitude de solutions correspondant chacune à un contexte particulier.
Nous décrivons ci-après les principales solutions proposées. Compte tenu des diffé- rents aspects qu’elles ont abordés, nous mettons l’accent sur l’aspect architecture en réponse aux limites de la couche Transport citées précédemment. D’autres aspects techniques concernant la mise en oeuuvre de ces nouvelles architectures, telles que la gestion des compositions, sont communs et font l’objet d’un état de l’art spécifique (section 1.3.2). Nous présentons donc dans cette section les nouvelles architectures de Transport ainsi que les éléments conceptuels s’y rapportant.

Nouvelles architectures

Cette section présente les différentes architectures proposées au niveau de la couche Transport pour faciliter son évolution et en améliorer les performances. Une de leurs caractéristiques communes est la composition dynamique d’un service de Transport à base de composants élémentaires offrant chacun un service ou une fonctionnalité d’un service (micro-service). Ce principe de décomposition / composition est apparu dans plusieurs architectures depuis le début des années 90 [41]. Il ne se résume cependant pas aux architectures des protocoles de Transport et concerne également d’autres architectures plus générales comme x-Kernel [43], V-Stream [44] ou autres. Dans cette partie, nous traitons uniquement des architectures de protocoles de Transport, et nous ferons référence, si besoin, aux autres architectures quand nous discuterons notamment des aspects techniques et conceptuels.
ADAPTIVE
ADAPTIVE, A Dynamically Assembled Protocol Transformation, Integration, and eValuation Environment [35][36], est l’une des premières solutions qui s’est intéressée aux problèmes architecturaux de la couche Transport, en proposant un framework pour la composition dynamique de protocoles de Transport. Il part du fait que l’ensemble des protocoles qui existent actuellement (à cette époque) est très limité en termes de services et de performances. Les solutions existantes ne peuvent pas prendre en compte les évolutions des applications et des technologies réseaux. Ainsi, un ensemble aussi limité de services ne pourra jamais couvrir les besoins variés des applications, notamment les application multimédias et interactives. Enfin, le modèle de conception de ces protocoles, dépourvu de toute flexibilité, empêche de les faire évoluer. L’architecture ADAPTIVE est présentée dans la figure 1.2.
Les concepteurs d’ADAPTIVE pointent donc comme limite principale le manque de flexibilité des solutions existantes qui fait que leur maintenance est fortement coûteuse notamment compte tenu de leur durée de vie relativement courte. Ils proposent comme solution une architecture plus souple qui facilite l’intégration de nouvelles fonctionnalités sans avoir à affecter les composants existants. Par ailleurs, ils traitent l’adaptabilité des services aux besoins spécifiques des différentes applications, et partent du principe qu’un protocole indépendant dédié à chaque situation est une approche irréalisable.
La solution qu’ils proposent repose sur le fait que la spécificité des besoins ou des contextes réseaux se limite la plupart du temps à un seul élément (service ou fonction protocolaire) et le reste est partagé. Ils proposent par conséquent une solution basée sur la notion de micro-protocoles, reprise de xKernel et l’assemblage dynamique selon les besoins de l’application. Les problèmes liés aux performances sont traités par une instanciation des éléments uniquement nécessaires aux besoins de l’application, réduisant de cette façon le surplus de données et de calcul dû aux services non nécessaires.
Enfin l’adaptabilité est traitée par cette instanciation dynamique de services, mais reste statique et à la charge de l’application. Par ailleurs, ADAPTIVE offre des outils avancés pour l’évaluation des performances afin d’aider l’utilisateur à tester facilement sa configuration.

La pile de protocoles ATN/OSI

Comme introduit un peu plus haut, le réseau ATN a été définit suivant le standard OSI à sept couches. Distingue les couches hautes (Upper Layer communication service) et les couches basses (ATN Internet communications service), comme illustré à la figure 1.12 [53].
Les applications sont de deux types : Air-Ground applications, définies dans le standard [55], et Ground-Ground applications, définies dans les standards [56][57]. Le standard définit plusieurs applications de la catégorie Air-Ground. Il s’agit principalement de l’application CM (Context Management) pour l’établissement de lien entre deux entités, CPDLC (Controler Pilot Data Link Communication), ADS (Automatic Dependent Surveillance), FIS (Flight Information Service), etc. Pour chaque application, le standard spécifie les éléments de services (ASE pour Application Service Elements), l’ensemble de ces services sont regroupés dans une Application Entity (AE), qui constitue la partie communicante de chaque application. Les couches hautes sont aussi constituées de l’équivalent des couches session et présentation du modèle OSI. Le standard définit deux applications dans la catégorie Ground-Ground, il s’agit de AIDC (ATSInterfacility Data Communication) et AMHS (ATS Message Handling Service).
La partie ATN Internet communication services est constituée du protocoles TP4 au niveau Transport qui offre un service proche de celui de TCP, et du protocole CLNP ConnectionLess Network Protocol), qui offre un service similaire au protocole IP. Les protocoles des couches liaisons et physique sont définis selon les liens physiques concernés, ils sont décrits dans le document [53]. L’accès aux services de communication pour les applications s’effectue via l’interface DS (Dialogue Service) qui offre des primitives de services correspondant aux protocoles des couches hautes.

La transition vers IP

La transition vers les standards de l’Internet a été motivée par la complexité qui résulte de la gestion de deux piles protocolaires lors de l’utilisation des réseaux de coeur de l’Internet. La procédure est encore dans son début, un standard a été définit [52] mais il ne présente que les spécifications d’un système utilisant les protocoles de l’Internet. Une des exigences de cette transition est le fait de disposer, pour chaque équipement, des deux piles protocolaires durant la phase de transition, qui au passage peut durer plusieurs années, voire plusieurs décennies. La problématique qui en résulte, et qui constitue notre cas d’étude, concerne la gestion de coexistence des deux piles protocolaires pendant la phase de transition. La problématique est illustrée sur la figure 1.13
Nous proposons pour cela, au chapitre 5, un exemple d’application de notre architecture pour gérer des applications et des protocoles hétérogènes correspondant aux deux piles protocolaires, et ce de façon transparente et autonome.

Limites des architectures existantes

Le fait de fonctionner, encore à ce jour, avec des solutions datant à quelques exceptions près des années 80, est dû à une série de limites qui rendent le déploiement de nouvelles solutions, par ajout ou par mise à jour, extrêmement coûteux à tous les points de vue (temps, difficulté, risques de bugs, …) et touchant tous les acteurs concernés (applications, systèmes, …) [48].
Les nouvelles architectures de Transport, présentées au chapitre précédent, ont apporté quelques solutions à ces limites, mais rencontrent elles-mêmes des difficultés pour être déployées, soit à cause d’un traitement partiel de ces limites, soit par des limites internes à l’architecture elle-même. Dans ce qui suit, nous présentons l’ensemble des limites pour le déploiement de nouvelles solutions au niveau Transport [34].
Problème de dépendance la difficulté dans l’intégration des nouvelles solutions vient avant tout du coût important qui résulte de leur déploiement, concernant notamment le système d’exploitation, mais aussi les applications et la version déployée du protocole lui-même en cas de mise à jour. Ce coût résulte de la forte dépendance qui existe entre la couche Transport et les acteurs externes, applications et systèmes notamment.
D’un côté, les interfaces par le biais desquelles les protocoles sont invoqués par les applications sont très spécifiques, leur syntaxe est donc incluse dans le code de l’application lors de sa conception. Une fois une application écrite pour un protocole donné, il n’est plus possible qu’elle utilise un autre protocole sans devoir modifier son code.
Cette dépendance entre les applications et les protocoles de Transport sous-jacents implique également que toute modification apportée à l’interface d’un protocole aura un impact sur l’application. Plus important, il n’est pas possible pour une application de tirer parti des nouvelles fonctionnalités d’un protocole sans modifier son code source. A titre d’exemple, il est courant que des applications soient obligées de gérer elle-même certains services s’ils ne sont pas offerts par le protocole sous-jacent (cas par exemple des applications multimédias fonctionnant avec UDP qui doivent implémenter leur propre contrôle de congestion). Si le protocole supporte le contrôle de congestion après conception de l’application, il n’est plus possible d’en tirer parti sans modifier le code de l’application, ni de migrer vers un autre protocole, tel que DCCP par exemple qui, lui, intègre un contrôle de congestion.
D’un autre côté, ces protocoles sont implémentés comme une partie du système d’exploitation. Il en résulte que toute modification du code de ces protocoles doit se faire dans le noyau, ce qui nécessite une modification du système d’exploitation. Ce fait a plusieurs répercussions sur le déploiement des protocoles. D’abord le coût d’une modification de noyau est plus élevé tant en termes de risques de bug qu’en terme de travail d’implémentation. Ensuite, ces modifications du système vont créer une certaine hété- rogénéité dans leurs différentes versions avec des fonctionnalités qui ne seront dispo- nibles que dans certains systèmes, créant ainsi une incohérence dans le fonctionnement global de la couche Transport.
Problème d’extensibilité le terme d’extensibilité peut être vu de différentes façons selon le contexte. Dans notre cas, nous l’entendons par la capacité à pouvoir apporter des modifications à un programme par ajout de nouvelles fonctionnalités ou par mise à jour des fonctionnalités existantes, sans avoir à recompiler le programme, au moins dans son intégralité. En effet, les protocoles de Transport, à l’instar de tant d’autres, sont codés en un seul bloc non séparé. Par conséquent, toute modification aussi petite soit-elle dans le protocole, nécessite une recompilation entière du code, ou à dé- faut, l’implication d’autres composants dans la compilation de la partie modifiée. Le manque d’extensibilité relève donc d’une sorte de dépendance interne, qui nous ramène aux implications du problème précédent.

Besoins pour une couche Transport évolutive

De la liste des limites que nous avons dressées dans la section précédente résulte un certain nombre de besoins pour que la couche Transport permette le déploiement, la gestion, l’adaptation et l’utilisation des nouvelles solutions protocolaires. Ces besoins sont les suivants.
Indépendance la couche Transport doit limiter au minimum ses interactions avec son environnement. Les applications dépendantes des services de la couche Transport doivent se limiter au service rendu et en aucun cas à la façon dont ce service est techniquement implanté. Ceci permettra, d’une part, à la couche Transport de faire évoluer les services offerts aux applications sans avoir à affecter les applications les utilisant, et d’autre part, aux applications de bénéficier de meilleurs services sans qu’elles aient à être modifiées.
Transparence tous les éléments de la couche Transport (composants internes) qui sont susceptibles d’évoluer doivent fonctionner de façon transparente les uns des autres.
Les composants échangent des services entre eux sans savoir ni comment ces services sont réalités, ni qui les réalisent. Il s’agit donc d’une sorte d’indépendance interne entre les composants de l’architecture. Cette indépendance est également à mettre en oeuvre à un niveau de granularité plus fin à l’intérieur des éléments eux-mêmes. Globalement, l’implantation des fonctions qui auront à être réalisées par certains éléments au profit d’autres, comme nous le verrons dans le monitorage du réseau par exemple, doit être complètement transparente aux autres éléments. Ainsi, lorsqu’un composant de la couche Transport devra être mis à jour ou remplacé par un autre, les modifications ne se rapporteront qu’à l’élément en question, dès lors que la fonction réalisée demeurera la même. Si un composant (qui assure par exemple un contrôle de congestion), a besoin de la valeur du RTT, il ne doit pas savoir qui calcule cette valeur, ni comment elle est calculée techniquement. De cette façon, même si le composant qui calcule le RTT varie selon les compositions, cela n’affectera pas le contrôle de congestion. Aussi la valeur en question doit être partagée de façon brute, sans aucun traitement supplémentaire, de sorte à ce que le contrôle de congestion puisse modifier sa formule d’estimation du RTT sans avoir à modifier les composants qui effectuent le monitoring de base.
Inconscience il s’agit du degré de connaissance sémantique que possède un élément de la couche vis-à-vis des données qu’il traite. Plus ce degré est faible, plus l’élément est extensible et sa durée de vie importante. Ceci concerne les éléments génériques traitant de concepts de haut niveau. A titre d’exemple, un élément chargé de sélectionner les composants adaptés à un certain contexte réseau ne doit pas se baser sur la sémantique du contexte en question, de son changement ou du service rendu pour l’application.
Le processus de sélection doit se baser uniquement sur des valeur objectives (délais, débit, pertes …) dont la description est externe au composant (via une base de données externe). De cette façon, il est possible d’ajouter autant de profils de réseau, de services, de composants, ou de métriques, sans avoir à modifier le composant de sélection.
Extensibilité telle que nous l’avons définie, le besoin en extensibilité est assuré via la réponse aux trois besoins précédents. Ainsi, l’indépendance règle les problèmes liés aux applications et aux systèmes d’exploitation, en limitant (annulant) sur ces derniers l’impact d’éventuelles évolutions. La transparence réduit le coût résultant de l’évolution interne de la couche Transport (évolution de ses composants). Enfin, l’inconscience des composants de gestion de l’architecture vis-à-vis de la sémantique des données augmente leur durée de vie en offrant la possibilité de les faire évoluer sans avoir à modifier l’élément lui-même.
Mise à l’échelle la couche Transport doit offrir un moyen permettant d’intégrer les différentes solutions sans « encombrer » le système d’exploitation. En termes d’implémentation, la couche Transport doit ainsi intégrer le moins de code possible dans le noyau afin d’en dépendre au minimum, et ce, en n’y incluant que la partie qui ne risque pas d’évoluer, ni surtout d’être étendue. Lors de l’exécution, la couche Transport doit assurer un fonctionnement optimal en ne chargeant que les éléments nécessaires. Répondre au besoin de mise à l’échelle lève ainsi les limites des systèmes d’exploitation à ne pouvoir intégrer qu’un nombre très limité de protocole.
Services et autonomie la couche Transport doit limiter l’interaction avec les applications aux services qui leur sont fournis. Ceci vise à réduire la dépendance classique des applications aux protocoles et à faciliter par la même occasion son utilisation. Par ailleurs, la couche Transport doit prendre la responsabilité du choix des composants nécessaires en tenant compte des besoins des applications et des réseaux de communication sous-jacents

Table des matières

ntroduction
1 Etat de l’art et Positionnement 
1.1 Evolution des protocoles de Transport
1.1.1 Approche générales et approches spécifiques
1.1.2 Solutions pour les applications et solutions pour les réseaux
1.1.3 Nouveaux protocoles et nouvelles versions
1.1.4 Analyse comparative
1.2 Limites de la couche Transport
1.2.1 Configurabilité
1.2.2 Adaptabilité
1.2.3 Flexibilité
1.2.4 Complexité
1.3 Évolutions architecturales au niveau Transport
1.3.1 Nouvelles architectures
1.3.2 Outils conceptuels pour les architectures configurables
1.3.3 Autonomie
1.4 Le modèle ATN/OSI
1.4.1 Présentation de l’ATN
1.4.2 La pile de protocoles ATN/OSI
1.4.3 La transition vers IP
1.5 Présentation des contributions
1.5.1 Positionnement des contributions
1.5.2 Contributions de la thèse
1.6 Conclusion
2 Architecture pour la couche Transport 
2.1 Limites et besoins
2.1.1 Limites des architectures existantes
2.1.2 Besoins pour une couche Transport évolutive
2.2 Une nouvelle architecture pour la couche Transport
2.2.1 Principes généraux et positionnement
2.2.2 Description globale de l’architecture
2.2.3 Structuration par rapport aux besoins
2.3 Description des composants
2.3.1 Composants de gestion de l’architecture
2.3.2 Bases de données
2.3.3 Composants de gestion des connexions
2.4 Cas d’utilisation et description comportementale
2.4.1 Cas d’utilisation
2.4.2 Description comportementale
2.5 Conclusion
3 Extensibilité de la couche Transport 
3.1 Approches de conception
3.1.1 Description des paradigmes
3.1.2 Application à la couche Transport
3.2 Extensibilité vis-à-vis des systèmes
3.2.1 Indépendance au noyau
3.2.2 Contraintes de mise à l’échelle
3.3 Extensibilité des composants de communication
3.3.1 Décomposition par services
3.3.2 Composant d’intégration et base locale des composants
3.3.3 Interactions entre composants
3.3.4 Invocation des composants
3.3.5 Autres éléments extensibles
3.4 Extensibilité des composants de gestion
3.4.1 Interface applications
3.4.2 Composant de décision
3.4.3 Cas du gestionnaire des applications legacy
3.5 Extensibilité des applications
3.5.1 Base globale des services
3.5.2 Interface abstraite
3.6 Conclusion
4 Autonomie de la couche Transpor
4.1 Besoins et problématique
4.1.1 Besoin en autonomie
4.1.2 Niveaux d’autonomie
4.1.3 Autonomie de la sélection des composants
4.2 Monitoring et changement de contexte
4.2.1 Recueil des données de monitoring
4.2.2 Profils de réseau et changements de contextes
4.2.3 Algorithme de détection de changement de contexte
4.3 Processus de décision
4.3.1 Eléments théoriques
4.3.2 Traitement de la requête de l’application
4.3.3 Sélection des composants
5 Implémentation et Évaluation 
5.1 Implémentation et déploiement
5.1.1 Intégration et interaction des composants
5.1.2 Principes d’intégration au noyau
5.1.3 Décision prédéfinie
5.2 Cas d’étude et évaluation
5.2.1 Cas d’étude
5.2.2 Evaluation des performances
5.3 Conclusion
Conclusion et Perspectives 
Bibliographie 

Télécharger le rapport complet