Autostabilisation et protocoles réseau

Autostabilisation et protocoles réseau

Colette Johnen

Franck Petit

Sébastien Tixeuil

* Laboratoire de Recherche en Informatique, (UMR CNRS 8623) Université Paris Sud-XI, 91405 Orsay cedex

{colette, tixeuil}@lri.fr

** Laboratoire de Recherche en Informatique d’Amiens, Université de Picardie Jules Verne, Amiens

[email protected]

† INRIA Futurs, Équipe Grand Large

RÉSUMÉ.En 1974, Dijkstra a défini l’autostabilisation comme la propriété pour un système ré- parti de retrouver de lui-même un comportement correct en un nombre fini d’étapes, et ce, quel que soit son état initial. L’autostabilisation constitue donc un moyen simple et efficace de to- lérer des fautes ou des pannes transitoires. Cet article est consacré aux travaux proposant des solutions autostabilisantes à des problèmes classiques dans le domaine des réseaux informa- tiques, notamment dans les domaines du routage, des communications point à point (transport de données) et des protocoles de contrôle. Des techniques de conception de protocoles autosta- bilisants sont également présentées, ainsi que des mécanismes permettant de réduire le temps de stabilisation lorsque le nombre de défaillances est faible.

ABSTRACT.In 1974, E.W. Dijkstra defined self-stabilization as the property for a distributed sys- tem to recover by itself a correct behavior in a finite number of steps, starting from any initial state. Thus, self-stabilization is a simple and efficient way to tolerate transient faults or fail- ures. This paper surveys works that propose self-stabilizing solutions to problems arising in Computer Networks, such as routing and transport layers, or network control protocols. We also review techniques to design self-stabilizing protocols, and mechanisms that reduce the sta- bilization time when the number of hitting faults is small.

MOTS-CLÉS :autostabilisation, réseaux, protocoles, routage, communications point à point, con- trôle réparti, transformation automatique.

KEYWORDS:self-stabilization, networks, protocols, routing, transport, distributed control, auto- matic transformers

RTSI-TSI. Volume 23 - n^◦8/2004

1. Introduction

Un algorithme réparti (ou protocole) est un algorithme destiné à fonctionner sur un système réparti, c’est-à-dire un ensemble de nœuds (ou processus, ordinateurs, processeurs) interconnectés entre eux et coopérant pour exécuter une tâche. Il est clair qu’un réseau d’ordinateurs est aussi un système réparti. Une des problématiques de l’algorithmique répartie est de fournir aux concepteurs de réseaux des protocoles qui réalisent les fonctions de base d’un système d’exploitation. Bien souvent, il s’agit d’algorithmes primitifs auxquels il est demandé de rendre un service permettant de contrôler le réseau. Ils doivent, par exemple, pouvoir détecter et prévenir des situations d’interblocage, décider si un calcul est terminé ou non, gérer les informations que les unités de traitement s’échangent par l’intermédiaire de messages, gérer les ressources que se partagent certains éléments du réseau... Des solutions existent pour tous ces problèmes, à condition que tous les éléments du réseau soient fiables.

Cependant, avec la multiplication du nombre des composants, les réseaux sont de plus en plus vulnérables aux défaillances (ou fautes). L’étude des algorithmes répartis s’oriente donc depuis quelques années vers la prise en compte des défaillances poten- tielles des éléments du réseau. Ces défaillances sont souvent classées en deux grandes catégories selon leur durée : les fautes définitives — la durée de la faute est supposée être supérieure au temps d’exécution de l’algorithme — et les fautes transitoires ou intermittentes. La différence entre fautes transitoires et fautes intermittentes est assez ténue et ne repose que sur les hypothèses faites sur la fréquence des fautes. Ainsi, la perte de messages due, par exemple, à l’engorgement des tampons (buffers) ou à des perturbations électroniques, est plutôt considérée comme une faute intermittente, c’est-à-dire qu’elle peut se répéter infiniment souvent. Une faute transitoire est suf- fisamment rare pour qu’on puisse considérer qu’elle ne se produit qu’une seule fois.

On étudie alors le comportement du réseau une fois que toutes les fautes (transitoires) sont terminées (pour plus de détails lire la section 2.2).

Bien que le concept d’autostabilisation soit un problème classique en automatique des systèmes, c’est Dijkstra qui le premier a introduit ce concept dans les systèmes répartis [DIJ 74] (voir également [DOL 00, HER 02]). L’autostabilisation s’avère être une bonne approche pour tolérer les fautes transitoires telles que les pannes des nœuds et les corruptions des canaux de communication. En effet, Dijkstra définit un système réparti comme étant autostabilisant si, indépendamment de son état initial, ce système retourne à un état légitime en un nombre fini d’étapes, c’est-à-dire un état à partir duquel le système fonctionne correctement jusqu’à ce qu’une nouvelle défaillance survienne (figure 1).

Tout réseau d’ordinateurs étant aussi un système réparti, l’approche de l’autos- tabilisation telle qu’elle est définie ci-dessus s’applique directement aux réseaux et consiste à ne pas se soucier du fonctionnement du réseau pendant les défaillances.

L’autostabilisation garantit qu’après l’occurrence de toutes les fautes transitoires, le réseau recouvre un fonctionnement (ou comportement) correct en un temps fini. Ceci implique que l’autostabilisation n’est pas une approche universelle en réponse à la

temps Fonctionnement Correct Stabilisation

Perturbation Fonctionnement Correct

Figure 1. L’autostabilisation selon Dijkstra

tolérance aux fautes. En particulier, dans un environnement où les conséquences de certaines défaillances sont inacceptables, mieux vaut envisager d’autres formes de ré- sistances aux fautes plus « robustes » que l’autostabilisation qui ne permet pas de contrôler l’état du réseau pendant les fautes.

Le retour manuel à un comportement correct après l’occurrence de défaillances peut s’avérer très coûteux. Le réseau tout entier devra - peut-être - être arrêté puis réinitialisé dans un état initial correct [PER 00]. Si cette approche est possible dans le cas de petits réseaux, elle est impraticable dans les réseaux de grande taille comme in- ternet. L’autostabilisation propose une manière de retrouver un comportement correct après une faute, sans le coût et les inconvénients d’une intervention humaine généra- lisée. En effet, après qu’une faute est diagnostiquée, il suffit d’enlever, de réparer ou de réinitialiser le ou les éléments défaillants et le réseau, de lui-même, retournera à un état global correct en un temps raisonnable.

De manière plus précise, [VAR 00b] montre que si les nœuds d’un réseau peuvent tomber en panne puis redémarrer dans l’état où ils se trouvaient avant la panne, alors le réseau peut atteindre un état global où l’état de chaque nœud est arbitraire. Si de plus les canaux de communication ne sont pas fiables, alors c’est le réseau entier qui peut atteindre un état global incorrect, c’est-à-dire que les nœuds et les canaux de communication se trouvent dans un état arbitraire. En partant d’un tel état, seul un protocole autostabilisant est capable de ramener le réseau dans un état légitime à partir duquel son comportement est correct.

La propriété d’autostabilisation est également en rapport avec la dynamicité des réseaux (réseau dont la topologie change au cours du temps). Un protocole est bien adapté aux réseaux dynamiques si son code n’a pas besoin d’être modifié en cas d’ajout ou de retrait de nœuds ou d’arcs dans le réseau, et s’il tolère des change- ments de topologie pendant son fonctionnement. Il convient de remarquer que tous les protocoles autostabilisants dont la complexité en nombre d’états par nœud ne dépend pas d’un paramètre global [DOL 93] sont dans ce cas. Dans ce type de réseau, lors- qu’un nouveau canal de communication est relié à un routeur, la taille de la mémoire du routeur n’a pas à être modifiée, le code n’a pas à être changé et le routeur n’a pas à être réinitialisé pour s’adapter à la nouvelle topologie.

C’est d’ailleurs dans ce but qu’ont été conçus certains protocoles utilisés dans in- ternet, les rendant ainsi par définition autostabilisants. C’est le cas par exemple de protocoles comme ARP (Address Resolution Protocol), Netchange, RIP (Routing In- formation Protocol), DEC Autonet et OSPF (Open Shortest Path First).

En définitive, l’autostabilisation est une propriété d’un système réparti, et non un cadre de conception ou de validation de protocole réseau. Si l’on dispose d’une mé- thodologie pour l’ingénierie des protocoles, l’autostabilisation est simplement une propriété supplémentaire. En particulier, acquérir la propriété d’autostabilisation ne signifie pas qu’il soit nécessaire de renoncer à d’autres approches de tolérance aux pannes ou se contraindre à un type de réseau particulier aux propriétés spécifiques. Le modèle historique de l’autostabilisation est celui des machines parallèles où les nœuds communiquent au moyen de mémoires partagées. Certains travaux se sont depuis in- téressés à des modèles plus généraux comme le modèle à échanges de messages (cf.

section 2). D’autres plus récents se sont focalisés sur certains types de réseaux comme les réseaux d’interconnexion (cf. section 3), les réseaux locaux (cf. § 3.1.1 à 3.1.3 et section 4) et les réseaux étendus comme internet (cf. § 3.1.4 et section 4).

Dans la section 2, nous présentons les modèles de communication couramment utilisés dans le domaine de l’autostabilisation. Dans la même section, nous décrivons la mesure de performance propre aux systèmes autostabilisants, suivie des techniques de validations courantes. Par la suite, nous présentons successivement les résultats ayant trait au routage (section 3), aux communications point à point (section 4), et aux protocoles de contrôle dans les réseaux (section 5). Dans la section 6, nous décrivons les deux principales approches de conception d’algorithmes autostabilisants. Ensuite, nous présentons des mécanismes pour accélérer le temps de convergence lorsque le nombre de défaillances est faible (section 7). Nous concluons cet article avec la sec- tion 8.

2. Modèles de communications, temps de stabilisation et techniques de preuves 2.1. Modéliser les communications

Le fait que les nœuds communiquent par échanges de messages et de manière asynchrone sont des hypothèses souvent implicites dans le domaine des réseaux. L’a- synchronisme vient du fait que le temps d’exécution d’un pas de programme d’un nœud n’est en général pas connu, pas plus que le délai d’acheminement d’un message d’un point à un autre du réseau, y compris entre deux voisins.

Or, les preuves et mesures de performances des algorithmes autostabilisants sou- lèvent des problèmes difficiles à résoudre en supposant que les communications se font par échanges de messages. C’est en grande partie pour cette raison que la plu- part des travaux du domaine de l’autostabilisation s’effectuent à partir de modèles de haut niveau dans lesquels les problèmes engendrés par les échanges de messages sont a priori ignorés. Ces modèles, plus simples et plus « fiables » que le modèle par

échanges de messages classique, permettent d’obtenir des résultats d’impossibilité, de calculer des complexités ou des bornes, ainsi que de valider des protocoles.

Dans ces modèles de haut niveau, les nœuds sont supposés communiquer par l’in- termédiaire de registres, mémoire partagée entre nœuds voisins dans le réseau d’inter- connexion. On distingue principalement deux types de modèles à registres : le modèle à états, introduit par Dijkstra dans son article novateur [DIJ 74] et le modèle à lecture- écriture dû à Dolev, Israeli et Moran [DOL 93]. Dans le modèle à états, un nœud est capable de lire en une étape atomique la valeur des variables de tous ses voisins.

Si ce modèle présente l’avantage de la simplicité dans l’expression des protocoles, il implique implicitement des coûts de communication importants. Dans le modèle à lecture-écriture, chaque lecture ou écriture est atomique. Dans ce modèle, il n’est plus possible d’avoir une vision instantanée de son voisinage car entre le moment où on lit la valeur du registre d’un premier voisin et le moment où on lit la valeur du registre d’un deuxième voisin, il est possible que le premier voisin ait déjà changé la valeur de son registre.

Concernant les communications par échanges de messages, les échanges sont sup- posés être réalisés par l’intermédiaire d’un canal bidirectionnel (full-duplex) reliant un émetteur à un récepteur et gérés par un protocole de communication autostabilisant P. Dans [GOU 91], il est tout d’abord montré que les actions deP ne peuvent pas être uniquement déclenchées par la réception de messages. En effet, dans un état ini- tial où le canal entre l’émetteur et le récepteur serait vide de messages (dans les deux directions), le système serait alors évidemment bloqué. En général, les déclencheurs d’actions sont de deux types : réception d’un message ou expiration de délai (timeout).

Ensuite, les auteurs montrent que, même en supposant quePest doté d’un mécanisme d’expiration de délai, si une borne majorant la taille des canaux de communication n’est pas connue (c’est-à-dire que la taille du canal est finie mais non bornée), alors le nombre d’états légitimes deP est infini. Ce résultat implique la nécessité d’avoir sur chaque nœud, une mémoire infinie ou des canaux de communication de taille infinie.

Évidemment, ces résultats théoriques semblent a priori constituer un obstacle ma- jeur au développement des protocoles autostabilisants dans la « pratique », car la mé- moire requise par ces protocoles serait potentiellement infinie. Cependant, des solu- tions peuvent être apportées en combinant entre elles les hypothèses suivantes : (1) la taille des canaux a une borne connue, (2) les canaux sont fiables et (3) il est en- visageable d’implanter un protocole probabiliste. Ces différentes hypothèses sont dé- taillées dans la section 4.

2.2. Complexité en temps

Si l’autostabilisation est un paradigme général pour retrouver un comportement correct suite à des défaillances transitoires, son domaine d’application en pratique dé- pend fortement du temps nécessaire pour assurer sa tâche en l’absence de défaillances,

mais aussi du temps effectivement pris pour revenir à ce comportement correct en pré- sence de fautes transitoires.

Historiquement, le temps dans les systèmes répartis correspond à une chaîne d’évé- nements causalement dépendants les uns des autres. Ces événements peuvent être des actions des nœuds ou des envois/réceptions de messages. Cependant, cette notion ne rend en général pas bien compte du parallélisme intrinsèque des protocoles qui s’exé- cutent sur plusieurs sites simultanément. Ainsi, la notion de cycle d’exécution (ou round) a été introduite pour définir un pas global d’exécution du système. Dans un round, les nœuds qui peuvent agir le font, et les messages qui étaient en cours de transfert sont transmis. La notion de round revient à considérer qu’il existe une borne sur le temps de transmission des messages dans un canal de communication et un délai maximal aux temps de « traitements » locaux sur les nœuds. Elle permet de déterminer plusieurs grandeurs temporelles des tâches s’exécutant dans le réseau.

La première de ces grandeurs est le temps de stabilisation. Etant donné un pro- tocole autostabilisant P destiné à accomplir une certaine tâcheT, le temps de sta- bilisation est le temps maximum mis parP pour qu’en partant d’une configuration quelconque, l’ensemble du réseau retrouve un fonctionnement correct vis-à-vis deT. La mesure dans le pire des cas du temps de stabilisation constitue évidemment un critère essentiel de comparaison des performances de protocoles destinés à accomplir une même tâche. Il s’avère même être un critère rédhibitoire dans certains cas. Par exemple, un protocole autostabilisant dont le temps de stabilisation est proportionnel au nombre de nœuds du réseau ne présente a priori qu’un intérêt limité dans un réseau de très grande taille. C’est la raison pour laquelle nous présentons dans la section 7 plusieurs améliorations par rapport au critère du temps de stabilisation. Intuitivement, l’idée consiste à définir une mesure de la gravité des défaillances, et à faire en sorte que le temps de stabilisation soit proportionnel à la gravité des défaillances.

La seconde grandeur temporelle en termes de performances consiste en l’évalua- tion du surcoût en temps imposé par les différents mécanismes logiciels mis en œuvre pour obtenir l’autostabilisation. En d’autres termes, en supposant l’absence de dé- faillances, il s’agit de mesurer le temps supplémentaire mis par un protocole autosta- bilisantP pour effectuer la tâcheT en l’absence de défaillance. Ce temps « supplé- mentaire » se mesure par rapport à d’autres protocoles réalisantT mais n’étant pas autostabilisants. En général, cette comparaison se fait soit par rapport au temps opti- mal pour accomplirT, soit par rapport aux meilleurs algorithmes réalisantT. Le point de vue dans la mesure de ce surcoût diffère selon qu’il s’agit d’une tâche statique ou dynamique. Une tâche est dite statique si elle consiste à effectuer un calcul une fois pour toutes, par exemple le calcul d’une table de routage ou l’élection d’un leader.

Une tâche dynamique est destinée à être répétée infiniment souvent, par exemple un protocole de communication entre deux nœuds du réseau ou l’accès répété à une res- source partagée. La mesure du surcoût s’effectue sur le temps de calcul pour les tâches statiques ou sur le temps de service pour des tâches dynamiques.

2.3. Prouver l’autostabilisation

Prouver la correction des systèmes autostabilisants ne diffère pas des preuves de correction que l’on peut trouver pour les protocoles classiques : on part d’un ensemble d’états globaux (les états initiaux dans le cas des systèmes non stabilisants, les états légitimes dans le cas des systèmes autostabilisants) et on prouve que toute exécution effectuée à partir de ces états globaux satisfait la spécification de la tâche impartie au système. Les techniques habituelles d’invariants peuvent être utilisées.

Prouver la convergence est moins classique puisqu’il faut montrer que de chacun des états globaux possibles du système (c’est-à-dire chaque produit possible des états locaux des composants de base du système), toute exécution mène à un état global lé- gitime. Les techniques que l’on trouve dans la littérature pour montrer la convergence des protocoles autostabilisants utilisent en général le schéma suivant : (i) établir un lien entre un système réparti et un système formel dans lequel la notion de convergence existe et où il existe des techniques de preuve bien connues, (ii) traduire le protocole dont on veut prouver la convergence dans le système formel choisi, et (iii) prouver la convergence du protocole traduit.

La première technique de preuve et certainement la plus largement utilisée est introduite dans [GOU 91]. Elle s’appelle la technique des étapes de convergence (con- vergence stairs). Elle consiste à définir k prédicats sur les étatsA1, A2, . . . , Ak

(k >1) et à montrer deux types de propriété : la clotûre et la convergence. La clôture consiste à prouver que tout pas de calcul à partir d’un état qui vérifieA_i (pour tout icompris entre1etk) atteint un état qui vérifie aussiAi. La convergence consiste à prouver qu’en partant d’un état quelconque α, toute exécution finit par atteindre un étatβ tel queA1est vérifié, puis, par réitération du procédé, en partant d’un étatα tel queAiest vérifié (pour touticompris entre1etk−1), toute exécution converge vers un état où Ai+1 est vérifié. Intuitivement, Ak (la dernière étape) correspond à un (sous-)ensemble des états où le protocole fonctionne correctement. Les prédicats A1, A2, . . . , Aksont appelés des attracteurs.

Une autre technique consiste à utiliser des fonctions de potentiel [KES 88]. L’idée est de trouver une fonctionfde l’ensemble des états du système dansRtelle que pour toute exécution du système, la valeur def des états atteints au cours de l’exécution décroît (ou croît) de manière monotone jusqu’à atteindre en un nombre fini de cycles d’exécution une certaine valeur de seuil à partir de laquelle le comportement du sys- tème est correct. Cette technique transforme les exécutions du système réparti en série à valeurs scalaires. Les techniques habituelles sur les séries peuvent être utilisées. La traduction — c’est-à-dire la découverte de la fonction de potentiel adaptée au système et qui permet de prouver sa convergence — requiert souvent beaucoup d’habileté.

Dans le domaine des systèmes de réécriture, plusieurs théorèmes permettent de dé- terminer si un système de réécriture particulier admet des dérivations infinies corres- pondant à un certain schéma. Par suite, la méthode proposée dans [BEA 01a] consiste à traduire un système réparti en système de réécriture, et à utiliser les résultats du do- maine pour prouver qu’il n’existe aucune chaîne de dérivation infinie correspondant à

des états illégitimes. Il s’ensuit que toute exécution du système contient seulement un nombre fini d’états globaux incorrects, et donc le système original finit par stabiliser.

A ce jour, la méthode proposée est spécifique aux topologies en anneau et en chaîne.

Dans [TSU 01], les techniques de vérification basées sur la représentation symbo- lique d’ensembles d’états du système (model-checking) sont utilisées pour vérifier la convergence de plusieurs protocoles autostabilisants ayant peu d’états. L’utilisation de diagrammes ordonnés de décision binaire (OBDD) permet de contourner le problème majeur que rencontre de telles techniques : l’explosion d’états à analyser.

La notion de convergence est également présente dans le domaine de l’automa- tique avec la théorie du contrôle et les systèmes d’itération [ARO 93]. En particulier, les itérations asynchrones ont été étudiées de manière extensive à des fins d’optimisa- tion sur les calculateurs parallèles. Plusieurs résultats dus à Üresin et Dubois [URE 90]

donnent des conditions suffisantes pour assurer la convergence des systèmes d’itéra- tions asynchrones. L’algèbre Max-plus et l’algèbre de chemins permettent de formali- ser ces systèmes et admettent une représentation matricielle qui rend possible l’utilisa- tion de techniques de [URE 90] pour prouver des propriétés de « point fixe » matriciel, qui correspond à la convergence des itérations répétées d’un vecteur à travers une ma- trice. Dans [DUC 03], une traduction d’un système réparti en un système matriciel de type Max-plus est proposée, et les résultats de point fixe matriciel sont utilisés pour prouver la convergence d’une classe de protocoles autostabilisants : les protocoles de construction de tables de routage basés sur une métrique strictement monotone.

3. Les protocoles de la couche réseau

La structure sous-jacente d’un réseau de communication est un graphe d’intercon- nexion. Le rôle des protocoles de la couche réseau est le transport des paquets entre l’émetteur du paquet et son destinataire (a priori, les deux routeurs ne sont pas voisins dans le graphe d’interconnexion). Les paquets vont donc traverser plusieurs routeurs intermédiaires situés entre l’émetteur de paquets et le destinataire. Les routeurs inter- médiaires choisissent le canal de communication que doit prendre chaque paquet, en fonction de la politique d’acheminement des paquets.

Dans la couche réseau d’internet, la politique d’acheminement des paquets est du type non connecté et par commutation de paquets (store and forward). Les paquets arrivant à un routeur sont stockés dans une file d’attente et ensuite routés. Un routeur décide à qui transmettre un paquet en transit en fonction du destinataire du paquet et aussi de sa table de routage. La principale difficulté de cette politique d’acheminement des paquets est d’assurer la cohérence des tables de routages entre les divers routeurs.

Si les tables de routages sont désynchronisées, les paquets peuvent circuler dans le réseau en bouclant et ne jamais atteindre leur destination.

3.1. Construction des tables de routages

Si la plupart des protocoles de construction de tables de routages autostabilisants font l’hypothèse de canaux bidirectionnels, il peut arriver que seuls des canaux uni- directionnels soient disponibles. C’est par exemple le cas dans les réseaux ad hoc, où les communications se font par ondes radio. Ainsi, un élément du réseau peut recevoir des messages d’un autre membre sans être capable de lui répondre directement. Dans [COB 01, DUC 01], plusieurs protocoles autostabilisants de construction de tables de routage sur des réseaux unidirectionnels sont présentés.

Par ailleurs, plusieurs problèmes connexes à la construction des tables de routage possèdent des solutions autostabilisantes. C’est le cas du problème de la construction de topologie. Il s’agit de faire en sorte que tous les routeurs connaissent la topologie courante du réseau [MAS 95, ABU 96, DOL 97b]. C’est aussi le cas du problème du recensement, le but étant que chaque routeur connaisse l’ensemble des routeurs du réseau [BEA 99a, DEL 02]. Le protocole proposé dans [ABU 96] est particulièrement adapté aux réseaux à haut débit.

Dans les deux sections suivantes, nous détaillons les résultats obtenus lorsque les canaux de communication sont bidirectionnels.

3.1.1. Métriques

La tâche principale d’un protocole de construction de tables de routage est de maintenir une table de routage sur chaque routeur qui assure en plus des propriétés de base (acheminer des paquets au destinataire) une propriété spécifique aux chemins pris par les paquets.

Cette propriété s’énonce généralement comme maximiser une métrique. Par exem- ple, les protocoles de routage tels que OSPF et RIP génèrent des tables de routage qui garantissent que le chemin entre deux nœuds quelconques du réseau est le plus court possible. Lorsque la topologie du réseau change, les tables de routage sont automa- tiquement reconstruites de sorte que les chemins obtenus sont de nouveau optimaux pour la métrique considérée. [DOL 97a] présente un protocole autostabilisant basé sur la métrique minimiser le nombre de routeurs dans les chemins. Cette métrique est similaire à la métrique du plus court chemin lorsque tous les canaux sont de même coût.

Dans [GHO 97], un protocole autostabilisant pour la métrique du débit maximal sur des graphes acycliques est présenté. Il s’agit de maximiser le débit maximum de chaque chemin, sachant que la valeur associée à chaque arc est le débit du canal de communication. Le débit d’un chemin est donc le plus petit débit des arcs qui le composent. Ce protocole utilise des numéros de session non bornés et donc une mémoire infinie. Un protocole autostabilisant générique de construction de tables de routage est présenté dans [GOU 99]. Il peut ainsi construire et maintenir les tables de routage pour la métrique du plus court chemin ou du débit maximal.

3.1.2. Garantie du service

Dans [ARO 90] sont présentés deux protocoles autostabilisants basés sur la mé- trique du plus court chemin. Un de ces protocoles est tolérant au changement de coût associé aux canaux, car il n’introduit pas de cycle dans les chemins de routage lorsque le coût des canaux change. Supposons qu’il existe un chemin entre les nœudspetq.

Après une ou des modifications du coût sur un ou plusieurs canaux, le protocole mo- difie les tables de routage pour construire un nouveau chemin de coût minimal entre petq. Durant cette phase de construction, le protocole garantit qu’il existe toujours un chemin entrepetq; ainsi même pendant la phase de reconstruction, des paquets peuvent être échangés entrepetq.

Les protocoles autostabilisants présentés dans [GOU 95, COB 97] construisent et maintiennent les tables de routage pour la métrique du débit maximal des graphes de topologie quelconque. Ces protocoles sont tolérants aux changements de débits des canaux. Dans [GOU 95], chaque routeur doit connaître une borne supérieure sur la taille du réseau. Les protocoles [GOU 95, COB 97] nécessitent aussi des numéros de session non bornés.

Dans [COB 02, JOH 03] sont présentés des protocoles autostabilisants génériques de construction des tables de routage également tolérants aux changements de « va- leur » des canaux. Dans [COB 02] chaque routeur doit connaître une borne supérieure sur la taille du réseau ; ce paramètre n’est pas à connaître dans [JOH 03].

3.1.3. Métriques composées

Pour une destination, plusieurs métriques peuvent simultanément exister : une qui minimise le coût du chemin (shortest path), une qui maximise le débit du chemin (maximum flow), une qui sélectionne le chemin ayant le plus petit taux de perte de paquets, etc. La métrique associée à IGRP est la composition de quatre métriques : minimiser le coût, maximiser le débit, minimiser la charge des canaux et minimiser le taux de perte des paquets. Malheureusement, il a été prouvé [GOU 98] qu’il n’existe pas de protocole autostabilisant qui maintienne des chemins ayant cette métrique.

3.1.4. Routages hiérarchiques

Le routage hiérarchique permet de réduire grandement la taille des tables de rou- tage et donc le temps nécessaire pour router les paquets. Une bonne métrique pour ce type de routage consiste à trouver un compromis entre la taille de la table de routage sur chaque routeur et la distance par rapport à un routage optimal pour une métrique particulière. Un protocole autostabilisant de construction de table de routage hiérar- chique pour la métrique des plus courts chemins est présenté dans [DAT 00a]. Dans le cas particulier du routage interdomaine dans internet, une solution autostabilisante a été proposée dans [CHE 02].

3.2. La politique wormhole d’acheminement des paquets

Dans le cas où l’acheminement des paquets est de type wormhole, les messages sont découpés en unités de contrôle de flux (flits), chaque flit n’excédant pas quelques octets. Toute l’information de routage et de contrôle des messages est stockée dans le premier flit (header flit). Quand le premier flit se déplace à travers le réseau vers sa destination, il réserve le canal traversé pour permettre le passage ultérieur des flits de données (data flits). Les autres flits du messages suivent le header flit à la manière d’un pipeline. Quand le dernier flit (tail flit) traverse un canal, la réservation du canal pour ce message est libérée. Si un header flit atteint un nœud ne possédant aucun canal de sortie disponible, les autres flits du message restent où ils sont jusqu’à ce que le header flit avance de nouveau.

Dans [DAT 03], un protocole autostabilisant d’acheminement des paquets de type wormhole est proposé. Ce protocole permet la communication entre deux ordinateurs d’un réseau, et peut à ce titre être utilisé par un protocole autostabilisant de plus haut niveau. En particulier, ce protocole tolère que des flits arbitraires, sans l’organisation header flit, puis data flits, puis tail flit, soient initialement présents dans le réseau suite à une défaillance transitoire.

3.3. La politique cut-through d’acheminement des paquets

La politique d’acheminement des paquets de type cut-through est utilisée dans de nombreux réseaux organisés en anneau parmi lesquels les réseaux Token Ring et FDDI. Dans ce schéma d’acheminement, un routeur peut commencer à transférer une partie d’un message à un autre routeur situé sur le chemin vers la destination avant d’avoir reçu le message entièrement. Si ce message est le seul trafic sur le chemin vers la destination, le délai total du message est égal à la somme du temps de transmission calculé sur le canal le plus lent du chemin et du délai de propagation. Par conséquent, il est proportionnel à la longueur du message et au nombre de routeurs sur le chemin vers la destination. Cette approche supprime le besoin d’avoir une mémoire locale à chaque nœud de taille supérieure à quelques bits, et réduit également le délai total de chaque message à une petite valeur bornée par la taille des tampons de transfert des nœuds.

En l’état actuel, le temps nécessaire pour recevoir/émettre des bits depuis/vers un médium de communication est beaucoup plus élevé que le temps nécessaire à l’exé- cution d’opérations élémentaires (calculs sur des entiers, tests, écriture et lecture de registres, etc.). C’est la raison pour laquelle bon nombre de travaux font l’hypothèse qu’un nœud donné est capable d’exécuter un nombre limité de pas de calcul entre les réceptions de deux parties d’un message. Les travaux menés dans le cadre de l’autos- tabilisation dans un modèle cut-through sont doubles :

1) Tout d’abord, [TIX 96] et [COS 99] présentent une version autostabilisante de protocoles existant dans le modèle cut-through (le Token Ring pour [TIX 96] et le

FDDI pour [COS 99]). L’objectif de ces protocoles est d’assurer la présence d’un et d’un seul jeton circulant dans l’anneau. Ces deux articles se concentrent sur l’étude du surcoût engendré par l’ajout de la propriété d’autostabilisation.

2) Par ailleurs, [BEA 99a] présente plusieurs techniques non triviales qui utilisent efficacement le modèle cut-through pour réduire l’espace mémoire et le temps de sta- bilisation d’un facteur de l’ordre de la taille du réseau d’un protocole de recensement facilement autostabilisant (car la quantité d’informations véhiculée par chaque mes- sage est importante).

4. Communications point à point

La communication fiable d’un point à l’autre du réseau consiste à délivrer en un temps fini une série de paquets entre deux nœuds distants dans l’ordre d’émission, sans perte, ni duplication.

4.1. Protocole du bit alterné

En faisant l’hypothèse que la contenance maximum des canaux est finie mais sans en connaître la limite, des versions du protocole du bit alterné sont proposées dans [AFE 93]. Ceux-ci tolèrent la perte de messages. Mais la taille de la mémoire des nœuds est là encore infinie ou le protocole est probabiliste. En supposant que les canaux de communication sont de taille bornée et agissent de manière quasi fiable, une nouvelle version autostabilisante du protocole du bit alterné est proposée dans [HOW 02]. Un canal quasi-fiable est un canal FIFO qui perd des messages seulement quand le nombre de messages déposés dans le canal dépasse un certaine seuil. Il est alors possible d’utiliser une quantité finie de mémoire, et [HOW 02] propose une im- plantation de ce protocole. Dans [DOL 97c], les auteurs présentent trois protocoles de synchronisation autostabilisants de deux nœuds. Les deux premiers protocoles sont proches des protocoles autostabilisants de la fenêtre glissante et du bit alterné pro- posés respectivement dans [GOU 91] et dans [AFE 93]. Le troisième protocole fait l’hypothèse originale que les deux nœuds ont un nombre fini d’états mais que la taille du canal croît infiniment.

4.2. Protocole de la fenêtre glissante

Des variantes autostabilisantes des protocoles de la poignée de main en deux temps (Two-Way Handshake) et de la fenêtre glissante (Sliding Window) sont proposées dans [GOU 91]. Ils supposent que les canaux de communication sont fiables. La stabili- sation de ces deux protocoles est obtenue en numérotant chaque message avec une séquence infinie d’entiers. Dès lors, la taille des canaux et de la mémoire des nœuds ne peut être qu’infinie. Dans [COS 96, SPI 97] d’autres versions du protocole de la fenêtre glissante sont proposées. Les protocoles supposent que la taille de la mémoire

des nœuds est finie et que la taille du canal bidirectionnel FIFO est bornée par une constanteB. Ils associent à chaque message un numéro de séquence dont la borne est supérieure àB. Le protocole de [COS 96] utilise la technique du nettoyage de comp- teur (Counter Flushing) présentée dans [VAR 00a] : l’émetteur va inévitablement en- voyer un paquet ayant un numéro de séquence distinct de tous les autres paquets en transit. Après la réception de l’accusé de réception de ce paquet, le canal contient uni- quement des paquets effectivement envoyés durant cette connexion (le canal est donc nettoyé des « vieux » paquets). Dans [SPI 97], à la réception d’un paquet n’ayant pas le numéro de séquence attendu, le destinataire de ce paquet envoie un grand nombre de paquets de « réinitialisation » (ce nombre est plus grand que la taille du canal plus celle de la fenêtre d’anticipation). Une fois que tous ces paquets ont été acquittés, le canal est nettoyé.

4.3. Protocole d’ouverture de connexion

Dans [HER 92], un protocole autostabilisant d’ouverture et de maintenance de connexion est proposé dans le cadre d’un réseau dynamique. Ce protocole suppose que le protocole chargé de la maintenance des tables de routage est lui-même autosta- bilisant. Périodiquement, l’émetteur et la destination envoient des paquets de contrôle le long du circuit virtuel pour vérifier que le circuit est fonctionnel. Si pour n’importe quelle raison, le circuit n’est plus opérationnel (par exemple dysfonctionnement des sous-réseaux ou pannes des routeurs intermédiaires), le circuit est fermé. L’émetteur établit un nouveau circuit virtuel pour continuer le transfert de données. Le protocole garantit qu’au plusNpaquets envoyés sur un circuit n’arrivent pas à destination avant que le dysfonctionnement du circuit ne soit détecté (N étant le nombre de nœuds du réseau). Cette approche est peu efficace dans le cas de réseaux de très grande taille.

En effet, plus le réseau est de grande taille, plus la topologie du réseau change fré- quemment. Donc les circuits virtuels sont opérationnels de moins en moins longtemps.

Ainsi, le débit de transfert de données d’un protocole basé sur l’approche présentée dans [HER 92] se réduit peu à peu à un « filet d’eau ».

4.4. Protocole de transmission de données via plusieurs chemins

Des protocoles de communication point à point autostabilisants sont présentés dans [AWE 96, DOL 97e]. Le réseau consiste en un ensemble de nœuds/routeurs connectés par les canaux FIFO de taille bornée pouvant perdre des messages mais pas les dupliquer. Ces protocoles utilisent plusieurs chemins entre l’émetteur et le desti- nataire ; ainsi, même si un chemin est hors service, la délivrance des paquets n’est pas stoppée.

Dans [AWE 96], il est supposé que chaque canal de communication est un UDL.

Un UDL est un canal de taille 1, ayant donc au plus un paquet en transit. Sachant qu’un UDL peut être réalisé sur n’importe quel canal de taille bornée via une version autostabilisante du protocole du bit alterné [AFE 93], cette hypothèse n’est pas limi-

tante. Supposant que chaque canal est un UDL, un protocole de type glissement de paquets (slide protocol) réduit le réseau à unC-channel de l’émetteur au destinataire.

UnC-channel est un canal de tailleCoù les paquets ne sont pas perdus mais peuvent être réordonnés. L’émetteur et la destination se synchronisent au moyen du bit alterné autostabilisant. Une fois synchronisés, l’émetteur envoieX ≥2C+ 1fois le même paquet via le C-channel (c’est-à-dire dans le réseau) à la destination. Parmi les X prochains paquets reçus par le destinataire, au moinsX−Csont identiques. Ainsi, le destinataire peut extraire le paquet à délivrer via un mécanisme de vote à la majorité simple sur lesX paquets reçus.

Dans [DOL 97e], chaque paquet contient la description complète du chemin qu’il doit prendre et un numéro de séquence lié au chemin. Ce protocole nécessite que les canaux soient FIFO. Son principe consiste à garantir que deux paquets non perdus et envoyés sur le même chemin arrivent à destination dans l’ordre dans lequel ils ont été envoyés. Lorsqu’un paquet arrive à la destination, cette dernière vérifie qu’il a le numéro de séquence attendu pour le chemin pris par ce paquet. Si oui, le paquet est délivré et un acquittement est envoyé. Cet acquittement contient le numéro de séquence que devra avoir le prochain paquet pour être délivré. Le protocole nettoie périodiquement les chemins utilisés dans le réseau : il les vide des « vieux » paquets.

C’est pourquoi le protocole peut utiliser des numéros de séquence bornés.

5. Protocoles de contrôle du réseau

La plupart des tâches à réaliser en vue du contrôle de réseau reviennent souvent à amener les nœuds à s’entendre sur une valeur commune ou à se synchroniser. Parmi les problèmes à résoudre en vue d’atteindre ces objectifs, on trouve l’élection d’un leader (LE pour Leader Election) et les protocoles à vagues.

L’élection d’un leader consiste à amener l’ensemble des nœuds à choisir un des leurs comme leader. Une fois que le réseau dispose d’un unique leader, de nombreuses tâches demandant un contrôle centralisé peuvent être réalisées, par exemple, la mainte- nance d’une base de données réparties, la détection de cycle dans les tables de routage, etc.

Les protocoles à vagues sont des outils de synchronisation à l’origine de nom- breuses solutions dans la résolution de problèmes de contrôle du réseau, comme le partage ou l’allocation de ressources, la diffusion d’informations, etc. Une vague est en fait une séquence de pas de calculs impliquant tous les nœuds du réseau et se ter- minant par une action particulière communément appelée décision.

Dans ce qui suit, nous présentons les résultats les plus récents pour ces deux para- digmes obtenus dans le domaine de l’autostabilisation. La plupart de ces travaux, sauf indication contraire, fonctionnent dans le modèle à registres (cf. section 2).

5.1. Protocoles d’élection d’un leader

De nombreux travaux ont montré l’importance des hypothèses faites sur le modèle choisi, comme la présence ou non d’identité sur les processeurs, les conditions de synchronisation entre les processeurs. Nous présentons ci-dessous différentes familles de résultats obtenus en fonction des hypothèses faites.

5.1.1. Protocoles déterministes sur des réseaux avec identifiants

Dans un réseau avec identifiants, chaque routeur possède une adresse réseau propre qui ne peut être corrompue car elle est stockée en ROM. Il existe plusieurs protocoles autostabilisants de LE déterministes où l’espace mémoire dépend de la taille du réseau [AFE 90, AGG 93, ARO 94].

Un protocole autostabilisant est silencieux [DOL 99a] si une fois que le système est stabilisé, l’état des nœuds n’est pas modifié. Les nœuds vont uniquement vérifier périodiquement que l’état de leurs voisins est inchangé. Ainsi, un protocole silencieux est moins coûteux en termes de communication, une fois que le réseau est stabilisé, qu’un protocole non silencieux. Dans [DOL 99a], il a été établi que l’espace mémoire nécessaire pour un protocole de LE silencieux estO(log₂N)dans le cas général,N étant la taille du réseau.

5.1.2. Protocoles déterministes sur des réseaux anonymes

Un réseau anonyme est un réseau où les nœuds n’ont pas d’identifiant propre et exécutent le même code. Un protocole autostabilisant doit converger vers un état où il y a un leader à partir de n’importe quel état. Sur un anneau anonyme, un proto- cole de LE peut être conçu uniquement (i) si l’anneau est de taille première et (ii) si l’ordonnancement est centralisé [ANG 80, BUR 89]. Sous un ordonnancement cen- tralisé, à chaque étape de calcul, un seul nœud exécute son code local. Ce type d’hy- pothèse implique implicitement un contrôle centralisé du réseau. Dans [ITK 95], un protocole de LE déterministe sous un ordonnancement centralisé pour les anneaux bidirectionnels nécessitant un espace mémoire constant est présenté (c’est-à-dire que l’espace mémoire nécessaire au protocole est indépendant de la taille de l’anneau).

Dans [BEA 99c], il est prouvé qu’un protocole déterministe autostabilisant de LE pour les anneaux unidirectionnels nécessite au moinslog₂(N)bits sur chaque élément du réseau. Un protocole nécessitant4 + log₂(N)bits par élément du réseau est présenté dans [FIC 01].

5.1.3. Protocoles probabilistes

Pour s’abstraire des difficultés rencontrées dans la section précédente, les proto- coles fonctionnant sur les réseaux anonymes sont en général probabilistes. Dans ce cas, le résultat de certaines actions est aléatoire. Formellement, il dépend de la valeur d’une variable aléatoire.

Un protocole autostabilisant de LE sur des anneaux est présenté dans [MAY 92].

Ce protocole suppose que la « vivacité » du réseau est assurée de manière externe : un

mécanisme externe insère un message dans l’anneau et ceci uniquement lorsque aucun paquet/message ne circule dans l’anneau. Ce protocole est le seul protocole supposant que les éléments du réseaux communiquent par messages. Dans [BEA 99c], un pro- tocole autostabilisant de LE sur un anneau est présenté. Dans [DOL 97d, BEA 02], des protocoles autostabilisants de LE pour des réseaux de topologie quelconque sont présentés. Il a été prouvé que l’espace mémoire nécessaire aux protocoles [BEA 99c, BEA 02] est minimal.

5.2. Protocoles à vagues

Les deux familles de protocoles à vagues les plus utilisés sont la circulation d’un jeton (TC pour Token Circulation) et la propagation d’information avec retour (PIF pour Propagation of Information with Feedback).

Dans le premier cas, un unique nœud initialise la circulation d’un unique jeton.

Les circulations de jeton les plus étudiées sont :

– la circulation en profondeur (DFTC pour Depth-First Token Circulation) car elle offre l’avantage d’être déterministe et équitable ;

– la circulation de jeton probabiliste car, contrairement à la circulation de jeton en profondeur, elle offre l’avantage de fonctionner sur les réseaux anonymes.

La TC est particulièrement adaptée à la résolution de problèmes ayant un compor- tement séquentiel, comme l’exclusion mutuelle.

Le PIF peut être décrit de la manière suivante : un nœud initialise une vague de PIF en « diffusant » un message m. La vague se termine lorsque l’émetteur dema reçu l’accusé de réception demde la part de tous les nœuds du réseau. Le PIF est donc un mécanisme de synchronisation exploitant au mieux le parallélisme offert par la topologie du réseau.

5.2.1. La circulation en profondeur de jeton

De nombreux protocoles autostabilisants ont été proposés sur des réseaux de to- pologies spécifiques : la chaîne et l’anneau ; par exemple [BRO 89, BUR 89, DIJ 74, GHO 93, GOU 96]. Des protocoles DFTC autostabilisants ont également été propo- sés sur des topologies plus complexes comme les arbres couvrants [DOL 93, PET 97a, PET 99, PET 00] ou quelconques [HUA 93, JOH 95, PET 97b, DAT 00c, PET 01]. La plupart des travaux récents portent sur la minimisation de l’espace mémoire nécessaire au bon fonctionnement du protocole ou du temps nécessaire au système pour stabiliser.

L’intérêt porté à la réduction de l’espace mémoire s’explique par le fait qu’un pro- tocole nécessitant un espace constant par canal de communication, est transparent à l’évolution de la topologie du réseau. Un accroissement de la taille du réseau ne néces- site pas d’ajouter de la mémoire à chaque nœud ou de changer le code ou un paramètre du protocole. Ainsi, le protocole est bien adapté aux réseaux dynamiques (réseau dont la topologie change au cours du temps). En revanche, les protocoles nécessitant une

connaissance d’une donnée globale au réseau (par exemple, la tailleN, le diamètre D...) ne sont pas adaptés aux réseaux dynamiques. Les protocoles présentés dans [PET 97a, PET 99, PET 00] sont des DFTC à mémoire constante par canal, leur op- timalité en espace est prouvée dans [PET 00]. Cependant, ils ne fonctionnent que sur des arbres couvrants. Les DFTC présentés dans [JOH 95, PET 97b, DAT 00c] sont à mémoire constante par canal et fonctionnent sur des réseaux quelconques, [DAT 00c]

ayant la meilleure complexité connue à ce jour.

En termes de temps de stabilisation, les deux protocoles pour les réseaux dont la topologie est un arbre et présentés dans [PET 99] sont instantanément stabilisants [BUI 99b]. Le fait qu’ils soient instantanément stabilisés signifie qu’indépendamment de l’état initial, durant une circulation correctement initialisée, tous les nœuds du ré- seau obtiennent le jeton. Les protocoles proposés dans [PET 99] proposent un service fiable (en plus d’être optimaux en espace mémoire). A ce jour, la meilleure complexité en temps de stabilisation dans un graphe quelconque estO(N)[PET 01].

Tous les protocoles présentés ci-dessus ont été écrits dans le modèle à registres.

Les protocoles de [JOH 95] et de [PET 97b] sont respectivement adaptés aux commu- nications par échange de messages dans [PET 97d] et dans [PET 97c].

5.2.2. La circulation de jeton probabiliste

La plupart des protocoles pour les anneaux unidirectionnels sont basés sur la tech- nique : « retarder pour une période aléatoire la circulation du jeton » [HER 90, BEA 95, KAK 97, BEA 99d, ROS 00, DAT 00b]. Le nœud ayant le jeton décide aléatoirement de garder ou de passer le jeton à son unique voisin. Une fois l’anneau stabilisé, la circulation du jeton est également retardée. Le protocole de [DAT 00b] garantit une borne supérieure enO(N³)au temps de service. Le temps de service est le temps né- cessaire à un jeton pour faire le tour de l’anneau. Les autres protocoles n’ont pas de borne supérieure au temps de service.

Les protocoles présentés dans [KAK 97, KAK 02, JOH 02] sont basés sur une autre technique. Un jetonTest bloqué sur un nœud lorsque l’anneau a plusieurs jetons, les autres jetons vont continuer à circuler. Finalement, le jeton bloqué va être rattrapé par un autre jeton et les deux jetons vont fusionner en un seul. Le nombre de jetons va ainsi diminuer. Une fois l’anneau stabilisé, la circulation de l’unique jeton n’est pas retardé ou peu, c’est pourquoi le temps de service est optimal dans le cas des protocoles présentés dans [KAK 97, JOH 02]. Le protocole de [JOH 02] fonctionne sous tout ordonnancement alors que le protocole de [KAK 97] fonctionne que sous un ordonnancement centralisé.

D’une manière générale, la marche aléatoire [ALE 79] est une technique fort uti- lisée pour implanter une circulation de jeton dans un réseau quelconque : le nœud ayant le jeton choisit aléatoirement le voisin à qui il va passer le jeton. Des protocoles autostabilisants fondés sur cette technique sont proposés dans [ISR 90, DUR 00].

Il y a relativement peu de travaux sur la circulation de jeton probabiliste avec des communications réalisées par échanges de messages [MAY 92, HIG 98, ROS 00]. Les

protocoles existants fonctionnent uniquement sur des réseaux en anneaux et supposent qu’un mécanisme externe et fiable insère un jeton dans l’anneau s’il n’y en a pas.

5.2.3. La propagation d’information avec retour

Le problème du PIF est équivalent au problème de la TC sur l’anneau et sur la chaîne. Le PIF est un outil de base pouvant être utilisé dans la construction de pro- tocoles autostabilisants effectuant des tâches diverses, comme l’élection de leader [DOL 97d, VAR 93], la réinitialisation [AFE 90, ARO 94, AWE 93] et la synchro- nisation [ALI 98, AWE 93, AWE 91b] du système. Tous ces travaux supposent la construction ou l’existence d’un arbre couvrant du réseau. Dans le cas d’un proto- cole de PIF autostabilisant, en fonction de l’état initial, une vague se terminant peut ne pas avoir atteint tous les nœuds. En d’autres termes, certains nœuds peuvent ne pas avoir reçu le message envoyé par l’initiateur de la vague. L’autostabilisation ga- rantit seulement qu’après un nombre fini de vagues, toutes les vagues suivantes sont correctes et atteignent tous les nœuds.

Plusieurs protocoles de PIF sur des arbres couvrants à la fois optimaux en espace et instantanément stabilisants ont été proposés dans [BUI 99a, BUI 99b]. Le fait que ces protocoles sont instantanément stabilisés signifie que lorsqu’un nœud initie une vague de PIF (envoie un message), tous les nœuds ont bien reçu son message à la fin de la vague.

Les seuls protocoles autostabilisants de PIF pour des réseaux quelconques fonc- tionnant sans l’hypothèse d’un arbre couvrant sont ceux présentés dans [VAR 00a, COU 01, COU 02]. Le protocole de [COU 02] a l’avantage d’être instantanément sta- bilisant.

6. Méthodes de conception de protocoles autostabilisants

Dans cette section, nous présentons deux approches orthogonales de conception de protocoles autostabilisants. La première, à l’instar de la décomposition en couches bien connue dans le domaine des réseaux, réside dans l’assemblage (ou la composi- tion) d’algorithmes autostabilisants simples. La seconde tient compte de l’expérience acquise. Elle consiste à proposer une « machine à autostabiliser » dont le principe est présenté dans cette section.

6.1. Techniques de composition d’algorithmes autostabilisants

L’une des principales difficultés relatives aux techniques de composition d’algo- rithmes autostabilisants est de montrer que l’algorithme obtenu par composition est autostabilisant, sachant que chacun de ses éléments participant dans la composition est autostabilisant.

La technique la plus naturelle est la composition collatérale [HER 91]. Elle consiste à réunir des algorithmesP1, P2, . . . , Pk(k >1). Ces algorithmes ne partagent au- cune variable et aucun type de messages. Pour prouver que la composition collatérale deP1, P2, . . . , Pk(k >1) est autostabilisante, il suffit de prouver les deux proprié- tés suivantes : (1) P1 est autostabilisant ; (2) siPi (1 ≤i < k) sont stabilisés alors Pi+1 finit lui aussi par atteindre un état légitime.Pk étant bien évidemment l’algo- rithme que l’on souhaite voir fonctionner correctement sur le réseau. Dans le même article, une autre technique de composition est présentée qui nécessite un prédicat de sélection. Les deux modules qui entrent dans la composition ne communiquent pas, mais ils modifient les mêmes variables de sortie. A un moment donné, le prédicat de sélection est vrai seulement pour un module. A partir de ce moment, seul ce module pourra modifier les variables de sortie communes aux deux modules.

Dans [VAR 97], un autre type de composition de modules autostabilisants a été dé- fini. Les modules communiquent les uns avec les autres au moyen de leurs variables de sortie. Cette technique s’apparente beaucoup aux modèles en couches utilisés dans les réseaux où la description des fonctionnalités offertes par la couche i+ 1 s’ap- puie sur celles fournies (à l’aide d’une interface) par la couchei, la première couche s’appuyant sur les caractéristiques physiques des équipements.

Le but de la composition [DOL 99b] est d’accélérer l’autostabilisation d’un algo- rithme. Cet algorithme utilise le résultat de l’algorithme autostabilisant le plus rapide parmikalgorithmes qui effectuent en parallèle la même tâche.

La composition par croisement consiste à améliorer la qualité d’un algorithme P1, en utilisant les propriétés d’un autre algorithmeP2[BEA 01b]. Informellement, l’algorithme obtenu P1¦P2 effectue la même tâche que l’algorithmeP1en ayant les propriétés de P2. L’utilisation principale de composition par croisement est la transformation d’un algorithme autostabilisantP1(nécessitant un niveau de synchro- nisation important entre les éléments du réseau) en un algorithmeP1⁰qui maintient la propriété d’autostabilisation, même si les éléments du réseaux sont asynchrones.

6.2. Autostabilisation automatique de protocoles

Il est fréquent que l’on sache implanter une tâche grâce à un protocole ad hoc.

Si ce protocole ne possède pas la propriété d’autostabilisation, il est fort peu probable qu’il fonctionne correctement dans un environnement où des défaillances ou des chan- gements topologiques du réseau peuvent survenir. Il est alors intéressant de disposer d’une « machine à autostabiliser », c’est-à-dire d’un compilateur qui prend en entrée un protocole n’étant pas autostabilisant et qui fournit en sortie un autre protocole, qui effectue la même tâche que le protocole fourni en entrée, mais qui possède en plus la propriété d’être autostabilisant.

Pour proposer un tel compilateur, les auteurs supposent en général qu’une incohé- rence peut être détectée, et que cette détection déclenche la réinitialisation complète du système. On peut considérer cette technique comme une forme d’autostabilisation.

En effet, partant d’un état quelconque, le protocole de calcul de l’état global détecte l’inconsistance du système puis lance une réinitialisation du système.

De nombreux travaux du domaine de l’autostabilisation sont fondés sur cette tech- nique, les plus représentatifs étant [ARO 94, AFE 90, COU 03, KAT 93]. Dans [AFE 90], les auteurs proposent une construction d’arbre couvrant autostabilisante. Chaque nœud du graphe est racine d’un arbre, c’est-à-dire que chaque processus participe au main- tien d’autant d’arbres couvrants qu’il y a de nœuds dans le graphe. Lorsqu’un nœud détecte localement une incohérence, il déclenche une réinitialisation globale du sys- tème en diffusant une vague (cf. section 5.2) sur l’arbre dont il est la racine. Cette approche offre l’avantage de fonctionner avec des changements topologiques. Par ailleurs, aucun processus n’a besoin d’être capable de vérifier à lui seul la consistance du système dans son ensemble.

Dans [ARO 94], une autre approche est proposée. Les auteurs combinent plusieurs modules. Un premier module se charge de désigner un processus unique — le lea- der — parmi les processus (cf. §5.1 pour ce problème). Une fois la désignation du lea- der stabilisée, un arbre couvrant du système ayant le leader comme racine est construit.

Ensuite, lors de la détection d’une incohérence locale, chaque processus peut émettre une demande de réinitialisation vers le leader en utilisant une branche de l’arbre cou- vrant construit. Dans une dernière phase, le leader réinitialise le système en diffu- sant une vague sur l’arbre. Par rapport à la méthode précédente, cette technique offre l’avantage de ne pas imposer la maintenance de plusieurs arbres par les nœuds, mais un seul arbre couvrant du système. Elle a cependant l’inconvénient d’être centralisée et de ne pas tolérer les changements topologiques.

Dans [KAT 93], les auteurs supposent que le système dispose d’un processus parti- culier (le leader) capable de vérifier la consistance du système vis-à-vis de la spécifica- tion du problème à résoudre. Le leader détecte que le système est dans un état incorrect en collectant l’état de tous les processus du réseau avec un protocole de prises d’ins- tantanés (snapshot). Alors que les solutions évoquées ci-dessus [ARO 94, AFE 90]

fonctionnent dans le modèle à registres, la solution proposée dans [KAT 93] offre l’énorme avantage de fonctionner dans le modèle à passage de messages (modèle beaucoup plus proche de la réalité que le modèle à registres). Malheureusement, ce protocole engendre un surcoût important en nombre de messages, le rendant ainsi in- utilisable dans la pratique. En effet, sur un réseau complet, sa complexité en nombre de messages estΩ(N!)une fois stabilisé,N étant le nombre de processus dans le ré- seau. Dans les mêmes conditions, une version implantable est proposée dans [FLA 97]

puisque, dans les mêmes conditions d’analyse, elle n’utilise queO(N³)messages.

Fonctionnant selon le même principe que [KAT 93], le compilateur proposé dans [COU 03] offre l’avantage de construire une version instantanément stabilisante d’un protocole stabilisant. Il démontre ainsi la puissance d’expression de la stabilisation instantanée : tout problème non stabilisant pouvant être autostabilisé en utilisant le compilateur de [KAT 93] peut être stabilisé instantanément. Cependant ce compilateur suppose une communication par registres.

Les techniques proposées ci-dessus comportent l’inconvénient évident de réinitia- liser l’ensemble du système. Or, il convient de noter que circonscrire localement l’effet d’une faute transitoire (ou pas) intervenue sur l’un des éléments du réseau (nœud, ca- nal de communication) équivaut à circonscrire un changement de topologie. En outre, les changements de topologie ne concernent généralement qu’une région assez res- treinte du réseau. En fait, lorsque cela est possible, il serait plus avantageux de cir- conscrire l’effet de l’incohérence lié au changement de topologie à son voisinage le plus proche. Cette approche, d’abord suggérée dans [AFE 90], est abordée sous diffé- rents angles dans [GHO 96, DOL 97b, BEA 98] et exposée dans la prochaine section.

7. Autostabilisation améliorée

L’autostabilisation permet de tolérer un nombre arbitrairement grand de défaillan- ces, mais dans de nombreux cas, elle souffre de problèmes de performances lorsque le nombre de défaillances est petit. Par exemple, dans [AWE 91a, AWE 94, AFE 97, DOL 97b, KAT 93], la défaillance transitoire d’un seul nœud entraîne la perturba- tion du réseau tout entier, ce qui rend ces solutions inutilisables en pratique pour des réseaux de grande taille. De cette observation, un objectif de recherche récent s’est développé : plus le nombre de défaillances dans le réseau est faible, et plus le nombre de perturbations causées par ces défaillances devrait être faible également.

Les protocolesk-stabilisants [BEA 99b] sont des protocoles stabilisants pour le cas où une borne supérieurek ≤N sur le nombre de fautes est connue oùN est le nombre total de nœuds. Pour modéliser une faute, on utilise la distance de Hamming entre les états [DOL 97b]. Plus spécifiquement, siC1etC2sont des états, la distance entre eux est le nombre de nœuds dont les états locaux sont différents dansC1et dans C2. SoitCun état non légitime etLun état légitime dont la distance àCest la plus petite (Ln’est pas forcément unique). Le nombre de fautes dansCest la distance àL.

Les nœuds défaillants sont ceux dont l’état dansCet dansLsont différents.

Le fait que le processus de récupération sur erreur puisse impliquer le réseau tout entier empêche son utilisation dans des réseaux de grande taille tels qu’internet.

Pour permettre le passage à l’échelle, il a été suggéré (par exemple dans [GHO 02, KUT 99a, KUT 99b]) que plus le nombre de fautes touchant le réseau était réduit, et plus le temps de reprise sur erreur devrait être faible. De tels protocoles (appelés fault local, fault scalable ou encore time adaptive dans la littérature) ont été proposés tout d’abord pour des cas simples. Ces cas simples peuvent être (i) qu’un nœud est capable de se rendre compte qu’il est défaillant [AFE 02], ou (ii) considérer uniquement le cas des tâches non réactives [KUT 99a, KUT 99b]. Une tâche non réactive est un calcul réparti dont le résultat est fonction des données en entrée. Ainsi, pour un ensemble de données en entrée, le calcul est effectué une seule fois.

Des études ont également été menées pour le problème du passage de jeton dans un anneau [BEA 99b, GEN 00, GEN 01]. Cependant, [GEN 02] montre que pour les systèmes dynamiques (tels que le passage de jeton), il existe une borne inférieure de

l’ordre deNpas de calcul avant un retour à la normale, et ce même en présence d’une seule faute. Ce résultat implique que les protocoles adaptables en temps n’ont de sens que dans les systèmes synchrones ou si on mesure la complexité en termes de tours d’exécution.

Les protocoles autostabilisants peuvent être vus comme un cas particulier des pro- tocolesk-stabilisants oùk =N est la taille du réseau. De façon similaire, les proto- coles adaptables en temps peuvent être vus comme un simple raffinement des proto- coles autostabilisants. Dans [GEN 01] est introduite la notion dek-adaptabilité pour dénoter la capacité à retrouver un comportement correct à partir d’un état comprenant knœuds corrompus en un temps qui dépend uniquement du nombre effectif de fautes.

Pour des raisons historiques, la plupart des protocoles qualifiés d’adaptables en temps [BEA 99b, KUT 99a, KUT 99b] sont k-adaptables en temps selon cette terminolo- gie : ils présupposent qu’il existe une borne sur le nombre de fautes qui atteignent le système pour garantir un temps de stabilisation rapide.

8. Conclusion

L’autostabilisation est un paradigme général de programmation qui permet à un système réparti de retrouver de lui-même un comportement correct à partir de n’im- porte quel état.

Dans le contexte particulier des réseaux d’ordinateurs, l’autostabilisation rend pos- sible la résistance des systèmes répartis à certains types de défaillances. A l’inverse d’autres approches de tolérance aux pannes, l’autostabilisation ne s’intéresse pas aux causes des défaillances (panne, malveillance, bogue, etc.), mais aux effets de celles-ci (corruption de la mémoire vive des nœuds, perte, duplication et déséquencement des messages, etc.). Ainsi, les protocoles autostabilisants tolèrent des pannes qui n’avaient pas été prévues lors de la conception du système (par exemple dues à une expansion trop rapide du réseau), et donc de construire des systèmes dont la résistance aux fautes est pérenne.

Dans ce survol, nous avons présenté plusieurs travaux proposant des solutions au- tostabilisantes à des problèmes classiques dans le domaine des réseaux informatiques.

En particulier, nous avons dénombré et comparé les solutions disponibles dans les do- maines de la construction des tables de routage, de l’acheminement des messages à travers un réseau, des communications point à point et des protocoles de contrôle.

D’un point de vue méthodologique, nous avons d’une part montré que de nom- breux arguments mathématiques permettant de montrer la convergence (par exemple ceux issus de la théorie du contrôle) pouvaient être utilisés pour prouver le caractère autostabilisant d’un protocole réseau, à condition de disposer d’un formalisme adé- quat. Par ailleurs, nous avons présenté plusieurs « transformateurs » qui permettent automatiquement de rendre un protocole donné autostabilisant (au prix d’un surcoût qui peut s’avérer élevé suivant le contexte d’exécution du protocole), ainsi que des

opérations de composition de protocoles qui préservent le caractère autostabilisant du résultat de la composition.

Enfin, nous avons présenté plusieurs avancées récentes du domaine pour les grands réseaux ou les réseaux fortement dynamiques. Ces améliorations permettent de limiter l’impact des fautes : plus les perturbations sont limités (en termes de nombre et de localisation), plus le réseau absorbe leur effet rapidement.

Remerciements

Ce travail a été partiellement financé par l’action JemSTIC STAR et par l’action spécifique Dynamo.

9. Bibliographie

[ABU 96] ABU-AMARA H., COAN B., DOLEV S., KANEVSKY A., WELCH J., « Self- stabilizing topology maintenance protocols for high-speed networks », IEEE-ACM Tran- sactions on Networking, vol. 4, n^o 6, 1996, p. 902-912.

[AFE 90] AFEKY., KUTTENS., YUNGM., « Memory-efficient self-stabilization on general networks », WDAG90 Distributed Algorithms 4th International Workshop, Springer-Verlag LNCS :486, 1990, p. 15-28.

[AFE 93] AFEKY., BROWNG. M., « Self-stabilization over unreliable communication me- dia », Distributed Computing, vol. 7, n^o 1, 1993, p. 27-34.

[AFE 97] AFEKY., KUTTEN S., YUNGM., « The local detection paradigm and its appli- cations to self-stabilization », Theoretical Computer Science, vol. 186, n^o 1-2, 1997, p. 199-229.

[AFE 02] AFEKY., DOLEV S., « Local Stabilizer », Journal of Parallel and Distributed Computing, vol. 62, n^o 5, 2002, p. 745-765.

[AGG 93] AGGARWAL S., KUTTENS., « Time optimal self-stabilizing spanning tree algo- rithm », FSTTCS93 13th Conference on Foundations of Software Technology and Theore- tical Computer Science, Springer-Verlag LNCS :761, 1993, p. 400-410.

[ALE 79] ALELIUNASR., KARPR. M., LIPTONR., LOVASZL., RACKOFFC., « Random walks, universal traversal sequences and the complexity of the maze problem », FOCS79 20th Annual IEEE Symp. on Foundation of Computer Science, 1979, p. 218-223.

[ALI 98] ALIMAL. O., BEAUQUIERJ., DATTAA. K., TIXEUILS., « Self-stabilization with global rooted synchronizers », ICDCS98 18th International Conference on Distributed Computing Systems, 1998, p. 102-109.

[ANG 80] ANGLUIND., « Local and global properties in networks of processors », STOC80 12th Annual ACM Symposium on Theory of Computing, ACM, 1980, p. 82-93.

[ARO 90] ARORA A., GOUDA M. G., HERMAN T., « Composite routing protocols », SPDP90 2nd IEEE Symposium on Parallel and Distributed Processing, 1990, p. 70-78.

[ARO 93] ARORAA., ATTIEP., EVANGELISTM., GOUDAM. G., « Convergence of iteration systems », Distributed Computing, vol. 7, n^o 1, 1993, p. 43-53.