DE60218144T2

DE60218144T2 - Verfahren und Vorrichtung zur Routenoptimierung in geschachtelten mobilen Netzwerken

Info

Publication number: DE60218144T2
Application number: DE60218144T
Authority: DE
Inventors: Christophe Janneteau; Alexis Olivereau; Alexandru Petrescu; Hong-Yon Lach
Original assignee: Motorola Inc
Current assignee: Motorola Mobility LLC
Priority date: 2002-06-19
Filing date: 2002-06-19
Publication date: 2007-10-31
Anticipated expiration: 2022-06-20
Also published as: AU2003250832A1; WO2004002106A2; WO2004002106A3; DE60218144D1; CN1663217A; EP1376973B1; US20050226189A1; EP1376973A1; AU2003250832A8; US7430174B2; ATE354241T1

Description

Gebiet der Erfindung
Diese Erfindung bezieht sich auf Telekommunikationssysteme, in denen Daten zwischen mobilen Knoten, zum Beispiel Personal Digital Assistants mit Fähigkeit zur drahtlosen Kommunikation, und einem Datennetz, zum Beispiel dem Internet, fließen.
Hintergrund der Erfindung
Das Internet wird immer beliebter und Benutzer möchten zunehmend auf das Internet zugreifen, während sie unterwegs sind. Zu diesem Zweck können unterschiedliche Typen von mobilen Knoten (d. h. mobilen Kommunikationseinheiten), zum Beispiel ein Mobiltelefon oder ein Personal Digital Assistant(PDA) mit Fähigkeit zur drahtlosen Kommunikation, verwendet werden.
Mobile Benutzer greifen zunehmend über unterschiedliche Typen von festen oder drahtlosen Zugangsnetzen, zum Beispiel ein zellulares Funkkommunikationsnetz, wie z. B. ein Universal Mobile Telecommunication System (UMTS)-Netz, ein HiperLAN/2 oder IEEE 802.11b Lokalnetz, ein Bluetooth-Lokalkommunikationssystem, oder feste Zugänge, wie z. B. das Ethernet und so weiter, auf das Internet zu. Die Datenroute zwischen dem mobilen Knoten und dem Internet umfasst darüber hinaus ein Internetprotokollsubnetz (IP-Subnetz), so dass die Route ist wie folgt: Mobiler Knoten – Zugangsnetz – IP-Subnetz – Internet (und umgekehrte Reihenfolge für die Datenroute von dem Internet zu dem mobilen Knoten).
Ein Beispiel für ein Netz, das mobile Netzknoten unterstützt, wird in der europäischen Patentanmeldung EP 0 578 041 offenbart, wobei Loose Source Routing (LSR) verwendet wird, um Datenpakete entlang einem Pfad zu einem mobilen Knoten zu routen.
Gegenwärtig ist, zum Beispiel durch Verwendung eines Protokolls, das als Mobile IP bekannt ist, ein nahtloses Handover des Zugangs zu dem Internet von einem Zugangsnetz zu einem anderen möglich.
Herkömmliche Mobilitätsunterstützung ist bestrebt, kontinuierliche Internet-Konnektivität zu mobilen Hosts zur Verfügung zu stellen, wodurch es individuellen mobilen Benutzern ermöglicht wird, sich mit dem Internet zu verbinden, während sie mobil sind und ihren Internetzugangsstandort ändern. Demgegenüber beschäftigt sich Netzmobilitätsunterstützung mit Situationen, wo ein gesamtes Netz seinen Verbindungspunkt zu der Internettopologie und somit seine Zugänglichkeit in der Topologie ändert. Solch ein Netz in Bewegung kann als ein mobiles Netz bezeichnet werden.
Es gibt eine große Anzahl von Szenarien, wo solche mobilen Netze vorhanden sind. Zum Beispiel ist ein Personal Area Network (PAN, d. h. ein Netz von mehreren persönlichen Geräten, einem Einzelnen zugeordnet) bekannt, wobei das PAN seinen Verbindungspunkt zu der Internettopologie ändert, während der Benutzer in einem Einkaufszentrum spazieren geht. Darüber hinaus kann ein Netz in einem Bus oder einem Flugzeug eingebettet sein, so dass für Passagiere ein bordeigener Internetzugang zur Verfügung gestellt wird. Ein Passagier kann ein einzelnes Kommunikationsgerät (z. B. ein Laptop) verwenden oder selbst ein mobiles Netz (z. B. ein PAN) sein. Insbesondere stellt diese Konfiguration einen Fall eines mobilen Netzes, das ein mobiles Netz besucht, (d. h. geschachtelte Mobilität) dar.
Als solches kann ein mobiles Netz als ein Satz von Knoten, bestehend aus einem oder mehreren IP-Subnetzen, einem mobilen Router (MR) zugeordnet, definiert werden. Diese IP-Subnetze können auch als eine mobile Einheit mit Bezug auf den Rest des Internets, d. h. ein MR und all seine zugeordneten Knoten (so genannte mobile Netzknoten oder MNNs), betrachtet werden.
Ein Dokument [1], IETF Internet-Draft draft-ernstmonet-terminology-00.txt, Februar 2002, verfasst von Thierry Ernst, Hong-Yon Lach, beschreibt eine Liste von Definitionen für die mobile Netz-Terminologie, die in dieser An wendung angewendet werden kann. Insbesondere können die folgenden Begriffe definiert werden wie folgt:

(i) ein lokaler fester Knoten (LFN): Ein Knoten, der sich permanent innerhalb des mobilen Netzes befindet und der seinen Verbindungspunkt nicht ändert. Ein LFN kann entweder ein lokaler fester Host (LFH) oder ein lokaler fester Router (LFR) ein;
(ii) ein lokaler mobiler Knoten (LMN): Ein lokaler mobiler Knoten ist einer, der zu dem mobilen Netz gehört und seinen Verbindungspunkt von einer Verbindung innerhalb des mobilen Netzes zu einer anderen Verbindung innerhalb oder außerhalb des mobilen Netzes ändert. In diesem Zusammenhang kann angenommen werden, dass die Heimatverbindung des LMN eine Verbindung innerhalb des mobilen Netzes ist. Ein LMN kann entweder ein lokaler mobiler Host (LMH) oder ein lokaler mobiler Router (LMR) sein;
(iii) ein besuchender mobiler Knoten (VMN): Ein VMN ist einer, der nicht zu dem mobilen Netz gehört und seinen Verbindungspunkt von einer Verbindung außerhalb des mobilen Netzes zu einer Verbindung innerhalb des mobilen Netzes ändert (d. h. bei der Heimatverbindung des VMN handelt es sich nicht um eine Verbindung innerhalb des mobilen Netzes). Ein VMN, der sich mit einer Verbindung innerhalb des mobilen Netzes verbindet, erhält eine Adresse auf derjenigen Verbindung. Ein VMN kann entweder ein besuchender mobiler Host (VMH) oder ein besuchender mobiler Router (VMR) sein;
(iv) eines mobilen Netzes Präfix (bzw. Mobiles-Netz-Präfix): Eine Bitfolge, die aus einer Anzahl von Anfangsbits einer IP-Adresse besteht, die ein mobiles Netz innerhalb der Internettopologie identifiziert. Knoten, die zu dem mobilen Netz gehören (d. h. zumindest MR, LFNs und LMNs) teilen denselben IPv6-"Netzbezeichner'". Für ein einzelnes mobiles IP-Subnetz ist des mobilen Netzes Päfix der "Netzbezeichner" dieses Subnetzes;
(v) eine Egress-Schnittstelle eines MR: Dabei handelt es sich um die Schnittstelle, die der Heimatverbindung zugeordnet ist, falls sich das mobile Netz zu Hause befindet. Alternativ handelt es sich dabei um die Schnittstelle, die einer fremden Verbindung zugeordnet ist, falls sich das mobile Netz in einem fremden Netz befindet;
(vi) eine Ingress-Schnittstelle eines MR: Dabei handelt es sich um die Schnittstelle, die einer Verbindung innerhalb des mobilen Netzes zugeordnet ist. Das Konzept von Egress- und Ingress-Schnittstellen kann auf weitere Knotentypen innerhalb eines mobilen Netzes wie folgt erweitert werden: (a) Alle Netzschnittstellen von Hosts (fest oder mobil) in einem mobilen Netz gelten als Egress-Schnittstellen. Keine von ihnen gilt als eine Ingress-Schnittstelle. (b) Ein fester Router in einem mobilen Netz (d. h. LFR) kann etliche Egress- und Ingress-Schnittstellen auf weisen. Der Typ jeder Schnittstelle sollte auf solchen Routern vorkonfiguriert sein. Bei einer Egress-Schnittstelle handelt es sich gewöhnlich um eine Schnittstelle auf dem kürzesten Pfad zu einem mobilen Router. Ein fester Router in einem mobilen Netz sollte zumindest eine Egress-Schnittstelle aufweisen.
(vii) Ein MR kann mehrere Egress- und Ingress-Schnittstellen aufweisen.
(viii) Ein mobiles Netz kann mehrere MRs aufweisen.

In letzter Zeit hat es eine Menge Interesse an und Untersuchungen über die Mobile IPv6-Spezifikation gegeben, wie in dem Dokument [2]: IETF Internet-Draft draft-ietfmobileip-ipv6-15.txt, Juli 2001, verfasst von David B. Johnson, beschrieben. Eine grobe Besorgnis bei Mobile IPv6 besteht darin, dass die Untersuchungen erwiesen haben, dass der IPv6-Standard gegenwärtig nicht im Stande ist, Netzmobilität angemessen anzugehen. Insbesondere beschreibt das von Thierry Ernst und Hong-Yon Lach verfasste Dokument [3]: IETF Internet-Draft draft-ernst mobileip-v6-network-02.txt, Juni 2001, ausführlich Probleme, auf die man bei Mobile IPv6 beim Unterstützen mobiler Netze stößt. Auch in einer Doktorarbeit von Thierry Ernst, "Network Mobility Support in IPv6", Thesis Department of Mathematics and Computer Science of Universite Joseph Fourier, 29. Oktober 2001, XP-002215680, wurden Betrachtungen über IPv6-Netzmobilität angestellt.
Zusammengefasst ist ermittelt worden, dass, auch wenn eines MRs Heimatagent, also Home Agent (HA) im Stande ist, Pakete abzufangen, die an MNNs adressiert sind, die hinter dem MR arbeiten, des MRs HA eindeutig nicht im Stande ist, sie zu der Care-of-Adresse des geeigneten MR zu kapseln. Man beachte, dass jedes Datenpaket eine Quelladresse und eine Zieladresse aufweist. Bei einem getunnelten Paket handelt es sich um ein Paket, das ein anderes Paket in sich kapselt. Folglich weist das kapselnde Paket ein Paar von Quell- und Zieladressen auf. Ein weiteres gekapseltes Paket weist zusätzliche Quell- und Zieladressen auf.
Die Unkenntnis über einen wahren Standort eines bestimmten MNN resultiert daraus, dass der HA keine (geschweige denn eine bevorzugte) Datenroute zu dem mobilen Netz kennt, sobald ein 'besuchter' Standort erreicht wurde. Wenn sich ein MR bei seinem HA registriert, informiert der MR den HA leider nur darüber, eine hostspezifische Route in seiner Routing-Tabelle zu registrieren. Die Erfinder der vorliegenden Erfindung haben erkannt, dass eine bevorzugte Netzroute, erzeugt unter Verwendung der mobilen Netzadresse (Präfix, Präfixlänge und Care-of-Adresse) des geeigneten MR, in dieser Angelegenheit außerordentlich hilfreich wäre.
Auf dem Gebiet dieser Erfindung beschreibt die Mobile IPv4-Spezifikation, ausführlich in [4] C. Perkins, IETF RFC 3220, "IP Mobility Support for IPv4", Standards Track, Januar 2002, beschrieben, wie Netzmobilität in dem Fall von IPv4-Mobilität unterstützt werden kann. Allerdings ist auch festgestellt worden, dass IPv4 keine Routenoptimierung für MNNs hinter dem MR unterstützt.
Folglich wird all der (eingehende und ausgehende) Verkehr zwischen einem MNN und seinen korrespondierenden Knoten (CNs) an des MRs Home Agent übermittelt. Dieses Problem wird in dem Fall von geschachtelter Mobilität verschlimmert, wo ein CN Daten an einen MNN, der hinter einer Anzahl von MR-Verbindungen ist, oder einen mobilen Knoten, der ein mobiles Netz besucht, übermitteln möchte. In dem Fall geschachtelter Mobilität wird das Paket somit als Folge dessen, dass es durch all die Home Agents all der geschachtelten MRs geroutet wird, etliche Male gekapselt. Dabei handelt es sich eindeutig um ineffizientes Routing.
Ähnlich beschreibt in dem Fall von IPv6 das Dokument [5]: IETF Internet-Draft draft-kniveton-mobrtr-00.txt, November 2001, verfasst von T. J. Kniveton, wie mobile Netze mit keinen Modifikationen an Mobile IP (v4 oder v6) zu unterstützen sind. Der Mechanismus, der vorgeschlagen wird, um die Unterstützung geschachtelter Mobilität anzugehen, wird mit Bezug auf 2 beschrieben. Er leidet unter demselben Problem eines multiplen Tunnelings durch die Home Agents der geschachtelten mobilen Router wie in dem vorherigen Absatz beschrieben. Wenn ein MR, zum Beispiel MR2 260, sich mit einem besuchten Netz 110 (über eine andere mobile Netz MR1-Verbindung) verbunden hat, wird ein bidirektionaler Tunnel 210, 215, 220 zwischen MR2 260 und seinem HA – HA2 250 – errichtet. Wenn ein Knoten, zum Beispiel LFN2 165, MR2 260 zugeordnet ist und über das Internet 115 ein IP-Paket an einen CN, sagen wir mal CN2 255, senden möchte, wird dasjenige Paket durch MR2 260 (zu HA2 250) und erneut durch MR1 150 (zu HA1 240) getunnelt. Das mehrfach getunnelte Datenpaket wird dann zu dem HA des letzten MR, nämlich zu HA1 240, übertragen, um die Daten zu tunneln. HA1 240 leitet sie dann über des Quell-MRs HA, nämlich HA2 250, an den beabsichtigten Empfänger CN2 255 weiter.
Dieses vorgeschlagene Datenroutingverfahren und die damit verbundenen Probleme werden am besten über ein Beispiel beschrieben. Lassen Sie uns deshalb annehmen, dass LFN2 165 ein Datenpaket zu CN2 255 sendet. Das Datenpaket wird erst zu MR2 260 geroutet 205. Das Datenpaket wird dann durch MR2 260 zum Senden an HA2 250 getunnelt. Dieser Tunnelingprozess des Datenpakets von MR2 260 zu HA2 250 wird aus Notwendigkeit selbst erst zu seinem verbundenen MR, nämlich MR1 150, geroutet 210. MR1 150 tunnelt die Daten weiter und leitet 215 das mehrfach getunnelte Paket zu seinem HA, nämlich HA 1 240, weiter. HA1 240 enttunnelt das Datenpaket wie durch MR1 150 getunnelt und leitet 220 das teilweise enttunnelte Paket an seinen ursprünglichen beabsichtigten Empfänger, HA2 250, weiter. HA2 250 enttunnelt das Paket wie durch MR2 260 getunnelt weiter und leitet 225 das voll enttunnelte Datenpaket an CN2 255 weiter.
Die vorgeschlagene Lösung stellt eindeutig keine Unterstützung zur Routenoptimierung zur Verfügung, da sowohl eingehende als auch ausgehende Pakete durch den Home Agent beider MRs 150, 260 geroutet werden. Tatsächlich folgen Pakete von CN2 255, an LFN2 165 adressiert, demselben Pfad (in umgekehrter Reihenfolge) und werden dann durch jeden Home Agent 240, 250 jedes der geschachtelten MRs 150, 260 gekapselt. Dabei handelt es sich, insbesondere für eine praktische Situation, wonach es viel mehr als zwei Ebenen in dem geschachtelten Netz geben kann, erneut eindeutig um ineffizientes Routing.
Die Lösung, die in einem von Thierry Ernst und Hong-Yon Lach verfassten Dokument IETF Internet-Draft drafternst-mobileip-v6-network-02.txt, Juni 2001, vorgestellt wird, schlägt ein Mittel zum Unterstützen von Netzmobilität in dem Framework von Mobile IPv6 vor. Diese Lösung stellt das folgende Konzept vor: wenn ein mobiler Router zu einem besuchten Netz roamt, sendet er ein Prefix Scope Binding Update an seinen Home Agent (HA). Im Gegensatz zu einer klassischen Mobile IPv6 Binding Update-Nachricht bindet ein Prefix Scope Binding Update eine Heimatadresse nicht mit einer Care-of-Adresse.
Demgegenüber wird für einen bestimmten MR das MR-Präfix mit der MR-Care-of-Adresse gebunden. Nach Empfang eines Pakets, dessen Präfix dem MR-Präfix entspricht, muss der Home Agent das Paket dann an die MR-Care-of-Adresse tunneln, die als diejenige, die im Stande ist, das getunnelte Paket an den beabsichtigten Empfänger zu übermitteln, identifiziert worden ist. Ähnlich kann ein MR Prefix Scope BUs zu den korrespondierenden Knoten der Knoten, die er versorgt, senden. Diese Lösung bringt eine effizientere Unterstützung von mobilen Netzen für Mobile IPv6, da sie eine begrenzte Verbesserung zur Routenoptimierung zur Verfügung stellen kann.
Allerdings hat der Umfang dieses Drafts ausdrücklich den Fall geschachtelter Mobilität ausgeschlossen, was ein wesentliches Hindernis für eine effiziente Routenoptimie rung darstellt. Als solches schafft es die in dem Thierry Ernst-Dokument IETF Internet-Draft draft-ernst-mobileip-v6-network-02.txt vorgeschlagene Lösung, Juni 2001, in vielen praktischen Situationen nicht, eine nützliche Lösung zur Routenoptimierung zur Verfügung stellen. Die Probleme, die insbesondere in dem Fall geschachtelter Mobilität aus diesem Dokument hervorgehen, werden erneut am besten in einer Beispielsituation aufgezeigt.
Bezieht man sich nun auf 3, erkennt man, dass ein Mechanismus zum Routen von Datenpaketen in einem IPv6-Netz unter Verwendung des Vorschlags von Thierry Ernst: IETF Internet-Draft draft-ernst-mobileip-v6-network-02.txt, Juni 2001, dargestellt wird. Insbesondere werden die Probleme, die von der Verwendung dieses Mechanismus in einer geschachtelten Mobilität herrühren, hervorgehoben.
Ein mobiler Router MR1 150 ist einer besuchten Verbindung 110 zugeordnet. Ein mobiler Router MR2 260 ist MR1s Verbindung 155 zugeordnet. Ein lokaler fester Knoten LFN2 165 ist MR2s Verbindung 230 zugeordnet. Lassen Sie uns erneut annehmen, dass LFN2 165 versucht, mit einem korrespondierenden Knoten CN2 255 zu kommunizieren.
Lassen Sie uns darüber hinaus annehmen, dass zu Beginn des einfachen Szenarios, das in 3 ausführlich dargestellt wird, MR1 150 und MR2 260 schon BU-Nachrichten an ihre entsprechenden HAs 240, 250 gesendet haben. Das heißt, HA1 240 weiß, dass MR1s 150 Präfix unter MR1s Care-of-Adresse erreichbar ist. Desgleichen weiß HA2 250, dass MR2s 260 Präfix unter MR2s Care-of-Adresse erreichbar ist.
Wenn ein Datenpaket von CN2 255 zu LFN2 165 gesendet wird, hat CN2 255 keine Kenntnis von dem tatsächlichen Standort von LFN2 165. Folglich wird deshalb das Datenpaket, das er sendet, zu einer Heimatverbindung-2 105 geroutet 325. HA2 250 fängt das Datenpaket ab und tunnelt es an MR2s Care-of-Adresse. Das versteht sich, da HA2 250 weiß, dass MR2s Präfix unter MR2s Care-of-Adresse erreichbar ist.
Dieses getunnelte Paket (von HA2 250 zu MR2s 260 Care-of-Adresse) wird zu einer Verbindung-1 245 geroutet 320, da MR2s 260 Care-of-Adresse MR1s 150 Präfix entspricht. HA1 240 fängt das Datenpaket ab und tunnelt es an MR1s Care-of-Adresse, nämlich zu der besuchten Verbindung 110, da HA1 240 weiß, dass MR1s Präfix unter MR1s Care-of-Adresse erreichbar ist.
MR1 150 enttunnelt dann das von HA1 240 empfangene Datenpaket. MR1 150 leitet dann den Inhalt an den ursprünglichen Empfänger, MR2 260, weiter. Unterdessen sendet MR1 150 ein Binding Update an den Sender des gekapselten Pakets (das heißt HA2 250), um ihn zu informieren, dass MR1s Präfix unter MR1s Care-of-Adresse erreichbar ist. Man beachte, dass es sich aus MR1-Sicht bei HA2 250 um einen korrespondierenden Knoten und nicht seinen Home Agent handelt (d. h. das 'H'-Bit in dem BU ist nicht gesetzt). Es bleibt dem HA2 250 überlassen, dieses Binding Update zu akzeptieren oder nicht.
MR2 260 enttunnelt das Datenpaket, das er empfangen hat (d. h. den Teil des Datenpakets, der durch HA2 250 gekapselt worden war) und leitet den Inhalt (das Anfangspaket von CN2 255) an LFN2 165 weiter. Unterdessen sendet MR2 260 eine Binding Update-Nachricht an den Sender des gekapselten Pakets (das heißt CN2 255), um ihn zu informieren, dass MR2s Präfix (die LFN2 165-Adresse umfassend) unter MR2s Care-of-Adresse erreichbar ist. Diese Information wird in des CNs Binding Cache 370 gespeichert.
Sobald ein Anfangspaket sein Ziel erreicht hat, führt eine Übertragung eines zweiten oder nachfolgenden Pakets von CN2 255 an LFN2 165 zu dem in 4 dargestellten Szenario. Nach Überprüfung seines Binding Cache 370 erkennt CN2 255, dass LFN2 165 unter MR2s Care-of-Adresse erreichbar ist.
Folglich sendet er das Datenpaket mit einem Routing-Header für LFN2 165 an MR2s Care-of-Adresse. MR2s Care-of-Adresse gehört zu MR1s Verbindung und wird deshalb zu der Heimatverbindung-1 245 geroutet. Auf diese Weise wird dadurch, dass die Übertragung des Datenpakets zu und von HA2 250 umgangen wird, eine geringfügige Verbesserung zur Routenoptimierung erzielt.
HA1 240 fängt dann das Datenpaket ab und tunnelt das Paket an MR1s Care-of-Adresse, da HA1 240 weiß, dass MR1s Präfix unter MR1s Care-of-Adresse erreichbar ist.
MR1 150 enttunnelt das Paket von HA1 240 und leitet den Inhalt an den mobilen Router MR2 260 des ursprünglich beabsichtigten Empfängers, LFN2 165, weiter. Unterdessen sendet MR1 150 ein Binding Update an den Sender des gekapselten Pakets (das heißt CN2 255), um ihn darüber zu infor mieren, dass MR1s Präfix unter MR1s Care-of-Adresse erreichbar ist.
Bei Empfang des Originalpakets wie durch CN2 255 gesendet ersetzt MR2 260 seine Adresse in dem Zielfeld des Pakets durch die Adresse, die in dem Routing-Header umfasst ist (das heißt LFN2 165), und leitet das Datenpaket an den endgültigen Empfänger weiter.
Die Erfinder der vorliegenden Erfindung haben ein wesentliches Problem bei dem in 4 dargestellten Szenario identifiziert. Alle nachfolgenden Pakete von CN2 255 an LFN2 165 werden in exakt derselben Weise wie das zweite Datenpaket geroutet. Das heißt, es gibt keine nachfolgende Verbesserung in Richtung Routenoptimierung. Das wird in Bezug auf 5 deutlicher dargestellt.
Bezieht man sich nun auf 5, erkennt man, dass ein bekannter Binding Cache 500 dargestellt wird. Der Binding Cache umfasst eine Liste von Einträgen, die für jeden MR in einem Szenario geschachtelter Mobilität spezifisch sind. Die Binding Cache-Einträge umfassen zum Beispiel ein MR3-Präfix und Präfixlänge 530 mit einer Verbindung 532 zu einer ermittelten MR3-Care-of-Adresse 534, falls eine ermittelt worden ist. Der MR3-Eintrag 535 ist mit dem nächsten Eintrag in dem Binding Cache, nämlich demjenigen für MR2, verbunden 536. Das MR2-Präfix und Präfixlänge 520 umfasst eine Verbindung 522 zu einer ermittelten MR2-Care-of-Adresse 524, falls eine ermittelt worden ist. Eine ähnliche Anordnung und Verbindung 526 wird zu MR1 ausgeführt und so weiter.
Darüber hinaus umfassen die Binding Cache-Einträge einen Flageintrag (nicht dargestellt). Ein 'P'-Flag ist das "Prefix Scope Registration"-Flag. Wenn es gesetzt ist, wird ein Feld "Heimatadresse" mit dem Präfix des mobilen Netzes (dem Präfix, das durch den mobilen Router bekannt gemacht wird) gefüllt und die "Präfixlänge" entspricht der Länge des Präfixes des mobilen Netzes.
In dem Dokument von Thierry Ernst: IETF Internet-Draft draft-ernst-mobileip-v6-network-0.2.txt, Juni 2001, wird spezifiziert, dass der Binding Cache nach einem Eintrag entsprechend der Zieladresse des Pakets in einem Durchgang durchsucht wird. Als Ergebnis der Suche ist entweder nichts gefunden worden (kein Eintrag) oder es ist die volle Adresse gefunden worden (128-Bit Übereinstimmung für eine IPv6-Adresse, P-Flag gelöscht) oder die ersten Bits der Zieladresse entsprechen einem registrierten Präfix für die registrierte Präfixlänge. In dem letzteren Falle befindet sich das Ziel in einem mobilen Netz.
Mit Bezug auf 4 überprüft CN2 255 deshalb noch seinen Binding Cache und findet den Eintrag 'MR2 260-Präfix erreichbar unter MR2 260 Co@' 520, 524, wenn CN2 255 ein Paket an LFN2 165 senden muss. CN2 255 erwägt den Eintrag 'MR1 150-Präfix erreichbar unter MR1 CO@' 510, 514 nicht einmal, da dies keinen Bezug zu der LFN2-Adresse zu haben scheint. Die Erfinder haben erkannt, dass sich diese Unzulänglichkeit daraus ergibt, dass die LFN2 165-Adresse ohne Beziehung zu dem MR1-Präfix ist. Die Tatsache, dass MR2 260 Co@ zu dem MR1-Präfix gehört, wird durch CN2 255 weder erkannt noch gar verwendet.
Folglich bezieht sich die einzige Optimierung, die der Thierry Ernst-Vorschlag unterstützen kann, auf den HA (HA2 250) des MR (MR2 260), der den kommunizierenden MNN versorgt (LFN2 165 in dem obigen Beispiel). Diese Lösung beschreibt in der Tat ein Mittel, damit Pakete direkt von CN2 255 an HA1 240 – anstatt von CN2 255 an HA2 250 und danach an HA1 240 – gesendet werden. Allerdings stellt diese Lösung, falls es n aufeinander folgende Ebenen geschachtelter Mobilität gäbe, eine minimale Routenoptimierung zur Verfügung; nicht mehr, als dass sie einen CN2 255 → HA_n-1 → HA_n-2 → ... → HA1-Pfad anstatt eines CN2 255 → HA_n → HA_n-1→ HA_n-2 ... → HA1-Pfads aufweist. Dieser Vorschlag ist deshalb insbesondere in dem Fall geschachtelter Netze nach wie vor eindeutig ineffizient.
Daher ergibt sich ein Bedarf für einen Mechanismus, Vorrichtung und zugehörige Verfahren, um insbesondere in dem Fall von IPv6 eine Routenoptimierung bei Netzmobilität zu unterstützen. Insbesondere hat sich eine Notwendigkeit ergeben, eine Routenoptimierung in dem Fall geschachtelter Mobilität zu unterstützen, wobei die vorher genannten Probleme wesentlich gemindert werden.
Aussage der Erfindung
Gemäß einem ersten Aspekt der vorliegenden Erfindung wird ein Verfahren zum Übertragen eines Datenpakets von einem ersten Kommunikationsknoten zu einem zweiten Kommunika tionsknoten in einem mobilen Netz nach Anspruch 1 zur Verfügung gestellt.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird ein Speichermedium nach Anspruch 13 zur Verfügung gestellt.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird eine Vorrichtung nach Anspruch 14 zur Verfügung gestellt.
Weitere Aspekte der vorliegenden Erfindung erfolgen nach den abhängigen Ansprüchen.
Kurze Beschreibung der Zeichnungen
1 stellt die Bewegung eines mobilen Netzes in einem Internet dar;
2 stellt einen bekannten Paketdatenroutingmechanismus für mobile Netze bei Anwendung auf geschachtelte Mobilität dar;
3 stellt einen bekannten Paketdatenroutingmechanismus für mobile Netze bei Anwendung auf geschachtelte Mobilität dar, der die Ineffizienz des Datenroutings hervorhebt;
4 stellt einen bekannten Paketdatenroutingmechanismus für mobile Netze bei Anwendung auf geschachtelte Mo bilität dar, der die Ineffizienz eines verbesserten Prozesses des Datenroutings hervorhebt; und
5 stellt einen bekannten Binding Cache zum Routing von Datenpaketen in Netzen mobiler Knoten dar.
Nun werden beispielhafte Ausführungsformen der vorliegenden Erfindung beschrieben, und zwar mit Bezug auf die Begleitzeichnungen, in denen:
6 eine Netztopologie zum Advertising einer mobilen Routermobilität innerhalb mobiler Netze gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung darstellt;
7, 8 und 9 Flussdiagramme, damit ein MNN-Router ein Care-of-Route-Advertisement einrichtet und sendet, gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung darstellen;
10 eine Netztopologie zum Senden erweiterter BUs an CNs gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung darstellt;
11 ein Flussdiagramm eines MNN, eine Care-of-Route erzeugend, gemäß Ausführungsformen der vorliegenden Erfindung darstellt;
12 und 13 Flussdiagramme eines MNN, der erweiterte BU-Nachrichten an seine(n) CN(s) (und HAs) sendet, gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung darstellen;
14 und 15 Flussdiagramme eines MNN, der ein erweitertes BU an seine(n) CN(s) (und seine HAs) sendet, gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung darstellen;
16 ein Flussdiagramm eines dynamischen Discovery-Verfahrens eines mobilen Netzes Präfixes für einen MNN in einem mobilen Netz gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung darstellt;
17, 18 und 19 Flussdiagramme von Prozessen von MNN-Routern, die eine Mobiles-Netz-Präfix-Advertisement-Nachricht senden, gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung darstellen;
20 ein Flussdiagramm, wo ein erster Knoten ein Datenpaket zu einem zweiten Knoten sendet, gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung darstellt;
21 bevorzugte Beispiele von Datenpaketformaten, durch einen ersten Knoten zu einem zweiten Knoten gesendet, gemäß Ausführungsformen der vorliegenden Erfindung darstellt;
22 und 23 eine Mobiles-Netz-Präfix-Solicitation-Nachricht beziehungsweise eine Mobiles-Netz-Präfix- Advertisement-Nachricht gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung darstellen;
24 und 25 eine Care-of-Route-Solicitation-Nachricht beziehungsweise eine Care-of-Route-Advertisement-Nachricht gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung darstellen;
26 und 27 eine von einem LFN beziehungsweise einem VMN gesendete erweiterte BU-Nachricht gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung darstellen;
28 einen erweiterten Binding Cache gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung darstellt;
29 die Errichtung einer Care-of-Source-Route von einem empfangenen erweiterten BU gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung darstellt; und
30 ein Flussdiagramm ist, das einen Prozess, wo ein erster Knoten ein erweitertes BU von einem zweiten Knoten empfängt, gemäß Ausführungsformen der vorliegenden Erfindung darstellt.
Beschreibung einer bevorzugten Ausführungsform
Es gibt gegenwärtig keinen Standardmechanismus, der insbesondere in dem Fall von IPv6 für Datennetze geschachtelter Mobilität Netzmobilität angemessen unterstützt. Ins besondere gibt es keine Vorkehrung oder Unterstützung zur Routenoptimierung.
Das ist ein großes Problem, da geschachtelte Mobilität ein sehr realistisches Szenario für Mobile Router-Anwendungen ist. Darüber hinaus ist die Routenoptimierung mit Bezug auf die Bewegung eines mobilen Netzes viel wichtiger als für die Bewegung eines einzelnen mobilen Knotens, da die verarbeitete Menge an Verkehr viel größer ist.
Die bevorzugte Ausführungsform der vorliegenden Erfindung wird in Bezug auf die Routenoptimierung beim Übertragen zumindest eines Datenpakets zwischen einem korrespondierenden Knoten (Kommunikationseinheit) und einem lokalen festen Knoten (oder umgekehrt) beschrieben. In diesem Zusammenhang kann die Routenoptimierung als "the Shortest Path" (also auf "dem kürzesten Pfad") direkte Kommunikation zwischen einem mobilen Netzknoten (MNN) und seinen korrespondierenden Knoten (CNs), insbesondere für einen MNN innerhalb eines mobilen Netzes, wo ein Szenario geschachtelter Mobilität (mobile Netze, die mobile Netze besuchen) existiert, betrachtet werden.
Es ist vorgesehen, dass der korrespondierende Knoten jede Kommunikationseinheit sein kann, die im Stande ist, ein Datenpaket durch ein Datennetz (wie z. B. das Internet) zu senden – zum Beispiel ein Webserver, ein PC oder eine Workstation, die einen Webserver, wie z. B. www.yahoo.com, ausführt, usw. Bei dem CN kann es sich auch um jede mobile Datenkommunikationseinheit, wie z. B. ein General Packet Radio System (GPRS)-Gerät oder ein Zellulartelefon der 3.
Generation (3G), einen Personal Digital Assistant (PDA) usw., durch irgendeinen Typ an Zugang mit dem Datennetz verbunden, handeln. Man beachte, dass sich der CN auch selbst in einem mobilen Netz befinden kann.
Wie in dem vorhergehenden Abschnitt erläutert wird, muss ein mobiler Router (MR) eine Binding Update (BU)-Nachricht an seinen Home Agent (HA) senden, wenn er sich zu einem fremden Netz bewegt. Durch Senden einer BU-Nachricht an seinen HA hält der MR IP-Erreichbarkeit für sich selbst ebenso wie für Knoten, die er versorgt (MNNs), aufrecht.
Gemäß der bevorzugten Ausführungsform wird dem Mechanismus keine Beschränkung auferlegt, um durch das mobile Netz verwendet zu werden, um seinen Home Agent über seinen neuen Standort zu informieren. Diesbezüglich kann jeder bekannte Ansatz, wie z. B. diejenigen, die in [3] Thierry Ernst, Hong-Yon Lach, IETF Internet-Draft draft-ernstmobileip-v6-network-02.txt, Juni 2001, oder [5] T. J. Kniveton, IETF Internet-Draft draft-kniveton-mobrtr-00.txt, November 2001, beschrieben werden, angepasst und verwendet werden. Die Anpassung solcher Verfahren ermöglicht es, dass in Fällen geschachtelter Mobilität eine Routenoptimierung erzielt wird.
Darüber hinaus wird in einer verbesserten Ausführungsform der vorliegenden Erfindung dargestellt, wie die Ansätze in [3] Thierry Ernst, IETF Internet-Draft draft-ernstmobileip-v6-network-02.txt, Juni 2001, und [5] wirksam eingesetzt werden können, um auf dem Pfad HA → MN (wo MN ent weder ein Host oder ein Router ist) ebenfalls eine Routenoptimierung zu erzielen.
Die bevorzugte Ausführungsform der vorliegenden Erfindung verwendet drei entscheidende Konzepte, die entweder einzeln oder vorzugsweise in Kombination verwendet werden. Die drei entscheidenden Konzepte sind:

(i) Advertising der Mobilität eines mobilen Routers innerhalb seines mobilen Netzes.
(ii) Senden von einer oder mehreren erweiterten Binding Update-Nachrichten durch MNNs an ihre entsprechenden CNs. Eine durch einen MNN gesendete erweiterte Binding Update-Nachricht würde eine "Care-of-Route" anstatt einer einzelnen Care-of-Adresse in gewöhnlichem Mobile IP umfassen. Die Care-of-Route ist eine geordnete Liste von IP-Adressen, die ein CN verwendet, um seine Pakete auf dem kürzesten Pfad zu dem MNN zu sourcerouten, wodurch eine Routenoptimierung erzielt wird.
(iii) Empfangen von erweiterten BU-Nachrichten durch die CNs. Als Antwort auf die empfangenen BU-Nachrichten Sourcerouten von Paketen, die an MNN adressiert sind, durch die Route, die aus der Care-of-Route-Adresse abgeleitet wird, um eine Routenoptimierung zu erzielen.

(A) Mobiler Router macht seine Mobilität in dem mobilen Netz bekannt:
Um eine Routenoptimierung für MNNs in dem Fall eines einzelnen mobilen Netzes wie auch mehrschichtiger aggre gierter mobiler Netze (geschachtelter Mobilität) zu realisieren, schlagen die hier beschriebenen erfinderischen Ideen vor, MNNs die Mobilität der mobilen Netze (oder mobilen Router), denen sie zugeordnet sind, zur Kenntnis zu bringen. Das steht in direktem Gegensatz zu dem in [3] vorgeschlagenen Ansatz, wo die Mobilität eines mobilen Routers seinen entsprechenden MNNs verheimlicht wird.
Um bekannt zu machen, dass er sich zu einem neuen Verbindungspunkt bewegt hat, sendet ein mobiler Router (z. B. MR1) eine "Care-of-Route-Advertisement"-Nachricht, adressiert an all die Knoten hinter ihm (d. h. jegliche LFNs, LMNs, VMNs), in das mobile Netz, das er versorgt. Diese Nachricht umfasst die Care-of-Adresse des MR1 selbst ebenso wie die Care-of-Adressen von all den mobilen Routern über MR1 in der Hierarchie aggregierter mobiler Netze in dem Fall von geschachtelter Netzmobilität. Diese Liste von Care-of-Adressen von oberen mobilen Routern wird vorzugsweise durch all die Care-of-Route-Advertisements, auf jeder Ebene der Hierarchie aggregierter mobiler Netze gesendet, dynamisch geordnet und erstellt.
Bezieht man sich nun auf 6, erkennt man, dass eine Netztopologie 600 zum Advertising der Mobilität solch eines mobilen Routers innerhalb mobiler Netze gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung dargestellt wird. Die in 6 dargestellte Topologie stellt insbesondere die Unterstützung geschachtelter Mobilität gemäß der bevorzugten Ausführungsform der Erfindung dar. Es versteht sich für einen qualifizierten Fachmann, dass die in dem Netz von 6 dargestellte Anzahl an Elementen nur zum Zwecke der Klarheit begrenzt wird.
Die in 6 dargestellte Netztopologie stellt ein zweites mobiles Netz (MR2) dar, das ein erstes mobiles Netz (MR1) besucht, das einem besuchten Netz zugeordnet ist. Das erste mobile Netz umfasst einen festen Router (LFR1), der seine eigene Verbindung versorgt.
Da MR1 650 ein fremdes Netz 110 besucht, hat er eine Care-of-Adresse {MR1_CoA} 652 erworben. Das fremde Netz 110 ist fest, also werden keine Care-of-Route-Advertisements in der Verbindung zwischen der besuchten Verbindung 110 und MR1 650 weitergeleitet. Gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung erstellt MR1 650 seine eigene Care-of-Route-Advertisement-Nachricht und umfasst seine eigene Care-of-Adresse 652 in der Advertisement-Nachricht.
Es erfolgt ein Multicast dieser Nachricht an alle Knoten innerhalb (unterhalb) seiner eigenen Verbindung (MR1-Verbindung 155) durch seine Ingress-Schnittstelle. Alle Knoten auf der Verbindung empfangen deshalb diese Advertisement-Nachricht. Es wird erwartet, dass Router (LFR, LMR, VMR) bei Empfang solch einer Nachricht die geordnete Liste von Care-of-Adressen 652 extrahieren und diese Liste zu den Verbindungen, die sie versorgen, weiterleiten. In diesem Zusammenhang leitet der zweite MR (MR2) 660 die Care-of-Adressen 652 an seine eigene Verbindung (MR2-Verbindung) 230 weiter. Falls es sich bei diesem Router um einen obersten Router eines mobilen Netzes nicht innerhalb seines Hei matnetzes handelt (d. h. einen VMR wie in dem Falle von MR2 660), hängt er seine eigene Care-of-Adresse an die empfangene Liste an. MR2 660 umfasst dann die MR2-Care-of-Adresse 662 bei der Erstellung einer neuen geordneten Liste. MR2 erstellt dann seine eigene Care-of-Route-Advertisement-Nachricht zum Multicast auf seiner eigenen Verbindung (MR2-Verbindung) 230 durch seine Ingress-Schnittstelle. Als Folge wird MR1_CoR in dem ersten mobilen Netz bekannt gemacht (wobei MR1-Verbindung 155 und LFRl-Verbindung 670 umfasst werden), während die geordnete Liste {MR1_CoR 652, MR2_CoR 662} in dem zweiten mobilen Netz 230 bekannt gemacht wird.
Der Prozess, CN2 655 unter Verwendung einer erweiterten BU-Nachricht über die optimale Route zu LFN2 665 über die MR2-Care-of-Adresse 662 zu informieren, wird später beschrieben. Auf diese weise kann die vollständige Route für das Datenpaket durch verbesserte Extrahierung, Verwendung und Bekanntmachung von Adressdaten überall in den Netzen ermittelt werden.
Der in 6 dargestellte Prozess stellt ein praktisches Szenario dar, wo viele geschachtelte Ebenen vorhanden sein können. Deshalb versteht es sich für einen qualifizierten Fachmann, dass der oben genannte Prozess leicht zu einem Beispiel für geschachtelte Mobilität, die n aufeinander folgende Ebenen (n mobile Router MR₁, ..., MR_n und n entsprechende Home Agents HA₁, ..., HA_n) umfasst, verallgemeinert werden kann.
Bezieht man sich nun auf 7, 8 und 9, erkennt man, dass verschiedene Flussdiagramme 700, 800, 900 dargestellt werden, damit irgendein Router in einem mobilen Netz, wie z. B. MR, VMR, LFR und LMR, eine Liste von Care-of-Adressen, die in einer Care-of-Route-Advertisement (CoR_Advt)-Nachricht umfasst wird, gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung erstellt und sendet. Außerdem sind diese Prozesse nur für MNN gültig, bei denen es sich um Router handelt (z. B. LFR, MRs).
Im Prinzip sendet ein Router in einem mobilen Netz eine CoR_Advt-Nachricht als Antwort auf eines von drei Ereignissen:

(i) Empfang eines CoR_Advt an seiner Egress-Schnittstelle, das seine eigene CoR modifiziert, wie in 7 beschrieben wird;
(ii) periodisches Senden eines CoR_Advt, wie in 8 beschrieben wird; und
(iii) Empfang einer Care-of-Route-Solicitation (CoR_Sol)-Nachricht an einer Ingress-Schnittstelle, wie in 9 beschrieben wird.

In 7 beginnt der Prozess bei einem Schritt 710. An seiner Egress-Schnittstelle wird eine neue CoR_Advt-Nachricht empfangen, wie in einem Schritt 720 dargestellt wird, und die Liste von Care-of-Adressen extrahiert, wie in einem Prozess A von 11 weiter beschrieben wird. Falls die Care-of-Route des entsprechenden MNNs (MNN_CoR) in einem Schritt 740 nicht geändert worden ist, endet der Prozess in einem Schritt 780. Falls allerdings die entsprechende MNN_CoR-Adresse in dem Schritt 740 geändert worden ist, erstellt der Router eine neue CoR_Advt-Nachricht und umfasst (hängt an) in ihr die neue MNN_CoR, wie in einem Schritt 750 dargestellt wird. Die neue CoR_Advt-Nachricht wird dann durch alle Ingress-Schnittstellen des entsprechenden MNN zu allen Knoten gesendet, wie in einem Schritt 760 dargestellt wird.
Man erkennt, dass in 8 ein Flussdiagramm die bevorzugte Operation für den Fall, dass ein periodischer CoR_Advt-Nachrichtentimer in einem Schritt 820 abgelaufen ist, darstellt. In diesem Fall erstellt der Router eine neue CoR_Advt-Nachricht und umfasst (hängt an) in ihr die MNN_CoR, wie in einem Schritt 850 dargestellt wird. Die neue CoR_Advt-Nachricht wird dann wie in einem Schritt 860 durch alle Ingress-Schnittstellen des entsprechenden MNN zu allen Knoten gesendet. Der CoR_Advt-Nachrichtentimer wird dann in einem Schritt 870 neu gestartet.
Ein Router in einem mobilen Netz (MR, LFR, LMR, VMR) startet eine periodische Übertragung von CoR_Advt-Nachrichten nur, wenn seine CoR non-null wird (d. h. zumindest eine Adresse umfasst). Es ist vorgesehen, dass der Router diese periodische Aussendung beendet, wenn seine CoR null/empty wird. Zum Beispiel startet ein MR die periodische Aussendung, wenn er (oder ein oberster MR) sich aus seinem Heimatnetz heraus bewegt, und beendet die periodische Aussendung, wenn er (oder der oberste MR) zu seinem Heimatnetz zurückkehrt.
In 9 stellt ein Flussdiagramm den bevorzugten Prozess nach Empfang einer Care-of-Route-Solicitation (CoR_Sol)-Nachricht an einer Ingress-Schnittstelle dar, wie in einem Schritt 920 dargestellt wird. In diesem Fall erstellt der Router eine neue CoR_Advt-Nachricht und umfasst (hängt an) in ihr MNN_CoR, wie in einem Schritt 950 dargestellt wird, wenn die (CoR_Sol)-Nachricht an einer Ingress-Schnittstelle ifc_j empfangen wird. Zwei mögliche Ansätze sind für das Senden einer CoA_Advt-Operation in einem Schritt 960 vorgesehen. Ein erster Ansatz besteht darin, die CoA_Advt-Nachricht durch ifc_j an die Quelladresse der Care-of-Route-Solicitation-Nachricht (CoR_Sol) zu senden. Alternativ kann die CoA_Advt-Nachricht durch die ifc_j an alle Knoten auf den Verbindungen gesendet werden. Man beachte, dass, wenn ein mobiler Router (MR) seinen Standort ändert, er eine CoR_Sol-Nachricht senden sollte, um im Gegenzug eine CoR_Advt-Nachricht zu empfangen. Der MR ist dann im Stande, seine neue Care-of-Route (CoR) zu berechnen. Diese CoR wird aus der geordneten Liste von Adressen, empfangen in der CoR_Advt-Nachricht (falls nicht leer, also 'empty'), an die MRs neue Care-of-Adresse angehängt wird, hergestellt. Da diese neue CoR nicht leer ist, beginnt der MR ein periodisches Senden seiner eigenen CoR_Advt-Nachrichten.
Etliche Ansätze sind für die Implementierung von Careof-Route-Solicitation- und Care-of-Route-Advertisement-Nachrichten vorgesehen. Zuerst können die Nachrichten als eine Internet Control Message Protocol für IPv6, IETF RFC 1885 (ICMPv6)-Erweiterung oder als irgendein neues Protokoll oben auf IP (v4 oder v6), wie z. B. das User Datagram Protocol, IETF RFC 768 (UDP), Transmission Control Protocol, IETF RFC 793 (TCP) usw., implementiert werden.
Zweitens kann eine Care-of-Route-Advertisement-Nachricht an die IPv6 'all-node' verbindungslokale, also Link-Local- Multicastadresse gesendet werden. In diesem Fall wird die Nachricht nur auf der lokalen Verbindung gesendet. Eine bevorzugte Art wäre es, das Care-of-Route-Advertisement an die IPv6 'all-node' standortlokale, also Site-Local- Multicastadresse zu senden, wo der Standort das gesamte mobile Netz ist, das durch diesen MR versorgt wird. Das würde dabei helfen, die Operation auf Zwischenroutern (LFR, LMR zu Hause) in dem mobilen Netz zu reduzieren, da das Care-of-Route-Advertisement dann transparent zu all den Verbindungen des mobilen Netzes weitergeleitet würde. Auf diese Art und Weise braucht dieser Zwischenrouter (LFR, LMR zu Hause) die CoR-Liste nicht zu extrahieren und zu kopieren.
Eine bevorzugte Implementierung dieser Nachrichten wäre es, sie als Erweiterungen von ICMPv6 Router Solicitation- und ICMPv6 Routen Advertisement-Nachrichten zu definieren. Bei einer Care-of-Route-Advertisement-Nachricht würde es sich um eine ICMPv6 Router Advertisement-Nachricht (RA), die eine neue "Care-of-Route-Advertisement"-Option umfasst, handeln. Bei einer Care-of-Route-Solicitation-Nachricht würde es sich um eine ICMPv6 Router Solicitation-Nachricht (RS), die eine neue "Care-of-Route-Advertisement"-Option umfasst, handeln. Die Care-of-Route-Advertisement-Option wäre in der RA umfasst, wenn ein Router seine (non-empty)_CoR innerhalb des mobilen Netzes bekannt machen muss. Die Care-of-Route-Solicitation-Option kann durch einen MNN in der RS umfasst sein, um ausdrücklich um eine RA mit der Care-of-Route-Advertisement-Option zu ersuchen.
Falls diese Option nicht in der RA umfasst wäre, würde das bedeuten, dass die CoR dieses Routers null/empty ist.
Bezieht man sich nun auf 24 und 25, erkennt man, dass eine Care-of-Route-Solicitation-Nachricht beziehungsweise eine Care-of-Route-Advertisement-Nachricht gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung dargestellt werden.
Bei der Care-of-Route-Solicitation (CoR_Sol)-Nachricht 2400 in 24 handelt es sich um eine mit der neuen "Care-of-Route-Solicitation"-Option erweiterte ICMPv6 Router Solicitation-Nachricht. Sie umfasst einen einzelnen IP-Header 2425, der eine IP-Quelladresse (Ip src) 2410 für einen Host und eine IP-Zieladresse (Ip dst) 2420, die die 'All Routers' IP-Multicastadresse angibt, umfasst. Der IP-Header 2425 wird von einer Router Solicitation-Nachricht 2430 gefolgt, die die Care-of-Route-Solicitation (CoR_Sol)-Option umfasst.
Bei der Care-of-Route-Advertisement (CoR_Advt)-Nachricht 2500 in 25 handelt es sich um eine mit der neuen "Care-of-Route-Advertisement"-Option erweiterte ICMPv6 Router Advertisement-Nachricht. Sie umfasst einen einzelnen IP-Header 2525, der eine IP-Quelladresse 2510 für eine Router-Ingress-Schnittstelle und eine IP-Zieladresse 2520 umfasst, die einen Knoten (oder alle Knoten auf der Verbindung) angibt, der (die) das Paket empfangen soll (sollen). Der IP-Header 2525 wird von einer Router Advertisement-Nachricht 2530 gefolgt, die die Care-of-Route-Advertisement-Option umfasst, die die Care-of-Route (d. h. geordnete Liste von Adressen) wie durch den Router bekannt gemacht umfasst.
B) MNNs senden erweiterte Binding Updates an ihre entsprechenden CNs:
Es wird erwartet, dass jeglicher MNN, wobei ein LFN, ein LMN oder ein VMN umfasst werden, in einem mobilen Netz so genannte erweiterte Binding Updates an seine CNs sendet, um eine Routenoptimierung auf dem Pfad CN → MNN zu erzielen. Gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung würde eine durch einen MNN gesendete erweiterte BU-Nachricht eine "Care-of-Route" anstatt einer einzelnen Care-of-Adresse umfassen, wie in Mobile IP bekannt ist. Wie oben beschrieben wird, handelt es sich bei der Care-of-Route um die geordnete Liste von IP-Adressen, damit der CN eine Source Route daraus ableitet, um sein Paket durch den kürzesten Pfad an den MNN zu routen (d. h. Routenoptimierung).
Bezieht man sich nun auf 10, erkennt man, dass eine Netztopologie 1000 zum Senden erweiterter BUs an CNs gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung dargestellt wird. Nur zum Zwecke der Klarheit geht die Topologie von derjenigen oben mit Bezug auf 6 beschriebenen weiter.
Jeder MNN in dem mobilen Netz leitet seine Care-of-Route aus den Care-of-Route-Advertisement-Nachrichten ab, die er von seinem oberen Router empfängt. Zum Beispiel ist LFN1s 675 Care-of-Route eine Single-Hop-Route entsprechend MR1s 650 Care-of-A3resse {MR1_CoA} 652. LFN1 675 überträgt dann eine erweiterte BU-Nachricht 1010, die seine Care-of-Route zu CN1 1030 angibt.
Demgegenüber handelt es sich bei LFN2s 665 Care-of-Route um eine Two-Hop-Route entsprechend {MR1_CoA MR2_CoR}. In diesem Kontext verwendet die LFN2 665 Care-of-Route MR2_CoA 662 und den oberen Router von MR2, nämlich MR1s 650 CoA 652. LFN2 665 überträgt dann eine erweiterte BU-Nachricht 1020, die die MR1_CoA 652 und die MR2_CoA 662 zu CN2 655 angibt.
Bezieht man sich nun auf 11, erkennt man, dass ein bevorzugter Algorithmus gemäß Ausführungsformen der vorliegenden Erfindung beschrieben wird, damit ein MNN seine eigene Care-of-Route (MNN_CoR) erzeugt. Der Prozess (Prozess A) beginnt bei einem Schritt 1110. Wenn der MNN in einem Schritt 1120 eine neue CoR_Advt-Nachricht an seiner Schnittstelle ifc_i empfängt, ermittelt er in einem Schritt 1130, ob es sich dabei um eine Egress-Schnittstelle handelt. Falls es sich dabei nicht um eine Egress-Schnittstelle handelt, wird das CoR_Advt ignoriert und der Prozess endet in einem Schritt 1190. In diesem Fall ist die MNN-Care-of-Route unverändert.
Falls es sich bei ifc_i um eine Egress-Schnittstelle handelt, dann extrahiert der MNN in einem Schritt 1140 eine neue CoR (new_CoR) – geordnete Liste von IP-Adressen – aus dem CoR_Advt und in einem Schritt 1150 erfolgt eine Ermittlung darüber, ob sich der MNN zu Hause befindet (d. h. ifc_i seinem Heimat-IP-Subnetz zugeordnet ist). Falls sich der MNN zu Hause befindet, wird in einem Schritt 1180 die MNN_ CoR durch die neue Care-of-Route-Information ersetzt, falls es in einem Schritt 1170 einen Unterschied zwischen den Routen gibt. Falls der MNN nicht zu Hause ist, wird die MNN-Care-of-Route erstellt, indem in einem Schritt 1160 die MNN-Care-of-Adresse (in dem besuchten Netz erhalten) an die geordnete Liste von Care-of-Adressen, empfangen in der Care-of-Route-Advertisement-Nachricht, angehängt wird.
Man beachte, dass es sein kann, dass ein MNN solch eine Care-of-Route nicht beibehält, falls er nicht von einer Routenoptimierung auf dem Pfad CN → MNN oder auf dem Pfad HA → MNN profitieren will. In der bevorzugten Ausführungsform der vorliegenden Erfindung wird es allerdings befürwortet, dass solche Care-of-Route-Kenntnis eingehalten wird, um die in [3] und [5] beschriebenen Ansätze wirksam einzusetzen. Auf diese weise ist es möglich, auf dem Pfad HA → MN, wo es sich bei dem MN entweder um einen Host oder einen Router handelt, wie später beschrieben wird, eine Routenoptimierung zu erzielen.
Man beachte, dass der in 11 beschriebene Ansatz für jeglichen MNN, entweder einen Router oder einen Host, entweder fest oder mobil, gültig ist.
Bezieht man sich nun auf 12 und 13, sieht man, dass Flussdiagramme eines MNN, der erweiterte BU-Nachrichten an seine(n) CN(s) {und Home Agent – HA) sendet, gemäß den bevorzugten Ausführungsformen der vorliegenden Erfindung dargestellt werden. Erneut sind die Flussdiagram me auf jeglichen MNN, entweder einen Host oder einen Router, fest oder mobil, anwendbar.
12 beschreibt ein Flussdiagramm 1200 zum Senden erweiterter BU-Nachrichten an seine(n) CN(s) (und HA) im Anschluss an einen Empfang einer CoR_Advt-Nachricht an seiner Egress-Schnittstelle in einem Schritt 1215. Nach Empfang einer CoR_Advt-Nachricht führt der MNN den in 11 beschriebenen Prozess 'A' aus, um seine eigene CoR zu erzeugen, wie in einem Schritt 1220 dargestellt wird. Falls sich seine CoR in einem Schritt 1225 nicht geändert hat, endet der Prozess in einem Schritt 1265. Falls sich die CoR in dem Schritt 1225 allerdings geändert hat, ermittelt der MNN in einem Schritt 1230 alle von seinen CNs, die eine aktualisierte CoR-Nachricht empfangen müssen. Um in einem Schritt 1240 eine erweiterte BU-Nachricht zu senden, die die aktualisierte CoR-Nachricht umfasst, schreitet der MNN durch jeden der CNs, wobei in einem Schritt 1235 mit dem ersten CN begonnen wird. Falls der CN, der die erweiterte BU-Nachricht empfängt, die die aktualisierte CoR-Nachrichtenübertragung umfasst, in einem Schritt 1245 nicht der durch den MNN identifizierte letzte CN ist, geht der Prozess in einem Schritt 1250 zu dem nächsten CN, bis alle CNs die Übertragung empfangen haben.
Ein bevorzugter optionaler Schritt besteht darin, dass, wie in Schritten 1255 und 1260 dargestellt wird, der MNN, der nicht zu Hause ist, eine Nachricht, die seine neue Care-of-Route (CoR) umfasst, an seinen Home Agent (HA) sendet – entweder ein erweitertes BU oder ein erweitertes Pre fix Scope BU (falls der MNN [3] verwendete, um BU an seinen HA zu senden).
13 beschreibt ein alternatives Flussdiagramm 1300 zum Senden erweiterter BU-Nachrichten an seine(n) CN(s) (oder seinen HA) im Anschluss an ein periodisches Senden erweiterter BUs (EBUs) zu CNs (und erneut HA, falls MNN ein mobiler Host oder Router ist). Erneut findet dieses periodische Senden nur statt, wenn des MNNs CoR im Anschluss an einen Ablauf des periodischen EBU-Timers, einem bestimmten CN (z. B. CNi) oder MNNs HA zugeordnet, in einem Schritt 1320 non-null ist. Die erweiterte BU-Nachricht, die die aktualisierte CoR-Nachricht umfasst, wird in einem Schritt 1330 an CNi (oder HA) gesendet. Die Timerfunktion, dem entsprechenden CN (z. B. CNi oder HA) zugeordnet, wird dann in einem Schritt 1340 neu gestartet.
Man beachte, dass es sich in Bezug auf 12 und 13 bei einem CN um einen festen oder mobilen Host in dem Internet ebenso wie einen anderen MNN (von demselben oder anderen mobilen Netz) handeln kann.
Immer noch mit Bezug auf 12 und 13 erkennt man, dass, falls der MNN (Host oder Router) zu Hause ist (d. h. ein LFN, ein LMN zu Hause ist), der MNN ein erweitertes Binding Update zu allen seinen CNs sendet (und nicht zu seinem HA, da er zu Hause ist). Falls der MNN (Host oder Router) sich in einem besuchten Netz befindet (d. h. ein VMN ist), sendet der MNN ein erweitertes Binding Update zu all seinen CNs ebenso wie vorzugsweise seinem Home Agent.
Der MNN kann ein erweitertes Binding Update an seinen Home Agent senden, falls er auf dem Pfad HA → MNN eine Routenoptimierung erzielen will. Dieser Ansatz baut die in [3] und [5] vorgeschlagenen Verfahren dadurch aus, dass erweiterte BUs anstatt ihrer einfachen Binding Updates gesendet werden. In dem Fall von [3] sendet der mobile Router (MR) eine so genannte Prefix Scope BU-Nachricht an seinen HA. In diesem Zusammenhang definieren wir hier eine Erweiterung dieser Binding Update-Nachricht genannt 'erweitertes Prefix-Scope Binding Update', das die MR-Care-of-Route anstatt nur der MR-Care-of-Adresse umfasst. Dieses erweiterte Prefix-Scope Binding Update kann durch den MR an seinen HA gesendet werden, um auf dem Pfad HA → MR eine Routenoptimierung zu erzielen.
In dem Fall von [5] sendet der mobile Router (MR) ein einfaches Mobile IP Binding Update. In diesem Kontext definieren wir eine Erweiterung dieser BU-Nachricht als ein 'erweitertes Binding Update' (wie oben ausführlich dargelegt). Dieses umfasst die MR-Care-of-Route anstatt nur der MR-Care-of-Adresse. Dieses erweiterte Binding Update kann durch den MR an seinen HA gesendet werden, um auf dem Pfad HA → MR eine Routenoptimierung zu erzielen.
Es ist erwähnenswert, dass jeder MNN, der erweiterte BU-Nachrichten sendet, vorzugsweise eine 'erweiterte Binding Liste', definiert als eine Erweiterung der Mobile IP Binding Liste, wo Care-of-Adressen durch Care-of-Routen ersetzt werden, führt.
Bezieht man sich nun auf 14 und 15, erkennt man, dass Flussdiagramme eines optimierten Prozesses, damit ein MNN für eine interne Kommunikation in einem mobilen Netz ein erweitertes BU an seine(n) CN(s) (und seinen HA) sendet, gemäß einer verbesserten Ausführungsform der vorliegenden Erfindung dargestellt werden. Es ist vorgesehen, dass der verbesserte Prozess die Netzleistung verbessert, indem vermieden wird, dass "unnütze" erweiterte BU-Nachrichten in dem Fall einer internen Kommunikation in einem mobilen Netz gesendet werden. Tatsächlich wird, wenn zwei Knoten (entweder fest oder mobil zu Hause) in demselben mobilen Netz (d. h. nicht durch einen mobilen Router weg von zu Hause getrennt) Pakete zueinander senden, eine Routenoptimierung durch die Routinginfrastruktur innerhalb des mobilen Netzes naturgemäß realisiert. Als solches besteht für sie keine Notwendigkeit, erweiterte BU-Nachrichten zwischen einander auszutauschen.
In 14 als eine Erweiterung zu dem Flussdiagramm von 12 erkennt man, dass, wenn der MNN ein Host zu Hause ist (d. h. ein LFH oder ein LMH zu Hause ist), der MNN ein erweitertes Binding Update wie in einem Schritt 1410 nur an seine CNs, die sich nicht in demselben mobilen Netz befinden, sendet. Ferner sendet der MNN, wenn der MNN ein Router zu Hause ist (d. h. ein LFR oder ein LMR zu Hause ist), ein erweitertes Binding Update wie in dem Schritt 1410 nur an seine CNs, die sich nicht in demselben mobilen Netz befinden. Falls sich in einem Schritt 1420 der MNN (Host oder Router) in einem besuchten Netz befindet (d. h. ein VMN ist), sendet der MNN in einem Schritt 1240 ein erweitertes Binding Update nur an CNs, die sich nicht in die sem besuchten mobilen Netz befinden. Für CNs, die sich in dem besuchten mobilen Netz befinden, kann der MNN ein erweitertes Binding Update senden oder vorzugsweise ein modifiziertes erweitertes Binding Update senden, wo in einem Schritt 1430 nur eine Adresse in der Care-of-Route, d. h. nur des MNNs eigene Care-of-Adresse, spezifiziert wird.
Der mobile MNN (Host oder Router) sendet in Schritt 1260 und 1450 vorzugsweise auch ein Binding Update an seinen Home Agent. In diesem Zusammenhang werden unten zwei Fälle ins Auge gefasst. Wenn sich der MNN aus seinem mobilen Heimatnetz heraus bewegt hat, sendet der MNN vorzugsweise ein erweitertes Binding Update an seinen HA. Wenn sich der MNN in einem fremden IP-Subnetz innerhalb seines mobilen Heimatnetzes befindet, kann der MNN ein erweitertes Binding Update senden. Alternativ kann der MNN ein modifiziertes erweitertes Binding Update senden, wo nur eine Adresse, d. h. seine eigene Care-of-Adresse, in der Care-of-Route spezifiziert wird.
In dem Fall, wo der MNN auf dem Pfad HA → MNN durch Senden erweiterter BUs in der Operation von [3] oder erweiterter Prefix Scope BUs in der Operation von [5] wie oben beschrieben eine Routenoptimierung erzielen will, ist es erneut vorgesehen, dass der MNN eine erweiterte BU-Nachricht an seinen Home Agent senden kann.
Eine ähnliche Verbesserung zu 13 wird in 15 beschrieben, wobei erweiterte BU-Nachrichten, die nur die MNN_CoA umfassen, an entsprechende CNs, die in demselben mobilen Netz arbeiten wie der MNN, übertragen werden, wie in Schritten 1510, 1520, 1530 dargestellt wird.
Bezieht man sich nun auf 26 und 27, erkennt man, dass eine von einem LFN und einem VMN gesendete erweiterte BU-Nachricht gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung entsprechend dargestellt wird.
Die erweiterte BU-Nachricht, die in 26 von einer LFN-Nachricht 2600 gesendet wird, umfasst einen einzelnen IP-Header 2625, der als IP-Quelladresse 2610 den LFN und als IP-Zieladresse 2620 des CNs Adresse umfasst. Der IP-Header 2625 wird von einer Mobile IPv6 BU-Nachricht 2630 gefolgt, die die Care-of-Route-Mobilitäts-Option umfasst, die des LFNs Care-of-Route umfasst.
Die erweiterte BU-Nachricht, die in 27 von einer VMN-Nachricht 2700 gesendet wird, umfasst einen einzelnen IP-Header 2725, der eine IP-Quelladresse 2710 der VMN-Care-of-Adresse und eine IP-Zieladresse 2720 für den CN umfasst. Der IP-Header 2725 wird von einer Mobile IPv6 BU-Nachricht 2730 gefolgt, die die Care-of-Route-Mobilitäts-Option umfasst, die des VMNs Care-of-Route umfasst.
Bezieht man nun auf 16, erkennt man, dass ein Flussdiagramm 1600 eines dynamischen Discovery-Verfahrens für ein Mobiles-Netz-Präfix für jeglichen MNN in einem mobilen Netz gemäß der verbesserten Ausführungsform der vorliegenden Erfindung, oben beschrieben, dargestellt wird. In diesem Kontext ist ein Knoten, wie z. B. ein MNN, im Stande zu wissen, ob sich ein zweiter Knoten, sagen wir mal sein CN, in demselben aktuellen mobilen Netz wie er selbst befindet, wenn er ein EBU an, sagen wir mal, den CN sendet, wie oben beschrieben wird.
Der Prozess (Prozess B) beginnt bei einem Schritt 1610. Wenn der MNN eine neue Mobiles-Netz-Präfix-Advertisement-Nachricht (Mobile_Network_Prefix_Advt) an seiner Schnittstelle ifc_i in einem Schritt 1620 empfängt, ermittelt er in einem Schritt 1630, ob es sich dabei um eine Egress-Schnittstelle handelt. Falls es sich dabei nicht um eine Egress-Schnittstelle handelt, wird das Mobile_Network_Prefix_Advt ignoriert und der Prozess endet in einem Schritt 1670. In diesem Fall ist des MNNs Mobiles-Netz-Präfix (MNN_Mobile_Network_Prefix) unverändert. Falls es sich bei ifc_i um eine Egress-Schnittstelle handelt, dann extrahiert der MNN in einem Schritt 1640 ein neues Mobiles-Netz-Präfix (new_Mobile_Network_Prefix) und seine Präfixlänge (new_Mobile_Network_Prefix_Length) aus dem Mobile_Network_Prefix_Advt und in einem Schritt 1650 wird eine Ermittlung darüber durchgeführt, ob des MNNs Heimatadresse in ifc_i_New_Mobile_Network_Prefix auf den ersten New_Mobile_Network_Prefix-Length-Bits entspricht. Falls sie passt, werden das MNN_Mobile_Network_Prefix und MNN_Mobile_Network_Prefix_Length durch die neue Information in dem Schritt 1650 ersetzt und der Prozess endet in dem Schritt 1670. Falls es keine Übereinstimmung gibt, endet der Prozess direkt in dem Schritt 1670.
Man beachte, dass der in 16 beschriebene Ansatz für jeglichen MNN, entweder einen Router oder einen Host, entweder fest oder mobil, gültig ist.
Bezieht man sich nun auf 17, 18 und 19, erkennt man, dass verschiedene Flussdiagramme 1700, 1800, 1900 dargestellt werden, damit ein fester Router in einem mobilen Netz (d. h. LFR) seine eigenen Mobiles-Netz-Präfix-Advertisement (Mobile_Network_Prefix_Advt)-Nachrichten gemäß der verbesserten Ausführungsform der vorliegenden Erfindung erstellt und sendet.
Im Prinzip sendet ein fester Router in einem mobilen Netz eine Mobile_Network_Prefix_Advt-Nachricht als Antwort auf eines von drei Ereignissen:

(i) Empfang eines Mobile_Network_Prefix_Advt an einer Egress-Schnittstelle, das sein eigenes MNN_Mobile_Network_Prefix modifiziert, wie in 17 beschrieben wird;
(ii) periodisches Senden eines Mobile_Network_Prefix_Advt, wie in 18 beschrieben wird; und
(iii) Empfang einer Mobiles-Netz-Präfix-Solicitation-Nachricht (Mobile_Network_Prefix_Sol) an einer Ingress-ifc, wie in 19 beschrieben wird.

In 17 beginnt der Prozess bei einem Schritt 1705. An einer Egress-Schnittstelle wird, wie in einem Schritt 1710 dargestellt wird, eine neue Mobile_Network_Prefix_Advt-Nachricht empfangen und das neue Mobiles-Netz-Präfix (New_Mobile_Network_Prefix) und seine Länge werden extrahiert, wie in dem Prozess B von 16 weiter beschrieben wird. Falls die entsprechenden MNN_Mobile_Net work_Prefix und MNN_Mobile_Network_Prefix_Length in einem Schritt 1720 nicht geändert worden sind, endet der Prozess in einem Schritt 1735. Falls allerdings die entsprechenden MNN_Mobile_Network_Prefix und/oder MNN_Mobile_Network_Prefix_Length in dem Schritt 1720 geändert worden sind, erstellt der Router eine neue Mobile_Network_Prefix_Advt-Nachricht und umfasst (hängt an) die neuen MNN_Mobile_Network_Prefix und MNN_Mobile_Network_Prefix_Length in ihr, wie in einem Schritt 1725 dargestellt wird. Die neue Mobile_Network_Prefix_Advt-Nachricht wird dann wie in einem Schritt 1730 durch alle Ingress-Schnittstellen des entsprechenden MNN an alle Knoten gesendet. Das in 17 beschriebene Flussdiagramm gilt nur für einen festen Router in einem mobilen Netz.
In 18 veranschaulicht ein Flussdiagramm die bevorzugte Operation für den Fall, dass ein periodischer Mobile_Network_Prefix_Advt-Nachrichtentimer in einem Schritt 1810 abgelaufen ist. In diesem Fall erstellt der Router eine neue Mobile_Network_Prefix_Advt-Nachricht und umfasst (hängt an) in ihr die MNN_Mobile_Network_Prefix und MNN_Mobile_Network_Prefix_Length, wie in einem Schritt 1815 dargestellt wird. Die neue Mobile_Network_Prefix_Advt-Nachricht wird dann wie in einem Schritt 1820 durch alle Ingress-Schnittstellen des entsprechenden MNN (festen Routers) an alle Knoten gesendet. Der Mobile_Network_Prefix_Advt-Nachrichtentimer wird dann in einem Schritt 1825 neu gestartet. Das Flussdiagramm von 18 gilt für jeglichen Router in einem mobilen Netz (MR, LMR, LFR, VMR).
Ein Router in einem mobilen Netz (MR, LFR, LMR, VMR) startet eine periodische Übertragung von Mobile_Network_Prefix_Advt-Nachrichten nur, wenn seine CoR non-null wird (d. h. zumindest eine Adresse umfasst). Es ist vorgesehen, dass der Router diese periodische Aussendung beendet, wenn seine CoR null/empty wird. Zum Beispiel startet ein MR die periodische Aussendung, wenn er (oder ein oberster MR) sich aus seinem Heimatnetz heraus bewegt, und beendet die periodische Übertragung, wenn er (oder der oberste MR) zu seinem Heimatnetz zurückkehrt.
In 19 stellt ein Flussdiagramm den bevorzugten Prozess nach Empfang einer Mobiles-Netz-Präfix-Solicitation-Nachricht (Mobile_Network_Prefix-Sol) an einer Ingress-ifc dar, wie in einem Schritt 1910 dargestellt wird. In diesem Fall erstellt der Router eine neue Mobile_Network_Prefix_Advt-Nachricht und umfasst (hängt an) in ihr MNN_Mobile_Network_Prefix und MNN_Mobile_Network_Prefix_Length, wie in einem Schritt 1920 dargestellt wird, wenn die (Mobile_Network_Prefix_Sol)-Nachricht an einer Ingress-Schnittstelle ifc_j empfangen wird. Zwei mögliche Ansätze werden für das Senden einer Mobile_Network_Prefix_Advt-Operation in einem Schritt 1925 vorgesehen. Ein erster Ansatz besteht darin, die Nachricht durch ifc_j zu der Quelladresse der Mobiles-Netz-Präfix-Solicitation-Nachricht (Mobile_Network_Prefix_Sol) zu senden. Alternativ kann die Mobiles-Netz-Präfix-Advertisement-Nachricht durch die ifc_j an alle Knoten auf den Verbindungen gesendet werden. Das Flussdiagramm von 19 gilt für jeglichen Router in einem mobilen Netz (MR, LMR, LFR, VMR).
Man beachte, dass, wenn ein mobiler Router (MR) seinen Standort ändert (und somit eine non-null CoR bekommt), er ein Mobile_Network_Prefix_Advt auf seinen Ingress-Schnittstellen senden sollte.
Dieser mobile Router kann dieses Präfix aus seiner inneren Konfiguration wissen. Auf der anderen Seite kann es sein, dass feste Router in dem mobilen Netz (d. h. LFR) nicht a priori des mobilen Netzes Präfix kennen, zu dem sie gehören, und sie können es dank des in 17 beschriebenen Prozesses dynamisch ermitteln. Solche festen Router können natürlich eine Mobile_Network_Prefix_Sol-Nachricht senden, um im Gegenzug eine Mobile_Network_Prefix_Advt-Nachricht zu empfangen.
Für die Implementierung von Mobiles-Netz-Präfix-Solicitation- und Mobiles-Netz-Präfix-Advertisement-Nachrichten sind mehrere Ansätze vorgesehen. Erstens können die Nachrichten als ICMPv6-Erweiterung oder als jegliches neue Protokoll oben auf IP, UDP, TCP usw. implementiert werden. ICMP, UDP und TCP sind Protokolle, die auf IP (v4 oder v6) aufbauen:

– ICMPv6: Internet Control Message Protocol für IPv6, IETF RFC 1885
– UDP: User Datagram Protocol, IETF RFC 768
– TCP: Transmission Control Protocol, IETF RFC 793

Zweitens kann eine Netz-Präfix-Advertisement-Nachricht zu der IPv6 all-node verbindungslokalen, also Link-Local-Multicastadresse gesendet werden. In diesem Fall wird die Nachricht nur auf der lokalen Verbindung gesendet. Eine bevorzugte Weise wäre es, das Care-of-Route-Advertisement an die IPv6 all-node standortlokale, also Site-Local- Multicastadresse zu senden, wo der Standort das ganze mobile Netz ist, das durch diesen MR versorgt wird. Das würde dabei helfen, die Operation auf Zwischenroutern (d. h. LFR) in dem mobilen Netz zu reduzieren, da diese Nachricht dann transparent zu all den Verbindungen des mobilen Netzes weitergeleitet werden würde. Auf diese Weise braucht dieser Zwischenrouter (d. h. LFR) des mobilen Netzes Präfix nicht zu extrahieren und zu kopieren.
Eine bevorzugte Implementierung dieser Nachrichten wäre es, sie als Erweiterungen von ICMPv6 Router Solicitation- und ICMPv6 Router Advertisement-Nachrichten zu definieren. Eine Mobiles-Netz-Präfix-Advertisement-Nachricht wäre eine ICMPv6 Router Advertisement-Nachricht (RA), die eine neue "Mobiles-Netz-Präfix-Advertisement"-Option umfasst. Eine Mobiles-Netz-Präfix-Solicitation-Nachricht wäre eine ICMPv6 Router Solicitation-Nachricht (RS), die eine neue "Mobiles-Netz-Präfix-Advertisement"-Option umfasst. Die Mobiles-Netz-Präfix-Advertisement-Option wäre in RA umfasst, wenn ein Router des mobilen Netzes Präfix innerhalb des mobilen Netzes bekannt machen muss. Die Mobiles-Netz-Präfix-Solicitation-Option kann durch einen MNN in RS umfasst sein, um ausdrücklich um eine RA mit der Mobiles-Netz-Präfix-Advertisement-Option zu ersuchen.
Bezieht man sich nun auf 22 und 23, erkennt man, dass eine Mobiles-Netz-Präfix-Solicitation-Nachricht beziehungsweise eine Mobiles-Netz-Präfix-Advertisement-Nachricht gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung dargestellt werden.
Die Mobiles-Netz-Präfix-Solicitation-Nachricht 2200 in 22 ist eine mit der neuen Mobiles-Netz-Präfix-Solicitation-Option erweiterte ICMPv6 Router Solicitation. Sie umfasst einen einzelnen IP-Header 2225, der eine IP-Quelladresse 2210 für einen Host und eine IP-Zieladresse 2220, die die All-Routers-IP-Multicastadresse angibt, umfasst. Der IP-Header 2225 wird gefolgt von der Router Solicitation-Nachricht 2230, die die in diesem Dokument vorgeschlagene Mobiles-Netz-Präfix-Solicitation-Option umfasst.
Die Mobiles-Netz-Präfix-Advertisement-Nachricht 2300 in 23 ist eine mit der neuen Mobiles-Netz-Präfix-Advertisement-Option erweiterte ICMPv6 Router Advertisement-Nachricht. Sie umfasst einen einzelnen IP-Header 2325, der eine IP-Quelladresse 2310 für eines Routers Ingress-Schnittstelle und eine IP-Zieladresse 2320 umfasst, die einen Knoten (oder alle Knoten auf der Verbindung) angibt, der (die) das Paket empfangen soll (sollen). Der IP-Header 2325 wird von der Router Advertisement-Nachricht 2330 gefolgt, die die Mobiles-Netz-Präfix-Advertisement-Option umfasst, die des mobilen Netzes Präfix und des mobilen Netzes Präfixlänge, durch den Router bekannt gemacht, umfasst.
C) Korrespondierende Knoten und Home Agent empfangen erweitertes Binding Update:
Bezieht man sich nun auf 20, erkennt man, dass ein Flussdiagramm 2000 einen Prozess darstellt, damit ein erster Knoten ein Datenpaket zu einem zweiten Knoten basierend auf dem Parsing seines Erweiterten Binding Cache (EBC) gemäß den bevorzugten Ausführungsformen der vorliegenden Erfindung sendet. Ein erster Knoten, zum Beispiel ein CN oder HA, empfängt einen Hinweis, dass ein Datenpaket zu einem zweiten Knoten, zum Beispiel einem MNN, gesendet werden soll, wie in einem Schritt 2020 dargestellt wird. Der CN sucht wie in einem Schritt 2030 innerhalb eines erweiterten Binding Cache (EBC), der die Care-of-Source-Routen speichert, die aus in erweiterten BUs empfangener Care-of-Route-Information abgeleitet werden, nach des MNNs Adresse.
Falls in einem Schritt 2040 des MNNs Adresse gefunden wird, ist der CN (oder HA) im Stande, das Paket wie in einem Schritt 2050 durch die in dem EBC gefundene Care-of-Source-Route zu des MNNs Adresse zu sourcerouten, wobei eine Routenoptimierung erzielt wird. Ansonsten sendet der CN das Datenpaket an den MNN unter Verwendung des bekannten Verfahrens direkt an des MNNs Heimatadresse, wie in einem Schritt 2060 dargestellt wird.
Bezieht man sich nun auf 21, sieht man, dass bevorzugte Beispiele für Datenpaketformate, die durch einen ersten Knoten, sagen wir mal einen CN, zu einem zweiten Knoten, sagen wir mal einem MNN, gesendet werden, gemäß den bevorzugten Ausführungsformen der vorliegenden Erfindung dargestellt werden.
Ein erstes Format eines Datenpakets 2100 umfasst einen einzelnen IP-Header 2110, der eine IP-Quelladresse 2112 und eine IP-Zieladresse 2114 entsprechend der ersten IP-Adresse in CNs Care-of-Source-Route zu MNN umfasst. Der einzelne IP-Header 2110 wird von einem Routing-Header 2120 gefolgt, der die (m-1) anderen Adressen (von CNs Care-of-Source-Route zu MNN) in der Route zu dem zweiten Knoten umfasst. Die Datennutzlast 2130 folgt dem Routing-Header.
Ein zweites Format eines Datenpakets 2150 umfasst 'm' aufeinander folgende IP-Header, von denen jeder entsprechende IP-Quelladressen 2112, 2152, 2162, 2172 und entsprechende IP-Zieladressen 2114, 2154, 2164, 2174 umfasst. Die 'm' aufeinander folgenden IP-Header brauchen deshalb keinen separaten Routing-Header, also folgt die Datennutzlast 2180 den IP-Headern. Jeder von den aufeinander folgenden IP-Headern weist seine IP-Zieladresse einer der IP-Adressen von CNs Care-of-Source-Route zu MNN entsprechend gesetzt auf. Der erste Header umfasst die erste Adresse der Care-of-Source-Route (CoSR), der zweite Header umfasst die zweite Adresse und so weiter zu dem letzten Header. Der letzte IP-Header 2172, 2174 zusammen mit der Datennutzlast 2180 bildet das Originalpaket 2190, das von dem ersten Knoten zu dem zweiten Knoten zu senden ist.
Jeder Knoten (CN, MNN, HA), der erweiterte Binding Updates empfangen soll, hat einen erweiterten Binding Cache (EBC) zu führen. Der EBC wird hier als eine Erweiterung des Mobile IP Binding Cache definiert, wo Care-of-Adressen durch "Care-of-Source-Routen" (CoSR), abgeleitet aus den Care-of-Routen (CoR), die in den erweiterten Binding Upda tes empfangen werden, ersetzt werden. Es ist erwähnenswert, dass die Care-of-Source-Route, die in dem erweiterten Binding Cache verzeichnet ist, leicht verschieden (d. h. kürzer) von der in dem erweiterten Binding Update empfangenen Care-of-Route sein kann.
Bezieht man sich nun auf 28, erkennt man, dass ein erweiterter Binding Cache 2800 gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung dargestellt wird.
Der erweiterte Binding Cache 2800 umfasst eine Liste von Einträgen 2810, 2840, 2870, von denen jeder spezifisch für eine Heimatadresse eines MNN ist. Der erweiterte Binding Cache-Eintrag 2810 umfasst zum Beispiel eine erste Heimatadresse 2815 mit einer Verbindung 2818 zu einer ersten Care-of-Source-Route 2820, falls eine ermittelt worden ist. Die erste Care-of-Source-Route 2820 umfasst entsprechende verbundene Care-of-Source-Route-Adressen 2825, 2830 und 2835, um die Route zu der ersten Heimatadresse zu identifizieren. Der erste Eintrag 2810 ist verbunden 2837 mit einem zweiten Eintrag 2840 mit einer Verbindung 2848 von einer zweiten Heimatadresse 2845 zu einer zweiten Care-of-Source-Route 2850, falls eine ermittelt worden ist. Die zweite Care-of-Source-Route 2850 umfasst entsprechende verbundene Care-of-Source-Route-Adressen 2855, 2860 und 2865, um die Route zu der zweiten Heimatadresse zu identifizieren. Eine ähnliche Anordnung und Verbindung 2867 wird zu einem dritten Eintrag 2870 ausgeführt und so weiter.
In der Erfindung wird erwogen, dass das erweiterte BU auch Einträge für eines mobilen Routers (MR) Präfix und Präfixlänge umfassen kann. Das ist besonders nützlich, wenn ein MR ein erweitertes Prefix Scope BU als eine Erweiterung zu [3] an seinen HA oder seine CNs sendet, wo die CoR die CoA in dem Prefix-Scope Binding Update ersetzt. In diesem Fall wird das Heimatadressfeld durch ein "Präfix- und Präfixlänge"-Feld in dem EBC des entsprechenden HA oder CNs ersetzt.
Bezieht man sich nun auf 29, erkennt man, dass der Aufbau einer Care-of-Source-Route 2900 aus einem empfangenen erweiterten BU gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung dargestellt wird. Eines ersten Knotens Care-of-Route (N1_CoR) umfasst eine geordnete Liste von Care-of-Route-Adressen (N1_CoR[1], N1_CoR[2], ...) 2910. Wenn der erste Knoten N1 eine erweiterte BU-Nachricht von einem zweiten Knoten N2 empfängt, die N2s Care-of-Route (N2_CoR) umfasst, vergleicht der erste Knoten die zwei geordneten Listen von Care-of-Route-Adressen, um zu ermitteln, wenn es zwischen ihnen einen Unterschied gibt 2940. Die Adresse von N2_CoR, die als unterschiedlich ermittelt wurde, und alle nachfolgenden Adressen von N2_CoR werden dann verwendet, um eine neue Care-of-Source-Route 2930 für Datenpaketübertragungen von N1 zu N2 zu erzeugen. Dieser Prozess wird mit Bezug auf das Flussdiagramm von 30 weiter beschrieben.
Bezieht man sich nun auf 30, erkennt man, dass ein Flussdiagramm 3000 eines Prozesses zum Ermitteln einer Care-of-Source-Route, die in einem erweiterten Binding Ca che umfasst werden soll, gemäß bevorzugten Ausführungsformen der vorliegenden Erfindung dargestellt wird. Ein erster Knoten (N1) empfängt ein erweitertes Binding Update von einem zweiten Knoten (N2) und muss die Care-of-Source-Route ermitteln, die in dem erweiterten Binding Cache für diesen Eintrag (N2) umfasst werden soll.
Der Prozess beginnt bei einem Schritt 3002. Wenn ein erster Knoten (N1, der selbst ein MNN zu Hause oder in einem fremden Netz oder jeglicher Host in der Topologie sein kann) in einem Schritt 3004 ein EBU empfängt, das eine neue Care-of-Route für einen zweiten Knoten (N2) umfasst, ermittelt N1 in einem Schritt 3006, ob diese N2-Care-of-Route (in dem EBU empfangen) leer ist.
Falls die neue Care-of-Route für N2, empfangen in dem EBU, in dem Schritt 3006 leer ist, durchsucht N1 seinen erweiterten Binding Cache, um zu prüfen, ob es einen Eintrag (d. h. eine Care-of-Source-Route) für diesen zweiten Knoten in dem EBC gibt, wie in einem Schritt 3008 dargestellt wird. Falls in dem EBC kein Eintrag vorhanden ist, endet der Prozess in einem Schritt 3046. In diesem Fall wird für N2 kein Eintrag in N1s erweitertem Binding Cache benötigt. Bei Adressierung eines Pakets an N2s Heimatadresse erfolgt das Datenpaket von N1 direkt auf dem kürzesten Pfad (eine Routenoptimierung wird erzielt, ohne dass Source Routing erforderlich ist). Falls allerdings in dem Schritt 3008 ein Eintrag in dem EBC vorhanden ist, wird in einem Schritt 3010 der Eintrag für den zweiten Knoten entfernt (d. h. N1_CoSR (to N2)), bevor der Prozess in dem Schritt 3046 endet.
Falls die neue in dem EBU empfangene N2-Care-of-Route in dem Schritt 3006 nicht leer ist, wird in einem Schritt 3012 eine Ermittlung darüber durchgeführt, ob ein Care-of-Route-Eintrag für den ersten Knoten vorhanden ist. Falls in dem Schritt 3012 eine Care-of-Route für den ersten Knoten nicht vorhanden ist, wird eines ersten Knotens (N1) Care-of-Source-Route zu dem zweiten Knoten (N2) erzeugt, die der Care-of-Route des zweiten Knotens entspricht (N1_CoSR (to N2) := N2_CoR), wie in einem Schritt 3014 dargestellt wird. N1 durchsucht dann seinen erweiterten Binding Cache, um zu prüfen, ob es einen Eintrag (d. h. eine Care-of-Source-Route) für diesen zweiten Knoten in dem EBC gibt, wie in einem Schritt 3016 dargestellt wird. Falls in dem EBC kein Eintrag vorhanden ist, wird dem EBC in einem Schritt 3020 ein Eintrag für N2 hinzugefügt (N1_CoSR (to N2)) und der Prozess endet in dem Schritt 3046. Falls in dem Schritt 3016 ein Eintrag in dem EBC vorhanden ist, wird der Eintrag des zweiten Knotens in einem Schritt 3018 aktualisiert (d. h. N1_CoSR (to N2)), bevor der Prozess in dem Schritt 3046 endet.
Falls der erste Knoten in dem Schritt 3012 seine eigene Care-of-Route aufweist, werden alle Adressen in den Care-of-Routen der zwei Knoten (N1 und N2) durchsucht, wobei damit begonnen wird, dass in einem Schritt 3022 ein Zähler gesetzt wird (i = 0). N1 vergleicht in einem Schritt 3024 die IP-Adressen in seiner eigenen Care-of-Route (N1_CoR) eine nach der anderen mit den IP-Adressen, die in der Care-of-Route des erweiterten Binding Update, von Knoten N2 empfangen, aufgeführt sind.
Er beginnt mit den ersten Adressen N1_CoR(1) und N2_CoR(1) und fährt sodann fort. Falls in einem Schritt 3026 eine Übereinstimmung für eine bestimmte Adresse der Care-of-Routen des ersten Knotens und des zweiten Knotens gefunden wird, wird in einem Schritt 3028 eine Ermittlung darüber durchgeführt, ob des zweiten Knotens Care-of-Route-Adresse die letzte Adresse ist. Falls es sich dabei um die letzte Adresse handelt, ist in einem Schritt 3030 die gesamte Care-of-Route von N2 durchsucht worden und der Prozess bewegt sich wie oben beschrieben zu dem Schritt 3008. Falls des zweiten Knotens Care-of-Route-Adresse in dem Schritt 3028 nicht die letzte Adresse ist, wird in einem Schritt 3032 eine Ermittlung darüber durchgeführt, ob des ersten Knotens Care-of-Route-Adresse die letzte Adresse für den ersten Knoten ist. Falls in dem Schritt 3032 des ersten Knotens Care-of-Route-Adresse nicht die letzte Adresse ist, wird der Zähler in einem Schritt 3034 inkrementiert und die nächsten Adressen werden in dem Schritt 3024 durchsucht. Falls in dem Schritt 3028 des ersten Knotens Care-of-Route-Adresse die letzte Adresse ist oder in dem Schritt 3026 keine Übereinstimmung gefunden wurde, stoppt der Suchprozess in einem Schritt 3036 und die Care-of-Source-Route von N1 zu N2 wird in 3038 gesetzt.
In 3038 wird die Care-of-Source-Route zu N2 von N1 so gesetzt, dass sie Teil der geordneten Liste von Adressen von N2s Care-of-Route, ausgehend von der i^ten Adresse zu der letzten, entspricht. Diese i^te Adresse ist diejenige, bei der die Schleife in N2s Care-of-Route-Adressen in dem Schritt 3036 anhielt. Das heißt: N1_CoSR (to N2) = {N2_CoR(i) → N2_CoR(i+1) → ... → N2_CoR(n-1) → N2_CoR(n)}. N1 durchsucht dann seinen erweiterten Binding Cache, um zu prüfen, ob es einen Eintrag (d. h. eine Care-of-Source-Route) für diesen zweiten Knoten in dem EBC gibt, wie in einem Schritt 3040 dargestellt wird.
Falls in dem EBC kein Eintrag vorhanden ist, wird dem EBC in einem Schritt 3042 ein Eintrag für N2 hinzugefügt (N1_CoSR (to N2)) und der Prozess endet in dem Schritt 3046. Falls in dem Schritt 3040 ein Eintrag in dem EBC vorhanden ist, wird in einem Schritt 3044 der Eintrag des zweiten Knotens in N1s EBC aktualisiert (d. h. N1_CoSR (to N2)), bevor der Prozess in dem Schritt 3046 endet.
Falls N1 in dem Schritt 3012 keine Care-of-Route aufweist (NR_CoR leer oder nicht vorhanden ist), dann wird die Care-of-Source-Route von N1 zu N2 so gesetzt, dass sie N2s Care-of-Route in dem Schritt 3014 entspricht. Das heißt: N1_CoSR(to N2) = N2_CoR. N1 durchsucht dann seinen erweiterten Binding Cache, um zu prüfen, ob es einen Eintrag (d. h. eine Care-of-Source-Route) für diesen zweiten Knoten in dem EBC gibt, wie in dem Schritt 3016 dargestellt wird. Falls in dem EBC kein Eintrag vorhanden ist, wird dem EBC in dem Schritt 3020 ein Eintrag für N2 hinzugefügt (N1_CoSR(to N2)) und der Prozess endet in dem Schritt 3046. Falls in dem Schritt 3016 ein Eintrag in dem EBC vorhanden ist, wird in dem Schritt 3018 der Eintrag des zweiten Knotens in N1s EBC aktualisiert (d. h. N1_CoSR(to N2)), bevor der Prozess in dem Schritt 3046 endet.
N1 sollte dann das Paket über die Care-of-Source-Route zu N2 sourcerouten, um eine Routenoptimierung zu erzielen, wie mit Bezug auf 21 und 22 beschrieben wird. Wie vorher beschrieben wird, kann das auf verschiedene Art und Weisen implementiert werden. Eine erste Art und Weise besteht darin, den IPv6 Routing-Header zu verwenden. In diesem Fall wird die erste Adresse in der Care-of-Source-Route als die Zieladresse in dem IPv6 Header gesetzt und die übrigen Adressen der Care-of-Source-Route (CoSR) werden in dem Routing-Header in derselben Ordnung gesetzt. Eine zweite Art und Weise besteht darin, dass der erste Knoten 'n' Ebenen an Kapselung des zu sendenden Datenpakets erstellt, wobei 'n' die Anzahl von Adressen in der Care-of-Source-Route ist. Die Kapselung #k weist die Adresse #k der geordneten Liste von Adressen in der Care-of-Source-Route als die Zieladresse auf.
Darüber hinaus brauchen die verschiedenen oben beschriebenen Schritte nicht unbedingt in der Ordnung ausgeführt werden, in der sie beschrieben worden sind. Es versteht sich für einen qualifizierten Fachmann, dass eine alternative Ordnung verwendet werden kann, wo immer noch ein Nutzen in dem Routenoptimierungsprozess erzielt werden kann.
Es versteht sich, dass die Anordnung und spezifischen Details von Schnittstellen, Adresstypen, Routern usw. in den obigen Ausführungsformen lediglich Beispiele sind und die Erfindung nicht auf diese Beispiele beschränkt ist. Die Erfindung sollte als auf andere Aspekte des Internets oder andere Typen von Datennetzen oder Protokollen und Subnetzen davon anwendbar betrachtet werden. Darüber hinaus kann die Erfindung auch auf andere Netze als das Internet angewendet werden, wenn solche Netze Subnetze und Zugangsnetze aufweisen, die denjenigen entsprechen, die oben für den Fall des Internets beschrieben werden.
Die Erfindung – oder zumindest Ausführungsformen davon – sorgt dafür, dass die folgenden Vorteile, einzeln oder in Kombination, zur Verfügung gestellt werden:

(i) Ein Datenpaket kann unter Verwendung dieses verbesserten Routenoptimierungsverfahrens viel effizienter übertragen werden.
(ii) Verbesserte Privatsphäre von Datenpaketübertragungen, da jeder Knoten in der Topologie dafür zuständig ist, seine eigenen Binding Updates an seine CNs und seinen Home Agent zu senden. Somit ist jeder Knoten im Stande zu entscheiden, ob er durch Senden eines Binding Update seinen aktuellen Standort offen legen möchte, um eine Routenoptimierung durchzuführen. Dabei handelt es sich um einen deutlichen Vorteil über [3], wo Privatsphäre nicht zugelassen ist.
(iii) Die durch die IETF definierten Sicherheitslösungen zur Bereitstellung von "Adresseigentums"-Berechtigung (z. B. Return Route-Fähigkeit) sind in dem Kontext der vorliegenden Erfindung nach wie vor anwendbar. Dabei handelt es sich erneut um einen klaren Vorteil über [3], wo erforderlich ist, dass ein neuer Sicherheitsmechanismus eingeführt wird.
(iv) Ein gesicherter Austausch von neuen Nachrichten (z. B. "Care-of-Route-Advertisement"), in der vorliegenden Erfindung eingeführt, kann entweder durch Shared Secret (in dem Fall von Knoten, die zu derselben Organisation gehören) oder durch ein neues IETF-Protokoll, wie z. B. PANA, in dem Fall, wo ein mobiler Knoten (Host oder Router) ein fremdes Netz besucht, sehr leicht realisiert werden.
(v) Eine Lösung für ein effizientes Datenrouting in IPv6, IPv4 oder ähnlichem Datennetzprotokoll ist insbesondere für Systeme, die geschachtelte Netzmobilität unterstützen, erzielt worden.

Zwar werden oben die spezifischen und bevorzugten Implementierungen der Ausführungsformen der vorliegenden Erfindung beschrieben, doch ist es offensichtlich, dass ein qualifizierter Fachmann Änderungen und Modifikationen solcher erfinderischen Ideen leicht anbringen könnte.
Somit sind ein Mechanismus, Vorrichtung und zugehörige Verfahren beschrieben worden, um eine Routenoptimierung bei Netzmobilität, insbesondere in dem Fall von IPv6, zu unterstützen, wodurch die mit bekannten Mechanismen, Vorrichtungen und zugehörigen Verfahren verbundenen Nachteile wesentlich gemindert worden sind. Insbesondere sind ein Mechanismus, Vorrichtung und zugehörige Verfahren beschrieben worden, um eine Routenoptimierung in dem Fall von geschachtelter Mobilität zu unterstützen.

Claims

Verfahren zum Übertragen (2000) eines Datenpakets auf einem Kommunikationspfad von einem ersten Kommunikationsknoten zu einem zweiten Kommunikationsknoten in einem mobilen Netz, wobei das Verfahren durch die Schritte gekennzeichnet ist, dass: der erste Kommunikationsknoten (1030) eine Routennachricht von dem zweiten Kommunikationsknoten (655) empfängt, wobei die Routennachricht eine Liste aus einer Mehrzahl von intermediären Adressen zwischen dem ersten Kommunikationsknoten (1030) und dem zweiten Kommunikationsknoten (655) umfasst, wobei die Mehrzahl von intermediären Adressen eine Adresse eines mobilen Routers (650, 660) umfasst; der erste Kommunikationsknoten (1030) als Antwort auf die Liste von intermediären Adressen einen bevorzugten Kommunikationspfad erzeugt (3014, 3038); und der erste Kommunikationsknoten (1030) das zumindest eine Datenpaket von dem ersten Kommunikationsknoten (1030) über den bevorzugten Kommunikationspfad zu dem zweiten Kommunikationsknoten (655) überträgt.
Verfahren zum Übertragen eines Datenpakets nach Anspruch 1, wobei das mobile Netz geschachtelte Netzmobili tätsoperation unterstützt und der Schritt zum Übertragen den Schritt umfasst: Routing des zumindest einen Datenpakets über eine Mehrzahl von mobilen Routern (650, 660), identifiziert durch die intermediären Adressen in dem mobilen Netz.
Verfahren zum Übertragen eines Datenpakets mach Anspruch 1 oder Anspruch 2, wobei das mobile Netz gemäß einer IPv6- und/oder IPv4-Spezifikation arbeitet.
Verfahren zum Übertragen eines Datenpakets nach einem vorangehenden Anspruch, wobei der erste Kommunikationsknoten (1030) ein korrespondierender Knoten des zweiten Kommunikationsknotens (655) ist und/oder der zweite Kommunikationsknoten (655) ein mobiler Netzknoten ist.
Verfahren zum Übertragen eines Datenpakets nach einem vorangehenden Anspruch, wobei das Verfahren darüber hinaus durch den Schritt gekennzeichnet ist: Senden einer Care-of-Route-Advertising-Nachricht durch eine Mehrzahl von Kommunikationsknoten in dem mobilen Netz, die Routeninformation in Bezug auf Kommunikationsknoten, dem zweiten Kommunikationsknoten (655) zugeordnet, umfasst, so dass ein Kommunikationspfad zu einem beabsichtigten Empfänger ermittelt werden kann.
Verfahren zum Übertragen eines Datenpakets nach einem vorangehenden Anspruch, wobei die Liste der Mehrzahl von intermediären Adressen Adressen von einem oder mehreren mobilen Routern (650, 660) über dem zweiten Kommunikations knoten in einer Routenhierarchie umfasst, um das Datenpaket an einen beabsichtigten Empfänger zu übermitteln.
Verfahren zum Übertragen eines Datenpakets nach Anspruch 5 oder Anspruch 6, wobei das Verfahren darüber hinaus durch den Schritt gekennzeichnet ist: Anfordern von Übertragung von einer oder mehreren Care-of-Route-Advertisement-Nachrichten, wobei Routeninformation von einer oder mehreren IP-Adressen umfasst wird, von angrenzenden Kommunikationsknoten, wenn sich der zweite Kommunikationsknoten zu einem neuen Standort innerhalb des mobilen Netzes bewegt.
Verfahren zum Übertragen eines Datenpakets nach einem der vorangehenden Ansprüche 5 oder 7, wobei das Verfahren darüber hinaus durch die Schritte gekennzeichnet ist: Extrahieren von intermediären Routennachrichten aus der Routeninformation in der Care-of-Route-Advertising-Nachricht an einem Kommunikationsknoten; und Übertragen der intermediären Routennachrichten zu Kommunikationsknoten, die der extrahierende Kommunikationsknoten versorgt.
Verfahren zum Übertragen eines Datenpakets nach Anspruch 8, wobei das Verfahren darüber hinaus durch den Schritt gekennzeichnet ist: Anhängen einer Routennachricht der Kommunikationseinheit an die Liste intermediärer Routen in der Care-of-Route-Advertising-Nachricht an dem Kommunikationsknoten.
Verfahren zum Übertragen eines Datenpakets nach einem der vorangehenden Ansprüche 5 oder 7 bis 9, das darüber hinaus durch den Schritt gekennzeichnet ist: periodisches Senden der Care-of-Route-Advertising-Nachricht an alle oder eine selektierte Anzahl von Kommunikationsknoten (1030, 655) in dem mobilen Netz.
Verfahren zum Übertragen eines Datenpakets nach einem der vorangehenden Ansprüche 5 oder 7 bis 10, wobei das Verfahren darüber hinaus durch den Schritt gekennzeichnet ist: Senden einer Präfixadvertisementnachricht des mobilen Netzes durch einen mobilen Router bei einer Spitze einer Routinghierarchie in dem mobilen Netz, um des mobilen Netzes Präfix bekannt zu machen; und Ermitteln durch Kommunikationsknoten in demselben mobilen Netz, dass sie sich innerhalb des mobilen Netzes des sendenden mobilen Routers befinden.
Verfahren zum Übertragen eines Datenpakets nach einem der vorangehenden Ansprüche, wobei das Verfahren darüber hinaus durch den Schritt gekennzeichnet ist: Senden einer Routeninformation umfassenden erweiterten Binding Update-Nachricht nur an Kommunikationsknoten außerhalb des mobilen Netzes des sendenden Kommunikationsknotens.
Speichermedium (665), das prozessorimplementierbare Anweisungen speichert, um einen Prozessor zu steuern, um das Verfahren nach einem der Ansprüche 1 bis 12 auszuführen.
Mobiles Netz, das einen ersten Kommunikationsknoten (1030) umfasst, eingerichtet, um auf einem Kommunikationspfad ein Datenpaket zu einem zweiten Kommunikationsknoten (655) zu übertragen (2000), wobei der erste Kommunikationsknoten (1030) umfasst: Mittel, eingerichtet, um eine Routennachricht von dem zweiten Kommunikationsknoten (655) zu empfangen, wobei die Routennachricht eine Liste aus einer Mehrzahl von intermediären Adressen zwischen dem ersten Kommunikationsknoten (1030) und dem zweiten Kommunikationsknoten (655) umfasst; Mittel, eingerichtet, um als Antwort auf die Liste von intermediären Adressen einen bevorzugten Kommunikationspfad zu erzeugen (3014, 3038); und Mittel, eingerichtet, um das zumindest eine Datenpaket von dem ersten Kommunikationsknoten (1030) über den bevorzugten Kommunikationspfad zu dem zweiten Kommunikationsknoten (655) zu übertragen (2050); und wobei das mobile Netz durch den zweiten Kommunikationsknoten (655) gekennzeichnet ist, der umfasst: Mittel, eingerichtet, um die Routennachricht zu dem ersten Kommunikationsknoten zu übertragen, wobei die intermediären Adressen der Routennachricht eine Adresse eines mobilen Routers (650, 660) umfassen.