UHMMA
Avancement des travaux.
What's new ?

C. CASTELLUCCIA - L. BELLIER - INRIA Rhône-Alpes
claude.castelluccia@inrialpes.fr

Février 2000

28-2-2000.   Plusieurs avancées mineures ces derniers jours :

• codage d'un protocole de partage dynamique de charge des MA. Sur un grand domaine, il y aura plusieurs MA sur le réseau virtuel. Ce protocole permet d'équilibrer la charge des MA. Le fonctionnement est simple. Chaque MA ajoute dans les rt adv. qu'il envoie sur le réseau virtuel, sa charge actuelle. Ainsi, chaque MA se constitue une liste de MA avec la charge correspondante. Cette liste étant triée par ordre croissant de charge, seul le premier de la liste envoie des annonces aux Base Stations. Un MA calcule sa charge en comptabilisant le nombre de mobiles qu'il gère, sachant qu'un mobile en mode 2 est plus couteux qu'un mobile en mode 1. Ceci garantit donc une répartition des enregistrements des mobiles sur les différents MA, et un équilibre des charges entre MA. Rappelons que l'administrateur communique la liste des BS de chaque MA. Il est donc possible d'attribuer un MA pour un groupe de BS. Si plusieurs MA sont affectés au même groupe de BS, ils partageront la charge de se groupe.
• ré écriture complète des spécifications d'implémentations dans FreeBSD. L'ancienne version était en effet plus un patch de la toute première version de ces spécifications. En cours de route, les choses ont beaucoup évolué. Voilà une version à jour, coordonnée avec les spécifications fonctionnelles.

11-2-2000.   Le nouveau draft Mobile IPv6 est sorti (cf. page de Download).
Les quelques nouveautés sont :

• discussions autours de la sécurité.
• changement du processus de découverte des Home Agents.
• ajout d'une fonctionnalité DAD dans un home Agent pour les Mobiles qu'il enregistre.
• changement de la politique de séquençage des retransmissions de BU par les mobiles. Le numéro de séquence doit etre supérieur à chaque retransmission.

Ces modifications ne me touchent que peu. Seul le dernier point me fait faire la grimace. Car c'est cette politique que j'avais initialement implémenté, puis j'ai du me mettre en conformance avec le draft 9, donc les retransmission n'incrémentaient pas le numéro de séquence. Il faut maintenant faire machine arrière.

4-2-2000.   Le MA est maintenant capable d'abandonner un smooth handoff qui n'abouti pas. Dans un tel cas, il avertit le mobile que l'enregistrement a échoué et retire le mobile de sa liste. C'est au mobile à agir en conséquence de cet echec.
Un bug ENORME a été corrigé au passage : le mobile ne tenait aucunement compte du status dans les acquitements ;-)

3-2-2000.   Le mobile vient s'enrichir d'une nouvelle fonctionnalité. Lorsqu'il arrive sur un site avec un MA et qu'il s'enregistre, si l'enregistrement echoue au bout de x tentative, le mobile swap en mode MIP.
Le x ammène une nouvelle option de configuration. Par défaut x vaut 8, mais peut être paramétrer par /etc/mobile6 avec la directive Domain RtReg=x.
Cette fonctionnalié a été testée et est donc ajoutée au document récapitulatif des tests UHMMA (de même le how to a été modifié pour prendre en compte le nouveau paramêtre).
Dans le même ordre d'idée, l'abandon d'un smooth handoff après x tentatives, sur un MH a également était codé. Un mobile qui était managé en mode 2 et qui se déplace sur un site nouveau domain où le mode 2 n'est pas disponible swap en demandant sa liste de cn à son ma précédent. Si celui-ci ne répond pas, le mobile passe directement dans son nouveau mode. Cela veux donc dire qu'il perd sa liste de cn. POur le HA on se débrouille en envoyant un BU avec un seq grand, mais les CN sont perdus.
Reste maintenant à faire de même entre deux MA qui font un smooth handoff.