DE60310593T2

DE60310593T2 - Routing in einem datenkommunikationsnetz

Info

Publication number: DE60310593T2
Application number: DE60310593T
Authority: DE
Inventors: Motorola SAS Alexandru PETRESCU; Motorola SAS Christophe JANNETEAU; Motorola SAS Hong-Yon LACH
Original assignee: Motorola Inc
Current assignee: Motorola Mobility LLC
Priority date: 2002-10-09
Filing date: 2003-10-08
Publication date: 2007-05-16
Anticipated expiration: 2023-10-09
Also published as: US20060050692A1; DE60310593D1; EP1552665B1; EP1552665A1; JP2006502636A; JP4226553B2; AU2003285348A1; WO2004034669A1; ATE349131T1; US7706301B2; EP1408666A1

Description

Gebiet der Erfindung
Diese Erfindung bezieht sich auf einen Datenfluss in Kommunikations- und Computernetzen. Die Erfindung ist anwendbar, jedoch nicht begrenzt, auf einen Adress-/Routing-Mechanismus für mobile Knoten innerhalb solcher Netze.
Hintergrund der Erfindung
Das Internet wird immer mehr beliebter, wobei der Zugriff auf das Internet über Computernetze und Kommunikationsnetze bereitgestellt wird. Der Standardkommunikationsmechanismus, welchen Kommunikationseinheiten verwenden, um auf das Internet zuzugreifen, ist das bekannte Internetprotokoll (IP) Version 4 und Version 6.
Tatsächlich wünschen Benutzer zunehmend, über ihre mobile(n) Kommunikationsvorrichtung(en) auf das Internet zuzugreifen, während sie unterwegs sind. Diese Vorrichtungen werden im IP-Sprachgebrauch mobile Knoten genannt. Unterschiedliche Arten von mobilen Knoten können für diesen Zweck eingesetzt werden, beispielsweise ein tragbarer Personal-Computer (PC), ein mobiles Telefon oder ein persönlicher digitaler Assistent (PDA) mit kabelloser Kommunikationsfähigkeit. Darüber hinaus greifen mobile Benutzer auf das Internet über unterschiedliche Arten von feststehenden oder kabellosen Zugriffsnetzen zu, wie etwa ein zellulares Radiokommunikationsnetz, wie etwa ein universales mobiles Telekommunikationssystem (UMTS) Netz, ein HiperLAN/2 (HiperLAN = lokales Netz mit hoher Leistung) oder ein IEEE 802.11b lokales Netz, ein lokales Bluetooth Kommunikationssystem oder fixierte Zugriffe wie etwa das Ethernet, usw.
Es ist derzeit möglich, einen Handover-Zugriff des Internets von einem Zugriffsnetz zu einem anderen zu unterstützen, z.B. unter Verwendung eines als mobiles IP bekanntes Protokoll. Herkömmliche Mobilitätsunterstützung beabsichtigt, eine kontinuierliche Internetverbindung zu mobilen Hosts zu bieten, um es dadurch individuellen mobilen Benutzern zu erlauben, während dem sie unterwegs sind, eine Verbindung mit dem Internet herzustellen, wobei dem mobilen Host die Möglichkeit gegeben wird, die Stelle ihres Internetzugriffes zu bewegen. Vor kurzem gab es eine beträchtliche Menge Interesse und Forschung in der mobilen IPv6 Spezifikation, wie es in dem von David B. Johnson mitverfassten Dokument: IETF Internet-Draft draft-ietf-mobileip-ipv6-18.txt, Juni 2002, beschrieben ist.
Innerhalb von IPv6 Netzen werden Host-Vorrichtungen und Client-Vorrichtungen Adressen zugeordnet, welche einhundertachtundzwanzig Bits umfassen, um die Vorrichtung gegenüber anderen Vorrichtungen innerhalb oder außerhalb des Netzes zu identifizieren. Die Einhundertachtundzwanzig -Bit-Adressen sind als Internetprotokoll Version 6 Adressen (IPv6-Adressen) bekannt. Nachfolgend werden die Bezeichnungen IPv6-Adressen und IP-Adressen austauschbar verwendet. IP-Adressen bieten einen einfachen Mechanismus zur Identifizierung der Quelle und des Zieles der Nachrichten, die innerhalb des IP-Netzes versendet werden.
Herkömmlicherweise wurden IP-Adressen, die Vorrichtungen innerhalb der IP-Netze identifizieren, in einer statischen Art und Weise während der Netzkonfiguration zugeteilt. Durch Verwendung dieser Art der statischen Zuteilung sind Datenrouter und andere Netzkomponenten vorkonfiguriert, dass sie die statisch zugeteilten Adressbindungen verwenden, die eine Verknüpfung der Vorrichtungen mit ihren IP-Adressen herstellen.
In großen oder sich schnell verändernden Netzen ist jedoch die statische Zuteilung der IP-Adressen oftmals unzureichend. Als ein Ergebnis wurden verschiedene Verfahren entwickelt, die es ermöglichen, dass IP-Adressen automatisch zugeteilt werden. Die zwei am häufigsten verwendeten Verfahren umfassen:

(i) Automatische Verteilung durch zentrale Server, und
(ii) Adressherleitung durch ein enges Zusammenwirken zwischen Hosts und dem direkt benachbarten Router.

In einem anderen, in einigen IP-Netzen verwendeten Verfahren analysieren Router von Client-Vorrichtungen empfangene IP-Datenpakete. Jedes Datenpaket hat eine Quelladresse und eine Zieladresse. Die Quelladressen in diesen Datenpaketen werden ausgelesen und verwendet, um Routen innerhalb des Routers zu aktualisieren, um Datenpakete zu und/von speziellen Vorrichtungen zu überbringen. In diesen letzteren Arten von Netzen werden Routen, basierend auf den Paketen, die innerhalb des Netzes zirkulieren, analysiert, jedoch werden Adressen nicht automatisch zugeteilt.
Ein getunneltes Paket ist ein Datenpaket, welches in sich ein anderes Datenpaket einschließt. Folglich weist das einschließende Datenpaket ein paar von Quell- und Zieladressen auf. Ein weiteres eingeschlossenes Paket hat zusätzliche Quell- und Zieladresse, usw. Solch ein Tunnelmechanismus ermöglicht es einem Basisagenten, der gegenwärtigen Position eines mobilen Knotens nachzufolgen und Pakete von der Basisstation (gekennzeichnet durch eine IP-Adresse oder Basisadresse) zu der neuen Position (einer neuen IP-Adresse oder der Peer-Adresse) weiterzuleiten. Unter einer Routing-Perspektive ermöglicht das Tunneln, dass eine Route des Datenpaketes bestimmt wird, das heißt durch das Ent-Tunneln der Datenpakete, um so die Quell-Adresse jedes eingeschlossenen Paketes zu bestimmen.
Zunehmend werden IP-Adressen innerhalb der Netze durch Serversysteme unter Verwendung des dynamischen Host-Konfigurationsprotokolls (DHCP), wie es in Internet RFC 1541 definiert ist, welches hierin durch Bezugnahme beinhaltet ist, zugeteilt. Für Netze, die das DHCP-Protokoll verwenden, sind einer oder mehrere DHCP-Server konfiguriert, um Nachrichten abzuhören, die IP-Adressen anfordern. Wenn möglich, weist der DHCP-Server dann eine IP-Adresse dem Client-System zu, welches die Nachricht sendet. Die neuste, zugewiesene IP-Adresse ist dann in einer Nachricht enthalten, die durch den DHCP-Server an das Client-System gesendet wird. Die IP-Adresse wird eigentlich an das Client-System auf einer zeitbegrenzten Basis geliefert, um dadurch eine Wiederverwendung der gleichen Adressen durch den gleichen oder einen anderen Client zu ermöglichen.
Im Allgemeinen hat sich die Verwendung der DHCP-Server, um IP-Adressen an Client-Systemen zuzuteilen, als besonders vorteilhaft erwiesen, um unerfahrene Benutzer vor der Handhabung langer Zeichenfolgen von Zahlen (IP-Adressen) zu bewahren. Darüber hinaus ermöglicht es einem Administrator eine strenge Kontrolle über die Verwaltung des Adressenpools und garantiert die Eindeutigkeit jeder verwendeten Adresse. Dies ist im Besonderen in Netzen richtig, die eine große Anzahl von Client-Systemen umfassen.
Nun Bezug nehmend auf 1, ist ein bekannter IP-Routingmechanismus beschrieben, der das IETF Mobile IPv6 Protokoll in einem Netz verwendet. Als ein Beispiel ist ein Netz gezeigt, das häufig in einem Netz mit campusartiger Mobilität vorkommt. Das Netz verwendet Verbindungstechnologien, wie etwa das Ethernet und das 802.11b.
In dieser Hinsicht wird ein mobiler Knoten 160 in einer Computer-/Kommunikations-Domäne mit Mikromobilität (lokaler Mobilität) betrieben. Die Computer-/Kommunikations-Domäne mit Mikromobilität ist als eine Baumstruktur konfiguriert, mit einer Schnittstelle 120 zwischen Knoten in der lokalen Domäne und beispielsweise dem Internet 110. Zum Beispiel sei angenommen, dass der mobile Knoten ein tragbarer Computer ist, der geeignet ist, um mit dem Internet 110 durch kabellose Verknüpfung mit einer beliebigen Anzahl von Zugriffspunkten/Zugriffsroutern 140–150 zu kommunizieren.
Die Zugriffsrouter sind typischerweise an Relais mit dynamischem Host-Konfigurationsprotokoll (DHCP) verknüpft. Die Routing-Funktionalitäten (in der Software) und die DHCP-Relay-Funktionalitäten (in der Software) werden in dem gleichen Zugriffsknoten ausgeführt. Optional können die zwei Funktionalitäten über zwei unterschiedliche Knoten verteilt werden, jedoch mit den Einschränkungen, dass:

(i) das Relais auf der Verbindung direkt neben dem mobilen Knoten angeordnet sein muss, um die durch den mobilen Knoten gesendeten, übertragenen Adress-Autokonfigurations-Nachrichten zu empfangen, und
(ii) die Router-Funktionalität soweit wie möglich in Richtung des Randes der Domäne mit lokaler Mobilität angeordnet sein muss, um das korrekte Fortschreiten der Routen zu gewährleisten.

Die Domäne mit Mikromobilität umfasst die Router 130, 132, 134, um die Zugriffsrouter/DCHCP-Relais 140–150 mit der Schnittstelle zu verbinden, die einen DHCP-Server 120 umfasst. Wenn der mobile Knoten 160 sich an dem Zugriffsrouter 140 angemeldet hat, wird ihm eine temporäre IP-Adresse zugeteilt, die dem Basisagenten 105 des MN's (= des mobilen Knotens) über 165 gemeldet wird. Der MN 160 kann auf Anwendungen von dem Anwendungsserver 115 über eine Route 170 zugreifen, die das Internet 110, die/den Schnittstelle/DHCP-Server 120 und eine Vielzahl von seriell verknüpften Zwischenroutern 130 (wobei nur ein Router gezeigt ist) und den Zugriffsrouter 140 umfaßt.
Vor allem, wenn sich der MN 160 an einem anderen Zugriffsrouter/DHCP-Relais 150 anmeldet, wird dem MN eine neue IP-Adresse zugewiesen. Die neue IP-Adresse wird in der Nachricht 175 dem Basisagenten 105 des MN's mitgeteilt, so dass die Kommunikation in Richtung der Basisposition (Basisadresse) des MN zu der neuen Position des MN 160 (Peer-Adresse) geroutet werden kann. Im Hinblick darauf würde ein Fachmann anerkennen, dass ein Netz, das ein IETF Mobile IPv6-Protokoll benützt, zur Handhabung einer Domäne mit Mikromobilität (oder lokaler Mobilität) nicht ideal geeignet ist. Die Unangemessenheit geht von einem hohen zusätzlichen Steuerungsaufwand aus, der sich aus den häufigen Meldungen an den Basisagenten 105 ergibt.
Verfahren, die DHCP und Mobile IP verwenden, um die Mobilität an einem IP Niveau zu handhaben, sind in den Dokumenten von Charles E. Perkins, et al. beschrieben:

(i) "Using DHCP with Computers that Move", Proceedings of the Ninth Annual IEEE Workshop on Computer Communications, 1994; und
(ii) "DHCP for Mobile Networking with TCP/IP", Proceedings of the IEEE Symposium on Computers and Communications, 1995.

DHCP wird verwendet, um eine Peer-Adresse (CoA) (= Care-of-Address oder Serviceadresse) dynamisch zu erhalten, die nachfolgend mit einem Basisagenten registriert wird. Auf diese Art und Weise legt ein Basisagent IP-Tunnel an und erhält diese aufrecht, die Pakete zu mobilen Knoten durch die Router 130, 132, 134 liefern.
Ein wesentliches Problem mit mobilen Knoten ist das Erfordernis, neue CoAs zuzuweisen, während und sobald der mobile Knoten auf das Netz über einen unterschiedlichen Zugriffs-Punkt zugreift. Darüber hinaus wurde das Erfordernis des Tunnelns in solchen IP-Systemen, im Besonderen in einer Domäne mit Mikromobilität, durch die Erfinder der vorliegenden Erfindung als ein weiterer wesentlicher Nachteil erkannt.
US 5,812,819 A mit dem Titel "Remote Access Apparatus and Method which Allow Dynamic Internet Protocol (IP) Address Management", beschreibt einen Mechanismus, um die gleiche CoA während dem Wechsel der Anschlusspunkte zu verwenden. Der primäre Schwerpunkt der US 5,812,819 A ist es, eine eindeutige persönliche Kennung zu verwenden, so dass ein Benutzer mit jeder erneuten Verbindung die gleiche CoA erhält. Jedoch, obwohl US 5,812,819 A die Aufrechterhaltung der gleichen CoA beschreibt, benötigt der Mechanismus dennoch die und leidet daher an den Nachteilen der Zwischen-Domänen-Tunnelung durch einen Basisagenten des mobilen IPv6.
"Adressen-Autokonfigurations-Protokolle" sind als ein wichtiges Erfordernis für mobile IP-Knoten in den folgenden Dokumenten festgestellt worden:

(i) Dynamic Host Configuration Protocol for IPv6 (DHCPv6), Internet Draft, draft-ietf-dhc-dhcpv6-19.txt; und
(ii) "DHCP for IPv6" von Charles E. Perkins et al., Bound, und veröffentlicht auf dem Third IEEE Symposium on Computer and Communications, 1998.

Die Gründe, die für Adress-Autokonfigurations-Protokolle festgestellt worden sind, die eine wichtige Erfordernis für mobile IP-Knoten sind, umfassen:

(a) In Folge der weitreichenden Internetdurchdringung, die dazu geführt hat, dass der Transportkontrollprotokoll (TCP)/IP Stapel in Allzweck-Computermaschinen eingesetzt wurde, hat der Benutzer solch einer Maschine kaum die Fähigkeit (oder den Wunsch), seinen TCP/IP Stapel manuell zu konfigurieren.
(b) Mit der Einführung von kleineren und allgegenwärtigen Vorrichtungen ist es oftmals der Fall, dass es keinen Benutzer gibt, um die Vorrichtungsstapel zu konfigurieren: Sie müssen als Plug-n-Play (Plug-n-Play = Anschließen und Loslegen) konfiguriert werden.

Im IPv6 bestehen zwei Adress-Autokonfigurations-Mechanismen: "zustandsunabhängig" und "zustandsabhängig". Der wesentliche Unterschied zwischen diesen beiden Mechanismen ist der, dass die zustandsabhängige Autokonfiguration ein Paar von Hosts (Server und Relais) verwenden, um sowohl eine Adress-Datenbank aufrecht zu erhalten als auch eine Knotenanfrage weiterzuleiten, und das Relais antwortet mit der Zuweisung einer Adresse über ein Netz. In der zustandsunabhängigen Autokonfiguration ist der Nachrichtenaustausch für Autokonfiguration auf eine Verbindung begrenzt, und es ist hier kein aufrecht zu erhaltender Status vorhanden.
WO 98/26549, mit dem Titel "Method for Using DHCP to Override Learned IP Addresses in a Network", beschreibt ein Verfahren, wobei DHCP-Nachrichten für IP-Zuteilungsereignisse abgefragt werden. Wenn ein Ereignis getriggert wird, wird eine vorkonfigurierte IP-Route in einer zentralen "Router"-Tabelle aktualisiert.
Jede Route liefert eine Zuordnung zwischen einer IP-Adresse und einem Client-System. Wenn der Router ein IP-Paket empfängt, liest er die Zieladresse des Paketes von dem Erkennungssatz des Paketes aus. Der Router sucht dann in der Routen-Tabelle nach einen Route, die zu der Zieladresse des empfangenen IP-Paketes paßt. Wenn der Router eine passende Route findet, leitet der Router das IP-Paket zu dem in der passenden Route umfassten Client-System weiter.
Vor allem ist das Verfahren in einer Einwahl-Umgebung anwendbar, wo sich alle Clients mit einem Router verbinden und alle angesteuerten Server durch direkte Verbindung auf den gleichen Router gelegt sind. Folglich ist die Anwendbarkeit der WO 98/26549 sehr begrenzt.
Unter Verwendung des DHCP-Protokolles fragen Client-Systeme ab und empfangen dynamisch zugewiesene IP-Adressen von den DHCP-Serversystemen. Der Router hört nach DHCP-ACK-Nachrichten ab, die von dem DHCP-Serversystemen an die Client-Systeme gesendet werden. Die DHCP-ACK-Nachricht umfasst eine IP-Adresse, die einem speziellen Client-System zugewiesen wurde. Wenn der Router eine DHCP-ACK-Nachricht erkennt, liest der Router die für das Client-System zugewiesene IP-Adresse aus. Unter Verwendung der in der DHCP-ACK-Nachricht umfassten IP-Adresse, "lernt" der Router die IP-Adresse des Client-Systems, wobei er eine IP-Adresse anfordert. Der Router fügt dann die Route seiner Routentabelle hinzu. Die neue Route ist gekennzeichnet, um anzuzeigen, dass der DHCP-Server diese zugeteilt hat. Nachfolgend wird der Router nur diese IP-Adresse wieder erlernen, wenn sie erneut durch das DHCP-Serversystem zugeteilt wird.
In einigen Fällen wird die erlernte IP-Adresse einer Route widersprechen, die ursprünglicherweise innerhalb der Routen-Tabelle des Routers konfiguriert wurde. In diesen Fällen wird die widersprechende Route von der Router-Tabelle entfernt. Auf diesem Wege ermöglicht WO 98/26549, dass Routen, die dynamisch zugewiesene IP-Adressen wiedergeben, bereits konfigurierte Routen ersetzen. Die Erfinder der vorliegenden Erfindung haben die Begrenzungen dieses Verfahrens beobachtet und anerkannt, indem es nur in der Lage ist, Router mit neuen IP-Routen zu aktualisieren, und dass es ungeeignet ist, neue IP-Routen in einem Netzszenario zu verarbeiten.
Darüber hinaus sorgt das Verfahren für Aktualisierungen innerhalb nur eines "zentralen" Routers, wo alle Klienten und Server angeschlossen sind und diesen als einen ein zigen "zentralen" Kommunikationsknoten verwenden. Es ist bekannt, dass solche Sternnetze nicht für große Systeme mit hunderten von Klienten oder tausenden von Servern implementierbar sind. Die Erfinder der vorliegenden Erfindung haben einen Bedarf erkannt, eine Routenaktualisierungen innerhalb einer gesamten Routerwolke (eine Ansammlung von Routern) bereit zu stellen, wo alles in einer netzwerk-ähnlichen Topologie verbunden ist, wobei die Anzahl der Router ausgelegt ist, um jede Anzahl von Clients und Servern zu verbinden.
US 6,249,523 , mit dem Titel "Router for which a Logical Network Address which is not Unique to the Gateway Address in Default Routing Table Entries", gibt ein Verfahren an, um ARP-Cache-Eingänge zu aktualisieren, wobei nur in einer lokalen Übertragungsverbindung effektiv "geroutet" wird, wenn es durch DHCP-Nachrichten getriggert wird.
EP 1011241 offenbart ein Schema zur Routenaktualisierung innerhalb einer Domäne mit lokaler Mobilität. EP 1011241 betrachtet die anfängliche Zuteilung der Peer-Adresse in der Domäne mit lokaler Mobilität durch DHCP. EP 1011241 offenbart ein Protokoll, das vollständig für Routen-Aktualisierungen mit IPv4 ausgestaltet ist, welches nicht auf IPv6 angewendet werden kann. Darüber hinaus, wie in anderen Szenarien, offenbart EP 1011241 nur das Triggern einer einzelnen Routen-Aktualisierungs-Nachricht von einer Basisstation bei der "Inbetriebnahme" oder von einem mobilen Knoten, wenn er in eine aufgesuchte Domäne eintritt.
Es ist nennenswert, dass das Dokument mit dem Titel "Cellular IPv6, Internet Draft Personal Proposal", draftshelby-seamoby-cellular-ipv6-00.txt. einen Mechanismus beschreibt, um IP-Mobilität innerhalb einer Domäne durch ent sprechende Aktualisierung der IP-Routen pro Host zu handhaben. Das zellulare IPv6 ist ein neues Protokoll, dessen Standardisierung für eine Anzahl von Jahren angestanden ist. Das zellulare IPv6 ist äquivalent zu anderen Routing-Protokollen, wie etwa das RIP. Einer der Gründe, dass das zellulare IP zur Standardisierung nun akzeptiert werden muss, ist der, dass es Paging-Konzepte verwendet, welche in einer 3GPP Umgebung selbstverständlich sind. Jedoch sind solche Konzepte mit IP-Protokollen in Folge der architektonischen Ineffizienzen, wie etwa der Netzüberlastung (Übertragung) von periodischen (zeitgetriggerten) Daten über eine große Anzahl von Netzen, undurchführbar. Ferner ist der Routenstatus in diesem Dokument auf einen "persönlichen Ansatz" begrenzt. Als solcher ist der Mechanismus für Standard IP-Mobilitätsszenarien unangemessen.
Zusammenfassend haben die Erfinder der vorliegenden Erfindung erkannt, dass die derzeitigen Implementierungen der IPv6 an dem Erfordernis leiden, dass sie den entfernten Basisagenten regelmäßig melden müssen, wenn ein mobiler Knoten mobil ist, beispielsweise die kontinuierliche Aktualisierung der CoA des mobilen Knotens. Ferner bringen IPv6 Probleme in den Tunnel-Anforderungen ein, wenn es für einige Konfigurationen solche komplexen und kostspieligen Bandbreite/Durchsatz-Mechanismen nicht notwendig sind. Derzeitige Versuche ein oder mehrere der obigen Probleme zu lösen, haben einen Folgeeffekt auf andere IP-Protokolle.
Beschreibung der Erfindung
Gemäß einem ersten Aspekt der vorliegenden Erfindung ist hier ein Verfahren zur Unterstützung der Mobilität in einem Internetprotokoll (IP)-basierenden Datennetz vorgesehen, wie in Anspruch 1 beansprucht ist.
Gemäß einem zweiten Aspekt der vorliegenden Erfindung ist hier ein Internetprotokoll (IP)-basierendes Netz gemäß Anspruch 9 vorgesehen.
Weitere Aspekte der vorliegenden Erfindung sind jene, wie in den abhängigen Ansprüchen beansprucht sind. Zusammenfassend beschreibt die bevorzugte Ausführungsform der vorliegenden Erfindung einen Mechanismus, um IPv6 lokale Mobilität zu handhaben, ohne dass irgendeine Tunnelung von Datennachrichten in Richtung eines entfernten Basisagenten benötigt wird. Der Mechanismus verwendet Adress-Autokonfigurations-Mechanismen, die geeignet sind, in Routen-Aufrechterhaltung verwendet zu werden. Vorteilhafterweise können Routen-Aktualisierungsnachrichten sowohl von einem DHCP-Server und einem Zugriffsknoten, wie etwa einem DHCP-Relais, gesendet werden, wenn neue IP-Routen bestimmt werden. Vorzugsweise werden alte oder nicht akzeptierbare IP-Routen innerhalb der lokalen Mobilität gelöscht. Das Verfahren ist in der Lage, Standard-IETF-Protokolle zu verwenden, wie etwa das DHCPv6 und das RIP.
Kurze Beschreibung der Zeichnungen
1 stellt ein bekanntes mobiles Computer-/Kommunikationsnetz und einen Mechanismus dar, um mit einem mobilen Knoten zu kommunizieren.
Beispielhafte Ausführungsformen der vorliegenden Erfindung werden nun unter Bezugnahme auf die beigefügten Zeichnungen beschrieben, in denen:
2 ein mobiles Computer-/Kommunikationsnetz darstellt, das geeignet ist, um die bevorzugte Ausführungsform der vorliegenden Erfindung zu implementieren;
3 einen Server mit einem dynamischen Hostkonfigurationsprotokoll (DHCP) darstellt, der geeignet ist, um die bevorzugte Ausführungsform der vorliegenden Erfindung zu implementieren;
4 ein Flussdiagramm eines Verfahrens darstellt, das durch einen Zugriffsrouter-DHCP-Relais gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung implementiert ist; und
5 ein Flussdiagramm eines Verfahrens darstellt, das durch einen DHCP-Server gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung implementiert ist.
Beschreibung der bevorzugten Ausführungsformen
Nun Bezug nehmend auf 2, ist eine Netzkonfiguration gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung dargestellt. Die Netzkonfiguration verwendet vorzugsweise das IETF Mobile IPv6 Protokoll. Als ein Beispiel ist ein Netz gezeigt, das häufig in einem Netz mit campusartiger Mobilität zu finden ist. Das Netz verwendet Verbindungstechnologien, wie etwa das Ethernet und das 802.11b.
Die bevorzugte Netztopologie, wie sie in 2 dargestellt ist, weist eine baumartige Struktur auf, wie sie Fachleuten bekannt ist. Jedoch, obwohl die bevorzugte Ausführungsform unter Bezugnahme auf eine baumartige Struktur beschrieben ist, sind die hierin beschriebenen, erfindungsgemäßen Konzepte ebenso auf jede netzwerkartige Struktur anwendbar. Konzeptionell entspricht der Ursprung des Baumes dem DHCP-Server (DS), wobei die MN-Bewegung nur durch die Blätter des Baumes gehandhabt werden. Die bevorzugte Ausführungsform zeigt die letzten Etappen, wie sie kabellose Zugriffs-Medien verwenden, um mit den mobilen Knoten zu kommunizieren, obwohl jeder Zugriffsmechanismus annehmbar ist (einschließlich das Einwählen und andere verkabelte zugriffsähnliche DSL, oder einfach das Ethernet).
Es wird auch in dem Kontext der bevorzugten Ausführungsform der vorliegenden Erfindung angenommen, dass jeder Zugriffsrouter (AR) (= access router) zusammen mit einem DHCP-Relais (DR), und die Internetschnittstelle entsprechend zusammen mit dem DHCPv6-Server angeordnet ist angeordnet. Alle dazwischen liegende Router sind normale Router.
In dieser Hinsicht wird ein mobiler Knoten 160 in einer Computer-/Kommunikations-Domäne mit Mikromobilität (lokal) betrieben. Die Computer-/Kommunikations-Domäne mit Mikromobilität (lokal) ist wie eine Baumstruktur konfiguriert mit einer Schnittstelle 220 zwischen Knoten in der lokalen Domäne und dem Internet 110. Beispielsweise nehmen wir an, dass der mobile Knoten ein tragbarer Computer ist, der geeignet ist, um mit dem Internet 110 durch kabellose Verknüpfung mit jedem der Anzahl von Zugriffspunkten/Zugriffsroutern 240–250 zu kommunizieren.
Die Domäne mit Mikromobilität umfasst Router 230, 232, 234, die die Zugriffsrouter/DCHCP-Relais 240–250 mit der Schnittstelle verbinden, die einen DHCP-Server 220 umfasst. Wenn sich der mobile Knoten 160 an dem Zugriffsrouter 240 angemeldet hat, wird ihm eine temporäre IP-Adresse zugeteilt, welche über 165 an den Basisagenten 105 des MN's gemeldet wird. Der MN 160 ist geeignet, um auf Anwendungen von dem Anwendungs-Server 115 über eine Route 170 zuzugreifen, welche das Internet 210, die/den Schnittstelle/DHCP-Server 220 und eine Anzahl von willkürlichen oder netzwerkgekoppelten Zwischen-Routern 230 (wobei irgendeine Anzahl von Zwischen-Routern auf jedem Pfad gezeigt ist) und dem Zugriffsrouter 240 umfasst.
Vor allem gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung, wenn sich der MN 160 an einem anderen Zugriffsrouter/DHCP-Relais 250 anmeldet, wird die gleiche IP-Adresse verwendet. In dieser Hinsicht, wenn ein MN seinen Anbindungspunkt zwischen zwei Zugriffsroutern (AR), etwa dem AR 240 und dem AR 250, ändert, bestätigt er seine zuvor erhaltene Adresse an dem DHCPv6-Server (DS) 220 über das DHCPv6-Relais (DR), das gemeinsam mit dem derzeitigen AR 250 angeordnet ist. Eine "CONFIRM"-Nachricht (= Bestätigungsnachricht) triggert dann eine Aktualisierung der Routen in dem DS 220 von dem Pfad in Richtung dem vorhergehenden AR 240 zu dem Pfad in Richtung des neuen AR 250 mit der Route, die jede der entsprechenden Zwischen-Routern 234 umfasst. Eine neue Route wird daher zu der Adresse in der Nachricht durch den/das Zugriffsrouter/DHCP-Relais 250 hinzugefügt. Die "CONFIRM"-Nachricht wird gleichzeitig an den DS 220 weitergeleitet.
Anstelle der Weitergabe einer mögliche neuen CoA für die neue Route an den Basisagenten 105 des MN 160, empfängt der DS 220 tatsächlich die "CONFIRM"-Nachricht von dem DR, die die gleiche CoA (die "bestätigte" Adresse) enthält, und aktualisiert seine Routing-Tabelle. Auf diese Art und Weise werden jegliche neuen Nachrichten für MN 160, die von dem Internet 110 kommen und über die/den Schnittstelle/DHCP-Server 220 gesendet werden, abgefangen und zu der neuen Ad resse umgeleitet, wobei sie hierbei nicht der alten Route folgt.
Folglich ist es vorgesehen, dass jeder Zugriffsknoten, beispielsweise ein Relais 250 mit dynamischem Host-Konfigurationsprotokoll (DHCP), eine Empfangsfunktion umfasst, die wenigstens eine Internet Protokoll (IP)-Nachricht von einem mobilen Knoten empfängt, wobei die IP-Nachricht eine mobile Knotenadresse umfasst, die zur Verwendung für die Routenbeibehaltung geeignet ist, um Daten zu und/oder von dem mobilen Knoten zu liefern. Der Zugriffsknoten umfasst auch einen Prozessor, der wirksam mit der Empfangsfunktion gekoppelt ist, um die IP-Nachricht abzufangen und diese zu analysieren, und um eine Route zu bestimmen, um Daten zu und/oder von dem mobilen Knoten zu liefern. Der Zugriffsknoten 250 triggert eine Übertragung von einer oder mehreren Routen-Aktualisierungsnachrichten über eine Anzahl von Netzelementen (wie etwa den Zwischen-Routern 230 zwischen dem Zugriffsknoten zu einem DHCP-Server in dem IP-basierenden Datennetz).
Vorzugsweise wird die alte Route gelöscht, sobald die Schnittstelle/der DHCP-Server 220 die neue Route an dem MN 160 akzeptiert hat, um die von der Innenseite der Domäne mit lokaler Mobilität kommenden Pakete richtig weiterzuleiten.
Die Netzwerkprotokolle basieren auf IPv6 und als solche verwenden sie eine statusabhängige IPv6-Adressautokonfiguration (d.h. DHCPv6) und ein Routing-Protokoll mit Abstandsvektor. Ein bevorzugtes Routing-Protokoll mit Abstandsvektor, wie etwa das getriggerte Routing-Informationsprotokoll (RIP), wird verwendet. In dieser Hin sicht wird die DHCP-CONFIRM-Nachricht verwendet, um das getriggerte RIP zu triggern.
Autokonfiguration:
Ein statusabhängiger Autokonfigurationsmechanismus ist ausgewählt, da das Vorhandensein eines DR und eines DS 220 an den Enden der Routing-Domäne mit Mikromobilität eine strenge Kontrolle der Aktualisierungen der Routing-Pfade ermöglicht. In dem statusunabhängigen Fall, kann/können die Routing-Pfadaktualisierung(en) nur durch ein Ende des Routing-Pfades getriggert werden, d.h. durch den AR 250.
Ein spezieller Nachrichtenaustausch befasst sich mit der Erneuerung (oder Freigabe davon) einer bereits zugewiesenen IPv6-Adresse eines MN, wenn sich dieser zu einer neuen Verbindung bewegt. Der Nachrichtenaustausch folgt dem folgenden Verfahren: Nach der Erkennung einer Bewegung und nach der Anmeldung an einem neuen AR 250 erzeugt der MN 160 eine CONFIRM-Nachricht, die verschiedene Kennungen ihrer konfigurierten Schnittstellen enthält, unter denen sie die Adresse verwendet, die sie verwendet hatte, als sie erstmalig die Schnittstelle mit einem Server konfiguriert hat. Die CONFIRM-Nachricht wird an den DR (der vermutlich mit dem neuen AR angeordnet wurde) gesendet und anschließend an den DS 220 weitergeleitet. Nach dem Empfang der "CONFIRM"-Nachricht erzeugt der DS 220 eine "REPLY"-Nachricht (= Antwort-Nachricht), um diese durch den entsprechenden DR an den MN 160 zu senden. Auf diesem Weg wird die DHCPv6- Abwicklung abgeschlossen und der MN 160 kann fortfahren, die ursprünglich zugewiesene Adresse innerhalb des neuen untergeordneten Netzes unter dem neuen AR 250 zu verwenden.
Trigger-Mechanismus:
Der bevorzugte Trigger-Mechanismus ist ein Satz von prozessor-implementierbaren Befehlen (d.h. Software), der die Auswertung der DHCP-Nachrichten (Bestätigung durch DS und DR und ACK für DR) mit den RIP-Nachrichten (nicht angeforderte Routen-Aktualisierungen) verknüpft. Der Empfang und die Auswertung der Standard-DHCP-Nachrichten werden verbessert, um Standard-RIP-Nachrichten auf den Markt zu bringen. Das Routing-Informations-Protokoll (RIP) ist ein Standardalgorithmus mit Abstandsvektor zum Austausch der Routing-Nachrichten und zum Berechnen der Routen innerhalb einer Administrator-Domäne.
Die bevorzugte Ausführungsform der vorliegenden Erfindung ist unabhängig von dem zugrunde liegenden Peer-Host-Routing-Protokoll, und benutzt eine geringfügige Veränderung des RIP, so dass das Protokoll:

(i) standardmäßige RIP v2 Merkmale umfasst;
(ii) standardmäßige getriggerte RIP-Erweiterungen enthält;
(iii) standardmäßige RIP-Erweiterungen umfasst, solange dies eine IPv6-Umgebung ist;
(iv) periodische Aktualisierungen durch die Übertragung gesamter Routing-Tabellen bietet, welche vollständig entfernt werden; und
(v) Aktualisierungen der Peer-Host-Routen nach dem Empfang der getriggerten Aktualisierung fortführt.

Herkömmlicherweise sind die IP-Routing-Protokolle mit keinen besonderen topologischen Voraussetzungen ausgestal tet. In solchen Fällen geht das zugrunde liegende Modell davon aus, dass die Verbindungsfähigkeit unter den Routern die Form eines Diagramms annimmt, und das Verbindungen periodisch wegfallen und wieder aufgenommen werden. Ein Routing-Protokoll ist so ausgestaltet, dass das Netz als ein Ganzes bei dieser Art der Unterbrechung fortbesteht.
In dieser Art und Weise bietet das Netz IP-Mobilität innerhalb einer Domäne mit lokaler Mobilität durch das Aufbauen und aufrecht Erhalten der IP-Routen. Wenn ein MN seinen Anbindungspunkt zwischen zwei Zugriffsroutern (AR) verändert, bestätigt er seine zuvor erhaltene Adresse an dem DHCPv6-Server (DS) über das DHCPv6-Relais (DR), das gemeinsam mit dem derzeitigen AR angeordnet ist. Die CONFIRM-Nachricht triggert die Inbetriebnahme der getriggerten Routen-Aktualisierungen, wobei folglich die Routen in dem DS, dem vorhergehenden AR, dem neuen AR und in allen Zwischen-Routern verändert werden.
Ein Fachmann würde erkennen, dass die in dem Netz von 2 gezeigte Anzahl von Elementen nur zum Zwecke des Verständnisses begrenzt ist. Darüber hinaus ist es innerhalb der Betrachtungsweise der Erfindung, dass andere Netzkonfigurationen und Zwischenverknüpfungen der Elemente verwendet werden können.
Vorteilhafterweise haben die Erfinder der vorliegenden Erfindung die weiteren Vorteile erkannt und verstanden, die durch die dynamische Ausbildung und Aufrechterhaltung der Peer-Host-Routen innerhalb einer kleinen Domäne mit Mikromobilität dargeboten werden. Im Spezielleren haben die Erfinder dargelegt, dass das Peer-Host-Routing, das herkömmlicherweise für großformatige Netze, wie etwa das Internet, das sich über Kontinente erstreckt und großformatige Rou ting-Tabellen und die sehr häufigen Aktualisierungen einer großen Anzahl von Mobilen unterstützt, implementiert worden ist, geeigneter ist, als die Verwendung von Tunneln, infolge der:

(i) Einfachheit der Routing-Protokolle und breiten Verfügbarkeit der Implementierungen;
(ii) effizienteren Verwendung der Bandbreite, die andererseits verwendet wurde, um Pakete in einem Tunnel-Mechanismus einzuschließen;
(iii) Vermeidung eines Bedarfs, vollständig neue Protokoll-Dateneinheiten (Agenten mit lokaler Mobilität) einzuführen; und
(iv) relativ geringen Anpassung der bestehenden Router und DHCPv6-Server, wie nachfolgend beschrieben wird.

Hierarchische mobile IPv6 Schemata wie sie beschrieben sind durch: Claude Castellucia, in "A Hierarchical Mobile IPv6 Proposal", von dem 4. ACTS Mobile Communications Summit, 1999 und David B. Johnson und Charles E. Perkins in Hierarchical Foreign Agents and Regional Registration, Minutes of the Mobile IP working group meeting, 35. IETF, März 1996. Die erfindungsgemäßen Konzepte der vorliegenden Erfindung bieten zwei wichtige Vorteile über bekannte, hierarchische mobile IPv6 Schemata hinaus:

(i) Bandbreiteeinsparungen durch das Eliminieren von Tunneln.
(ii) Eliminierung der lokalen Mobilitätshandhabung von Dateneinheiten (d.h. MAP), das die anhängige IETF Standardisierung für mehrere Jahre gewesen ist.
(iii) Verwendung der gleichen CoA innerhalb der gesamten Domäne mit lokaler Mobilität (HMIP verändert den CoA, aber führt nicht die Veränderung weiter zu dem ent fernten Basisagenten (HA) fort. Vorteilhafterweise vermeiden die hierin beschriebenen erfindungsgemäßen Konzepte nicht nur das Fortführen des CoA an den HA, sondern erhalten die gleiche CoA aufrecht).

Wenn sie mit all den anderen Mikromobilitäts- (oder lokale Mobilität) Handhabungs-Schemata verglichen werden, bieten die hierin beschriebenen erfindungsgemäßen Konzepte:

(i) die inhärente Konfigurationsflexibilität der statusabhängigen Autokonfiguration, wohingegen die anderen Mikromobilitäts-Handhabungs-Schemata alle annehmen, dass die IP-Adresse manuell konfiguriert wird;
(ii) die Fähigkeit, eine schnellere Weiterleitung der Routen-Aktualisierungen durch das Triggern zu implementieren, wobei in einer im Wesentlichen gleichzeitigen Art und Weise Routenaktualisierungen von zwei unterschiedlichen Punkten des Baumes, nämlich dem DS und dem DR, getriggert werden, wohingegen andere Mikromobilitäts-Handhabungs-Schemata die Routen-Aktualisierung von nur einem Punkt triggern; und
(iii) das Verfahren der vorliegenden Erfindung ist in der Lage, die Standard IETF Protokolle zu verwenden.

Nun Bezug nehmend auf 3, wird ein Server mit einem dynamischen Host-Konfigurationsprotokoll (DHCP) 310 dargestellt, der gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung ausgebildet ist. Der DHCP-Server 310 umfasst eine Signalverarbeitungsfunktion 320, die wirksam mit einer Empfangsfunktion 325 und einem Speicherelement 330 verknüpft ist. Das Speicherelement umfasst eine Router-Verarbeitungsfunktion 340 und eine Routen-Tabelle 350. Der DHCP-Server 310 kommuniziert mit anderen Vorrichtungen in dem Netz über einen Eingabe-Port 360 und einen Ausgabe-Port 370. Das DHCP-Verfahren verwendet eine DHCP-Adressentabelle, um den Zuweisungen der Adressen an mobile Geräte nachzugehen und auch um Anfragen zuzulassen und abzuweisen.
Gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung empfängt die Empfangsfunktion wenigstens eine erste Internetprotokollnachricht von einem mobilen Knoten durch einen ersten Zugriffsknoten, wie es oben beschrieben ist. Die wenigstens eine erste Internetprotokollnachricht umfasst eine Adresse, die verwendet wird, um eine Datenroute aufzubauen, um Daten zu und/oder von den mobilen Knoten über den ersten Zugriffsknoten zu liefern. Die Signalverarbeitungsfunktion 320 verarbeitet die erste Internetprotokollnachricht, um die Datenroute zu/von dem mobilen Knoten zu bestimmen, und sie speichert die Routeninformation.
Der DHCP-Server 310 wurde ausgebildet, um wenigstens eine zweite Internetprotokollnachricht von dem mobilen Knoten durch einen zweiten Zugriffsknoten zu empfangen, so dass die zweite Internetprotokollnachricht eine Adresse umfasst, die verwendet wird, um eine zweite Datenroute aufzubauen. Die Signalverarbeitungsfunktion 320 bestimmt dann, ob die zweite Datenroute die gleiche ist, wie die gespeicherte erste Datenroute. In Antwort auf die Bestimmung, triggert der DHCP-Server 310 eine Nachricht an alle seine Nachbarrouter und nachfolgend an alle Router in der Routing-Domäne, wobei die erste Datenroute gelöscht wird, wenn die zweite Route angenommen wird. Alternativ triggert der DHCP-Server 310 eine Nachricht an den zweiten Zugriffsknoten, wobei die zweite Datenroute gelöscht wird, wenn die neue Route nicht angenommen wird.
Vorzugsweise sind die ersten und zweiten Internetprotokollnachrichten IPv6-Nachrichten, wie etwa statusabhängi ge IPv6-Autokonfigurations-"CONFIRM"-Nachrichten. In einer verbesserten Ausführungsform der vorliegenden Erfindung, fängt die Signalverarbeitungsfunktion 320 statusabhängige DHCPv6-Autokonfigurations-IP-Nachrichten ab, die von dem mobilen Knoten über die ARs gesendet wurden, und verarbeitet die Nachricht, um eine neue Datenroute zu bestimmen, um Daten zu und/oder von dem mobilen Knoten zu liefern. In Antwort wird die neue Route verwendet, um die Datenroute in der Router-Tabelle in Antwort auf die verarbeitet statusabhängige DHCPv6-Autokonfigurations-IP-Nachricht zu aktualisieren. Die Signalverarbeitungsfunktion 320 sendet dann eine Routenlöschnachricht zu den Netzelementen in der Datenroute, um ihre Routenaufnahmen zu aktualisieren.
Nun Bezug nehmend auf 4, stellt ein Flussdiagramm 400 eine bevorzugte Betriebsweise des Zugriffsrouters dar. Es wird vorausgesetzt, dass der MN bereits eine Adresse für seine Schnittstelle mit einer gewöhnlichen DHCPv6-Transaktion konfiguriert hat, wie es oben unter Bezugnahme auf 2 beschrieben wurde. Darüber hinaus ist daran gedacht, dass der MN gegenwärtig innerhalb eines untergeordneten Netzes aktiv ist, während seine Routing-Adresse einen Zugriff zu/von dem MN über den alten AR anzeigt. Der mobile Knoten hat zuvor diese alte Adresse dem DS durch den DR bestätigt.
Die Betriebsweise des AR startet in Schritt 410. Der MN bewegt sich zu einem neuen AR. Der MN erzeugt eine "CONFIRM"-Nachricht und überträgt diese Nachricht an den neuen AR, wie es in Schritt 420 gezeigt ist. Nach dem Empfang der "CONFIRM"-Nachricht in Schritt 430, speichert der AR die Schnittstellenadresse, von der er die "CONFIRM"-Nachricht empfängt, in Schritt 440.
Der DR (der wirksam mit dem AR verknüpft ist) leitet die "CONFIRM"-Nachricht zu dem DS weiter, wie es in Schritt 450 gezeigt ist. Zusätzlich fügt der DR auch eine neue Route zu dieser Adresse durch die (gespeicherte) Schnittstellen-Adresse hinzu, die die "CONFIRM"-Nachricht wie in Schritt 460 empfängt. Dieser Routen-Zusatz an die "CONFIRM"-Nachricht wird stromaufwärts zu allen Zwischen-Routern in dem neuen Pfad zu dem DS zurückgeleitet vorzugsweise mittels nicht angeforderter Routen-Aktualisierungs-Nachrichten, wie es in Schritt 470 gezeigt ist. Auf diese Art und Weise hat sich der MN zu einem neuen Zugriffspunkt bewegt, und es ist eine neue Route zu dem MN durch den AR/DR in der "CONFIRM"-Nachricht erzeugt worden, die zu dem DS gesendet wurde.
Nun Bezug nehmend auf 5 stellt ein Flussdiagramm 500 eine bevorzugte Betriebsweise das DHCPv6-Servers (DS) dar in Antwort auf das Empfangen einer "CONFIRM"-Nachricht mit einer neuen Routenaktualisierung von dem AR/DR, wie es oben unter Bezugnahme auf 4 beschrieben wurde.
Die DS-Betriebsweise startet in Schritt 510. Nach dem Empfang der "CONFIRM"-Relais-Vorwärts-Nachricht von dem neuen AR in Schritt 520 entscheidet der DS im Schritt 530, ob er positiv (vorzugsweise das Triggern der Löschung der alten Route) oder negativ (vorzugsweise das Triggern der Löschung der neuen Route, bevor sie durch den DR hinzugefügt wird) antwortet.
Es ist vorgesehen, dass der DS negativ antwortet, wenn er entscheidet, dass der MN zu viel Zeit benötigt, um zwischen den ARs zu umzuschalten. Beispielsweise könnte der Laptop MN in einen Ruhezustand übergegangen oder sogar ausgeschaltet sein, in welchem Falle der DS die CONFIRM- Nachricht ablehnt, da die Adresse in der Zwischenzeit einem anderen neuen MN zugewiesen wurde. Alternativ, wenn der MN sich mit einer anderen Domäne mit lokaler Mobilität verbindet, wird er diese Adresse gegenüber einem anderen DHCP-Server bestätigen, der diese Adresse nicht besitzt.
Wenn der DS entscheidet, in Schritt 530 auf die "CONFIRM"-Nachricht negativ zu antworten, triggert der DS im Schritt 540 die Weiterleitung einer Routenlöschnachricht an alle Zwischenrouter zu dem neuen AR,. Auf diese Art und Weise werden alle Zwischenrouter, die soeben eine neue Route an die MN-Adresse aufgezeichnet haben, die sie von der "CONFIRM"-Nachricht ausgelesen haben, die von dem AR zu dem DS gesendet wurde, die neue Routen-Aufzeichnung löschen. In dieser Hinsicht sendet der DS eine Antwort auf die "CONFIRM"-Nachricht an den MN über den entsprechenden AR/DR, um den MN und implizit den unterbrechenden AR/DR von der negativen Entscheidung zu informieren „ wie es in Schritt 550 gezeigt ist.
Wenn der DS entscheidet, positiv auf die "CONFIRM"-Nachricht in Schritt 530 zu antworten, entfernt der DS die alte Route an der dem MN zugeteilten Adresse, wie sie in seiner internen Routing-Tabelle gespeichert ist, wie es in Schritt 560 gezeigt ist. Im Wesentlichen gleichzeitig fügt der DS die neue Routeneingabe zu der dem MN zugewiesenen Adresse hinzu, wobei die Route die Schnittstelle anzeigt, durch welche die "CONFIRM"-Nachricht empfangen wurde, wie in Schritt 570. Der DS triggert dann die Weiterleitung einer Routenlöschnachricht an alle Zwischen-Router zwischen sich selbst und dem alten AR/DR in Schritt 580. Auf diese Art und Weise werden alle Zwischen-Router, die eine nun überholte Route an die MN-Adresse aufgezeichnet haben, die Routenaufzeichnung löschen. In diesem Hinblick sendet der DS eine Antwort auf die "CONFIRM"-Nachricht an den MN über den entsprechenden DR. Die Antwort informiert den MN und implizit den unterbrechenden DR/AR über die negative Entscheidung, wie es in Schritt 550 gezeigt ist.
Auf diese Art und Weise ist der DHCPv6-Server in der Lage, die gleiche (CoA)-Adresse dem MN zuzuweisen, nachdem sich der MN zu einem neuen Zugriffsrouter bewegt hat. Vorteilhafterweise wird in diesem Lösungsansatz die Peer-Adresse des MN's dann als eine gültige Adresse für die gesamte Domäne mit Mikromobilität aufrecht erhalten unabhängig davon, welchen Zugriffsrouter der MN innerhalb der Domäne verwendet.
Ferner ist die Kombination des AR/DR und des DHCPv6-Servers durch das Abfangen der Nachricht zu dem Basisnetz in der Lage, eine IP-Adresse an dem MN aufrecht zu erhalten, ohne Inanspruchnahme von wertvollen Bandbreiteressourcen in der Weiterleitung der neuen Route innerhalb der Domäne mit Mikromobilität zu höheren Dateneinheiten in dem Netz.
Ein weiterer Vorteil dieses Mechanismus ist es, dass durch die Bereitstellung einer einzelnen CoA des MN's überall in der Domäne mit lokaler Mobilität (Mikromobilität) kein Bedarf besteht, Tunnelungs- und Enttunnelungsbetätigungen durchzuführen, welche auch wertvolle Ressourcen (d.h. Rechenressourcen an Knoten und Bandbreiteressourcen an Netzen) in Anspruch nehmen.
Die erfindungsgemäßen Konzepte der vorliegenden Erfindung finden spezielle Anwendbarkeit in Domänen mit Netzen mit Mobilitätsunterstützung, wie etwa in einem Universitätscampus oder in einer Firma, wo Knoten beispielsweise über mehrere Stockwerke in einem Gebäude verteilt sind. Die Topologie solcher Netze ist typischerweise eine Baumstruktur mit kaum mehr als drei Niveaus in der Struktur. Die Mobilitätsbesetzung von solchen Domänen umschließt typischerweise einige Hundert Knoten. Die Mehrheit der Kommunikation in diesen Domänen findet unter Knoten innerhalb der Domäne statt und nicht zu einem externen Internet. Darüber hinaus sind lokale Knoten in der Lage, sich innerhalb der Domäne zu bewegen. Auch besuchende Knoten können akzeptiert werden, um diese Domäne zu besuchen und sich innerhalb dieser recht vollständig zu bewegen.
Solch eine Domäne benutzt vorzugsweise ein internes Schnittstellenprotokoll (IGP) (= Interior Gateway Protocol)-Routingprotokoll, beispielsweise ein Routing-Informations-Protokoll (RIP), ebenso wie ein statusabhängiges Adress-Autokonfigurationsschema, wie etwa das (DHCP). Folglich ist es innerhalb dieser Domäne ökonomischer durchführbar, eher DHCP- und RIP-Funktionalitäten wieder zu verwenden statt mobile IP-Einheiten einzusetzen, was die Modifizierung jedes Client-PC's, jedes Servers und die Einführung von Basisagenten erforderlich machen würde.
Die Erfinder der vorliegenden Erfindung haben erkannt, dass in solch einer Domäne der DHCP-Server (DS) niemals in einer Situation ist, eine CONFIRM-Nachricht zurück zu weisen. Folglich wird ein sich bewegender PC immer die gleiche Peer-Adresse innerhalb dieser Domäne verwenden. Diese Adresse ist seine einzige Adresse und es besteht daher kein Bedarf, eine Basisadresse und eine Peer-Adresse zuzuteilen, wie es durch das mobile IPv6 benötigt wird.
Darüber hinaus haben die Erfinder der vorliegenden Erfindung erkannt, dass eine schnellere Weiterleitung der Routenaktualisierungen durch das kontinuierliche Triggern der Routen-Aktualisierungs-Nachrichten erreicht werden kann, beispielsweise basierend auf der weiteren Verwendung der DHCP-Nachricht. In dem Kontext der vorliegenden Erfindung wird dies dadurch erreicht, dass man sich auf die obligatorischen und periodischen Nachrichten einer DHCPv6-CONFIRM-Nachrichtverläßt. In alternativen Ausführungsformen kann ein solches kontinuierliches Triggern irgendein regelmäßiges, periodisches oder sogar unregelmäßiges Triggern der Routen-Aktualisierungs-Nachrichten von den zwei Endpunkten einschließen.
In diesem Fall kann eine modifizierte Betriebsweise des AR/DR in 4 ebenso wie des DS in 5 implementiert werden. Im Spezielleren ist daran gedacht, dass sowohl der DS als auch der AR den Routenzusatz zu allen Zwischen-Routern triggern kann. Vorteilhafterweise führen solch ein von zwei Punkten ausgehender Routen-Aktualisierungs-Trigger-Mechanismus effektiv zu schnelleren Aktualisierungen.
Folglich ist ein Mechanismus, um die Adress-Autokonfiguration mit der Routen-Beibehaltung zu kombinieren, um die Mobilität zu unterstützen, beschrieben worden. Dies steht im Gegensatz zu herkömmlichen Adress-Autokonfigurations-Mechanismen, welche vollständig automatisch und getrennt von der Routenaufrechterhaltung durchgeführt worden sind. Die Routenaufrechterhaltung wurde in einer halbmanuellen/halb-automatischen Art und Weise durchgeführt, insoweit als die Routeninformation anfänglich manuell in jedem Router eingeführt wurde und dann die Router miteinander kommunizieren, um die kürzesten zur Verfügung stehenden Routen aufzufinden.
Es ist anzuerkennen, dass die Anordnung und die spezifischen Details der Schnittstellen, Addressarten, Routern, etc. in den obigen Ausführungsformen weitestgehend Beispiele sind, und dass die Erfindung nicht auf diese Beispiele begrenzt ist. Die Erfindung sollte als derart ausgestaltet angesehen werden, dass sie auf andere Arten von Daten (Computer-/Kommunikations-) Netzen oder Protokollen und untergeordnete Netze davon anzuwenden ist. Darüber hinaus kann die Erfindung auch auf andere Domänen als eine Baumstruktur oder eine Domäne mit im Wesentlichen Mikromobilität angewendet werden, wenn solche Netze untergeordnete Netze und Zugriffsnetze haben, deren Funktionen den oben beschriebenen entsprechen.
Die Erfindung oder zumindest Ausführungsformen davon neigen dazu, die folgenden Vorteile einzeln oder in Kombination zu bieten:

(i) Ein Datenpaket kann weitaus effizienter übertragen werden, mit einer minimalen Anzahl von Tunnelungsvorgängen, die durch dazwischen liegende Router durchgeführt werden, wodurch eine gesteigerte Routenaktualisierung erreicht wird.
(ii) Im Vergleich zu den hierarchischen mobilen IPv6 Schemata bieten die oben beschriebenen erfindungsgemäßen Konzepte: (a) Bandbreiteeinsparungen, durch das Eliminieren der Tunnel; und (b) Eliminierung der lokalen Mobilitäts-Handhabungs-Einheiten (d.h. Mobilitäts-Anker-Punkt (MAP)), welches die gültige IETF Standardisierung für einige Jahre gewesen ist. (c) Die Verwendung der gleichen CoA vermeidet die Aktualisierung nicht nur des entfernten HAs sondern auch jeder neuen Einheit, wie etwa eines MAP.
(iii) Im Vergleich mit allen anderen Mikromobilitäts- (oder lokalen Mobilitäts-) Handhabungs-Schemata bieten die oben beschriebenen, erfindungsgemäßen Konzepte: (a) eine inhärente Konfigurationsflexibilität der statusabhängigen Autokonfiguration im Gegensatz zu anderen Mikromobilitäts-Handhabungs-Schemata, wo die IP-Adresse manuell konfiguriert wird; (b) eine weitaus schnellere Weiterleitung der Routenaktualisierungen durch das im Wesentlichen gleichzeitige Triggern von zwei separaten Punkten des Baumes, nämlich des DS und des DR; (c) eine weitaus schnellere Weiterleitung der Routenaktualisierungen, durch kontinuierliches/regelmäßiges Triggern der Routenaktualisierungs-Nachrichten basierend auf der kontinuierlichen Verwendung der DHCP-Nachricht; (d) eine weitaus schnellere Weiterleitung der Routenaktualisierungen, wenn ein Zugriffsknoten durch die Bestätigung einer Möglichkeit, die gleiche Adresse unter Verwendung der DHCP-Nachricht wieder zu verwenden, verändert wird; und (e) Kompatibilitätsvorteile da Standard – IETF-Protokolle verwendet werden können.
(iv) Im Vergleich mit dem zellularen IPv6 verwendet die vorliegende Erfindung keine Form von Paging. Folglich wird keine Datenübertragung benötigt und eine effizientere und eine weniger Bandbreite erfordernde Lösung wird erreicht. Im Gegensatz zu dem zellularen IP, schlägt die vorliegende Erfindung einen "Peer-Host Routen"-Ansatz vor, der sich in besonderer Weise auf Standard -RIP und – DHCP als bestehende, vollständig spezifizierte, als Software erhältliche Lösungen bezieht.
(v) Die Technik zieht ihre Vorteile aus der Verwendung der gleichen CoA für das Routen aller Datenpakete zu einem speziellen mobilen Knoten innerhalb einer Domäne mit Mikromobilität jedoch mit der Eliminierung einer Intra-Domänen-Tunnelung, die von dem Mechanismus zugelassen wird, der in US 5,812,819 A vorgeschlagen ist.

Während die spezifischen und bevorzugten Implementierungen der Ausführungsformen der vorliegenden Erfindung oben beschrieben sind, ist es eindeutig, dass ein Fachmann leicht Abänderungen und Veränderungen an den bevorzugten Ausführungsformen anwenden könnte, die in die erfindungsgemäßen Konzepte fallen.
Folglich sind Verfahren, um die lokale Mobilität in TCP/IP-Netzen und der zugehörigen Netzelementen zu unterstützen, beschrieben worden, wobei die Nachteile, die zu den bekannten Mechanismen, Vorrichtungen und Verfahren gehören, wesentlich verringert worden sind.

Claims

Verfahren zur Unterstützung der Mobilität (400, 500) in einem auf einem Internetprotokoll (IP) basierenden Datennetz, wobei das Verfahren die Schritte umfasst: Erzeugen einer ersten zustandsabhängigen IP-Autokonfigurationsnachricht an einem mobilen Knoten, wobei zustandsabhängige IP-Autokonfiguration so definiert ist, dass ein Serverhost und ein Relay-Host verwendet werden, um sowohl eine Adressdatenbank aufrecht zu erhalten als auch Nachrichten zu/von einem Knoten bei der Zuteilung einer Adresse über ein Netz weiterzuleiten, und wobei diese Nachricht eine Adresse enthält, die zur Verwendung zur Routenbeibehaltung zu/von dem mobilen Knoten geeignet ist; Übermitteln (420) der erzeugten Nachricht durch den mobilen Knoten zu einem ersten Zugriffsknoten, wo der Zugriffsknoten seine Adresse zu der Nachricht hinzufügt; Weiterleiten (450) der erzeugten Nachricht durch einen Zugriffsknoten zu einem Server mit einem dynamischen Hostkonfigurationsprotokoll (DHCP); und Analysieren der Nachricht in dem DHCP-Server, um eine Route zu bestimmen, um Daten zu und/oder von dem mobilen Knoten zu liefern; und Analysieren der Nachricht an dem Zugriffsknoten, um eine Route zu bestimmen, um Daten zu und/oder von dem mobilen Knoten zu liefern; wobei das Verfahren gekennzeichnet ist durch die Schritte: Triggern (470) einer oder mehrerer Routenaktualisierungsnachrichten von dem Zugriffsknoten und dem DHCP-Server zu einer Anzahl von Netzelementen (230) zwischen dem Zugriffsknoten und dem DHCP-Server in dem IP-basierenden Datennetz, wobei die eine oder mehrere Routenaktualisierungsnachricht(en) von dem Zugriffsknoten und dem DHCP-Server im Wesentlichen gleichzeitig getriggert wird/werden.
Verfahren zur Unterstützung der Mobilität (400, 500) nach Anspruch 1, wobei eine oder mehrere Routenaktualisierungsnachrichten im Wesentlichen kontinuierlich gesendet wird/werden.
Verfahren zur Unterstützung der Mobilität (400, 500) nach Anspruch 1, wobei das Verfahren ferner gekennzeichnet ist durch die Schritte: wiederholen der Schritte des Erzeugens, des Übertragens (420) und des Weiterleitens für eine zweite zustandsabhängige IP-Autokonfigurationsnachricht, wenn sich der mobile Knoten mit einem zweiten Zugriffsknoten verknüpft; Analysieren der zweiten Nachricht an dem DHCP-Server, um zu bestimmen, dass die für die Routenbeibehaltung in der zweiten Nachricht verwendete zweite Adresse nicht mit der in der ersten Nachricht analysierten ersten Adresse übereinstimmt; und Triggern einer Routenaktualisierungsnachricht, basierend auf der Bestimmung.
Verfahren zur Unterstützung der Mobilität (400, 500) nach Anspruch 3, wobei das Verfahren ferner durch die Schritte gekennzeichnet ist: Übertragen in Antwort auf die Bestimmung einer Löschnachricht (540) zu dem ersten Zugriffsknoten (240) oder dem zweiten Zugriffsknoten (250) und einer Anzahl von Netzelementen (230) zwischen dem DHCP-Server (200) und dem ersten Zugriffsknoten (240) oder dem zweiten Zugriffsknoten (250), wo die Löschnachricht die Anzahl von Netzelementen anweist, überholte Adressinformation zu löschen, die für die Routenbeibehaltung zu/von dem mobilen Knoten verwendet wurde.
Verfahren nach Anspruch 4, wobei die Löschnachricht (540) eine IPv6-Kommunikationsnachricht ist, die von einem DHCP-Server zu einem Zugriffsknoten über eine Anzahl von Routern übertragen wird.
Verfahren zur Unterstützung der Mobilität (400, 500) nach Anspruch 3, wobei die erste und/oder zweite, zustandsabhängige Internetprotokoll-Autokonfigurationsnachricht eine DHCPv6-"CONFIRM"-Nachricht ist.
Verfahren zur Unterstützung der Mobilität (400, 500) nach Anspruch 3, wobei die für die Routenbeibehaltung verwendete Adressinformation auf einem Abstandsvektor-Routingprotokoll basiert, z.B. dem Routinginformationsprotokoll (RIP).
Verfahren zur Unterstützung der Mobilität (400, 500) nach Anspruch 1, das ferner gekennzeichnet ist durch den Schritt: Aktualisieren der Routenbeibehaltungsinformation durch einen oder mehrere aus der Gruppen aus einem DHCP-Server (220), einem Zugriffsknoten, einem DHCP-Relay, einem Zugriffsrouter (250) und einem dazwischengeschalteten Router (234).
Auf einem Internetprotokoll (IP) basierendes Netz (200), das betreibbar ist, um eine erste zustandsabhängige IP-Autokonfigurationsnachricht an einem mobilen Knoten (160) zu erzeugen, wobei die zustandsabhängige IP-Autokonfiguration so definiert ist, dass ein Serverhost und ein Relay-Host verwendet werden, um sowohl eine Adressdatenbank aufrecht zu erhalten als auch Nachrichten zu/von einem Knoten in der Zuordnung einer Adresse über ein Netz weiterzuleiten, und wobei die Nachricht eine Adresse enthält, die zur Verwendung für die Routenbeibehaltung zu/von dem mobilen Knoten geeignet ist, wobei das Netz Hosts umfasst, die einen Zugriffsknoten (240), ein Relay (250) mit einem dynamischen Hostkonfigurationsprotokoll (DHCP), und einen Server (220) mit einem dynamischen Hostkonfigurationsprotokoll DHCP enthalten, wobei der Zugriffsknoten und der DHCP-Server umfassen: eine Empfangsfunktion (325), um wenigstens eine erste Internetprotokoll (IP)-Nachricht von dem mobilen Knoten (160) zu empfangen, wobei die wenigstens eine erste IP-Nachricht eine mobile Knotenadresse umfasst, die zur Verwendung zur Routenbeibehaltung geeignet ist, um Daten zu und/oder von dem mobilen Knoten zu liefern; und einen Prozessor (320), der mit der Empfangsfunktion (325) betätigbar verknüpft ist, wobei der Prozessor die wenigstens eine erste IP-Nachricht analysiert, um eine Route zu bestimmen, um Daten zu und/oder von dem mobilen Knoten zu liefern, dadurch gekennzeichnet, dass der entsprechende Prozessor eine Übertragung von einer oder mehreren Routenaktualisierungsnachricht(en) von dem Zugriffsknoten (240) und von dem DHCP-Server entsprechend zu einer Anzahl von Netzelementen (230) zwischen dem Zugriffsknoten (240) und dem DHCP-Server (220) in dem IP-basierenden Datennetz triggert, wobei die eine oder mehrere Routenaktualisierungsnachricht(en) von dem Zugriffsknoten und dem DHCP-Server im Wesentlichen gleichzeitig getriggert wird/werden.
Netz nach Anspruch 9, wobei der Prozessor die Übertragung in einer im Wesentlichen kontinuierlichen Art und Weise triggert.
Netz nach Anspruch 10, wobei wenigstens einer der Hosts (240, 250, 220) wenigstens eine zweite IP-Nachricht empfängt und analysiert, die einen zweiten Satz von Adressen umfasst, die zur Verwendung zur Routenbeibehaltung von dem mobilen Knoten durch einen zweiten Zugriffsknoten geeignet ist, so dass der Prozessor wenigstens eine zweite IP-Nachricht analysiert, um zu bestimmen, ob der zweite Adressensatz mit dem ersten Adressensatz übereinstimmt.
Netz nach Anspruch 11, ferner dadurch gekennzeichnet, dass der Prozessor (320) in Antwort auf die Bestimmung eine Routenaktualisierungsnachricht zu dem ersten Zugriffsknoten triggert oder eine Routenaktualisierungsnachricht zu dem zweiten Zugriffsknoten triggert, um für die Routenbeihaltung zu/von dem mobilen Knoten verwendete, überholte Adressinformation zu löschen.
Netz nach Anspruch 11, wobei die wenigstens eine erste IP-Nachricht und die wenigstens eine zweite IP-Nachricht IPv6-Nachrichten sind.
Netz nach Anspruch 11, wobei die wenigstens eine erste IP-Nachricht und/oder die wenigstens eine zweite IP-Nachricht eine zustandsabhängige IPv6-Autokonfigurations"CONFIRM"-Nachricht ist.
Netz nach Anspruch 11, wobei der Host ferner gekennzeichnet ist, durch: ein Speicherelement (330), das mit dem Prozessor (320) wirksam verknüpft ist, das eine Routertabelle (350) zum Speichern von Routenbeibehaltungsinformation enthält, die von der ersten und/oder zweiten IP-Nachricht abgeleitet ist.