Apr`es avoir identifi´e des temps de latence excessifs dans le paragraphe pr´ec´edent, nous proposons des m´ecanismes adapt´es pour les r´eduire. Pour cela, nous envisageons d’´etendre les protocoles de base OLSR et MP-OLSR avec 3 solutions diff´erentes. Nous donnons dans ce qui suit une description d´etaill´ee de ces nouvelles techniques de r´eparation de pannes. Suite au premier rejet d’un paquet de donn´ees, le nœud qui d´etecte la d´efaillance d’un lien `a l’aide du m´ecanisme LLN va agir d’une mani`ere r´eactive pour informer la source selon les processus suivants.
4.4.1 Strat´egie de notification d’une erreur de route (RE)
Cette strat´egie se base sur un m´ecanisme souvent utilis´e dans les protocoles de routage r´eactifs dans les MANETs. Il consiste en l’envoi d’un message de contrˆole unicast (appel´e RERR NOTIF) pour notifier la source d’une rupture de route (voir figure 4.4). Quand un nœud d´etecte une cassure de lien, il g´en`ere un message RERR NOTIF contenant l’adresse de l’interface correspondante au lien d´efaillant et il l’envoie en unicast vers la source des donn´ees. A la r´eception de ce message, le nœud source met `a jour sa table de topologie en supprimant les informations li´ees au lien perdu. Cela va engendrer un recalcul d’une nouvelle table de routage relative `a la vue de la topologie actuelle (voir le diagramme d’activit´e de la figure 4.5).
Un des avantages de cette strat´egie est que le message de contrˆole suppl´ementaire est envoy´e en unicast et non pas en inondation, ce qui permet de diminuer le surcoˆut dans le r´eseau. Par contre, il est important de s’assurer que ce message de contrˆole RERR NOTIF soit re¸cu avec succ`es. Quant aux paquets de donn´ees qui sont envoy´es avant que le RERR NOTIF parvienne `a la source, ils seront rejet´es.
4.4.2 Strat´egie par l’envoi imm´ediat d’un message TC (FTC)
Apr`es la d´etection d’une rupture de lien sur l’une de ses interfaces, le nœud envoie imm´ediatement un message TC (appel´e FAST TC) sans attendre l’intervalle p´eriodique par d´efaut pour l’´emission des messages TC (voir la figure 4.6). Ce message TC tient compte du changement de la topologie via l’incr´ement du num´ero de s´equence ANSN (Advertised Neighbor Sequence Number). Ce dernier permet de ne pas pr´eserver des informations obsol`etes, pour tenir les tables le plus `a jour possible. La diffusion du message
Figure 4.4 — Strat´egie de notification de l’erreur de route (RE).
TC entraˆıne un coˆut non n´egligeable en termes de ressources r´eseau. Pour r´eduire ce surcoˆut, nous d´efinissons une p´eriode de temps appel´ee FAST TC INTERVAL contrˆolant l’envoi d’un prochain message FAST TC `a son expiration si la mˆeme erreur persiste pour un mˆeme ´ev`enement de d´efaillance (voir diagramme d’activit´e pr´esent´e par la figure 4.7). Dans le mˆeme ordre d’id´ee, une autre optimisation envisag´ee consiste en la diffusion du FAST TC tout en limitant son rayon au nombre de sauts entre le nœud qui d´etecte la panne et la source. Cette strat´egie est similaire `a celle propos´ee dans le travail [51]. Cependant, nous ´evitons aussi l’utilisation du d´elai suppl´ementaire (i.e. J itter) qui s´epare la g´en´eration et l’´emission du message FAST TC par le nœud d´etectant la panne ; mais ce d´elai standard est pr´eserv´e quand ce message de contrˆole est retransmis par les nœuds interm´ediaires selon [10] afin d’´eviter les collisions potentielles. Ainsi, la mise `a jour de la topologie devient plus rapide. Le FAST TC INTERVAL est mis `a 0.5 s dans les prochaines exp´eriences de simulation.
Figure 4.6 — Strat´egie bas´ee sur l’envoi imm´ediat d’un message TC (FTC).
4.4.3 Strat´egie de r´e´emission des paquets de donn´ees (DR)
Cette strat´egie est sp´ecialement con¸cue pour le protocole MC MP-OLSR. Elle s’appuie sur le principe selon lequel un paquet de donn´ees, qui devrait par d´efaut ˆetre rejet´e par un nœud ayant d´etect´e une panne, sera ici r´e´emis vers le nœud source (voir figure 4.8). Cette r´e´emission aura lieu quand aucun autre chemin alternatif vers la destination n’est trouv´e
Figure 4.7 — Diagramme d’activit´e de la strat´egie FTC.
suite au processus standard d’autor´eparation de route de MP-OLSR. Cette strat´egie tire profit du routage `a la source employ´e par le protocole MP-OLSR pour d´eterminer le chemin inverse ramenant `a la source. Le paquet de donn´ees va alors ˆetre achemin´e vers la destination en passant par la source via ce chemin inverse. Avant de relayer ce paquet `
a la destination, le nœud source met `a jour sa base de topologie locale avec les derni`eres informations et effectue un recalcul de la table de routage (voir le diagramme d’activit´e de la figure 4.9).
Dans cette strat´egie, on ne peut envisager de ne r´e-envoyer le paquet de donn´ees vers la destination via un chemin alternatif qu’apr`es avoir v´erifi´e si le d´elai applicatif tol`ere le temps de re-transmission de ce mˆeme paquet. Cette comparaison n´ecessite le calcul de la diff´erence entre l’instant du premier envoi d’un paquet de donn´ees et l’instant de son deuxi`eme retour `a la source. Si le d´elai maximal autoris´e par l’application est d´epass´e alors le paquet sera rejet´e par la source. Une telle approche permet d’´economiser de la bande passante.
Figure 4.8 — Strat´egie de r´e´emission des donn´ees (DR).
Figure 4.9 — Diagramme d’activit´e de la strat´egie DR.
rejet des paquets de donn´ees si possible et de faire un traitement de contrˆole `a partir des messages de donn´ees sans le besoin d’un message de contrˆole additionnel. Mais elle ajoute un calcul suppl´ementaire au niveau de la source qui doit inspecter les paquets de donn´ees.
strat´egies de r´etablissement de route propos´ees tendent `a r´eduire le surcoˆut induit par les messages de contrˆole. A titre d’exemple, le m´ecanisme RE envoie un seul message de contrˆole en unicast dans une seule direction tandis que le m´ecanisme DR n’utilise aucun paquet de contrˆole suppl´ementaire.
Dans la section suivante, nous allons ´etudier, par simulation, le comportement de chacune des strat´egies de r´eparation de pannes propos´ees.