6.2. Routing Locator Selection (Sélection de localisateur de routage)
6.2. Routing Locator Selection (Sélection de localisateur de routage)
Les côtés client et serveur peuvent vouloir contrôler la sélection des RLOCs utilisés pour les sessions entre eux. Cela se fait en manipulant les champs Priority et Weight dans les messages Map-Reply EID vers RLOC. Les informations de RLOC peuvent également être glanées à partir de paquets tunnelisés reçus ou de messages Map-Request EID vers RLOC.
Plusieurs scénarios de sélection de RLOC et les contrôles disponibles sont les suivants:
o Le côté serveur ne retourne qu'un seul RLOC. Le client ne peut utiliser que ce RLOC. Le serveur a le contrôle total sur la sélection.
o Le côté serveur retourne une liste de RLOCs où un sous-ensemble a la même Priority optimale. Le client ne peut utiliser que ce sous-ensemble selon les poids attribués par le serveur. Le serveur contrôle à la fois le sous-ensemble et la répartition de charge entre ses membres. Si le client détermine que le sous-ensemble est inaccessible (à moins que la Priority du RLOC ne soit fixée à 255), il peut utiliser des RLOCs en dehors du sous-ensemble. Le contrôle est partagé: le serveur décide de la liste de RLOCs de destination et de la distribution de charge, le client peut sélectionner des alternatives lorsque les RLOCs de la liste sont inaccessibles.
o Le côté serveur définit le Weight d'un sous-ensemble de RLOCs à 0. Le client peut décider lui-même comment répartir le trafic sur le sous-ensemble. Le serveur définit la liste, le client définit la distribution de charge. Le client peut toujours utiliser d'autres RLOCs lorsque la liste fournie par le serveur est inaccessible.
o L'une ou l'autre partie (plus communément l'ETR côté serveur) décide de ne pas envoyer de Map-Request. Par exemple, lorsque l'ETR côté serveur n'envoie pas de Map-Request, il glane le RLOC de l'ITR côté client, laissant l'ITR côté client responsable de la joignabilité et de la préférence bidirectionnelles des RLOCs. L'ETR côté serveur glane en mettant en cache l'EID source interne et le RLOC source externe des paquets reçus. L'ITR côté client contrôle la manière dont le trafic de retour est dirigé, et peut alterner l'utilisation du RLOC source externe, l'ajoutant ainsi à la liste utilisée par l'ETR côté serveur pour le trafic de retour. Cette méthode ne fournit pas de Priority ou Weight, et l'ETR côté serveur doit supposer que chaque RLOC d'ITR client a la même Priority optimale avec un Weight de zéro. De plus, les paquets de données ne peuvent pas transmettre un encodage EID-Prefix, et le cache EID vers RLOC sur le Tunnel Router peut devenir très volumineux.
o Les entrées Map-Cache "glanées" (apprises à partir du RLOC source des paquets encapsulés reçus) ne sont stockées et utilisées que pendant quelques secondes en attendant une vérification. La vérification est effectuée en envoyant un Map-Request à l'EID source (adresse IP source interne) du paquet encapsulé reçu. La réponse à ce "Map-Request de vérification" est utilisée pour remplir complètement l'entrée Map-Cache pour l'EID "glané" et est stockée et utilisée selon le champ TTL du Map-Reply reçu. Une fois l'entrée vérifiée stockée, les paquets ultérieurs dont l'EID source correspond à l'EID-Prefix de l'entrée vérifiée ne provoquent plus de glanage de données.
Un RLOC qui apparaît dans un Map-Reply EID vers RLOC est supposé joignable lorsque le bit R de l'enregistrement Locator est défini sur 1. Lorsque le bit R est 0, un ITR ou PITR NE DOIT PAS encapsuler vers ce RLOC. Les informations contenues dans le Map-Reply ou stockées dans le système de base de données de mappages ne fournissent pas la joignabilité du chemin vers le RLOC. La joignabilité n'appartient pas au système de mappages et est déterminée par un ou plusieurs des algorithmes de joignabilité de localisateur de routage décrits dans la section suivante.