Zusammenfassung
- RFC 2103 unterschied zwei unabhängige Folgen von Mobilität: Ein Endpunkt-Locator konnte sich ändern, und die Netztopologie konnte sich ändern. Beides konnte ohne das andere geschehen.
- Ein Dynamic Association Module konnte die Endpunkt–Locator-Zuordnung bei stabiler Topologie erneuern. Bewegte sich ein ganzes Netz, mussten auch Karten und Router mitwirken.
Das wichtigste Feld in RFC 2103s Vier-Fälle-Matrix wirkt zunächst widersprüchlich: Der Locator bleibt gleich, die Topologie ändert sich.
Ein Netzknoten kann neue Nachbarn erhalten und trotzdem im selben übergeordneten Nimrod-Knoten bleiben. Seine Endpunkte behalten ihre Locator. Eine Abfrage liefert somit eine aktuelle und korrekte Zuordnung, während eingehende Pakete eine neue Beschreibung der Konnektivität benötigen. Das Binding stimmt; ein aus der alten Karte berechneter Weg kann trotzdem falsch sein.
Die genaue Grenze der sauberen Abstraktion
RFC 1992 trennte topologisch bedeutungslose Endpunktkennungen von Locatoren, die einen Knoten in einer hierarchischen Karte verorteten. Beim Providerwechsel musste deshalb auch der Locator wechseln; ein altes Präfix in einen anderen Kartenteil mitzunehmen, hätte die Hierarchie abgeflacht.
RFC 2103 machte daraus ein Mobilitätsmodell. Das Dynamic Association Module, kurz DAM, pflegte die veränderliche Beziehung zwischen Endpunkten und Locatoren. Es war weder ein vorgeschriebener Server noch ein umbenanntes DNS, sondern eine Vergleichsabstraktion. Seine Funktion konnte in einer Datenbank, einem Heimatrepräsentanten oder in verteiltem Routerzustand liegen.
Vier Fälle wurden getrennt: Weder Locator noch Topologie ändern sich; nur der Locator ändert sich; nur die Topologie ändert sich; beide ändern sich. Nur der zweite Fall gehört vollständig zur bequemen Geschichte des Rebindings. Im dritten hat das DAM nichts zu aktualisieren, obwohl Nimrods Karte geändert werden muss. Im vierten sind beide Seiten betroffen.
Netzbewegung ließ die Abstraktion auslaufen
RFC 2103 nannte umziehende Organisationen und drahtlose Netze in Zügen, Flugzeugen, Autos oder Schiffen. Wechselt ein Knoten seine Nachbarn, ändert sich der Graph. Verlässt er seinen übergeordneten Knoten, können zusätzlich die Locator seiner Geräte wechseln.
Die gewöhnlichen Topologie-Updates von Nimrod waren wahrscheinlich für langsame Änderungen optimiert. Schnell bewegte Netze könnten besondere Nachrichten an Knotenrepräsentanten benötigen, damit eingehende Pakete der neuen Topologie folgen. Das Dokument spezifizierte diese Interaktion nicht. Es hielt die Konsequenz fest: Netzwerkmobilität konnte eine engere Kopplung von DAM, Routing und Routern verlangen als Endpunktmobilität.
Eine frische Zuordnung beantwortet daher nur, welcher Locator jetzt zu einem Endpunkt gehört. Sie belegt weder aktuelle Nachbarn noch Kartenverteilung, Neuberechnung oder nutzbaren Weiterleitungszustand.
Drei Orte für den Zustand
Eine zentrale, von der Quelle befragte Datenbank war einfach und erlaubte einen direkten Weg. Sie schuf jedoch einen einzelnen Ausfallpunkt und galt nicht als langfristig skalierbar.
Verteilte Pflege mit Remapping am Heimatort entsprach Mobile IP. Die Quelle sendete weiter zur Heimat, ein Repräsentant leitete zum aktuellen Ort um. Das vermied Änderungen an Quellen und gewöhnlichen Routern, bündelte Kontrollverkehr und konnte den Ort verbergen. Dafür entstanden Dreiecks-Routing, Abhängigkeit vom Heimatrepräsentanten und offene Skalierungsfragen. RFC 2103 nannte dies einen brauchbaren ersten Schnitt, nicht die Endlösung.
Die dritte Klasse legte Zustand in Router. Sie war komplexer, eignete sich aber besser für Topologieänderungen. Eine lokale Reaktion wurde möglich, indem gerade jene Nimrod-Komponenten einbezogen wurden, die das DAM ursprünglich aus dem Problem heraushalten sollte.
Mobile IP war Mechanismus, nicht Ergebnis
Die Adaption von RFC 2002 bestand aus Entdeckung, Registrierung und Weiterleitung. Ein mobiler Host registrierte einen Foreign Agent oder transienten Locator beim Home Agent. Dieser speicherte das Binding, fing Pakete ab, kapselte sie und leitete sie zum Foreign Agent. Dort mussten Entkapselung, Visitor-List-Abfrage und Zustellung erst noch gelingen.
Die Registrierung konnte erfolgreich sein und die spätere Weiterleitung scheitern. Ein gecachter Foreign-Agent-Locator konnte veralten. Fehlte der Endpunkt in der Visitor List, sollte der Foreign Agent das Paket verwerfen und einen Fehler zurückgeben. Ein Umweg konnte funktionieren, ohne optimal zu sein. Authentisierung entschied auch nicht über die Berechtigung zum Beitritt in das besuchte Netz.
RFC 2103 unterschied Offline-Mobilität mit abgebrochener Sitzung und Online-Mobilität mit fortgesetzter Sitzung. Online-Unterstützung war wünschenswert, aber für keine konkrete Transportsitzung nachgewiesen. Auch Skalierung blieb ungemessen: Ein System mit Reaktionszeit o versagt bei mehr als 1/o Anschlusswechseln, ohne dass ein Einsatz einen Wert für o lieferte.
Die Dokumentgrenze
Der RFC-Editor-Eintrag und der IETF-Datatracker bewahren ein Informational-Dokument vom Februar 1997. RFC 2103 erklärt, keine Protokollspezifikation zu sein. Deregistrierung, Authentisierungsdetails, schnelle Updates, prädiktives Routing und DAM–Router-Interaktion bleiben offen.
Genau darin liegt die historische Bedeutung. Nimrod trennte Identität, Ort und Routing; RFC 2103 zeigte, wo diese Schichten nicht mehr zusammenpassten. Ein bewegter Endpunkt ließ sich durch eine neue Zuordnung beschreiben. Ein bewegtes Netz änderte den Graphen, der die Zuordnung nutzbar machte.
Lu Hengs Running-Code Primacy, Minimum Initial Specification und Reality Layers dienen hier als offengelegte moderne Deutung, nicht als historische Quelle. Eine Veröffentlichung beschreibt eine Schnittstelle; betriebliche Wahrheit entsteht erst durch implementierte Updates, Routerannahme und beobachtete Pfade.
Die belastbare Aussage bleibt eng: Ein aktuelles Binding belegt ein aktuelles Binding. Für funktionierende Mobilität braucht es zusätzlich Topologierevision, Update-Verteilung, Routenentscheidung, Weiterleitung, Autorisierung, Sitzung und Zustellung.
Quellen
- RFC Editor — RFC-2103-Eintrag
- RFC 2103 — Mobility Support for Nimrod
- IETF Datatracker — RFC 2103
- RFC 1992 — The Nimrod Routing Architecture
- RFC 2102 — Multicast Support for Nimrod
- RFC 2002 — IP Mobility Support
- Lu Heng — Running-Code Primacy
- Lu Heng — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
- Lu Heng — On Reality Layers
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten
