5. Modèle conceptuel d'un hôte (Conceptual Model of a Host)
Bien qu'il ne soit pas requis que les implémentations se conforment à un modèle conceptuel spécifique d'un hôte, cette section décrit un modèle conceptuel qui peut être utilisé par les hôtes pour aider à comprendre Neighbor Discovery. Un hôte maintient conceptuellement un certain nombre de structures de données :
Cache de voisins (Neighbor Cache) - Un ensemble d'entrées sur les voisins individuels auxquels du trafic a été envoyé récemment. Les entrées sont indexées sur l'adresse IP unicast on-link du voisin et contiennent des informations telles que son adresse de couche liaison, un drapeau indiquant si le voisin est un routeur ou un hôte (appelé IsRouter dans ce document), un pointeur vers tous les paquets mis en file d'attente en attendant que la résolution d'adresse se termine, etc. Une entrée de cache de voisins contient également des informations utilisées par l'algorithme de détection d'inaccessibilité des voisins, y compris l'état d'accessibilité, le nombre de sondes sans réponse et l'heure à laquelle le prochain événement de détection d'inaccessibilité des voisins doit avoir lieu.
Cache de destination (Destination Cache) - Un ensemble d'entrées sur les destinations vers lesquelles du trafic a été envoyé récemment. Le cache de destination inclut à la fois les destinations on-link et off-link et fournit un niveau d'indirection dans le cache de voisins ; le cache de destination mappe une adresse IP de destination à l'adresse IP du voisin de prochain saut. Contrairement au cache de voisins, le cache de destination contient des entrées pour les destinations on-link et off-link. Maintenir un cache de destination séparé du cache de voisins remplit plusieurs objectifs. Premièrement, le cache de destination peut contenir des entrées pour des destinations qui ne sont pas adjacentes sur la liaison. Deuxièmement, le cache de destination peut contenir des entrées qui sont soumises à la découverte du MTU de chemin, aux messages de redirection, etc.
Liste de préfixes (Prefix List) - Une liste des préfixes qui définissent un ensemble d'adresses qui sont on-link. Les entrées de la liste de préfixes sont créées à partir d'informations reçues dans les Router Advertisements. Chaque entrée a une valeur de temporisateur d'invalidation associée (extraite de l'annonce) utilisée pour expirer les préfixes. Une entrée de liste de préfixes contient également un drapeau indiquant si le préfixe peut être utilisé pour la détermination on-link et/ou l'autoconfiguration d'adresse, comme spécifié dans [ADDRCONF].
Liste de routeurs par défaut (Default Router List) - Une liste de routeurs auxquels des paquets peuvent être envoyés. Les entrées de la liste de routeurs par défaut pointent vers des entrées dans le cache de voisins ; l'algorithme de sélection d'un routeur par défaut favorise les routeurs connus pour être accessibles par rapport à ceux dont l'accessibilité est suspecte. Chaque entrée a également une valeur de temporisateur d'invalidation associée (extraite des Router Advertisements) utilisée pour supprimer les entrées qui ne sont plus annoncées.
Les structures de données conceptuelles décrites ci-dessus sont fonctionnellement séparées ; les implémentations sont libres de combiner certaines ou toutes d'entre elles de la manière la plus pratique. Les exigences de ce protocole peuvent être satisfaites de manière simple grâce à l'utilisation des structures de données ci-dessus dans le pseudocode des sections suivantes. Cependant, une implémentation est libre d'utiliser des structures de données alternatives tant que le comportement externe de l'implémentation reste inchangé.
5.1. Structures de données conceptuelles (Conceptual Data Structures)
Bien qu'il ne soit pas nécessaire que les hôtes maintiennent toutes les structures de données décrites ci-dessous, cette section décrit un ensemble de structures de données suffisantes pour implémenter Neighbor Discovery.
5.2. Algorithme d'envoi conceptuel (Conceptual Sending Algorithm)
Lorsqu'un nœud a un paquet à envoyer, il examine d'abord le cache de destination. Si aucune entrée n'existe pour la destination, le nœud en crée une et initialise son adresse de prochain saut en invoquant l'algorithme de détermination du prochain saut (Section 5.2). Une fois qu'une entrée de cache de destination a été créée, le nœud examine ensuite l'état de l'entrée de cache de voisins pour le prochain saut.
Une entrée de cache de voisins peut être dans l'un des cinq états :
INCOMPLETE (incomplet) - La résolution d'adresse est actuellement en cours sur l'entrée. Plus précisément, un Neighbor Solicitation a été envoyé à l'adresse multicast solicited-node de la cible, mais le Neighbor Advertisement correspondant n'a pas encore été reçu.
REACHABLE (accessible) - L'entrée est connue pour avoir été accessible récemment (il y a quelques dizaines de secondes). Une confirmation positive a été reçue au cours des dernières ReachableTime millisecondes que le chemin avant vers le voisin fonctionnait correctement. En état REACHABLE, aucune action spéciale n'a lieu lorsque des paquets sont envoyés.
STALE (périmé) - L'entrée est connue pour avoir été accessible récemment, mais aucune confirmation n'a été reçue récemment. En état STALE, aucune action n'a lieu jusqu'à ce qu'un paquet soit envoyé. Lorsqu'un paquet est envoyé, un nœud fait passer l'entrée à l'état DELAY ou PROBE, selon l'implémentation.
DELAY (délai) - L'entrée est connue pour avoir été accessible récemment, et un paquet a été envoyé au cours des dernières DELAY_FIRST_PROBE_TIME secondes. Si aucune confirmation d'accessibilité n'est reçue dans les DELAY_FIRST_PROBE_TIME secondes suivant l'entrée dans l'état DELAY, envoyez un Neighbor Solicitation et changez l'état en PROBE. Retarder la transmission de la sonde donne l'occasion aux protocoles de couche supérieure de fournir une confirmation d'accessibilité.
PROBE (sonde) - Une confirmation d'accessibilité est activement recherchée en retransmettant des Neighbor Solicitations toutes les RetransTimer millisecondes jusqu'à ce qu'une confirmation d'accessibilité soit reçue.
Le cache de voisins contient également des informations nécessaires pour exécuter l'algorithme de détection d'inaccessibilité des voisins, y compris divers temporisateurs, compteurs, etc.
Lors de l'envoi d'un paquet à un voisin, un nœud utilise les informations d'état contenues dans l'entrée du cache de voisins pour déterminer ce qui, le cas échéant, doit être fait avant d'envoyer du trafic à ce voisin. Le pseudocode suivant illustre l'algorithme d'envoi :
if (l'entrée de cache de destination existe) {
next hop = next_hop du cache de destination;
} else {
next hop = Détermination du prochain saut (Section 5.2);
créer une entrée de cache de destination;
}
if (l'entrée de cache de voisins existe pour next hop) {
if (état de l'entrée de cache de voisins == INCOMPLETE) {
mettre le paquet en file d'attente sur l'entrée de cache de voisins;
/* La résolution d'adresse est déjà en cours */
}
if (état de l'entrée de cache de voisins == REACHABLE) {
envoyer le paquet;
}
if (état de l'entrée de cache de voisins == STALE) {
envoyer le paquet;
définir l'état de l'entrée de cache de voisins à DELAY;
définir le temporisateur de l'entrée de cache de voisins à DELAY_FIRST_PROBE_TIME;
}
if (état de l'entrée de cache de voisins == DELAY) {
envoyer le paquet;
/* le temporisateur est déjà défini */
}
if (état de l'entrée de cache de voisins == PROBE) {
envoyer le paquet;
/* La détection d'inaccessibilité des voisins est en cours */
}
} else {
créer une entrée de cache de voisins;
définir l'état de l'entrée de cache de voisins à INCOMPLETE;
if (l'adresse de couche liaison est facilement disponible) {
définir l'adresse de couche liaison;
définir l'état de l'entrée de cache de voisins à STALE;
envoyer le paquet;
} else {
mettre le paquet en file d'attente sur l'entrée de cache de voisins;
démarrer la résolution d'adresse;
}
}
5.3. Exigences de collecte des déchets et de délai d'expiration (Garbage Collection and Timeout Requirements)
Le cache de voisins, le cache de destination et la liste de préfixes doivent faire l'objet d'une collecte des déchets et expirer. Cependant, les périodes de délai d'expiration spécifiques ne sont délibérément pas spécifiées. Les périodes de délai d'expiration doivent être choisies pour fournir un équilibre raisonnable entre le maintien d'informations périmées et le coût de la mise à jour de ces informations. En général, les périodes de délai d'expiration devraient être suffisamment généreuses pour empêcher l'agitation du contenu du cache mais suffisamment courtes pour empêcher l'obsolescence à long terme.
Une implémentation conceptuelle pourrait utiliser les règles suivantes :
-
Les entrées de cache de voisins devraient (SHOULD) rester pendant au moins un temps spécifié par ReachableTime après leur transition vers l'état STALE. Cependant, elles peuvent rester plus longtemps si l'implémentation utilise une forme d'algorithme de collecte des déchets pour récupérer les entrées. Les entrées dans l'état INCOMPLETE n'ont pas besoin de rester pendant une telle période prolongée.
-
Les entrées de cache de destination devraient (SHOULD) rester dans le cache aussi longtemps que possible (c'est-à-dire indéfiniment). Cependant, la période de temps spécifique dépend de l'implémentation. Les implémentations DEVRAIENT (SHOULD) invalider une entrée de cache de destination si un message de redirection spécifiant une meilleure route vers la destination est reçu.
-
Les entrées de la liste de préfixes expirent conformément à la durée de vie spécifiée dans les Router Advertisements. La durée de vie d'une entrée est mise à jour lorsqu'un nouveau Router Advertisement arrive.
-
Les entrées de la liste de routeurs par défaut expirent conformément à la durée de vie du routeur spécifiée dans les Router Advertisements. Les Router Advertisements reçus avec une durée de vie de routeur de zéro indiquent que le routeur doit être retiré de la liste de routeurs par défaut immédiatement.