-
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 → HAn-1 → HAn-2 → ... → HA1-Pfad
anstatt eines CN2 255 → HAn → HAn-1→ HAn-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 MR1,
..., MRn und n entsprechende Home Agents
HA1, ..., HAn) 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 iten Adresse zu der letzten, entspricht.
Diese ite 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.