6.2. Routing Locator Selection (Routing-Locator-Auswahl)

6.2. Routing Locator Selection (Routing-Locator-Auswahl)

Sowohl die Client- als auch die Server-Seite müssen möglicherweise die RLOC-Auswahl kontrollieren, die die andere Seite für Sitzungen verwendet. Dies wird durch Manipulation der Priority- und Weight-Felder in EID-zu-RLOC-Map-Reply-Nachrichten erreicht. RLOC-Informationen können auch aus empfangenen Tunnelpaketen oder EID-zu-RLOC-Map-Request-Nachrichten gesammelt werden.

Mehrere Szenarien für die Auswahl von RLOCs und verfügbare Kontrollen sind wie folgt:

• Die Server-Seite gibt nur einen RLOC zurück. Der Client kann nur diesen RLOC verwenden. Die Server-Seite hat vollständige Kontrolle über die Auswahl.

• Die Server-Seite gibt eine Liste von RLOCs zurück, wobei eine Teilmenge dieselbe optimale Priority hat. Der Client kann nur diese Teilmenge gemäß den von der Server-Seite zugewiesenen Gewichten verwenden. Die Server-Seite kontrolliert sowohl die Teilmenge als auch die Lastverteilung zwischen ihren Mitgliedern. Wenn der Client feststellt, dass die Teilmenge nicht erreichbar ist (es sei denn, die Priority des RLOC ist auf 255 gesetzt), kann er RLOCs außerhalb der Teilmenge verwenden. Die Kontrolle wird teilweise geteilt: Die Server-Seite bestimmt die Liste der Ziel-RLOCs und die Lastverteilung, der Client kann Alternativen wählen, wenn RLOCs in der Liste nicht erreichbar sind.

• Die Server-Seite setzt das Weight einer Teilmenge von RLOCs auf 0. Der Client kann selbst entscheiden, wie er den Verkehr auf die Teilmenge verteilt. Die Server-Seite definiert die Liste, der Client definiert die Lastverteilung. Der Client kann weiterhin andere RLOCs verwenden, wenn die vom Server bereitgestellte Liste nicht erreichbar ist.

• Jede Seite (häufiger die Server-Seite ETR) entscheidet sich, keine Map-Request zu senden. Wenn beispielsweise die Server-Seite ETR keine Map-Request sendet, sammelt sie RLOCs vom Client-ITR, wobei der Client-ITR für die bidirektionale RLOC-Erreichbarkeit und -Präferenz verantwortlich ist. Die Server-Seite ETR sammelt durch Caching der inneren Quell-EID und der äußeren Quell-RLOC der empfangenen Pakete. Der Client-ITR kontrolliert, wie Rückverkehr stattfindet, und kann die äußere Quell-RLOC rotieren lassen, um sich damit der Liste hinzuzufügen, die die Server-Seite ETR für Rückverkehr verwendet. Diese Methode bietet keine Priority oder Weight, die Server-Seite ETR muss annehmen, dass jeder Client-ITR-RLOC dieselbe optimale Priority und ein Gewicht von Null hat. Darüber hinaus können Datenpakete keine EID-Präfix-Kodierung übermitteln, der EID-zu-RLOC-Cache auf Tunnel-Routern kann sehr groß werden.

• "Gesammelte" Map-Cache-Einträge (gelernt aus dem Quell-RLOC empfangener gekapselter Pakete) werden nur für Sekunden gespeichert und verwendet, um auf Verifizierung zu warten. Die Verifizierung erfolgt durch Senden einer Map-Request an die Quell-EID (innere IP-Quelladresse) des empfangenen gekapselten Pakets. Die Antwort auf diese "Verifizierungs-Map-Request" wird verwendet, um den Map-Cache-Eintrag für die "gesammelte" EID vollständig zu füllen und gemäß dem TTL-Feld der empfangenen Map-Reply zu speichern und zu verwenden. Nachdem der verifizierte Eintrag gespeichert wurde, führen nachfolgende Pakete, deren Quell-EID mit dem EID-Präfix des verifizierten Eintrags übereinstimmt, keine Datensammlung mehr durch.

RLOCs, die in einer EID-zu-RLOC-Map-Reply erscheinen, werden als erreichbar angenommen, wenn das R-Bit des Locator-Datensatzes auf 1 gesetzt ist. Wenn das R-Bit 0 ist, DARF ein ITR oder PITR nicht zu diesem RLOC kapseln. Die in einer Map-Reply enthaltenen Informationen oder im Zuordnungsdatenbanksystem gespeicherten Informationen bieten keine Pfaderreichbarkeit für RLOCs. Erreichbarkeit gehört nicht zum Zuordnungssystem und wird durch einen oder mehrere der im nächsten Abschnitt beschriebenen Routing-Locator-Erreichbarkeitsalgorithmen bestimmt.