Notre proposition se focalise ici sur la localisation des n÷uds dans un réseau hybride. Un n÷ud doit être accessible par son point d'accès : lorsqu'un paquet arrive dans la passerelle, il doit
Proposition d'une solution de localisation adaptée aux réseaux hybrides 113 être envoyé en multisauts jusqu'à la destination. Inversement, un terminal doit pouvoir envoyer ses paquets à des destinataires présents dans Internet. Mobile IP peut directement être utilisé pour gérer la macro-mobilité entre bulles ad hoc. Par contre, nous présentons ici une solution de gestion de la micro-mobilité inspirée de Cellular IP. Comme nous l'avions déjà souligné, la dorsale proposée dans le chapitre3page31convient particulièrement pour une telle adaptation. En eet, nous avions proposé la création d'une dorsale en forme d'arbre, se réparant de façon autonome lorsque des changements de topologie surviennent. Ainsi, nous pouvons adapter Cellular IP sur cette dorsale, gérant de façon transparente la mobilité des n÷uds. Nous détaillons donc ici le fonctionnement de ce protocole, que nous avons appelé Self-organized Mobility Management (somom) .
6.4.1 Description générale
Cellular IP s'appuyant sur une topologie en arbre des routeurs, nous proposons tout sim-plement d'utiliser la dorsale en arbre proposée précédemment. Les terminaux, bien que mobiles, maintiennent en continu la connectivité et la propriété de dominance de la dorsale. Ainsi, un protocole de localisation peut de façon transparente utiliser cette dorsale, levant le problème des changements de topologie. Naturellement, l'intégration de Cellular IP et de la dorsale ne peut être réalisée de façon totalement transparente puisque la dorsale subit des changements de topo-logie, et donc que les caches de localisation doivent être mis à jour en conséquence. Cependant, comme nous l'avions remarqué, la dorsale présente une persistance élevée : de telles mises à jour seront donc limitées. Une telle propriété est importante pour limiter la génération intempestive de tra c de contrôle.
Plus précisément, dans le sens download, le point d'accès qui ne connaît aucune route vers la destination inondera la dorsale. Une réponse de route mettra à jour les caches de localisation des terminaux faisant partie de la dorsale a n que les paquets suivants soient routés normalement. Dans le sens upload, nous verrons qu'une route est a priori connue vers le point d'accès, du fait de la forme particulière de la dorsale, le point d'accès constituant sa racine. Nous utiliserons donc cette information pour créer une route par défaut.
6.4.2 Accès à Internet
Le point d'accès peut représenter une route par défaut adéquate pour joindre Internet. Lors-qu'un terminal souhaite envoyer un paquet, il l'envoie à son point d'accès. Ensuite, le point d'ac-cès agira comme proxy a n de trouver une route dans Internet, faire de la translation d'adresses, du ltrage. . . La dorsale présente des propriétés pouvant convenir à une telle fonctionnalité : elle est en forme d'arbre, le point d'accès étant placé à sa racine. De plus, chaque n÷ud maintient l'identité de son père dans l'arbre. Ce parent constituera donc la route par défaut.
Plus précisément, pour un dominant, le père dans l'arbre est un voisin. Donc la route par défaut peut directement pointer vers ce père. Pour un dominé, le père peut se trouver à au plus kcdssauts. Cependant, comme la connaissance du kcds-voisinage est requise pour la maintenance de la dorsale, un dominé peut extraire un prochain saut vers son père, constituant sa route par défaut.
La connaissance proactive d'une route par défaut vers Internet représente un grand atout : aucun tra c de contrôle supplémentaire n'est requis, et la latence de découverte de route est nul. Nous pensons donc qu'une telle connaissance est utile dans les réseaux hybrides.
6.4.3 Localisation du mobile
De la même manière, un point d'accès qui reçoit des paquets de données venant d'Internet et à destination d'un de ses mobiles doit pouvoir connaître une route vers ce mobile. Nous proposons dans un premier temps une maintenance gratuite de route, telle que dans Cellular IP.
Lorsqu'un n÷ud reçoit un paquet de données relayé par un n÷ud R, il peut mettre jour dans sa table de routage l'entrée pointant vers la source du paquet de données, xant son prochain saut à R. Ainsi, lorsqu'un n÷ud initie une communication vers Internet, il envoie directement un paquet de données sur sa route par défaut, créant automatiquement dans chaque n÷ud intermédiaire une entrée correspondante dans sa table de routage. De même, si un changement de topologie dans la dorsale se produit, il su t que le n÷ud envoie un paquet de données pour mettre à jour les tables de routage obsolètes des n÷uds relais. De plus, nous pensons que les communications seront, dans un réseau hybride, majoritairement initiées par le terminal : pour l'envoi d'enregistrements Mobile IP, pour initier une requête http. . . Ainsi, le rafraîchissement de la route inverse, lors de chaque envoi de paquet de données permet de limiter les délais de création de route, et de limiter l'overhead. Une telle propriété représente selon nous un atout important pour un protocole de routage dans les réseaux hybrides.
Cependant, il peut arriver qu'un point d'accès reçoive un paquet de données à relayer pour un de ses mobiles et qu'il ne connaisse encore aucune route vers celui-ci. Pensant qu'un tel cas est rare, nous proposons ici une approche réactive, permettant de limiter l'overhead. La recherche réactive d'une route pourrait être comparée au mécanisme de paging de Cellular IP : un routeur Cellular IP doit trouver réactivement la localisation exacte d'un mobile, en inondant ses descendants dans l'arbre des routeurs Cellular IP.
Lorsque le point d'accès reçoit un paquet de données destiné à D et qu'aucune route vers D n'est connue, il engage la procédure suivante :
• Le point d'accès met en le d'attente le paquet de données. Puis il génère un paquet de Route Request et l'envoie à ses ls dans l'arbre en multicast ( g. 6.4 page suivante), l'adresse multicast correspondant à l'ensemble des n÷uds de la dorsale. L'AP initie donc une inondation de la dorsale.
• Un dominant recevant une Route Request regarde si la destination recherchée est présente dans sa table de voisinage :
◦ Si la destination n'est pas un de ses dominés, le dominant relaie la requête en multicast à ses ls.
◦ Si au contraire, le dominant est lui-même la destination ou la connaît, il génère une Route Reply et l'envoie à son père dans l'arbre. Un dominant joue donc le rôle de mandataire pour ses dominés.
Dans un tel mécanisme, seul un n÷ud peut générer une Route Reply (le n÷ud lui même s'il est dominant, ou sinon son père). Cependant, lorsqu'un dominé se retrouve déconnecté de la dorsale lors de la maintenance, un mécanisme de réparation se met en place, demandant une certaine latence avant que les informations convergent. A n de diminuer l'impact d'une déconnexion de la dorsale, tout dominant recevant une Route Request peut renvoyer une Route Reply si la destination est présente dans sa table de voisinage. Ainsi, plusieurs Route Reply peuvent être générées pour une même destination, augmentant l'overhead. Cependant, les Route Request devraient également se propager moins loin dans l'arbre, limitant ainsi le nombre de paquets de contrôle. Nous pensons donc qu'un tel mécanisme présente un impact limité sur le tra c de contrôle. De plus, nous pouvons remarquer que seuls les dominants relaient les Route Request, quelle que soit la méthode utilisée. C'est pourquoi l'overhead est beaucoup plus réduit que lors d'une inondation globale du réseau.
Lorsqu'un n÷ud reçoit une Route Reply, il met à jour sa table de routage, en ajoutant ou rafraîchissant l'entrée correspondant à la source du paquet. Puis, la Route Reply est envoyée via la route par défaut. Finalement, le paquet arrivera à la racine de la dorsale, le point d'accès. L'AP mettre donc à jour sa table de routage et pourra envoyer les paquets de données buerisés et destinés à ce n÷ud. Si d'autres paquets arrivent d'Internet, le point d'accès connaîtra dorénavant une route vers le mobile, et n'aura pas besoin de réinitier une découverte de route.
Si certains n÷uds sont fortement actifs et souhaitent maintenir continuellement une route pointant vers eux, ils peuvent supprimer la part réactive en envoyant périodiquement des Route
Proposition d'une solution de localisation adaptée aux réseaux hybrides 115
Fig. 6.4 Exemple de fonctionnement de somom lorsqu'un paquet de données arrive de l'Internet (kcds= 1)
Update agissant comme des Route Replies. Ainsi, aucune latence de découverte de route ne sera introduite. Un tel mécanisme pourrait être intéressant pour un serveur de données par exemple. Durant la maintenance, des réparations de la dorsale peuvent intervenir, introduisant des changements dans la topologie virtuelle. Un dominant changeant de père va créer un ensemble de routes obsolètes dans les caches de routage de la dorsale. Un dominant voyant qu'un de ses ls dans la dorsale est parti, supprime toutes les entrées de sa table de routage dont il constituait le prochain saut. Puis, il génère un Route Delete contenant la liste des entrées supprimées de sa table de routage. Ce paquet est ensuite envoyé à son père. Saut par saut, le Route Delete va supprimer les entrées obsolètes dans les tables de routage. Lorsque le point d'accès recevra un paquet destiné à un n÷ud de la branche reconnectée, l'entrée obsolète aura été supprimée, et une nouvelle découverte de route sera ré-initiée.
Dans le futur, les AP advertisements intégreront les paramètres Mobile IP, le pré xe réseau utilisé,. . . Ainsi, chaque n÷ud pourra découvrir les paramètres d'accès du réseau. Si le réseau hybride comprend plusieurs points d'accès, une dorsale par AP sera construite, comme décrit dans la section 3.5 page 41. Un dominant qui changera de dorsale fera un handover pour sa branche, récupérera les nouveaux paramètres d'accès tirés des AP advertisements et agira en tant que proxy, ou diusera ces paramètres.
6.4.4 Implémentation d'un mode ad-hoc
Nous avons proposé une solution optimisée pour les communications de et vers Internet. Cependant, il peut être quelquefois intéressant d'autoriser les communications de pair à pair. Nous proposons donc ici une extension permettant les communications internes. Le délai et la longueur de la route ne sont pas optimaux, mais nous pensons que ceci ne constitue pas un inconvénient sévère, ce type de communications n'étant pas majoritaires.
Fig. 6.5 Fonctionnement du mode ad hoc de somom
Lorsqu'un n÷ud S souhaite envoyer un paquet de données vers D, S ne sait pas si la des-tination est à l'intérieur de la bulle ad-hoc ou sur Internet. Ainsi, S va chercher s'il connaît une route vers D dans son cache de routage, ou si D est présent dans sa table de voisinage. Si c'est le cas, il lui envoie directement le paquet. Sinon, il l'envoie via sa route par défaut à son père, qui exécute la même procédure (étape 1 de la gure 6.5). Si nalement, aucun ascendant dans la dorsale ne connaissait la destination, le paquet arrive au point d'accès. Nous supposons que le point d'accès sait si la destination correspond à un de ses clients ou pas (selon le pré xe réseau, son cache de membres. . .). Si la destination est dans la bulle ad-hoc, il buerise le paquet, génère une Route Request (étape 2 g.6.5), et attend une Route Reply, comme normalement. Les paquets seront nalement envoyés sur la route découverte (étape 4 g. 6.5).
Si de nouveaux paquets arrivent pour la même destination, une route est déjà connue. Ainsi, le paquet n'arrivera certainement pas jusqu'à la racine de la dorsale. Il sera envoyé directement sur la bonne route par l'ancêtre commun de la source et de la destination dans la dorsale (étape 5 g.6.5). Ainsi, la longueur de la route ne sera pas optimale, mais nous pensons qu'un tel scénario se présentera dans un nombre de cas minoritaire.
6.4.5 Paging
Le paging est utilisé dans les réseaux cellulaire a n de limiter l'overhead des enregistrements. Un n÷ud ne s'enregistre que rarement, dans sa zone de paging, comprenant plusieurs points d'accès. Ainsi, un mobile peut se déplacer sans changer de zone de paging, et donc sans renouveler son enregistrement. Un Paging Master est supposé connecté (directement ou indirectement) à tous les points d'accès de la zone de paging. Le Paging Master ajoute le mobile dans son cache de membres avec un timeout long. Lorsqu'un paquet arrive pour un tel mobile, il véri e que la destination est présente dans son cache de membres. Ensuite, il regarde dans son cache de routage si un point d'accès lui est déjà associé. Si c'est le cas, le paquet de données est envoyé à l'AP correspondant. Sinon, le Paging Master initie une découverte de route, déclenchant l'envoi d'un Route Request par l'ensemble des points d'accès de sa zone de paging. Un mécanisme de paging peut être utile lorsqu'un terminal est mobile, et que le changement de point d'accès
Performances 117 engagerait un changement d'adresse IP, de recon guration, et donc engendrerait un overhead périodique important.