6.3.2. RLOC-Probing Algorithm (RLOC-Probing-Algorithmus)
6.3.2. RLOC-Probing Algorithm (RLOC-Probing-Algorithmus)
RLOC-Probing ist eine Methode, die ein ITR oder PITR verwenden kann, um den Erreichbarkeitsstatus eines oder mehrerer Lokatoren zu bestimmen, die in einem Map-Cache-Eintrag gecacht sind. Das Probe-Bit in Map-Request- und Map-Reply-Nachrichten wird für RLOC-Probing verwendet.
RLOC-Probing wird auf der Kontrollebene zeitgesteuert durchgeführt, wobei ein ITR oder PITR eine Map-Request von einer seiner Locator-Adressen an eine Locator-Adresse sendet. Eine als RLOC-Probe verwendete Map-Request wird nicht gekapselt und nicht wie bei der Anforderung von Zuordnungsdaten an einen Map-Server oder ein Zuordnungsdatenbanksystem gesendet. Der im Nachricht kodierte EID-Datensatz ist das EID-Präfix des Map-Cache-Eintrags, den der ITR oder PITR gecacht hat. Der ITR kann Zuordnungsdateneinträge seiner eigenen Datenbank-Zuordnungsinformationen einschließen, die das lokale EID-Präfix und RLOCs dieser Site enthalten. RLOC-Probes werden periodisch mit Timer-Intervallen mit Jitter gesendet.
Wenn ein ETR eine Map-Request mit gesetztem Probe-Bit empfängt, gibt er eine Map-Reply mit gesetztem Probe-Bit zurück. Die Quelladresse der Map-Reply wird gemäß den in Abschnitt 6.1.5 beschriebenen Verfahren gesetzt. Die Map-Reply sollte Zuordnungsdaten für das EID-Präfix enthalten, das in der Map-Request enthalten war. Dies gibt dem ITR oder PITR, der RLOC-Probes sendet, die Möglichkeit, Zuordnungsaktualisierungen zu erhalten, wenn sich die Datenbank-Zuordnungseinträge des ETR geändert haben.
RLOC-Probing hat Vor- und Nachteile. Sein größter Vorteil besteht darin, dass es mit mehreren Fehlerszenarien umgehen kann und es einem ITR ermöglicht, zu bestimmen, ob der Pfad zu einem bestimmten Locator erreichbar oder unerreichbar geworden ist, und somit einen robusten Mechanismus zum Wechseln zwischen gecachten Lokatoren bietet. RLOC-Probing kann auch eine grobe Schätzung der Round-Trip Time (RTT) zwischen einem Locator-Paar liefern, was für Netzwerkverwaltung und Auswahl von Pfaden mit geringer Latenz nützlich ist. Der Hauptnachteil sind die Anzahl der Kontrollnachrichten und der Bandbreiten-Overhead, die erforderlich sind, um die oben genannten Vorteile zu erzielen, insbesondere wenn sehr kurze Fehlererkennungszeiten erforderlich sind.
Laufende Forschung und Tests werden versuchen, den Kompromiss zwischen Fehlererkennungszeit und Nachrichten-Overhead zu charakterisieren.