4.5. Flooding (Inondation)
La majeure partie de l'algorithme d'inondation reste inchangée par rapport aux mécanismes d'inondation IPv4 décrits dans la section 13 de [OSPFV2]. Cependant, l'ajout de la portée d'inondation et du traitement des types de LSA inconnus a causé des changements dans l'algorithme d'inondation OSPF.
4.5.1. Réception des paquets de mise à jour d'état de lien
Pour IPv6, les étapes 2 et 3 sont modifiées comme suit:
(2) Examiner le type LS du LSA. Rejeter le LSA si la zone d'interface a été configurée comme zone stub ou zone NSSA et que le type LS indique "portée d'inondation AS".
(3) Sinon, si la portée d'inondation dans le type LS du LSA est définie sur "réservé", rejeter le LSA.
4.5.2. Envoi de paquets de mise à jour d'état de lien
Pour IPv6, les interfaces éligibles sont sélectionnées en fonction des facteurs suivants:
- La portée d'inondation du LSA
- Si le LSA a un type LS reconnu
- Le paramétrage du bit U dans le type LS
Le choix de l'ensemble des interfaces éligibles se divise en trois cas:
Cas 1: Le type LS du LSA est reconnu. Définir les interfaces éligibles en fonction de la portée d'inondation encodée dans le type LS.
Cas 2: Le type LS n'est pas reconnu et le bit U est défini sur 0. Il y a une seule interface éligible, à savoir l'interface sur laquelle le LSA a été reçu.
Cas 3: Le type LS n'est pas reconnu et le bit U est défini sur 1. Sélectionner les interfaces éligibles en fonction de la portée d'inondation encodée comme dans le cas 1.
4.5.3. Installation des LSA dans la base de données
Il existe trois emplacements distincts pour stocker les LSA, en fonction de leur portée d'inondation:
- Les LSA avec portée d'inondation AS sont stockés dans la structure de données OSPF globale
- Les LSA avec portée d'inondation de zone sont stockés dans la structure de données de zone appropriée
- Les LSA avec portée d'inondation locale au lien sont stockés dans la structure de données d'interface appropriée