-
HINTERGRUND DER ERFINDUNG
-
Gebiet der Erfindung
-
Die
vorliegende Erfindung betrifft das Wechseln von Übertragungsverbindungen in
einem Kommunikationsnetzwerk und spezieller den Wechsel bestehender
Sitzungen über
Adressen in einem Paketnetzwerk.
-
Beschreibung des Standes der Technik
-
Mit
dem Wachstum und der starken Zunahme von mobilen und drahtlosen
Rechner-Einrichtungen (mobilen Einrichtungen), die auf das Internet
zugreifen, ist eine Infrastruktur erforderlich, die einen reibungslosen
Wechsel über
Internet-Protokoll-(IP)-Subnetzwerke
(Subnetze) unterstützt.
Viele Benutzer verwenden ein dynamisches Host-Konfigurations-Protokoll (DHCP),
um eine IP-Adresse für
Verbindungen zu erhalten, aber die Verwendung von DHCP bietet nur
Portabilität
und liefert keine relative Transparenz für einen reibungslosen Bereichswechsel.
Jede Bewegung einer mobilen Einrichtung über ein IP-Subnetz erfordert
zuerst die Freigabe der alten IP-Adresse
und dann die Erlangung einer neuen IP-Adresse, was zum Verlust von Übertragungs-Verbindungen
(und Verbindungen höherer
Ebenen) führt.
-
Die
normale Netzwerk-Kommunikation zwischen zwei Einheiten umfasst die
Festlegung einer eindeutigen Endpunkt-Kennung, wie z. B. einer IP-Adresse,
die sich während
der Kommunikationsdauer nicht ändert. Zum
Beispiel beginnt eine typische Übertragungs-Steuerungs-Protokoll-(TCP)-Verbindungsaufbau-Prozedur zwischen
zwei Endpunkten (z. B. Rosts) damit, dass die Anwendungen ein Socket-Anwendungs-Programmierungs-Schnittstellen-(API)-Paket
benutzen. Jede Socket-API ist explizit auf ein gegebenes 5-Tupel
begrenzt, das die folgenden fünf
Elemente umfasst. Das erste Element ist das "Protokoll"-Element, welches das spezielle Kommunikations-Protokoll für das Paket
kennzeichnet. Das zweite Element ist das Element "Source IP address", das die IP-Adresse
des Quell-Knotens,
von dem das Paket stammt, kennzeichnet. Das dritte Element ist das
Element "Source
Transport Port",
das den Anschluss des Quell-Knotens, von dem das Paket stammt, kennzeichnet.
Das vierte Element ist das Element "Destination IP Address", das die IP-Adresse
des Ziel-Knotens, der das Paket empfängt, kennzeichnet. Das fünfte Element
ist das Element "Destination
Transport Port",
das den Anschluss des Ziel-Knotens, der das Paket empfängt, kennzeichnet.
Alle Änderungen
eines beliebigen dieser 5-Tupel-Elemente während einer Sitzung werden
einen Sitzungs-Fehler verursachen und typischerweise einen erneuten
Aufbau der Verbindung auslosen.
-
Bei
gegebener 5-Tupel-Struktur werden im Folgenden der Aufbau und die
Aufrechterhaltung einer Verbindung in derzeitigen TCP-kompatiblen
Paketnetzwerken beschrieben. Die Verbindungsaufbau-Prozedur einer
TCP-Engine umfasst eine Sequenz von ausgetauschten Nachrichten zwischen
einem Client (erster Endpunkt) und einem Server (zweiter Endpunkt).
Der Client beginnt mit dem Senden einer SYN-Nachricht an den Server,
und der Client empfängt
als Antwort eine Nachricht SYN-ACK vom Server. Der Client antwortet
als Quittung dem Server mit einer ACK-Nachricht, und die Verbindung
zwischen dem Client und dem Server ist dann geöffnet und voll funktionsfähig. Die
TCP-Engine an beiden Enden der Verbindung geht in den Zustand ESTABLISHED,
wobei die Zustandsinformation im TCP-Steuerblock (TCB) im Betriebssystemkern
gespeichert wird. Die TCP-Sitzung ist nun eindeutig im Netzwerk
durch das 5-Tupel identifizierbar, das in den IP-Datagrammen (Paketkopf-Teilen) enthalten
ist, die das Netzwerk durchlaufen. Aus der Sicht der Anwendung und des
Betriebssystems kann diese Sitzung eindeutig durch den Socket identifiziert
werden, der dieser Sitzung zugeordnet ist. Jede Änderung auch nur eines der
Elemente des 5-Tupels führt
zu einem Sitzungs-Fehler.
-
Ein
TCP-Sitzungs-Fehler tritt auf, wenn TCP die Sitzung abbricht und
die zugehörigen
Socket-Bindungen schließt.
Es gibt viele Gründe,
warum TCP eine Verbindung abbricht, einige davon sind: 1) Empfang
eines Paketes TCP RST (Reset) vom entfernten Ende; 2) Überschreitung
der Anzahl von Neuübertragungs-Versuchen,
die im Protokoll definiert sind; 3) zu viele unquittierte "Keep-alive"-Probe-Pakete; 4)
Aufforderung durch die Anwendung; und 5) eine anormale externe Bedingung.
Diese TCP-Reset-Bedingungen treten im Normalbetrieb eines Paketnetzwerks
routinemäßig auf
und können
durch Änderung
der Schnittstellen-IP-Adresse, ausgedehnte Zeiten des Verbindungsverlustes,
Host-Ausfälle/Neustarts
oder ähnliche
Beiträge
zu einem TCP-Verbindungsfehler entstehen.
-
Da
die Anwendung, die die TCP-Übertragungs-Sitzung
benutzt, an den Socket mit dem ursprünglichen 5-Tupel (mit der alten
IP-Adresse) gebunden ist, wird durch Ändern der IP-Adresse der Schnittstelle
die zugehörige
Socket-Bindung der Anwendung nicht geändert. Alle Benutzerdaten,
die von der Anwendung an den Kernel gesendet werden, werden in der
TCP-Ebene als Transportschicht-Segmente
in der TCP-Sende-Warteschlange
(send-Q) gespeichert, weil es keine gültige Ausgabe-Schnittstelle
mit der alten IP-Adresse gibt, auf der die Daten gesendet werden
können.
Der Neusende-Mechanismus von TCP versucht, diese Daten erneut auszusenden,
bis eine gültige
Route/Schnittstelle erscheint oder ein Timeout der Verbindung selbst
auftritt. Wenn zwischen den beiden End-Systemen keine Erreichbarkeit
vorliegt, bleibt der TCP-Zustand auf jeder Seite (normalerweise)
in seinem vorherigen Zustand (z. B. bleiben beide Seiten im Zustand
ESTABLISHED). Wenn die IP-Adresse
der Schnittstelle auf ihre ursprüngliche
Adresse (dadurch das ursprüngliche
5-Tupel) zurückkehrt,
wird die Kommunikation zwischen den Endpunkt-Anwendungen wieder
aufgenommen, vorausgesetzt, es ist eine Route vorhanden. Wenn sich
jedoch die IP-Adresse der Schnittstelle ändert, werden alle vom entfernten
Host empfangenen Datenpakete auf der IP- Ebene verworfen, da es keine gültige Schnittstelle
gibt, die den Daten zuzuordnen ist. Sowohl am lokalen Ende, als
auch am entfernten Ende tritt abhängig von deren TCP-Zustand
ein Timeout der entsprechenden Verbindungen auf.
-
Der
Prozess zum Aufbau und zur Aufrechterhaltung von Sitzungen ist restriktiv
und setzt Grenzen für bestimmte
Arten von Anwendungen, wie z. B. Teilnehmer-Mobilität oder fehlertolerante
Verbindungen. Mobile IP nach dem Stand der Technik wurde entwickelt,
um Host-Mobilität
zu erreichen, indem diese Einschränkungen unter Verwendung von
Routing-Techniken
in der Netzwerkschicht umgangen werden. Entsprechend Mobile IP muss,
damit ein Knoten seinen Zugangspunkt ändern kann, ohne seine Fähigkeit
zu kommunizieren zu verlieren, zurzeit typischerweise einer der
folgenden Mechanismen verwendet werden: Entweder 1) der Knoten muss
seine IP-Adresse ändern,
wenn er seinen Zugangspunkt ändert,
oder 2) es müssen
für den
Host spezifische Routen im Großteil
des Internet-Koppelbausteins
verbreitet werden. Beide diese Alternativen sind oft nicht akzeptierbar.
Der erste Mechanismus macht es einem Knoten unmöglich, Verbindungen auf Übertragungs-Ebene
und auf höheren
Ebenen aufrecht zu erhalten, wenn der Knoten den Standort wechselt.
Der zweite Mechanismus zeigt schwere Skalierungs-Probleme, die insbesondere
relevant sind, wenn man das explosive Wachstum des Verkaufs von
(mobilen) Notebook-Computern
berücksichtigt.
-
Im
Stand der Technik gibt es viele Verfahren, die vorgeschlagen wurden,
um Probleme der Host-Mobilität
und der Ausfallsicherheit zu verringern. Diese Verfahren können in
die klassifiziert werden, die eine Lösung für die Netzwerkschicht (z. B.
IP-Schicht), die Transportschicht (z. B. TCP/UDP (User Datagram
Protocol)) oder höherer
Ebenen (z. B. Socket- oder Anwendungsschicht) liefern.
-
Mobile
IP, wie in "Mobile
IP", IEEE Communications
Magazine, Mai 1997, Seite 84–99
beschrieben, unternimmt den Versuch, Probleme der Host-Mobilität auf der
Netzwerk-Ebene zu lösen,
indem ein Grad von Routing-Umwegen oder Dreieck-Routing aller Pakete
von einem entsprechenden Host zu einem mobilen Knoten verwendet
wird. Diese Routing-Umwege werden durch Verwendung von "Home Agents" und "Foreign Agents" erreicht, die Proxies
sind, welche Dienste für
den mobilen Knoten bereitstellen. Obwohl Mobile IP die Host-Mobilität und Erreichbarkeits-Probleme
gut behandelt, behandelt es keine Fehler von Übertragungsverbindungen (z.
B. wenn Änderungen
der Übertragungs-Endpunkte
zu einem Sitzungs-Fehler führen).
Typischerweise müssen
Anwendungen abhängig
von den Verbindungsmöglichkeiten
der Übertragungs-Sitzung neu
gestartet und eine neue Übertragungsverbindung
aufgebaut werden. Andere Nachteile von Mobile IP sind ein nicht
optimales Dreieck-Routing und ein umfangreicher Einsatz von IP-Tunneling.
Aus Sicherheitsgründen verbieten
Dienstanbieter typischerweise getunnelte Pakete. Wegen der erhöhten Häufigkeit
von Denial-Of-Service-(DOS)-Angriffen benutzen Dienstanbieter außerdem Eingangs-Filter,
um Pakete zu blockieren, die Quell-Adressen fälschen. Obwohl dieses Problem
der Eingangs-Filterung gelöst
werden kann, indem Rückwärts-Tunneling benutzt
wird, führt
Rückwärts-Tunneling
zu einer weiteren suboptimalen Verwendung von Vernetzungs-Ressourcen
und fügt
zusätzliche
Paket-Verzögerungen
zwischen zwei Endpunkten hinzu.
-
Verfahren,
die den Versuch unternehmen, das Problem der Ende-zu-Ende-Host-Mobilität auf der Übertragungs-Ebene
oder auf höheren
Ebenen zu lösen,
gehen typischerweise wie folgt vor: 1) Aufteilung der Verbindung
in mehrere Segmente, 2) Änderung
einer Standard-TCP-Implementation durch Hinzufügung neuer Nachrichten und
Zustände
zum TCP-Zustandsautomaten, oder 3) überlisten der Anwendung, so
dass sie glaubt, dass die Verbindung noch besteht, während versucht
wird, die Verbindung neu aufzubauen, wie zum Beispiel in Su, G.
und Nieh, J.: "Mobile
Communication with Virtual Network Address Translation" Feb. 2002, TR CUCS-003-02,
Department of Computer Science, Columbia University, XP002286437
offen gelegt.
-
Zum
Beispiel verwenden MSOCKS (Mobile Sockets) einen Proxy für Verbindungs-Teilung
zur Umleitung einer Verbindung. MSOCKS fügen einen Proxy in den Kommunikations-Pfad
zwischen den mobilen Knoten und seine entsprechenden Hosts ein und
benutzten einen TCP-Spleiß-Mechanismus,
um die Verbindung in mehrere Segmente aufzuteilen und somit die
Mobilitäts-Probleme
des mobilen Knotens vor den entsprechenden Hosts zu verstecken.
Durch die Hinzufügung
eines Kommunikations-Pfad-Proxy
kann sich der Dienst jedoch beträchtlich
verschlechtern.
-
Einige
Verfahren umfassen die Einführung
einer Bibliothek zwischen der Anwendung und der Socket-API, die
die Illusion einer einzigen, nicht unterbrochenen Verbindung über aufeinander
folgende Verbindungs-Instanzen aufrechterhält. All diese Lösungen erfordern
es, die Anwendung mit ihren (speziellen) Bibliotheken zu verbinden.
Die Illusion einer nicht unterbrochenen Verbindung erhält man,
indem man die Anwendung so überlistet,
dass sie glaubt, die Übertragungs-Sitzung ist noch
aktiv, obwohl die Übertragungs-Sitzung geschlossen
wurde. Die Zwischen-Bibliothek versucht dann, die (neue) Übertragungs-Verbindung
erneut aufzubauen und bildet die neue Übertragungs-Verbindung auf
die Anwendung ab, die sie benutzt. Die Implementation und die damit
verbundenen Schwierigkeiten im Betrieb solcher Lösungen umfassen Virtualisierungs-Mechanismen,
wie I/O-Polling, asynchrone und blockierungsfreie I/O-Prozesse,
der Bedarf an Timern und Signal-Handlern, und der Bedarf an zusätzlichen
Prozesssteuerungs-Schnittstellen, wie "wait", "kill" und "exec".
-
Ein
anderes Verfahren liefert einen Mechanismus zum Erreichen der Ende-zu-Ende-Host-Mobilität durch Änderung
des Übertragungs-Ebenen-Protokolls
und der End-Anwendungen. Die Änderung
fügt neue Zustände und
Semantiken zum endlichen TCP-Zustandsautomaten
hinzu und definiert neue TCP-Optionen, um die Migration der Verbindung
auszuhandeln. Es gibt weitere Verfahren, bei denen entweder der
TCP-Kopf, das Paketformat, die Protokoll-Semantik geändert werden,
oder zusätzliche
Kopfinformationen in den Paketen hinzugefügt werden. Der Nachteil dieser
Techniken ist jedoch, dass die Endbenutzer-Anwendungen die neue Funktion kennen
müssen,
um sie zu nutzen, was eine Änderung
der vorhandenen Anwendungen erforderlich macht.
-
In
einer Ausführung
liefert die vorliegende Erfindung ein Verfahren, um während einer
Sitzung zwischen einem Migrator und einem Nicht-Migrator in einem
auf Paketen basierenden Kommunikationssystem von einer aktuellen
Migrator-Endpunkt-Adresse
zu einer neuen Migrator-Endpunkt-Adresse zu wechseln. Ein Migrator
ist ein Endpunkt, der eine Adresse hat, die während der Sitzung von der aktuellen
Migrator-Endpunkt-Adresse
zu der neuen Migrator-Endpunkt-Adresse wechselt, und ein Nicht-Migrator
ist ein Endpunkt, der eine Adresse hat, die sich während der
Sitzung nicht ändert.
Das Verfahren umfasst den Schritt a) Im Migrator Ändern der
aktuellen Migrator-Endpunkt-Adresse
auf die neue Migrator-Endpunkt-Adresse durch die Schritte a1) Senden
einer Registrierungs-Anforderungs-Steuerungs-Nachricht an den Nicht-Migrator über einen
Außerband-Kanal,
um den Migrator beim Nicht-Migrator zu registrieren, a2) Empfangen
einer Registrierungs-Antwort-Steuerungs-Nachricht
vom Nicht-Migrator über
den Außerband-Kanal als Quittung
der Registrierung beim Nicht-Migrator, a3) nachdem die Schritte
a1) und a2) ausgeführt
wurden, logisches Umschalten auf die neue Migrator-Endpunkt-Adresse
durch Wechsel von einem aktuellen 5-Tupel, das die aktuelle Migrator-Endpunkt-Adresse
enthält,
auf ein neues 5-Tupel, das die neue Migrator-Endpunkt-Adresse enthält, und
a4) Aktualisierung einer Kernel-Struktur des Migrators durch Ändern eines
Socket mit dem neuen 5-Tupel, um das neue 5-Tupel wiederzugeben,
wobei der Socket der Sitzung zugeordnet ist. Das Verfahren umfasst
ferner die Schritte b) Einstellen der Übertragung von Paketen mit
der neuen Migrator-Endpunkt-Adresse
zum Nicht-Migrator, und c) Informieren des Nicht-Migrators über den Außerband-Kanal, der von dem
Kanal der Sitzung zwischen dem Migrator und dem Nicht-Migrator getrennt
ist, über
die Änderung
auf die neue Migrator-Endpunkt-Adresse durch die Schritte c1) Senden
einer Steuerungs-Nachricht an den Nicht-Migrator, die den Nicht-Migrator
von der Änderung
auf die neue Migrator-Endpunkt-Adresse informiert, und c2) Empfangen
der Bestätigung
vom Nicht-Migrator, dass der Nicht-Migrator die neue Migrator-Endpunkt-Adresse
geändert
hat. Das Verfahren umfasst ferner den Schritt d) der Wiederaufnahme
der Übertragung
von Paketen mit der neuen Migrator-Endpunkt-Adresse zum Nicht-Migrator.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
Weitere
Aspekte, Eigenschaften und Vorteile der vorliegenden Erfindung werden
aus der folgenden detaillierten Beschreibung, den beigefügten Ansprüchen und
den begleitenden Zeichnungen offensichtlich, in denen:
-
1 eine
nahtlose Übertragungs-Endpunkt-Mobilitäts-Architektur (Seamless
Transport Endpoint Mobility, STEM) für zwei Knoten zeigt, die über ein
Paket-Netzwerk kommunizieren;
-
2 eine
beispielhafte Migrations-Ereignis-Sequenz zwischen einem Migrator
und einem Nicht-Migrator zeigt;
-
3 ein
beispielhaftes Verfahren zeigt, das vom Migrator während der
Ereignis-Sequenz in 2 benutzt wird;
-
4 ein
beispielhaftes Verfahren zeigt, das vom Nicht-Migrator während der Ereignis-Sequenz
in 2 benutzt wird;
-
5 ein
beispielhaftes Format eines allgemeinen Steuerungs-Kopfes einer
STEM-System-Steuerungs-Nachricht zeigt;
-
6 ein
beispielhaftes Format eines Erweiterungs-Kopfes einer STEM-System-Steuerungs-Nachricht
zur Authentifizierung zeigt;
-
7 ein
beispielhaftes Format eines Erweiterungs-Kopfes einer STEM-System-Steuerungs-Nachricht
für die
Migration zeigt;
-
8 ein
beispielhaftes Format eines Erweiterungs-Kopfes einer STEM-System-Steuerungs-Nachricht
für Opaque
Data zeigt.
-
DETAILLIERTE BESCHREIBUNG
-
Die
folgende Terminologie und Definitionen werden als Hilfe zum Verständnis der
vorliegenden Erfindung benutzt. Ein "Migrator" oder "Migrations-Endpunkt" ist ein End-System, das sich gerade
im Prozess der Änderung
seiner Internet-Protokoll-(IP)-Adresse
befindet, oder sie bereits geändert
hat. Der Migrator ist das End-System, das eine Steuerungs-Nachricht
an einen entfernten Endpunkt auslöst, die seine neue IP-Adresse kennzeichnet.
Ein "Nicht-Migrator" oder "Nicht-Migrations-Endpunkt" oder "fester Endpunkt" ist das entfernte Endpunkt-System, das seine
IP-Adresse nicht ändert.
Der Nicht-Migrator akzeptiert die vom Migrator gesendete Steuerungs-Nachricht
und antwortet dem Migrator mit einer Quittungs-Nachricht. Ein Eins-zu-Eins-Zusammenhang
zwischen Migrator/Nicht-Migrator und Client/Server ist nicht notwendigerweise
vorhanden. Für die
TCP-Verbindungen ist ein Client ein System, das eine TCP-Verbindung zu einem
anderen System auslöst, während der
Server das System ist, das für
den Client einen Dienst bereitstellt, wie z. B. ein Datei-Übertragungs-Protokoll
(File Transport Protocol, FTP), Telnet oder Secure Shell (SSH).
Der Migrator/Nicht-Migrator kann entweder ein Client oder ein Server
sein.
-
Der
Prozess zum Aufbau und zur Aufrechterhaltung einer Sitzung zwischen
dem Migrator und dem Nicht-Migrator entspricht folgenden Charakteristiken.
Ein Knoten erhält
die bestehende Kommunikation mit anderen Knoten aufrecht, während er
seine IP-Adresse oder Schnittstelle ändert. Alle Nachrichten, die
erforderlich sind, die Verbindung auf die neue IP-Adresse zu ändern, können optional
authentifiziert werden, um einen Schutz gegen Sicherheitslücken der
Sitzung vorzusehen, wie z. B. gegen verschiedene Techniken von Umleitungs-
und Replay-Attacken. Der Knoten erhält eine IP-Adresse durch zum Beispiel das dynamische Host-Konfigurations-Protokoll (DHCP),
durch manuelle Konfiguration oder andere verfügbare Netzwerk-Mechanismen.
Die IP-Adresse (oder der Punkt des Anschlusses) ändert sich nicht rasch. Die
Geschwindigkeit, mit der sich IP-Adressen ändern können, während die entsprechende Übertragungs-Ebenen-Verbindung
aufrecht erhalten bleibt, ist von der Geschwindigkeit abhängig, mit
der die Knoten miteinander kommunizieren können und nach der Authentifizierung
ihre Kernel-Datenstrukturen aktualisieren können. Beide End-Systeme der
Verbindung haben vorzugsweise einen relativ symmetrischen Code,
der eine Ausführung
der vorliegenden Erfindung implementiert.
-
Gemäß beispielhaften
Ausführungen
der vorliegenden Erfindung führt
eine nahtlose Übertragungs-Endpunkt-Mobilitäts-Architektur
(STEM) eine dynamische Änderung
einer 5-Tupel-Zuordnung für
eine aufgebaute Sitzung (Verbindung) durch, die in der Kernel-Datenstruktur
des Migrators gespeichert ist, und informiert den Nicht-Migrator,
dieselbe Adressen-Änderung
seiner Kernel-Datenstruktur durchzuführen. Ein dynamisches, ladbares
Kernel-Modul und ein Steuerungs-Informations-Kommunikations-Dienstprogramm
werden in jedem der Endpunkte eingesetzt, um die Quell- und Ziel-IP-Adressen
in Paketen beider Endpunkte zu ändern.
Somit ist es wünschenswert,
dass, um eine erfolgreiche Übertragungs-Endpunkt-Migration
auf eine neue IP-Adresse zu erzielen, Referenzen auf die alte IP-Adresse
während
der Datenübertragung
beseitigt werden. Für
den Migrator enthalten alle an den Nicht-Migrator gesendeten IP-Pakete
die neue IP-Adresse
als Quelladresse, während
alle vom Nicht-Migrator empfangenen Pakete die neue IP-Adresse als
Zieladresse enthalten. Aus der Perspektive des Nicht-Migrators müssen alle
vom Migrator empfangenen IP-Pakete die neue IP-Adresse als Quelladresse
enthalten, während
alle zum Migrator gesendeten Pakete die neue IP-Adresse als Zieladresse
enthalten müssen.
-
1 zeigt
das STEM-System 100 für
die Knoten 101 und 102, die über das Internet 103 kommunizieren.
Der Knoten 101 enthält
zwei Benutzer-Anwendungen APP1 und APP2, die Daten erzeugen, die
vom Transportschicht-Modul 106 und vom Netzwerkschicht-Modul 107 verarbeitet
werden, bevor sie als Pakete über
das Internet 103 übertragen
werden. Knoten 102 enthält
Netzwerkschicht-Modul 108 und Transportschicht-Modul 109,
um Pakete zu verarbeiten, die vom Internet 103 empfangen
werden, um die Daten an Anwendungs-Server SRV1, SRV2 und SRV3 zu
liefern. Die Transportschicht-Module 106 und 109 kommunizieren
zum Beispiel auf der Grundlage des Übertragungs-Steuerungs-Protokolls (TCP), und die
Netzwerkschicht-Module 107 und 108 kommunizieren
zum Beispiel auf der Grundlage von IP. Die TCP/IP-Kommunikation
ist in der Technik wohlbekannt, und findet sich zum Beispiel in
Andrew S. Tannenbaum, Computer Networks, zweite Auflage, Prentice
Hall, 1988.
-
Die
Anwendung APP1 baut eine TCP/IP-Sitzung mit Anwendungs-Server SRV1
auf und erhält
sie aufrecht. STEM-Dienstprogramme 104 und 105 koordinieren
den Austausch und die Steuerung der Daten, wie z. B. die Erkennung
der 5-Tupel-Information,
die Quell- und Ziel-IP-Adressen enthält, für die Knoten 101 bzw. 102.
Die STEM-Dienstprogramme 104 und 105 können über einen
Außerband-Kanal
(Kanal, der vom TCP-Sitzungs-Kanal
getrennt ist) kommunizieren, der als User-Datagramm-Protocol-(UDP)-Sitzung dargestellt
ist, die über
das Internet 103 läuft.
-
Jedes
STEM-Dienstprogramm ist mit einem dynamisch ladbaren Kernel-Modul
(in 1 nicht gezeigt) implementiert. Ein Dienstprogramm
ist ein Programm, das kontinuierlich läuft und den Zweck hat, regelmäßige Dienstanforderungen
zu behandeln, deren Empfang vom Computersystem erwartet wird. Das
Dienstprogramm leitet die Anforderungen an andere Programme (oder
Prozesse) weiter, wie durch ein gegebenes Kommunikationsprotokoll
spezifiziert. Die Kernel-Module der STEM-Dienstprogramme 104 und 105 ändern ihre Kernel-Datenstruktur, in
der die 5-Tupel-Information gespeichert ist. Das 5-Tupel kennzeichnet
eindeutig einen Kernel-Socket-Deskriptor
(Deskriptor, der die TCP/IP-Sitzung in der Anwendung kennzeichnet).
-
2 zeigt
eine beispielhafte Migrations-Ereignis-Sequenz zwischen einem Migrator und
einem festen Ende (dem Nicht-Migrator). Die normale Datenübertragung
findet zwischen den beiden Endpunkten während des Zeitraums 201 statt,
wobei die IP-Adresse 192.168.1.1 für den Migrator benutzt wird.
In 2 werden Nachrichten über die TCP-Sitzung für Daten
vom Migrator unter (M) und für
Daten vom festen Ende unter (F) gezeigt, während Steuerungs-Nachrichten über den
Außerband-Kanal (z. B. UDP-Sitzung)
für Daten
vom Migrator unter (MD) und für Daten
vom festen Ende unter (FD) gezeigt werden.
An einem Punkt nach dem Verbindungsaufbau, aber vor dem IP-Adressen-Änderungs-Punkt 202 registriert
sich der Migrator optional beim festen Ende unter Verwendung einer
Registrierungs-Anforderung,
die das feste Ende mit einer Antwort über den Außerband-Kanal quittiert. Der
Migrator registriert sich optional beim festen Ende aus Sicherheitsgründen und um
das feste Ende zu informieren, dass der Migrator im Begriff ist,
seine IP-Adresse zu verlegen oder zu ändern.
-
Der
Migrator kann die neue IP-Adresse für seine Schnittstelle mit einer
Anzahl unterschiedlicher Verfahren erhalten. Der Migrator kann die
Adresse selbst von einem Netzwerk-Manager einer höheren Ebene oder
einem DHCP-Server anfordern, der dann die Adresse zuweist und liefert.
Alternativ kann die Schnittstele manuell auf eine neue IP-Adresse rekonfiguriert
werden.
-
Am
IP-Adressen-Änderungs-Punkt 202 beginnt
der Migrator damit, die IP-Adresse auf 192.168.2.99 zu ändern. Während der
Periode 203 nach dem IP-Adressen-Änderungs-Ereignis 202 aktualisiert
das Kernel-Modul des Migrators (z. B. Knoten 101) die IP-Adresse
in der 5-Tupel-Datenstruktur, die dem Socket-Deskriptor zugeordnet ist. Jeder Socket-Deskriptor
ist eindeutig einem 5-Tupel zugeordnet. Die Aktualisierung der Kernel-Datenstruktur
beginnt mit dem Suchen aller offenen Socket-Deskriptoren und deren
Abgleich gegen das spezifizierte 5-Tupel (das die alte IP-Adresse
wie eines der Tupel enthält).
Wenn eine gültige Übereinstimmung
erkannt wird, wird diese Datenstruktur geeignet geändert, um
die neue IP-(Endpunkt)-Adresse
widerzuspiegeln. Zusätzlich
dazu wird die Paket-Übertragung
zum Ziel-Knoten eingestellt. TCP-Datensegmente werden in der Sende-Warteschlange
des Knotens (TCP send-Q) gepuffert, bis eine gültige Route aufgebaut ist.
-
Somit
sind, soweit die Anwendung (z. B. APP1) betroffen ist, die Änderungen
des Kernels transparent, da die Anwendung weiter an denselben Socket-Deskriptor
gebunden ist. Somit verwendet die Anwendung denselben Socket-Deskriptor
und arbeitet weiterhin normal. Auf dem geänderten Socket-Deskriptor gesendete Daten
ergeben während
des Routen-Such-Prozesses
eine gültige
Route/Schnittstelle. Gleichzeitig informiert der Migrator über eine
Außerband-Kommunikation
(als Steuerungs-Nachricht "migrate
req" gezeigt) das
entfernte (feste) Ende über
die Änderung
auf die neue Endpunkt-IP-Adresse.
Auf der Grundlage dieser Information wendet das feste Ende die gleichen Änderungen
auf seine Kernel-Datenstrukturen an, so dass die Zieladresse im
IP-Kopf der vom festen Ende ausgesendeten Datenpakete den neuen
Wert widerspiegelt. Das feste Ende quittiert die Änderung
seines Kernels (als Steuerungs-Nachricht "migrate reply" gezeigt) zum Migrator, und die beiden
Endpunkte nehmen im Zeitraum 205 die Kommunikation als
normale TCP-Sitzung wieder auf, wobei die neue IP-Adresse für den Migrator
verwendet wird. TCP-Datensegmente,
die in der TCP send-Q gepuffert wurden, werden über die Schnittstelle zum Ziel
gesendet, da eine gültige
Route vorliegt, und die IP-Adresse aller gesendeten Pakete enthält die geeignete
neue Adresse im IP-Kopf.
-
Die
Steuerung des Migrations-Prozesses auf sanfte und systematische
Weise verhindert Bedingungen, die Wettrennen-Bedingungen genannt werden, die TCP-Reset-Nachrichten
erzeugen können,
welche die Verbindung beenden würden.
Speziell können
bevorzugte Ausführungen
diese Bedingungen verhindern, indem sie folgendes sicherstellen:
1) dass Kernel-Änderungen
des Migrators immer zuerst angewendet werden, bevor der Nicht-Migrator von diesen Änderungen
informiert wird, und 2) dass der Migrator während der Periode des Austausches
von Steuerungs-Nachrichten keine Daten auf der Sitzung sendet. Eine
solche Verhinderung kann zum Beispiel erzielt werden, indem Firewall-Regeln
im System benutzt werden (z. B. Output-Chain-Regeln von iptables in einem Linux-Betriebssystem),
um zu verhindern, dass Sitzungs-Daten das System verlassen, bis
der Migrations-Prozess beendet ist. Die Regeln werden dynamisch
zum Kernel hinzugefügt,
um die Übertragung
von Paketen auf dieser Sitzung zum entfernten Ende explizit zu verhindern.
Sobald vom Nicht-Migrator eine Quittung empfangen wurde, werden
die Regeln zurückgezogen,
um den Normalbetrieb wieder aufzunehmen. Alternativ können bevorzugte
Ausführungen
die Neuzuordnung der alten Endpunkt-IP-Adresse für eine bestimmte Zeitdauer
verzögern.
Hierdurch wird sichergestellt, dass zwei verschiedene Sitzungen
nicht gleichzeitig dieselbe IP-Adresse benutzen.
-
3 zeigt
ein beispielhaftes Verfahren, das vom Migrator während der Ereignis-Sequenz
in 2 benutzt wird. In Schritt 301 nimmt
der Migrator aktuell an einer bestehenden Sitzung teil, wobei der
Nicht-Migrator eine aktuelle Endpunkt-IP-Adresse benutzt. In Schritt 302 sendet
der Migrator über
einen Außerband-Kanal
(z. B. einen UDP-Kanal) eine Registrierungs-Anforderungs-Steuerungs-Nachricht
an den Nicht-Migrator,
um den Migrator beim Nicht-Migrator zu registrieren. Wenn Schritt 302 ausgeführt ist,
empfängt der
Migrator in Schritt 303 als Quittung der Registrierung
beim Nicht-Migrator über
den Außerband-Kanal
eine Registrierungs-Antwort-Steuerungs-Nachricht
vom Nicht-Migrator.
-
In
Schritt 304 beginnt der Migrator damit, seine aktuelle
Endpunkt-IP-Adresse in eine neu erworbene Endpunkt-IP-Adresse ("neue Endpunkt-IP-Adresse") zu ändern. In
Schritt 305 beendet der Migrator die Übertragung von Paketen und
stellt die Pakete in die Warteschlange TCP send-Q. In Schritt 306 beginnt
der Migrator damit, vom Nicht-Migrator empfangene Pakete, die die
alte Endpunkt-IP-Adresse enthalten, zu verwerfen. In Schritt 307 aktualisiert
der Migrator die Kernel-Datenstruktur des STEM-Dienstprogramms des
Migrators, damit sie die neue Endpunkt-IP-Adresse enthält.
-
In
Schritt 308 sendet der Migrator über den Außerband-Kanal eine Endpunkt-Adressen-Änderungs-Steuerungs-Nachricht
an den Nicht-Migrator, um anzuzeigen, dass der Migrator auf die
neue Endpunkt-IP-Adresse gewechselt hat. Während dieser Zeit fährt der
Migrator damit fort, Pakete in die Warteschlange TCP send-Q zu stellen.
In Schritt 309 empfängt
der Migrator über
den Außerband-Kanal
eine Endpunkt-Adressen-Änderungs-Quittungs-Steuerungs-Nachricht
vom Nicht-Migrator, die anzeigt, dass der Nicht-Migrator seine Kernel-Datenstruktur
geändert
hat, um die neue Endpunkt-IP-Adresse zu enthalten. In Schritt 310 fährt der
Migrator mit der Sitzung mit der neuen Endpunkt-IP-Adresse fort,
indem er Pakete von der TCP send-Q ausgibt.
-
4 zeigt
ein beispielhaftes Verfahren, das vom Nicht-Migrator während der Ereignis-Sequenz
in 2 benutzt wird. In Schritt 401 nimmt
der Nicht-Migrator an einer bestehenden Sitzung mit dem Migrator teil,
wobei eine aktuelle Endpunkt-IP-Adresse
verwendet wird. In Schritt 402 empfängt der Nicht-Migrator über einen
Außerband-Kanal
eine Registrierungs-Anforderung
vom Migrator, den Migrator beim Nicht-Migrator zu registrieren.
Wenn Schritt 402 ausgeführt
ist, registriert in Schritt 403 der Nicht-Migrator den
Migrator und sendet über
den Außerband-Kanal
als Quittung der Registrierung durch den Nicht-Migrator eine Registrierungs-Antwort-Steuerungs-Nachricht an den
Migrator.
-
In
Schritt 404 fährt
der Nicht-Migrator mit dem Empfang von Paketen vom Migrator fort,
die die alte Endpunkt-IP-Adresse
enthalten. In Schritt 405 empfängt der Nicht-Migrator über den
Außerband-Kanal
eine Endpunkt-Adressen-Änderungs-Steuerungs-Nachricht
vom Migrator, um anzuzeigen, dass der Migrator auf die neue Endpunkt-IP-Adresse
gewechselt hat. In Schritt 406 aktualisiert der Nicht-Migrator
die Kernel-Datenstruktur
des STEM-Dienstprogramms des Nicht-Migrators, um die neue Endpunkt-IP-Adresse
zu enthalten.
-
In
Schritt 407 sendet der Nicht-Migrator über den Außerband-Kanal eine Endpunkt-Adressen-Änderungs-Quittungs-Steuerungs-Nachricht
an den Migrator, die anzeigt, dass der Nicht-Migrator seine Kernel-Datenstruktur
geändert
hat, um die neue Endpunkt-IP-Adresse zu enthalten. In Schritt 408 fährt der
Nicht-Migrator mit der Sitzung mit der neuen Endpunkt-IP-Adresse fort.
-
Kehrt
man zurück
zu 1, benutzt das STEM-System 100 einen
Außerband-Steuerungs-Kanal,
der als UDP-Kanal 150 gezeigt wird, um zwischen Partnern,
wie z. B. den STEM-Dienstprogramm-Modulen 104 und 105 zu
kommunizieren. Die Außerband-Kommunikation über den
UDP-Kanal 150 bietet den Vorteil, dass der Migrator seine Änderungen
auch nachdem die IP-Adressen-Änderung
aufgetreten ist an den Nicht-Migrator übermitteln kann. Zusätzlich dazu
kann die Außerband-Kommunikation Informationen
bezüglich
mehreren TCP-Sitzungen gleichzeitig übertragen. Die 5 bis 8 zeigen
Formate für
beispielhafte Steuerungs-Nachrichten für den Migrator und den Nicht-Migrator,
die über
den UDP-Kanal 150 ausgetauscht werden können. In allen Steuerungs-Nachrichten
wird ein gemeinsamer Kopf verwendet, der einem UDP-Format entsprechen
kann, das eine von Null verschiedene Prüfsumme hat.
-
5 zeigt
ein beispielhaftes Format eines allgemeinen Steuerungs-Kopfes einer
STEM-System-Steuerungs-Nachricht. In 5 kennzeichnet "Version" die Versions-Nummer
des Protokolls, "Sequence #" kennzeichnet den
16-Bit-Zählwert
in der Sequenz der Daten-Nachrichten, "Identifier cookie" ist eine 48-Bit-Kennung, die einen
Knoten eindeutig kennzeichnet, und "Replay Protect ID" ist eine eindeutige 64-Bit-Kennung,
die auf einem Zeitstempel oder einem Zufallswert beruht, um gegen
Replay-Attacken zu schützen. "Type" kennzeichnet das
Paket als Steuerungs-Nachricht und kann vier Werte annehmen: eine "1" kennzeichnet die Nachricht als Registrierungs-Anforderung, eine "2" kennzeichnet die Nachricht als Registrierungs-Antwort,
eine "3" kennzeichnet die
Nachricht als Migrations-Anforderung und eine "4" kennzeichnet
die Nachricht als Migrations-Antwort. "Flags/Codes" kennzeichnet die Flags und Rückgabe-Codes,
die in der Migrations-Registrierungs-Steuerungs-Nachricht
benutzt werden, wobei eine "1" angibt, dass die
Registrierungs-Anforderung akzeptiert wird. Andere Werte von "Flags/Codes" können anzeigen,
dass die Registrierungs-Anforderung aus einem gegebenen Grund abgelehnt
wird.
-
Der
Registrierungs-Prozess beginnt damit, dass der Migrator eine Registrierungs-Anforderungs-Steuerungs-Nachricht, die seine
Fähigkeiten
anzeigt, an den Nicht-Migrator
sendet. Nach der Authentifizierung und Überprüfung antwortet der Nicht-Migrator
mit der Registrierungs-Antwort-Steuerungs-Nachricht,
in der der geeignete Antwort-Code eingestellt ist, der den Status
der Anforderung anzeigt. Das Feld "Identifier Cookie" wird dazu benutzt, einen Knoten eindeutig
zu kennzeichnen. Viele Verfahren, mit denen dieses Cookie erzeugt
werden kann, sind in der Technik bekannt. Zum Beispiel können Cookie-Erzeugungs-Verfahren
eingesetzt werden, die in SCTP oder TCP (z. B. SYN-Cookie-Erzeugung)
benutzt werden. Typischerweise ist das Cookie eine Funktion einer
Invarianten, die den Knoten kennzeichnet. Da sich die IP-Adresse kontinuierlich ändert, ergibt zum
Beispiel ein voll qualifizierter Domain-Name mit einer einseitigen
Hash- Funktion, die
auf den Domain-Namen angewendet wird, ein eindeutiges 48-Bit-Eintritts-Cookie.
-
Das
vom Migrator konstruierte Feld "Replay-Protection
ID" wird dazu benutzt,
die Registrierungs-Anforderungen und Antwort-Nachrichten anzupassen,
um Playback-/Replay-Attacken entgegenzuwirken. Eine Replay-Attacke
ist ein Angriff auf ein Sicherheits-Protokoll, bei dem die Wiederholung
von Nahrichten aus einem anderen Kontext in den ursprünglichen
Kontext benutzt wird, wodurch der/die ehrliche(n) Teilnehmer getäuscht werden,
zu glauben, dass sie den Protokoll-Ablauf erfolgreich beendet haben.
Die Registrierungs-Antwort-Nachricht vom Nicht-Migrator setzt dieses Feld auf einen
Wert, der auf der Grundlage des Feldes "Replay-Protection ID", das in der Anforderungs-Nachricht
empfangen wird, und des verwendeten Replay-Schutzmechanismus (z.
B. Zeitstempel oder Nonces (Zufallszahlen), die durch die Sicherheitsverbindung
des Knotens gegeben sind) berechnet wird.
-
6 zeigt
ein beispielhaftes Format eines Erweiterungs-Kopfes einer STEM-System-Steuerungs-Nachricht
zur Authentifizierung. In 6 kennzeichnet "Type" das Paket als Authentifizierungs-Kopf-Typ, "Length" ist die Länge des
Paketes, "SPI" ist ein Sicherheits-Parameter-Index,
der einen Sicherheits-Kontext zwischen zwei Partnern kennzeichnet,
und "Authentication" ist ein Authentifizierungs-Feld mit
variabler Länge.
-
Der
vom beispielhaften STEM-System verwendete Authentifizierungs-Mechanismus
kann ähnlich dem
in Mobile IP verwendeten sein. Jeder Knoten unterstützt eine
Sicherheitsverbindung, die durch den Opaque-Sicherheits-Parameter-Index (SPI)
und den Identifier-Cookie indiziert wird. Der SPI im Authentifizierungs-Erweiterungs-Kopf
definiert den Sicherheits-Kontext, der benutzt wird, um den Authentifizierungs-Wert zu
berechnen und von einem Empfänger
verwendet wird, den Wert zu überprüfen. Der
Empfänger
wählt den Authentifizierungs-Algorithmus
(z. B. den Verschlüsselungs- Algorithmus HMAC-MD5
(Hashed Message Authentication Code-Message Digest Version 5) und SHA (Secure
Hash Algorithm)), den Algorithmus-Modus (z. B. Präfix + Suffix)
und das Geheimnis (gemeinsamer Schlüssel oder öffentliches/privates Schlüssel-Paar), das zur Berechnung
der auf diesem SPI basierenden Authentifizierung benutzt wird. Der
berechnete Authentifizierungs-Wert schützt die Nutzinformation des
Paketes des UDP-Kanals (Registrierungs-Anforderungs-/Antwort-Steuerungs-Nachrichten),
andere Erweiterungen (Migrations-Anforderung-/Antwort-Steuerungs-Nachrichten)
und den Anfangs-Teil
des Paketkopfes (Typ, Länge
und den SPI).
-
7 zeigt
ein beispielhaftes Format eines Erweiterungs-Kopfes einer STEM-System-Steuerungs-Nachricht
für die
Migration. In 7 kennzeichnet "Type" das Paket als Migrations-Kopf-Typ, "Length" ist die Länge der
Daten, "Proto Flags" kennzeichnet den
Protokoll-Typ (z. B. Bit 0 = TCP, Bit 1 = UDP), "Old IP addr" ist die IP-Adresse vor der Migration, "New IP addr" ist die IP-Adresse
nach der Migration, "Old
Port" ist die alte
Anschluss-Nummer vor der Migration, und "New Port" ist die neue Anschluss-Nummer nach
der Migration.
-
Der
Migrationsprozess, wie oben beschrieben, umfasst den Austausch von
Migrations-Anforderungs-/Antwort-Steuerungs-Nachrichten zwischen den Partnern. Zusätzlich zum
gemeinsamen Kopf und zum optionalen Authentifizierungs-Kopf enthält die Steuerungs-Nachricht
ein oder mehrere Migrations-Köpfe.
Jeder Migrations-Kopf enthält
Informationen über
die Abbildung des alten 5-Tupels auf ein neues 5-Tupel für eine oder
mehrere Sitzungen zwischen den Partnern. Jedes Bit im Feld "Protocol flags" zeigt ein vordefiniertes
Protokoll. Es können
gleichzeitig mehr als ein Bit gesendet werden, um die Migration
mehrerer interessierender Protokolle anzuzeigen. Stellt man das
Feld auf einen Wert Null, zeigt dies die Migration für alle Protokolle
an. Die Felder "Old
IP" und "New IP" liefern die spezifizierte
Abbildung von der alten IP-Adresse
auf die neue IP-Adresse des Migrations-Endpunktes, während die
Felder "Old Port" und "New Port" die äquivalenten
Abbildungen für
die in jeder Sitzung verwendeten Anschlüsse liefern. Wie das Feld "Protocol ID Flags" können auch die
Anschluss-Felder auf einen Wert von Null gesetzt werden, um anzuzeigen,
dass der Migrator es wünscht, alle
Sitzungen zwischen den beiden Endpunkten zu migrieren, wie wenn
der mobile Knoten sich über
IP-Subnetze bewegt, und der mobile Knoten alle offenen Sitzungen
gleichzeitig migrieren möchte.
-
Zusätzlich zu
den Nachrichten im Außerband-Kanal,
die mit Bezug auf die 5, 6 und 7 beschrieben
wurden, können
zusätzliche
Außerband-Nachrichten
für spezielle
Anwendungen des STEM-Systems verwendet werden. Da das STEM-System
für die
Host-Mobilität
eingesetzt werden kann, können
Nachrichten für
Verbindungs-Übergabe
und Lokalisierungs-Management eingesetzt werden. Solche Nachrichten können Daten
enthalten, wie Position, fester Endpunkt, Signal-Rauschverhältnis (SNR),
Verbindungsqualität oder ähnliche
Informationen, die zusammengefasst als "Opaque Data" bezeichnet werden. 8 zeigt
ein beispielhaftes Format eines Erweiterungs-Kopfes einer STEM-System-Steuerungs-Nachricht
für Opaque
Data. In 8 kennzeichnet "Type" das Paket als vom
Typ Opaque Header, "Length" kennzeichnet die
Länge der
Felder "Sub Type" und "Opaque Data", "Sub-Type" kennzeichnet die
Art der Aktualisierungs-Information, die in den Opaque Data enthalten
ist (z. B. Positions-Aktualisierungs-Information), "Flag/Codes sind Flags
oder Codes, die dazu benutzt werden, den Austausch von Opaque Data
zu vereinfachen, und "Opaque
Data" sind die Opaque
Data variabler Länge
des Paketes.
-
Die
vorliegende Erfindung erlaubt folgende Vorteile. Endpunkte, die
gemäß einer
oder mehrerer Ausführungen
des STEM-Systems arbeiten, unterbrechen weder die Ende-zu-Ende-TCP-Verbindung, noch
weisen Sie einen Code/Proxy im Kommunikationspfad zwischen den Endpunkten
zu. Es wird kein neuer Code zum Datenpfad hinzugefügt, und
die Anwendung wird nicht dahingehend getäuscht, zu glauben, dass die
Verbindung noch besteht. Eine oder mehrere Ausführungen des STEM-Systems migrieren
dieselbe TCP-Verbindung zur neuen Adresse oder zum neuen Anschlusspunkt
(d. h. der TCP-Zustandsautomat des Endpunktes bleibt während des
Migrations-Prozesses im Zustand "ESTABLISHED").
-
Obwohl
die vorliegende Erfindung mit Bezug auf ein Paketnetzwerk beschrieben
wurde, das gemäß einem
TCP-IP-Kommunikations-Prozess
arbeitet, ist die vorliegende Erfindung nicht darauf beschränkt. Ein Fachmann
kann die hier gegebenen Lehren leicht auf andere Paketnetzwerke
erweitern, in denen ein Knoten seine Verbindung auf einen anderen
Knoten überträgt. Zusätzlich dazu
kann die vorliegende Erfindung für
den Einsatz in drahtlosen, Funk-, Zellular- oder anderen drahtlosen
Anwendungen (insgesamt als "drahtlose" Anwendungen bezeichnet)
bevorzugt werden, die vorliegende Erfindung ist aber nicht darauf
beschränkt
und kann in drahtgebundenen oder optischen Netzwerken eingesetzt
werden, welche die Kommunikation auf Paket-Basis unterstützen.
-
Die
vorliegende Erfindung kann in Form von Verfahren und Vorrichtungen
zur Ausführung
dieser Verfahren ausgeführt
werden. Die vorliegende Erfindung kann auch in Form von Programmcode
ausgeführt
werden, der auf materiellen Medien enthalten ist, wie z. B. auf
Disketten, CD-ROMs, Festplatten-Laufwerken
oder jedem anderen maschinenlesbaren Speichermedium, wobei, wenn
der Programmcode in eine Maschine, wie z. B. einen Computer, geladen
und von ihr ausgeführt
wird, die Maschine zu einer Vorrichtung zur Ausführung der Erfindung wird. Die
vorliegende Erfindung kann zum Beispiel auch in Form von Programmcode
ausgeführt werden,
sei er gespeichert auf einem Speichermedium, in eine Maschine geladen
und/oder von ihr ausgeführt, oder über ein Übertragungsmedium,
wie elektrische Leitungen oder Kabel, optische Fasern oder über elektromagnetische
Strahlung, übertragen,
wobei, wenn der Programmcode in eine Maschine, wie z. B. einen Computer,
geladen und von ihr ausgeführt
wird, die Maschine zu einer Vorrichtung zur Ausführung der Erfindung wird. Wenn
sie auf einem Allzweck-Prozessor implementiert werden, verbinden
sich die Programmcode-Segmente mit dem Prozessor, um ein einzigartiges
Gerät bereitzustellen,
das analog zu speziellen Logik-Schaltkreisen arbeitet.
-
Es
versteht sich ferner, dass verschiedene Änderungen in Details, Materialien
und Anordnungen der Teile, die beschrieben und gezeigt wurden, um
die Natur dieser Erfindung zu erklären, von einem Fachmann vorgenommen
werden können,
ohne vom Prinzip und Schutzumfang der Erfindung abzuweichen, wie
in den folgenden Ansprüchen
ausgedrückt. FIG. 1
| 106, 109 | Transportschicht |
| 107, 108 | Netzwerkschicht
(IP) |
| UDP
session | UDP-Sitzung |
| TCP
sessions | TCP-Sitzungen |
| 104, 105 | STEM-Dienstprogramm |
| Kernel
update | Kernel-Aktualisierung |
| Physical
network | Physikalisches
Netzwerk |
FIG. 2
| Fixed
end (F) | Festes
Ende (F) |
| 201, 205 | Datenaustausch |
| Addr
change | Adressenänderung |
| 203 | Pakete
vom Tx blockiert |
| Migrate
Req | Migrations-Anforderung |
| Migrate
reply | Migrations-Antwort |
FIG. 3
| 301 | Bestehende
Sitzung mit Nicht-Migrator wird unter Verwendung der aktuellen Endpunkt-Adresse
durchgeführt |
| 302 | Senden
eine Registrierungs-Anforderung zum Nicht-Migrator zum Registrieren |
| 303 | Empfangen
einer Registrierungs-Antwort vom Nicht-Migrator, um die Registrierung auszuführen |
| 304 | IP-Endpunkt-Adresse ändern |
| 305 | Unterbrechen
der Übertragung
von Paketen; Pakete in TCP-Warteschlange Send-Q stellen |
| 306 | Verwerfen
von Paketen vom Nicht-Migrator auf IP-Ebene |
| 307 | Aktualisieren
der Kernel-Struktur des Migrators durch die neue Endpunkt-Adresse |
| 308 | Senden
einer Endpunkt-Adressen-Änderungs-Steuerungs-Nachricht an den Nicht-Migrator;
Unterbrechen der Paket-Übertragung |
| 309 | Empfangen
einer Quittung für
die Endpunkt-Adressen-Änderungs-Steuerungs-Nachricht |
| 310 | Fortführen der
Sitzung mit der neuen Endpunkt-Adresse |
FIG. 4
| 401 | Bestehende
Sitzung mit Migrator wird unter Verwendung der aktuellen Endpunkt-Adresse
durchgeführt |
| 402 | Empfangen
einer Registrierungs-Anforderung vom Migrator |
| 403 | Senden
einer Registrierungs-Antwort zum Migrator |
| 404 | Fortführen des
Empfangens von Paketen vom Migrator |
| 405 | Empfangen
einer Endpunkt-Adressen-Änderungs-Steuerungs-Nachricht vom Migrator |
| 406 | Aktualisieren
der Kernel-Struktur des Nicht-Migrators durch die neue Endpunkt-Adresse |
| 407 | Quittieren
der Endpunkt-Adressen-Änderungs-Steuerungs-Nachricht vom Migrator |
| 408 | Fortführen der
Sitzung mit der neuen Endpunkt-Adresse |
FIG. 5
FIG. 6
FIG. 7
8