6.3 Purging Stale PMTU Information (Purge des informations PMTU obsolètes)

6.3 Purging Stale PMTU Information (Purge des informations PMTU obsolètes)

La topologie de l'Internet est dynamique; les routes changent au fil du temps. Le PMTU découvert pour une destination donnée peut être incorrect si une nouvelle route entre en usage. Ainsi, les informations PMTU mises en cache par un hôte peuvent devenir obsolètes.

Parce qu'un hôte utilisant PMTU Discovery définit toujours le bit DF, si la valeur PMTU obsolète est trop grande, cela sera découvert presque immédiatement une fois qu'un datagramme est envoyé à la destination donnée. Aucun tel mécanisme n'existe pour réaliser qu'une valeur PMTU obsolète est trop petite, donc une implémentation devrait "vieillir" les valeurs mises en cache. Lorsqu'une valeur PMTU n'a pas été diminuée pendant un certain temps (de l'ordre de 10 minutes), l'estimation PMTU devrait être réglée au MTU de la liaison de données du premier saut, et les couches de paquétisation devraient être notifiées du changement. Cela entraînera à nouveau le processus complet de PMTU Discovery.

Note: une implémentation devrait fournir un moyen de changer la durée du délai d'attente, y compris le régler à "infinity" (infini). Par exemple, les hôtes attachés à un réseau FDDI qui est ensuite attaché au reste de l'Internet via une ligne série lente ne vont jamais découvrir un nouveau PMTU non local, donc ils ne devraient pas avoir à supporter des datagrammes abandonnés toutes les 10 minutes.

Une couche supérieure NE DOIT PAS retransmettre des datagrammes en réponse à une augmentation de l'estimation PMTU, puisque cette augmentation ne vient jamais en réponse à une indication d'un datagramme abandonné.

Une approche pour implémenter le vieillissement PMTU consiste à ajouter un champ d'horodatage à l'entrée de table de routage. Ce champ est initialisé à une valeur "reserved" (réservée), indiquant que le PMTU n'a jamais été changé. Chaque fois que le PMTU est diminué en réponse à un message Datagram Too Big, l'horodatage est réglé à l'heure actuelle.

Une fois par minute, une procédure pilotée par temporisateur parcourt la table de routage, et pour chaque entrée dont l'horodatage n'est pas "reserved" et est plus ancien que l'intervalle de délai d'attente:

• L'estimation PMTU est réglée au MTU du premier saut associé.

• Les couches de paquétisation utilisant cette route sont notifiées de l'augmentation.

Les estimations PMTU peuvent disparaître de la table de routage si les routes par hôte sont supprimées; cela peut se produire en réponse à un message ICMP Redirect (redirection), ou parce que certains démons de table de routage suppriment les anciennes routes après plusieurs minutes. De plus, sur un hôte multi-hébergé, un changement de topologie peut entraîner l'utilisation d'une interface source différente. Lorsque cela se produit, si la couche de paquétisation n'est pas notifiée, elle peut continuer à utiliser une valeur PMTU mise en cache qui est maintenant trop petite. Une solution consiste à notifier la couche de paquétisation d'un changement PMTU possible chaque fois qu'un message Redirect provoque un changement de route, et chaque fois qu'une route est simplement supprimée de la table de routage.

Note: une méthode plus sophistiquée pour détecter les augmentations PMTU est décrite dans la section 7.1.