Cette partie adresse la probl´ematique des communications multicast entre les diff´erents clusters. En effet, si l’on consid`ere une r´epartition des membres de groupe multicast comme le groupe 2 sur la fig. A.7, le protocole STAMP permettra de g´erer la distribution des donn´ees multicast entre les membres d’un mˆeme cluster comme
Figure A.6 Comparaison diff´erentielle des overheads de donn´ees (bleu), de contrˆole (vert) et du taux de d´elivrance des paquets (rouge) en fonction de la mobilit´e.
Figure A.7Illustration de la r´epartition des membres de groupes multicast sur le r´eseau MANET clust´eris´e
dans les clusters F, C ou D et le protocole de routage multicast inter-cluster se chargera d’acheminer les donn´ees multicast entre ces diff´erents clusters. Si la litt´erature est tr`es abondante concernant les protocoles de routage multicast pour des environnements r´eseau non clust´eris´es avec un nombre de noeuds r´eduit, ce n’est pas du tout le cas concernant les protocoles de routage multicast pour les environnements r´eseau clust´eris´es. Une ´etude de l’existant nous permet cependant de distinguer deux cat´egories de protocoles. La premi`ere cat´egorie se compose de protocoles qui ne consid`erent pas le r´eseau comme ´etant clust´eris´e mais qui cr´ee une structure multicast sur le r´eseau global pour ensuite la diviser en sous structures g´er´ees localement. Cette approche n’est pas compatible avec notre approche car elle ne tire pas partie de la structure clust´eris´ee du r´eseau et elle ne fait pas de distinction entre les niveaux de routage inter et intra cluster. La seconde cat´egorie est en phase avec notre approche car elle consiste en des protocoles qui ont ´et´e con¸cu pour adresser le routage multicast inter-cluster seulement. Ces protocoles sont tous similaires dans le sens o`u ils proposent d’appliquer les solutions d´efinies pour les r´eseaux “`a plat” au niveau de la topologie des clusters. Cette solution est assez peu efficace du fait de l’effet “multiplicatif” du clustering sur les messages de contrˆole et sur les erreurs. De plus, cette approche ne tire pas partie du fait qu’il existe dans un r´eseau clust´eris´e d’autres services (tels que le routage unicast, le clustering, ...) qui ´echangent eux aussi des messages de contrˆole dont on peut tirer partie. En effet, le protocole de routage multicast inter-cluster pourrait faire du “piggybacking” de fa¸con `a int´egrer ces informations de contrˆole dans les messages de contrˆole existants. En conclusion de cet ´
etat de l’art, nous concluons qu’il n’existe pas de solution suffisamment optimis´ee et int´egr´ee pour le routage multicast inter-cluster dans un environnement MANET. Nous proposons donc le protocole SAFIR (ScAlable structure Free inter-cluster multicast Routing).
SAFIR d´efini une m´ethode pour router des datagrammes multicast entre clusters dans un r´eseau clust´eris´e fait de noeuds sans fil mobiles. SAFIR permet de g´erer les communications inter-cluster et suppose
Figure A.8Overhead de contrˆole en bit en fonction du nombre de noeuds
qu’un protocole de routage intra-cluster tel que STAMP est impl´ement´e pour g´erer les communications mul- ticast `a l’int´erieur de chaque cluster. Ainsi, l’objectif de SAFIR est de d´efinir comment un datagramme pour un groupe multicast G peut ˆetre achemin´e de cluster `a cluster jusqu’`a atteindre les clusters o`u se trouvent les membres du groupe multicast G. Cet objectif permet de mettre en avant diff´erentes questions auxquelles SAFIR doit r´epondre :
1. Comment un noeud connaˆıt-il la liste des clusters o`u se trouvent les membres pour un groupe multicast G?
2. Comment un cluster connaˆıt-il vers quel cluster voisin il doit faire suivre les datagrammes multicast? 3. Quel noeud est responsable de prendre la d´ecision de “forwarding”?
4. Sur quelle information se fonde la d´ecision de forwarding?
5. Comment est faite l’interconnexion entre le protocole inter-cluster et le protocole intra-cluster? Quelles sont les informations qui doivent ˆetre ´echang´ees?
Dans SAFIR, comme dans la plupart des protocoles de routage multicast inter-cluster, c’est le clusterhead qui a la responsabilit´e de d´ecider si un datagramme multicast doit ˆetre forward´e ou non. Contrairement aux autres protocoles de la litt´erature, aucun message Join / Leave / Ack n’est ´echang´e entre les clusterheads ou les noeuds gateway pour construire ou maintenir une structure multicast qui permettrait aux clusterheads de prendre leur d´ecision de forwarding. SAFIR d´efini une m´ethode dans laquelle chaque clusterhead prend sa d´ecision de forwarding ind´ependamment des autres clusters, de fa¸con autonome, de telle fa¸con que chaque paquet multicast suit son propre chemin quand il va de cluster en cluster. Pour cela, chaque clusterhead doit connaˆıtre deux informations sur son cluster. d’une part, il doit savoir quels sont les groupes multicast pour lesquels il y a des membres dans son cluster et d’autre part, il doit connaˆıtre la liste des ses clusters voisins. Ces deux informations sont ´echang´ees entre les clusterheads en utilisant les messages de contrˆole du protocole de clustering ou du protocole de routage unicast. Ainsi, chaque clusterhead connaˆıt les appartenances aux groupes multicast de chaque cluster, i.e. la r´epartition sur les clusters des membres des groupes multicast, et il est aussi capable de construire une table de routage unicast de niveau cluster, de type “vecteur de distance” ou de type “´etat de liens”. Le choix entre l’approche vecteur de distance ou l’approche ´etat de liens a des r´epercussions sur le processus de forwarding et sur la redondance des chemins de forwarding des donn´ees multicast. Quand un clusterhead re¸coit des paquets multicast, il est capable de d´eterminer quels sont les clusters o`u les destinataires i.e. les membres multicast sont et pour chaque cluster destination, il est capable de d´eterminer quel est le cluster vers lequel il doit faire suivre les donn´ees multicast, i.e. le cluster “next hop”.
Nous avons r´ealis´e une ´etude de performance sur le protocole SAFIR grˆace au simulateur `a ´ev`enement discret OPNET Modeler 11.5. Cette ´evaluation de performance avait divers objectifs :
• V´erifier l’int´erˆet du clustering par rapport `a une solution `a plat. Pour cela, nous avons compar´e l’utilisation de SAFIR coupl´e `a ODMRP pour l’intra-cluster `a celle d’ODMRP sans clustering. Les courbes A.8 et A.9 montre l’overhead de contrˆole et le taux de d´elivrance des donn´ees quand le nombre de noeuds du r´eseau augmente. L’int´erˆet de l’utilisation du clustering pour la r´eduction de l’overhead de contrˆole est bien prouv´e. De plus, nous montrons que cela ne se fait pas au d´etriment du taux de d´elivrance de donn´ees.
Figure A.9Taux de d´elivrance des donn´ees en % en fonction du nombre de noeuds
Figure A.10 Overhead de donn´ees en paquets en fonction du nombre de sources multicast par groupe
• Etudier l’influence du choix du protocole de routage multicast intra-cluster sur les performances globales du service multicast. Pour cela, on a compar´e les r´esultats de l’association SAFIR/STAMP et SAFIR/ODMRP. On donne aussi pour r´ef´erence les r´esultats de simulation dans le cas o`u ODMRP serait employ´e sans clustering. La figure A.10 pr´esente les r´esultats obtenus pour l’overhead de donn´ees en fonction du nombre de sources multicast pour un r´eseau de 200 noeuds et la figure A.11 pr´esente les r´esultats obtenus pour l’overhead de contrˆole en fonction du nombre de groupes. En conclusion, cette ´etude montre que un protocole de routage qui repose sur un arbre partag´e tel que STAMP permet d’obtenir de meilleurs r´esultats d’efficacit´e quant aux overheads de contrˆole et de donn´ees. En effet, ce type de protocole tire mieux parti de la structure en cluster.
Figure A.12Illustration des diff´erents probl`eme d’interconnexion `a r´esoudre