DE112004000524B4

DE112004000524B4 - Verfahren, Vorrichtung und System zum Sicherstellen eines zuverlässigen Zugangs zu einem Roaming-Mobilknoten

Info

Publication number: DE112004000524B4
Application number: DE112004000524T
Authority: DE
Inventors: Michael Beaverton Andrews; Farid Lake Oswego Adrangi; Ranjit Hilsboro Narjala
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2003-03-28
Filing date: 2004-02-26
Publication date: 2009-10-01
Anticipated expiration: 2024-02-27
Also published as: JP2006521034A; CN1768517B; WO2004095802A1; KR100886985B1; JP4660379B2; DE112004000524T5; US7535878B2; GB0513411D0; US20040190534A1; GB2414903A; KR20050113254A; GB2414903B; CN1768517A

Abstract

Verfahren zum Sicherstellen eines zuverlässigen Zugangs zu einem Mobilknoten, umfassend:
Abfangen (401) einer Care-of-Adresse-(„COA”)-Anforderung, wobei die COA-Anforderung einen Mobilknoten-Hostnamen enthält;
Lenken der COA-Anforderung an ein Konfigurationsmodul innerhalb eines Netzstapels, der an den Mobilknoten gekoppelt ist;
Ersetzen (403), durch das Konfigurationsmodul, des Mobilknoten-Hostnamens in der COA-Anforderung durch einen konfigurierten Alternativnamen vor einem Weiterreichen (404) der COA-Anforderung mit dem konfigurierten Alternativnamen an einen Physical Layer innerhalb des Netzstapels, der an den Mobilknoten gekoppelt ist; und Senden der COA-Anforderung mit dem konfigurierten Alternativnamen an einen Server.

Description

ERFINDUNGS GEBIET
Die vorliegende Erfindung betrifft das Gebiet mobiler Rechner und insbesondere ein Verfahren, eine Vorrichtung und ein System zum Sicherstellen eines zuverlässigen Zugangs zu einem Roaming-Mobilknoten.
ALLGEMEINER STAND DER TECHNIK
Ein Hostname ist ein eindeutiger Name, über den eine Recheneinrichtung auf einem Netz identifiziert werden kann. Hostnamen werden dazu verwendet, den Zugang zu Recheneinrichtungen zu vereinfachen, indem es Benutzern ermöglicht wird, zum Zugreifen auf diese Einrichtungen eindeutige Namen anstelle von Adressen zu verwenden. Ein Hostname wird in der Regel von einem DNS-(Domain Name System)-Server in eine Internetadresse übersetzt.
Der Einsatz von Hostnamen bei mobilen Rechenumgebungen hat zu zusätzlichen Überlegungen geführt. Da mobile Recheneinrichtungen (im weiteren „Mobilknoten”) immer populärer werden, sind verschiedene Protokolle entwickelt worden, um den Anforderungen des mobilen Rechnens gerecht zu werden. Damit Mobilknotenbenutzer beispielsweise sich von einer Stelle zu einer anderen bewegen können („Roam”), während sie gleichzeitig ihre Konnektivität zum gleichen Netz beibehalten, hat die Internet Engineering Task Force („IETF”) Roamingstandards veröffentlicht (Mobile IPv4, IETF RFC 3344, August 2002, im weiteren „Mobile IPv4”, und Mobile IPv6, IETF Mobile IPv6, Internet-Draft draftietf-mobileip-ipv6-19.txt (in Bearbeitung), Oktober 2002, im weiteren „Mobile IPv6”).
Mobile IPv4 ist gegenwärtig der vorherrschende Standard, und viele Netze sind heutzutage Mobile IPv4-konform. Mobile IPv4 hat das Konzept der Network Access Identifiers („NAIs”) eingeführt. NAIs können entweder in Mobile IPv4- oder IPv6-konformen Netzen zum eindeutigen Identifizieren eines Mobilknotens verwendet werden. Während ein Mobilknoten in der Regel durch einen Hostnamen identifiziert wird, kann er auch mit mehr als einem NAI identifiziert sein. Ähnlich wie bei Hostnamen können auch NAIs von einem DNS-Server in eine Internetadresse übersetzt werden.
US 2002/0007414 A1 offenbart ein Verfahren und ein System zur Steuerung von Paket-Routing in einem Zwei-Wege-System mit einer schnellen Downlink-Verbindung und einer langsameren Uplink/Downklink-Verbindung. Die Steuerung erfolgt durch eine Vorrichtung in einem lokalen Subnetz, welche Anforderungen aus der langsamen Uplink/Downlink-Verbindung verarbeitet und geeignet umleitet.
Die vorliegende Erfindung stellt eine Lösung zum zuverlässigen Zugreifen auf einen Roaming-Mobilknoten bereit. Dazu ist erfindungsgemäß ein Verfahren, eine Vorrichtung, ein System und ein Computerprogrammprodukt nach den Ansprüchen 1, 6, 12, 16 bzw. 18 vorgesehen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die vorliegende Erfindung wird beispielhaft und nicht als Einschränkung in den Figuren der beiliegenden Zeichnungen veranschaulicht, in denen gleiche Bezugszeichen ähnliche Elemente bezeichnen. Es zeigen:
1 eine bekannte heutige Corporate-Intranet-Struktur;
2 eine Tabelle, die die verschiedenen Möglichkeiten veranschaulicht, wie MN 140 konfiguriert werden kann;
3 einen Mobil-IP-Netzstapel gemäß Ausführungsformen der vorliegenden Erfindung; und
4 ein Flußdiagramm, das eine Ausführungsform der vorliegenden Erfindung veranschaulicht.
AUSFÜHRLICHE BESCHREIBUNG
Die Bezugnahme in der Beschreibung auf „eine Ausführungsform” der vorliegenden Erfindung bedeutet, das ein bestimmtes Merkmal, eine bestimmte Struktur oder eine Charakteristik, die in Verbindung mit der Ausführungsform beschrieben sind, in mindestens einer Ausführungsform der vorliegenden Erfindung enthalten ist. Somit beziehen sich die Ausdrücke „in einer Ausführungsform”, „gemäß einer Ausführungsform” oder dergleichen, die in der Beschreibung an verschiedenen Stellen erscheinen, nicht notwendigerweise alle auf die gleiche Ausführungsform.
1 veranschaulicht eine bekannte Corporate-Intranet-Struktur („Corporate Intranet 100”). Das Corporate Intranet 100 kann sowohl drahtgebundene als auch drahtlose Netze enthalten und kann mehrere Teilnetze umfassen. Teilnetze beziehen sich auf Abschnitte von Netzen, die sich möglicherweise das gleiche gemeinsame Adressformat teilen. Beispielsweise können auf einem Transport Control Protocol/Internet Protocol-(„TCP/IP”)-Netz alle Teilnetze die gleichen ersten drei Mengen von Zahlen verwenden (wie etwa 100.10.10).
Wie zuvor beschrieben kann ein Mobilknoten („im weiteren „MN 140”) einen Hostnamen und einen mit ihm assoziierten NAI aufweisen. Mobilknoten, die den Standards Mobile IPv4 und/oder Mobile IPv6 entsprechen (im weiteren kollektiv als „Mobile IP Standards” bezeichnet) können heutzutage über Teilnetze innerhalb des Corporate Intranet 100 hinweg frei roamen. Wenn MN 140 sein Home-Teilnetz verläßt, kann es weiterhin seine aktuellen Übertragungsverbindungen und konstante Erreichbarkeit auf eine von zwei Wegen beibehalten. Bei dem ersten Szenarium kann MN 140 sich bei einem Horne-Agenten („HA 130”) registrieren, wenn er sein Home-Teilnetz verläßt. Während des Registrierungsprozesses informiert MN 140 HA 130 über die „Care-of-Adresse” (im weiteren „COA”) des MN 140, nämlich die Adresse des MN 140 auf seinem neuen Teilnetz. Danach fängt HA 130 alle an MN 140 adressierten IP-Pakete ab und leitet die Pakete an die COA des MN 140 um. Während sich MN 140 von einem Teilnetz zum anderen bewegt, kann der MN 140 neue COAs über ein Dynamic Host Configuration Protocol („DHCP”) oder andere ähnliche Protokolle erhalten. Um sicherzustellen, daß HA 130 Pakete ordnungsgemäß an den MN 140 schicken kann, muß der MN 140 den HA 130 ständig mit seiner neuen COA aktualisieren, während er auf dem Corporate Intranet 100 roamt. Diese Konfiguration wird üblicherweise als ein „co-located” Kommunikationsmodus bezeichnet.
Wenn alternativ bei Mobile IPv4-konformen Netzen MN 140 sein Home-Teilnetz verläßt, kann es sich bei HA 130 über einen Fremdagenten („FA 135”) auf einem neuen („fremden”) Teilnetz des MN 140 registrieren. Durch Registrierung mit FA 135 kann MN 140 die IP-Adresse des FA 135 beim Registrieren beim HA 130 als seine COA verwenden. Bei diesem Szenarium fängt HA 130 weiterhin alle an MN 140 adressierten Pakete ab, doch werden diese Pakete nun an FA 135 weitergeleitet, nämlich die COA des MN 140, wie durch HA 130 bereitgestellt. FA 135 untersucht alle Pakete, die er empfangt, und sendet die entsprechenden an MN 140 an seiner aktuellen Stelle in dem fremden Teilnetz. Diese Konfiguration wird üblicherweise als ein „non-co-located” Kommunikationsmodus bezeichnet. Die Entscheidung, ob ein co-located oder non-co-located Modus verwendet wird, ist dem Durchschnittsfachmann wohlbekannt. Bestimmte Netze können beispielsweise den MN 140 zwingen, sich beim FA 135 zu registrieren, um seine Transportverbindungen beizubehalten. In anderen Netzen kann MN 140 die Option haben, sich bei FA 135 zu registrieren oder in einem co-located Modus zu arbeiten.
Wenn zusammengefaßt MN 140 über Teilnetze hinweg roamt, können ihm zugeordnet sein: (i) ein Hostname; (ii) ein NAI; (iii) eine invariante Home-Adresse und (iv) eine COA. Wie für den Durchschnittsfachmann offensichtlich ist, können diese mehreren Identifizierer für MN 140 beim Roamen von MN 140 zu Unstimmigkeiten führen. Einzelheiten dieser Unstimmigkeiten sind unten beschrieben.
2 ist eine Tabelle, die die verschiedenen Wege veranschaulicht, wie MN 140 konfiguriert sein kann, so daß es Mobile IPv4-Standards entspricht. Wie dargestellt kann der Mobilknoten gemäß einem von sechs Szenarien konfiguriert sein. In Szenarium 1 kann MN 140 in einem co-located Modus ein NAI zugeordnet sein, der von seinem Hostnamen verschieden ist. Wenn MN 140 seine COA erhält (z. B. über DHCP oder andere ähnliche Protokolle), kann in einem DNS-Server ein Abbildungseintrag erzeugt werden, der die COA auf den Hostnamen {Hostname, COA} des MN 140 abbildet. Diese COA kann sich beim Roamen des MN 140 über Teilnetze ständig ändern. Zusätzlich kann MN 140 so konfiguriert sein, daß er seine Home-Adresse durch eine NAI-Erweiterung in seiner Registrierungsanforderung an HA 130 erhält. HA 130 kann eine Home-Adresse an den MN 140 austeilen entweder vom IP-Adressenpool des HA 130 oder durch Anfordern der Home-Adresse von einem DHCP-Server über eine DHCP-(oder anderes ähnliches Protokoll)-Anforderung. Im letzteren Fall kann der DHCP-Server als Reaktion auf die Anforderung des HA 130 dem MN 140 eine Home-Adresse erteilen und sendet dem DNS-Server eine Aktualisierung, um in dem DNS-Server einen abbildenden Eintrag zu erzeugen {NAI, MN_H}. Wie bereits beschrieben versucht ein entsprechender Knoten („CN”) möglicherweise, den MN 140 unter Verwendung seines NAI und/oder Hostnamens zu erreichen. Wenn jedoch in dem obigen Szenarium 1 der CN versucht, unter Verwendung des Hostnamens des MN 140 auf den MN 140 zuzugreifen, anstatt zur Home-Adresse des MN 140 aufgelöst zu werden, wird der Hostname zur COA des MN 140 aufgelöst. Da diese Kommunikation nicht über den HA 130 gelenkt wird, der für die Aufrechterhaltung der mobilen Konnektivität des MN 140 verantwortlich ist, kann der MN 140 möglicherweise über seinen Hostnamen nicht zuverlässig erreicht werden.
In Szenarium 2 kann dem Mobile Node 140 in einem nicht-co-located Modus möglicherweise ein NAI zugewiesen sein, der von seinem Hostnamen verschieden ist. Der MN 140 kann wieder so konfiguriert sein, daß er seine Home-Adresse durch eine NAI-Registrierung erhält, was zu einem abbildenden Eintrag in dem DNS-Server führt {NAI, MN_H}. In diesem nicht-co-located Szenarium jedoch verwendet der MN 140 möglicherweise die Adresse des FA 135 als seine COA beim Registrieren bei dem HA 130. Somit erhält der MN 140 im Gegensatz zum Szenarium 1 keine COA, was zu einer Abbildung zwischen dem Hostnamen und der COA in dem DNS-Server führen würde. Folglich gibt es möglicherweise keinen abbildenden Eintrag für den Hostnamen des MN 140 in dem DNS-Server, und der CN erreicht den MN 140 möglicherweise nicht über seinen Hostnamen. Wenngleich dieses Szenarium keinen abbildenden Eintrag für den Hostnamen des MN 140 in dem DNS-Server auslöst, kann der DNS-Server zusätzlich dennoch möglicherweise einen veralteten Eintrag in seiner bindenden Tabelle (z. B. ist der Hostname des MN 140 möglicherweise immer noch auf eine alte COA von einer vorausgegangenen Konfiguration abgebildet). Wenn der CN in dieser Situation versucht, den MN 140 über seinen Hostnamen zu erreichen, wird der Hostname in dem DNS-Server auf die veraltete COA aufgelöst, was dazu führt, daß der CN den MN 140 nicht erreichen kann.
Gemäß Szenarium 3 kann dem MN 140 in einem co-located Modus ein NAI zugewiesen sein, der der gleiche ist wie sein Hostname. Wie oben in Szenarium 1 beschrieben, kann der DNS-Server Abbildungen für {NAI, MN_H} und {Hostname, COA} enthalten. Da jedoch der NAI und der Hostname gleich sind, kann in dieser Situation die Abbildung im DNS-Server aufgrund eines IP-Adressenkonflikts zwischen dem Hostnamen und dem NAI des MN 140 möglicherweise nicht vorhergesagt werden. Die Abbildungen können sich gegeneinander aufheben angesichts der Reihenfolge, in der die Abbildungen in den DNS-Server eingetragen werden. Infolgedessen ist ein Zugriff auf den MN 140 entweder über seinen Hostnamen oder NAI im besten Fall wahrscheinlich nicht vorhersagbar.
Im Szenarium 4 wird MN 140 in einem nicht-co-located Modus ein NAI zugewiesen, der der gleiche ist wie sein Hostname. Dieses Szenarium führt keinerlei Probleme ein, da, wie in Szenarium 2 oben beschrieben, der NAI in dem DNS-Server auf die invariante Home-Adresse {NAI, MN_H} des MN 140 abgebildet. Da jedoch der NAI der gleiche ist wie der Hostname, ungeachtet der Tatsache, daß es keine Abbildung für den Hostnamen gibt, kann in dieser Situation der MN 140 dennoch erreicht werden. Mit anderen Worten wird ein CN, der versucht, den MN 140 über seinen Hostnamen zu erreichen, den gleichen Namen als NAI des MN 140 eingeben, was im DNS-Server zu MN_H aufgelöst wird.
In Szenarium 5 kann dem MN 140 in einem co-located Modus eine statische Home-Adresse zugewiesen sein (z. B. durch die IT-Abteilung einer Firma), und eine Abbildung kann gegebenenfalls in dem DNS-Server erzeugt werden {Hostname, MN_H}. Während der MN 140 roamt und eine COA erhält, kann auch ein zweiter Eintrag in dem DNS-Server erzeugt werden {Hostname, COA}. Die beiden Abbildungen für den Hostnamen des MN 140 führen zu einem IP-Adressenkonflikt für den Hostnamen. Genauer gesagt kann die zweite Abbildung für den Hostnamen den ersten überschreiben, wodurch in dem DNS-Server die Abbildung {Hostname, COA} zurückbleibt. Wie in Szenarium 1 oben beschrieben, kann infolgedessen der MN 140 möglicherweise unter Verwendung seines Hostnamens nicht länger zuverlässig erreicht werden, da der Hostname möglicherweise auf die COA des MN 140 abgebildet ist.
In dem letzten Szenarium, Szenarium 6, kann dem MN 140 in einem nicht-co-located Modus eine statische Home-Adresse zugewiesen sein, was zu einem Abbildungseintrag in den DNS-Server für {Hostname, MN_H} führt. Wie dem Durchschnittsfachmann ohne weiteres klar ist, liefert dieses Szenarium keine Probleme, da in einem nicht-co-located Modus für MN 140 im DNS-Server kein anderer Abbildungseintrag erzeugt wird. Der CN kann deshalb den MN 140 über seinen Hostnamen zuverlässig erreichen.
Zusammengefaßt führen die obigen Szenarien 1, 2, 3 und 5 zu verschiedenen Zugänglichkeitsproblemen für MN 140, während er von Teilnetz zu Teilnetz roamt. Ausführungsformen der vorliegenden Erfindung lösen diese Probleme durch Verwendung eines konfigurierten alternativen Namens. Genauer gesagt werden bei Ausführungsformen der Erfindung DHCP-Anforderungen vom MN 140 nach COAs und Antworten auf solche Anforderungen innerhalb MN 140 abgefangen und durch konfigurierte Alternativnamen bzw. Hostnamen ersetzt. Dies eliminiert eine Hostnamen-Abbildung auf COAs im DNS-Server, wodurch die oben beschriebenen Probleme eliminiert werden. Dieses Konzept der Verwendung eines konfigurierten Alternativnamens wird unten im Zusammenhang mit 3 ausführlicher beschrieben.
3 veranschaulicht einen Mobile-IP-Netzstapel am MN 140 gemäß Ausführungsformen der vorliegenden Erfindung. Die Konzepte von Netzstapeln und das Weiterleiten von Meldungen Netzstapel „hoch” und „hinunter” sind dem Durchschnittsfachmann wohlbekannt, und eine weitere Beschreibung davon entfällt hier, um von der vorliegenden Erfindung nicht unnötig abzulenken. Wie dargestellt, fängt die mobile IP-Schicht („MIP Data Layer 303”) DHCP-Anforderungen ab, die von MN 140 gesendet werden, um eine COA zu erhalten (im weiteren als „COA-Anforderungen” bezeichnet). Anstatt jedoch die Anforderung direkt den Netzstapel hinunter zu lenken (d. h. zur Link Layer 302 und Physical Layer 301), kann gemäß einer Ausführungsform der vorliegenden Erfindung das Configuration Module 305 (konzeptual so dargestellt, daß es in der MIP Data Layer 303 enthalten ist) den Hostnamen des MN 140 in der COA-Anforderung durch einen konfigurierten Alternativnamen ersetzen. Dieser konfigurierte Alternativname kann dann den Netzstapel hinunter zur Link Layer 302 und Physical Layer 301 weitergereicht werden. Bei einer Ausführungsform ist die COA-Anforderung eine DHCP-Anforderung, und ein DHCP-Server kann die Anforderungen bearbeiten und eine DHCP-Antwort mit einer COA-Zuweisung (im weiteren als eine „COA-Antwort” bezeichnet) zurücksenden. Nach Empfang dieser COA-Antwort kann das Configuration Module 305 den Alternativnamen in der Antwort mit dem eigentlichen Hostnamen ersetzen und die COA-Antwort den Netzstapel hoch zur TCP/IP-Layer 304 weiterleiten.
Wie dem Durchschnittsfachmann ohne weiteres klar ist, kann der Hostname des MN 140 durch Abfangen und Modifizieren der COA-Anforderungen und COA-Antworten gemäß den oben beschriebenen Ausführungsformen nicht länger auf seine COA im DNS-Server abgebildet werden. Um deshalb sicherzustellen, daß es eine bestimmte Abbildung für den Hostnamen des MN 140 im DNS-Server gibt, kann bei einer Ausführungsform der vorliegenden Erfindung eine neue Registrierungsanforderungserweiterung („Hostname Extension”) verwendet werden. Die Hostname Extension kann gemäß den im Mobile IPv4-Standard spezifizierten Richtlinien hergestellt werden und konfiguriert werden, so daß HA 130 informiert wird, die Erzeugung eines Abbildungseintrags zwischen den Hostnamen des MN 140 und der Home-Adresse im DNS-Server {Hostname, MN_H} anzufordern. Auf diese Weise kann der HA 130 sicherstellen, daß der Hostname des MN 140 stimmig auf die Home-Adresse des MN 140 im DNS-Server abgebildet wird. Der NAI des MN 140 wird weiterhin auf die Home-Adresse {NAI, MN_H} des MN 140 abgebildet. Gemäß einer Ausführungsform der vorliegenden Erfindung ermöglichen diese beiden Abbildungen, daß der MN 140 unabhängig davon, ob Hostname und NAI die gleichen sind, sowohl über seinen Hostnamen als auch über den NAI erreicht werden kann.
4 ist ein Flußdiagramm, das eine Ausführungsform der vorliegenden Erfindung veranschaulicht. Obwohl die folgenden Operationen als ein sequentieller Prozeß beschrieben werden können, können viele der Operationen tatsächlich parallel oder gleichzeitig ausgeführt werden. Zusätzlich kann die Reihenfolge der Operationen umgeordnet werden, ohne vom Gedanken von Ausführungsformen der Erfindung abzuweichen. In 401 kann eine COA-Anforderung oder COA-Antwort abgefangen werden. Die Anforderung und/oder die Antwort können in 402 untersucht werden. Im Fall einer COA-Anforderung kann der Mobilknoten-Hostname in der Anforderung in 403 durch einen konfigurierten Alternativnamen ersetzt und in 404 im Netzstapel nach unten weitergereicht werden. Alternativ kann in 405 im Fall einer COA-Antwort der konfigurierte Alternativname durch den Mobilknoten-Hostnamen ersetzt werden, und die Antwort kann in 406 im Netzstapel nach oben weitergereicht werden.
Zusätzlich kann an jedem Punkt vor, während oder nach diesen Ereignissen der Home-Agent des Mobilknotens in 407 die Erzeugung eines Abbildungseintrags in dem DNS-Server anfordern, wodurch der Hostname des Mobilknotens auf die Home-Adresse des Mobilknotens abgebildet wird.
Die Mobilknoten, Home-Agenten und Fremd-Agenten gemäß Ausführungsformen der vorliegenden Erfindung können in einer Vielzahl von Datenverarbeitungseinrichtungen implementiert werden. Dem Durchschnittsfachmann ist ohne weiteres klar, daß diese Datenverarbeitungseinrichtungen verschiedene Software enthalten können und alle Einrichtungen umfassen können, die Mobilnetze unterstützen können, einschließlich zum Beispiel Mainframes, Workstations, PCs, Laptops, tragbare Handhelds, PDAs und/oder Mobiltelefone. Bei einer Ausführungsform können Mobilknoten tragbare Datenverarbeitungssysteme wie etwa Laptops, handgehaltene Recheneinrichtungen, Personal Digital Assistants und/oder Mobiltelefone umfassen. Gemäß einer Ausführungsform können Home-Agenten und/oder Fremd-Agenten Datenverarbeitungseinrichtungen wie PCs, Workstations und/oder Mainframe-Computer umfassen. Bei alternativen Ausführungsformen können Home-Agenten und Fremd-Agenten auch tragbare Datenverarbeitungssysteme ähnlich denen umfassen, die zum Implementieren von Mobilknoten verwendet werden.
Gemäß einer Ausführungsform der vorliegenden Erfindung können Datenverarbeitungseinrichtungen verschiedene Komponenten enthalten, die in der Lage sind, Anweisungen auszuführen, um eine Ausführungsform der vorliegenden Erfindung zu erreichen. Beispielsweise können die Datenverarbeitungseinrichtungen mindestens ein maschinenzugängliches Medium enthalten und/oder daran gekoppelt sein. Wie der Ausdruck in dieser Beschreibung verwendet wird, beinhaltet eine „Maschine” unter anderem jede Datenverarbeitungseinrichtung mit einem oder mehreren Prozessoren. Wie in dieser Beschreibung verwendet, beinhaltet ein maschinenzugängliches Medium jeden Mechanismus, der Informationen in beliebiger Form speichert und/oder überträgt, die durch eine Datenverarbeitungseinrichtung zugänglich sind, wobei das maschinenlesbare Medium unter anderem beschreibbare/nicht beschreibbare Medien (wie etwa einen Festwertspeicher (ROM), Direktzugriffsspeicher (RAM), magnetische Plattenspeicherungsmedien, optische Speicherungsmedien und Flash-Speichereinrichtungen) sowie elektrische, optische, akustische oder eine andere Form ausgebreiteter Signale (wie etwa Trägerwellen, Infrarotsignale und digitale Signale) beinhaltet.
Gemäß einer Ausführungsform kann in eine Datenverarbeitungseinrichtung verschiedene andere wohlbekannte Komponenten wie etwa einen oder mehrere Prozessoren enthalten. Der oder die Prozessoren und maschinenzugänglichen Medien können unter Verwendung eines Brücken-/Speichercontrollers kommunikativ gekoppelt sein, und der Prozessor kann in der Lage sein, in den maschinenzugänglichen Medien gespeicherte Anweisungen auszuführen. Der Brücken-/Speichercontroller kann an einen Grafikcontroller gekoppelt sein, und der Grafikcontroller kann die Ausgabe von Displaydaten auf einer Displayeinrichtung steuern. Der Brücken-/Speichercontroller kann an einen oder mehrere Busse gekoppelt sein. Ein Host-Bus-Host-Controller wie etwa ein USB-Host-Controller (Universal Serial Bus) kann an den/die Busse gekoppelt sein, und mehrere Einrichtungen können an den USB gekoppelt sein. Beispielsweise können Benutzereingabeeinrichtungen wie etwa eine Tastatur und Maus in der Datenverarbeitungseinrichtung zur Bereitstellung von Eingabedaten enthalten sein.
In der vorausgegangenen Beschreibung ist die Erfindung unter Bezugnahme auf spezifische Ausführungsbeispiele davon beschrieben worden. Es versteht sich jedoch, daß daran zahlreiche Modifikationen und Änderungen vorgenommen werden können, ohne vom breiteren Gedanken und Schutzbereich von Ausführungsformen der Erfindung abzuweichen, wie in den beigefügten Ansprüchen dargelegt. Die Beschreibung und Zeichnungen sind entsprechend eher in einem veranschaulichenden denn einem einschränkenden Sinne anzusehen.

Claims

Verfahren zum Sicherstellen eines zuverlässigen Zugangs zu einem Mobilknoten, umfassend: Abfangen (401) einer Care-of-Adresse-(„COA”)-Anforderung, wobei die COA-Anforderung einen Mobilknoten-Hostnamen enthält; Lenken der COA-Anforderung an ein Konfigurationsmodul innerhalb eines Netzstapels, der an den Mobilknoten gekoppelt ist; Ersetzen (403), durch das Konfigurationsmodul, des Mobilknoten-Hostnamens in der COA-Anforderung durch einen konfigurierten Alternativnamen vor einem Weiterreichen (404) der COA-Anforderung mit dem konfigurierten Alternativnamen an einen Physical Layer innerhalb des Netzstapels, der an den Mobilknoten gekoppelt ist; und Senden der COA-Anforderung mit dem konfigurierten Alternativnamen an einen Server.
Verfahren nach Anspruch 1, weiterhin umfassend: Abfangen (401), durch das Konfigurationsmodul auf dem Mobilknoten, einer COA-Antwort von dem Server, wobei die COA-Antwort von dem Server als Antwort auf die COA-Anforderung mit dem konfigurierten Alternativnamen gesendet wird und wobei die COA-Antwort den konfigurierten Alternativnamen enthält; Ersetzen (405), durch das Konfigurationsmodul, des konfigurierten Alternativnamens durch den Mobilknoten-Hostnamen und Senden (406), durch das Konfigurationsmodul, der COA-Antwort mit dem Mobilknoten-Hostnamen den Netzstapel des Mobilknotens hoch.
Verfahren nach Anspruch 2, das weiterhin ein Senden einer Registrierungsanforderung zum Abbilden eines Eintrags für den Mobilknoten-Hostnamen und der Mobilknoten-Home-Adresse in einem DNS-(Domain Name System)-Server umfasst.
Verfahren nach Anspruch 3, wobei das Senden der Registrierungsanforderung ein Senden einer Mobile-IP-Registrierungsanforderung mit einer Hostnamen-Erweiterung umfaßt.
Verfahren nach Anspruch 1, wobei der Server einen DHCP-(Dynamic Host Configuration Protocol)-Server umfaßt und die COA-Anforderung eine DHCP-Anforderung enthält.
System zum Sicherstellen eines zuverlässigen Zugangs zu einem Mobilknoten, umfassend: einen Mobilknoten, der in der Lage ist, eine Care-of-Adressen-(„COA”)-Anforderung zu senden, wobei die COA-Anforderung einen Mobilknoten-Hostnamen enthält; ein Konfigurationsmodul innerhalb eines Netzstapels, der an den Mobilknoten gekoppelt ist, wobei das Konfigurationsmodul in der Lage ist, die COA-Anforderung abzufangen, und wobei das Konfigurationsmodul weiterhin in der Lage ist, den Mobilknoten-Hostnamen in der COA-Anforderung durch einen konfigurierten Alternativnamen zu ersetzen, wobei das Konfigurationsmodul zusätzlich in der Lage ist, die COA-Anforderung mit dem konfigurierten Alternativnamen an einen Physical Layer im Netzstapel, der an den Mobilknoten gekoppelt ist, neuzusenden und einen Server, der in der Lage ist, die COA-Anforderung zu empfangen.
System nach Anspruch 6, wobei der Server weiterhin in der Lage ist, auf die COA-Anforderung mit dem konfigurierten Alternativnamen zu antworten, und wobei der Server zusätzlich in der Lage ist, eine COA-Antwort an den Mobilknoten zu senden, wobei die COA-Antwort den konfigurierten Alternativnamen enthält.
System nach Anspruch 7, wobei das Konfigurationsmodul auf dem Mobilknoten weiterhin in der Lage ist, die COA-Antwort abzufangen und den konfigurierten Alternativnamen in der COA-Antwort durch den Mobilknoten-Hostnamen zu ersetzen, wobei das Konfigurationsmodul zusätzlich in der Lage ist, die COA-Antwort den Netzstapel, der an den Mobilknoten gekoppelt ist, hoch zu senden.
System nach Anspruch 6, weiterhin mit einem DNS-(Domain Name System)-Server, der in der Lage ist, einen Eintrag für den Mobilknoten-Hostnamen und die Mobilknoten-Home-Adresse abzubilden.
System nach Anspruch 6, wobei der Server einen DHCP-(Dynamic Host Configuration Protocol)-Server umfaßt und die COA-Anforderung eine DHCP-Anforderung umfaßt.
System nach Anspruch 6, wobei sich das Konfigurationsmodul innerhalb des Netzstapels befindet und der Netzstapel auf dem Mobilknoten ist.
System zum Sicherstellen eines zuverlässigen Zugangs zu einem Mobilknoten, umfassend: einen Mobilknoten, der in der Lage ist, eine Care-of-Adressen-(„COA”)-Anforderung zu senden, wobei die COA-Anforderung einen Mobilknoten-Hostnamen enthält; und ein Konfigurationsmodul in einem Netzstapel, der an den Mobilknoten gekoppelt ist, wobei das Konfigurationsmodul in der Lage ist, die COA-Anforderung abzufangen und den Mobilknoten-Hostnamen durch einen konfigurierten Alternativnamen zu ersetzen, wobei das Konfigurationsmodul weiterhin in der Lage ist, die COA-Anforderung mit dem konfigurierten Alternativnamen den Netzstapel hinunter an einen Physical Layer weiterzureichen, wobei die COA-Anforderung mit dem konfigurierten Alternativnamen danach an einen Server neugesendet wird.
System nach Anspruch 12, wobei das Konfigurationsmodul in der Lage ist, eine COA-Antwort von dem Server abzufangen, wobei die COA-Antwort den konfigurierten Alternativnamen enthält, wobei das Konfigurationsmodul weiterhin in der Lage ist, den konfigurierten Alternativnamen durch den Mobilknoten-Hostnamen zu ersetzen, wobei das Konfigurationsmodul zusätzlich in der Lage ist, die COA-Antwort mit dem Mobilknoten-Hostnamen den Netzstapel, der an den Mobilknoten gekoppelt ist, hoch zu senden.
System nach Anspruch 12, wobei der Server einen DHCP-(Dynamic Host Configuration Protocol)-Server umfaßt und die COA-Anforderung eine DHCP-Anforderung umfaßt.
System nach Anspruch 12, wobei der Mobilknoten das Konfigurationsmodul enthält.
Vorrichtung zum Sicherstellen eines zuverlässigen Zugangs zu einem Mobilknoten, umfassend: ein Konfigurationsmodul in einem Netzstapel, das in der Lage ist, eine Care-of-Adressen-(„COA”)-Anforderung vom Mobilknoten abzufangen, wobei die COA-Anforderung einen Mobilknoten-Hostnamen enthält, wobei das Konfigurationsmodul weiterhin in der Lage ist, den Mobilknoten-Hostnamen durch einen konfigurierten Alternativnamen zu ersetzen, und wobei das Konfigurationsmodul weiterhin in der Lage ist, die COA-Anforderung mit dem konfigurierten Alternativnamen den Netzstapel hinunter an einen Physical Layer weiterzureichen, um neugesendet zu werden.
Vorrichtung nach Anspruch 16, wobei das Konfigurationsmodul in der Lage ist, eine COA-Antwort abzufangen, und wobei die COA-Antwort den konfigurierten Alternativnamen enthält, wobei das Konfigurationsmodul weiterhin in der Lage ist, den konfigurierten Alternativnamen durch den Mobilknoten-Hostnamen zu ersetzen, wobei das Konfigurationsmodul zusätzlich in der Lage ist, die COA-Antwort mit dem Mobilknoten-Hostnamen den Netzstapel, der an den Mobilknoten gekoppelt ist, hoch neuzusenden.
Maschinenzugreifbares Medium mit darauf gespeicherten Anweisungen, die, wenn durch eine Maschine ausgeführt, bewirken, daß die Maschine: eine Care-of-Adressen-(„COA”)-Anforderung vom Mobilknoten abfängt, wobei die COA-Anforderung einen Mobilknoten-Hostnamen enthält; die COA-Anforderung an ein Konfigurationsmodul innerhalb eines Netzstapels auf dem Mobilknoten lenkt; den Mobilknoten-Hostnamen in der COA-Anforderung durch einen konfigurierten Alternativnamen ersetzt vor einem Weiterreichen der COA-Anforderung mit dem konfigurierten Alternativnamen von dem Konfigurationsmodul an einen Physical Layer innerhalb des Netzstapels, der an den Mobilknoten gekoppelt ist, und die COA-Anforderung mit dem konfigurierten Alternativnamen an einen Server sendet.
Maschinenzugreifbares Medium nach Anspruch 18, wobei die Anweisungen bei Ausführung durch die Maschine weiterhin bewirken, daß die Maschine: durch das Konfigurationsmodul eine COA-Antwort von dem Server abfängt, wobei die COA-Antwort von dem Server als Antwort auf die COA-Anforderung mit dem konfigurierten Alternativnamen gesendet wird, und wobei die Antwort-COA den konfigurierten Alternativnamen enthält; durch das Konfigurationsmodul den konfigurierten Alternativnamen durch den Mobilknoten-Hostnamen ersetzt und die COA-Antwort mit dem Mobilknoten-Hostnamen von dem Konfigurationsmodul den Netzstapel, der an den Mobilknoten gekoppelt ist, hoch sendet.
Maschinenzugreifbares Medium nach Anspruch 19, wobei die Anweisungen bei Ausführung durch die Maschine weiterhin bewirken, daß die Maschine eine Registrierungsanforderung zum Abbilden eines Eintrags für den Mobilknoten-Hostnamen und die Mobilknoten-Home-Adresse in einem DNS-(Domain Name System)-Server sendet.
Maschinenzugreifbares Medium nach Anspruch 20, wobei die Anweisungen bei Ausführung durch die Maschine weiterhin bewirken, daß die Maschine eine Mobile-IP-Registrierungsanforderung mit einer Hostnamen-Erweiterung sendet.
Maschinenzugreifbares Medium nach Anspruch 19, wobei der Server einen DHCP-(Dynamic Host Configuration Protocol)-Server umfaßt und die COA-Anforderung eine DHCP-Anforderung enthält.