Nous évaluons en suite la performance de SPMIPv6 avec RO. Des informations importantes, comme le surcoût de signalisation, le délai de handover, la perte de paquets, le délai RTT et le débit TCP, ont été considérées. Le réseau maillé virtuel, décrit dans le schéma XIII, se compose de deux clusters contrôlés par CH1 (LMA1) et CH2 (LMA2), trois routeurs AR1, AR2 et AR3. La fonctionnalité de LMA fonctionne sur CHs tandis que la fonctionnalité de MAG fonctionne sur AR1, AR2 et AR3. AR1 et AR2 sont sous le contrôle de CH1. AR3 est sous le contrôle de CH2. CH1 et CH2 sont reliés ensemble. MN1 et MN2 n'ont aucun logiciel spécifique pour la gestion de mobilité. Pour simplification, les liens d'accès emploient la technologie d'accès d'IEEE 802.11 simulée par Ns-2.
Schéma XIII. Le Banc de Test pour l’Evaluation du SPMIPv6 avec RO
Les adresses IPv6 de MNs sont auto-configurées. Nous supposons qu'il n'y a aucun conflit de l'adresse IPv6, et employons un modèle de préfixe partagé avec un préfixe de 2001:1::/64. Les trois préfixes « sitescope » FEC0:1000::/64, FEC0:2000::/64 et FEC0:3000::/64 sont employés pour la procédure de détection de mouvement avancée au niveau réseau. Trois ARs sont configurés avec les daemons RADVd qui diffusent
- 17 -
des annonces de Router Advertisement (RAs) sur leur interface eth0. Les messages RAs contiennent deux préfixes et sont périodiquement envoyés à chaque MN toutes les 100 ms. La connectivité logique entre les entités dans le backhaul du réseau maillé est représentée par les liens point-à-point Ns-2 qui sont caractérisés par sa bande passante et son délai. Ceci nous permet d'imposer un délai spécifique dans la transmission des messages entre les entités pour produire les résultats d'émulation les plus proches des vrais résultats d'expérimentation.
Pour supporter le passage à grand échelle avec de multiples clusters, la signalisation supplémentaire est nécessaire. Ceci présente le délai supplémentaire pendant la phase d'établissement de communication. Pour mesurer le délai supplémentaire provoqué par le mécanisme de signalisation, nous utilisons l'outil ping6 et mesurons la période de voyage aller-retour (RTT) du premier paquet dans deux scénarios : (i) itinéraire préétabli sans signaler et (ii) itinéraire sur demande avec la signalisation. Soit r1 la variable aléatoire représentant le RTT du premier paquet de ping6 avec la signalisation, et r2 soit la variable aléatoire représentant le RTT du premier paquet de ping6 avec l'itinéraire préétabli sans signalisation. Dans les deux cas, nous incluons également la période de la procédure Neighbor Unreachability Detection (NUD) entre MNs et leur MAGs servant. Le coût moyen de signalisation en termes de retard peut être estimé comme moyenne (r1) - le moyenne (r2). Nous le mesurons dans les scénarios de intra-cluster et inter-cluster. Dans notre banc de test virtuel, en comparaison le coût de la signalisation et le RTT moyen des paquets de ping6 entre les deux MNs sur 500 échantillons, le délai supplémentaire pour le premier paquet est presque le même que le RTT moyen dans le scénario intra-cluster et est 1.5 fois de RTT moyen dans le scénario inter-cluster. Ce coût est donc tout à fait acceptable, particulièrement quand ce délai supplémentaire se produit une seule fois pour chaque communication.
Quant au délai de handover, nous commençons une session UDP (et dans un autre scénario, nous commençons une session TCP) à partir de MN2 à MN1. Ensuite, nous faisons déplacer le MN1 à partir d'AR1 à AR2 au milieu de la session. Pour émuler le fait que tous les MAGs ont la même adresse MAC partagée comme spécifié dans PMIPv6 de base, nous mettons à jour le cache ARP du MN1 de sorte que l’adresse MAC du AR servant est toujours valide et remplace l’adresse MAC de AR ancien dans la cache de MN1. Nous définissons le délai de handover comme la durée entre le dernier paquet reçu avant le handover et le premier paquet reçu après la procédure Location Registration. Pour la session UDP, le délai de handover mesuré est de 384.55ms. Cette valeur inclut approximativement 260.75 ms pour la détection de mouvement. Nous notons que le délai de handover est beaucoup influencé par la période de détection de mouvement dans ce cas-ci. Un mécanisme de détection de mouvement basé sur la couche 2 devrait considérablement réduire le délai global du handover. En ce qui concerne le trafic TCP, nous voyons qu'il est intéressant d'analyser le graphique de Time-Sequence. Ce graphique est efficace pour analyser le comportement de protocole de TCP et montre implicitement des métriques différentes
- 18 -
telle que la congestion, le RTT, le débit TCP, etc. Nous utilisons l'outil iperf pour produire du trafic TCP, outil tcpdump pour capturer le trafic et l'outil tcptrace pour analyser le trafic de TCP et pour produire des graphiques. Nous constatons qu'une session TCP est plus influencée par la mobilité qu'une session UDP, et cause un plus grand délai de handover, du au contrôle de congestion dans le protocole TCP.
Schéma XIV. CDF de RTT dans des scenarios différents
Nous mettons alors en application et évaluons le RO dans le cadre SPMIPv6. Nous employons ping6 pour mesurer le temps de RTT. Le schéma XIV montre la fonction de distribution cumulative (fonction de répartition) du RTT de 500 échantillons de Echo Request et Echo Response dans quatre cas différents: (i) communication d'intra- cluster sans RO, (ii) communication d'intra-cluster avec le RO, (iii) communication d'inter-cluster sans RO, et (iv) communication d'inter-cluster avec le RO. Les lignes continues représentent le RTT dans des scénarios de communication d'intra-cluster tandis que les lignes tirées représentent le RTT dans des scénarios de communication d'inter-cluster. Nous concluons que PMIPv6 et SPMIPv6 avec le RO peut fournir un plus petit RTT, et peut augmenter le débit TCP résultat.