DE69927238T2

DE69927238T2 - Mobil-IP mit Unterstützung für Dienstqualität

Info

Publication number: DE69927238T2
Application number: DE69927238T
Authority: DE
Inventors: Xiaobao Swindon Chen; Ioannis Chippenham Kriaras; Andrea Swindon Paparella
Original assignee: Lucent Technologies Inc
Current assignee: Nokia of America Corp
Priority date: 1999-02-26
Filing date: 1999-02-26
Publication date: 2006-07-13
Anticipated expiration: 2019-02-27
Also published as: EP1032179B1; US7610393B1; BR0000552A; JP3545987B2; JP2000253069A; AU744519B2; CN1264979A; EP1032179A1; CA2296954A1; DE69927238D1; KR20000076717A; AU1755000A; KR100380554B1

Description

Technisches Gebiet
Die vorliegende Erfindung betrifft Nachrichten, die dem Mobil-Internet-Protokoll (Mobil-IP) entsprechen und von einem Hostknoten in einem Netzwerk zu einem Mobilknoten gesendet werden, und insbesondere zur Aufrechterhaltung einer gewünschten Dienstqualität, wenn irgendein Mobil-Hostknoten seinen Punkt des Netzwerkanschlusses ändert.
Allgemeiner Stand der Technik
Durch die derzeitige Technologie des Internet-Protokolls (IP) und des Mobil-IP kann ein Hostendgerät oder Hostknoten, der normalerweise in einem bestimmten Netzwerk (dem „Heimat"-Netzwerk des Knotens) verbunden ist, vorübergehend mit einem anderen Netzwerk (einem „Fremd"-Netzwerk) verbinden und weiter IP-Pakete oder Nachrichten empfangen, die an seine Adresse in dem Heimatnetzwerk zu dem Hostendgerät gesendet werden. Ein solches Hostendgerät, das seinen Punkt des Netzwerkanschlusses ändert, ist als ein Mobilknoten bekannt. Um weiter IP-Pakete in dem Fremdnetzwerk zu empfangen, muß sich der Mobilknoten bei einem sogenannten „Heimatagenten" in seinem Heimatnetzwerk registrieren. Durch Registrieren bei seinem Heimatagenten gibt der Mobilknoten dem Heimatagenten eine „Gastadresse", an der er in dem Fremdnetzwerk adressiert werden kann. Der Heimatagent überwacht dann Verkehr in dem Heimatnetzwerk, und wenn der Heimatagent ein IP-Paket identifiziert, das eine Zieladresse trägt, die der Heimatadresse des Mobilknotens in dem Heimatnetzwerk entspricht, fängt er das IP-Paket ab. Das IP-Paket wird dann von dem Heimatagenten „umverpackt" und an der Gastadresse in dem Fremdnetzwerk zu dem Knoten gesendet. Die Gastadresse kann eine zusammen angeordnete Gastadresse oder eine Fremdagent-Gastadresse sein.
Die Technik zum Leiten eines IP-Pakets, das für eine Adresse in dem Heimatnetzwerk bestimmt ist, zu einer Gastadresse in dem Fremdnetzwerk ist beim Mobil-IP als „Tunneln" bekannt. Beim Tunneln des IP-Pakets zu der Gastadresse ist es wichtig, daß bestimmte Informationen bezüglich des ursprünglichen IP-Pakets in dem umverpackten IP-Paket behalten werden. Neben dem Halten des ursprünglichen Nutzsignals (oder Informationsteils) des IP-Pakets muß zum Beispiel der Mobilknoten an der Gastadresse weiter in der Lage sein, in dem „umverpackten" IP-Paket die Quellenadresse zu identifizieren, von der aus das IP-Paket ursprünglich gesendet wurde, sowie die Heimatadresse des Mobilknotens in dem Heimatnetzwerk.
Eine im Mobil-IP bekannte Technik zum Tunneln eines IP-Pakets zu einer Gastadresse eines Mobilknotens verkapselt das ursprüngliche IP-Paket in einem neuen IP-Paket als das IP-Paketnutzsignal. Das heißt, das ursprüngliche IP-Paket wird als das Nutzsignal (bzw. der Informationsteil) des neuen IP-Pakets ohne Änderung seines Inhalts integriert. Die Gastadresse wird als die neue Zieladresse zu dem neuen IP-Paket hinzugefügt und die Quellenadresse des neuen IP-Pakets wird als der Heimatagent identifiziert. Beim Empfang entfernt der Mobilknoten an der Gastadresse die „Verpackung" des neuen IP-Pakets, um das ursprüngliche IP-Paket wieder herzustellen.
Ein Nachteil bei dieser Technik besteht darin, daß das umverpackte IP-Paket keine Unterstützung von Dienstqualitätvorkehrungen entsprechend existierenden IP-Dienstqualitätsstandards ermöglicht.
Mit jedem IP-Paket sind Flußidentifikationsinformationen assoziiert und in dem IP-Paket enthalten, die die mit der IP-Paketübertragung assoziierte Dienstqualität identifizieren. Diese Flußidentifikationsinformationen sind an festen Positionen des IP-Pakets präsent, an denen zu Dienstqualität (QoS) fähige Routing-/Vermittlungselemente diese finden und abhängig von ihnen wirken können. Bei der Verkapselungstunnelungstechnik sind jedoch die Flußidentifikationsinformationen, die von der Quelle, aus der das IP-Paket stammt, in das IP-Paket aufgenommen werden, nicht zwischen dem Heimatagent und der Gastadresse verfügbar.
Die Verkapselungstechnik beim herkömmlichen Mobil-IP (wovon eine als IP-in-IP-Verkapselung bekannt ist) schirmt also die reale Quellenadresse (d.h. die Adresse des Korrespondentenknotens) und die reale Zieladresse (d.h. die Heimatadresse des Mobilknotens) sowie die Protokoll-ID in den IP-Paketen vor dem Heimatagenten des Mobilknotens ab. Außerdem verändert das Verkapselungs-Mobil-IP auch die Nutzsignalinfrastruktur (der ursprüngliche IP-Kopfteil wird zu einem Teil des Nutzsignals) und läßt die Flußdifferenzierung versagen, wenn nicht entsprechend Router verändert werden, um so in der Lage zu sein, die Modifikationen oder Änderungen zu erkennen. Änderungen oder sogar geringfügige Modifikationen von Routern erfordern häufig sehr viel Umentwurf und Austausch aller existierender Router. Dadurch werden Steuerung und Verwaltung der Netzwerke wesentlich mehr verkompliziert. Außerdem können Probleme im Hinblick auf Sicherheitssteuerung und Interoperabilität entstehen.
Die für die Verwendung im Internet vorgeschlagenen Vorkehrungen bezüglich Dienstqualität (QoS) werden durch Standards definiert, und bei IP wird ein bekannter Standard für Dienstqualitätszeichengabe als RSVP bezeichnet. Das RSVP (Betriebsmittelreservierungsprotokoll) wird in dem von IETF definierten Dienstqualitätsrahmen des integrierten Dienstemodells (IntServe) verwendet. Das integrierte Dienstemodell wurde so entwickelt, daß eine spezielle Behandlung bestimmter Arten von Verkehr, Mechanismen, durch die Anwendungen zwischen mehreren Ebenen von Abliefer diensten für ihren Verkehr wählen können, und Zeichengabe für Dienstqualitätsparameter auf der Schicht 3 in dem OSI-RM (Zeichengabe auf Schicht 2 in ATM) bereitgestellt werden.
IntServe definiert zwei Dienstklassen. Die Controlled Load Class (gesteuerte Lastklasse) ermöglicht Verkehrsablieferung auf dieselbe Weise wie bei unbelastetem Netzwerk („besser als beste Ablieferung"). Die Guaranteed QoS Service Class (garantierte QoS-Dienstklasse) liefert Verkehr für Anwendungen mit einer Bandbreitengarantie und Verzögerungsschranke ab.
IntServe erfordert QoS-fähige Knoten und ein Zeichengabeprotokoll zur Übermittlung von QoS-Anforderungen zwischen Anwendungen und Knoten und zwischen Knoten.
RSVP ist das von IntServe verwendete QoS-Zeichengabeprotokoll. RSVP stellt Empfänger-QoS-Anforderungen für alle Routerknoten entlang dem Transitweg des Verkehrs bereit, bewahrt den Soft-Zustand (Weg-/Reservierungszustände) und führt zu einer Reservierung von Betriebsmitteln in jedem Router.
Damit RSVP/IntServe-Dienstqualität funktioniert, müssen sich die Flußidentifikationsinformationen an einer festen Position in den IP-Paketen befinden. Eine RSVP-Sitzung wird durch Hostendgeräte konfiguriert, die vor der Datenübertragung sogenannte Weg- und Reservierungsnachrichten austauschen.
Um die Dienstqualitätssteuerung über den Transitweg zwischen Peer-Hostendgeräten zu ermöglichen, muß jedes Hostendgerät deshalb die Funktionalität zum Konfigurieren der notwendigen Nachrichten und zum Erkennen von einer RSVP-Sitzung entsprechenden Dienstqualitätsanforderungen besitzen.
Das existierende RSVP spezifiziert nicht, wie Nachrichten für Weg und Reservierung für Weg und Reservierung (Resv) im Szenario der Mobilitätssteuerung auf der Basis des Mobil-IP spezifisch zu verarbeiten sind. Außerdem sperrt das „Tunneln" des Standard-Mobil-IP (z.B. IP-in-IP-Verkapselung) die korrekte Flußidentifikation und Dienstklassendifferenzierung.
Eine Aufgabe der vorliegenden Erfindung ist deshalb die Bereitstellung einer Technik, die es ermöglicht, die durch die Quelle der Nachricht bestimmte Dienstqualitätsanforderung über das gesamte Routing der Nachricht zu einer Gastadresse eines Mobilknotens hinweg zu unterstützen.
Der allgemeine Stand der Technik umfaßt eine Arbeit von Rajagopalan B mit dem Titel „Mobility and quality of service (QoS) in the Internet", Mobile Multimedia Communications, Proceedings of 3^rd International Workshop on Mobile Multimedia Communications, Princeton, NJ, USA, 25.–27.9.1996, Seiten 129–135, XP002114826 1997, New York, NY, USA, Plenum, USA ISBN: 0-306-45772-5. Diese Arbeit betrifft Verkapselung und Tunnelung. Der allgemeine Stand der Technik umfaßt außerdem die internationale Veröffentlichung (P.C.T.) WO 98/40990. Diese beschreibt einen Router mit einem Prozessor, der in abgehenden Daten von einem Endgerät die permanente Adresse des Endgeräts mit der Routeradresse als Quellenadresse ersetzt.
Aus der Arbeit von Rajagopalan ist bekannt, ein Verfahren zur Herstellung einer Dienstqualitätssitzung zwischen einem Korrespondentenknoten und einem Mobilknoten bereitzustellen, wobei der Mobilknoten eine Heimatadresse in einem Heimatnetzwerk aufweist und vorübergehend an einer Gastadresse in einem Fremdnetzwerk verbunden ist, mit den folgenden Schritten: Erzeugen, in dem Fremdnetzwerk, einer modifizierten Antwortnachricht mit einer Zieladresse des Korrespon dentenknotens und einer Quallenadresse; und Senden der modifizierten Antwortnachricht.
Kurze Darstellung der Erfindung
Gegenüber dieser Offenlegung der Arbeit von Rajagopalan ist die vorliegende Erfindung dadurch gekennzeichnet, daß die modifizierte Antwortnachricht anstelle der Heimatadresse des Mobilknotens eine Quellenadresse der Gastadresse des Mobilknotens aufweist.
Die vorliegende Erfindung ist allgemein auf eine beliebige Dienstqualitätssitzung anwendbar, die Frage- und Antwortnachrichten zwischen zwei Endgeräten zur Konfiguration einer Dienstqualitätssitzung verwendet.
Das Verfahren kann ferner die folgenden Schritte umfassen: Empfangen, in dem Heimatnetzwerk, einer Anforderungsnachricht mit einer Quallenadresse des Korrespondentenknotens und einer Zieladresse der Heimatadresse des Mobilknotens; Erzeugen einer modifizierten Anforderungsnachricht durch Ersetzen der Zieladresse der Anforderungsnachricht mit der Gastadresse des Mobilknotens; und Senden der modifizierten Anforderungsnachricht zu dem Fremdnetzwerk, wodurch die Antwortnachricht als Reaktion auf die modifizierte Anforderungsnachricht erzeugt wird.
Das Verfahren kann ferner die folgenden Schritte umfassen: Empfangen, in dem Heimatnetzwerk, der modifizierten Antwortnachricht; Erzeugen einer weiteren modifizierten Antwortnachricht durch Ersetzen der Quellenadresse mit der Heimatadresse des Mobilknotens; und Senden der weiter modifizierten Antwortnachricht.
Der Schritt des Erzeugens der modifizierten Antwortnachricht kann in dem Mobilknoten ausgeführt werden. Der Schritt des Erzeugens der modifizierten Antwortnachricht kann folgendes umfassen: Erzeugen einer Antwortnachricht mit einer Quellenadresse der Heimatadresse des Mobilknotens und einer Zieladresse des Korrespondentenknotens; und Ersetzen der Quellenadresse mit der Gastadresse des Mobilknotens, wodurch die modifizierte Antwortnachricht erzeugt wird.
Der Schritt des Erzeugens der modifizierten Antwortnachricht kann durch Proxymittel in dem mit dem Mobilknoten assoziierten Fremdnetzwerk ausgeführt werden.
Das Verfahren kann ferner die folgenden Schritte umfassen: als Reaktion auf den Empfang der modifizierten Anforderungsnachricht in den Proxymitteln, Senden eines Dienstqualitätsanzeigesignals zu dem Mobilknoten, wodurch die modifizierte Antwortnachricht als Reaktion auf den Empfang einer Dienstqualitätsbestätigung von dem Mobilknoten erzeugt wird.
Der Korrespondentenknoten kann die Anforderungsnachricht erzeugen und empfängt die weiter modifizierte Antwortnachricht.
Der Korrespondentenknoten kann mit einem Korrespondentenproxymittel assoziiert sein, wodurch das Korrespondentenproxymittel die Anforderungsnachricht als Reaktion auf eine Dienstqualitätsanforderung von dem Korrespondentenknoten erzeugt, und das Korrespondentenproxymittel erzeugt als Reaktion auf den Empfang der weiter modifizierten Antwortnachricht eine Dienstqualitätsbestätigung.
Die Erfindung liefert außerdem eine Mobil-IP-Umgebung mit der Fähigkeit zur Unterstützung einer Dienstqualitätssitzung, mit einem Korrespondetenknoten und einem Mobilknoten, wobei der Mobilknoten eine Heimatadresse in einem Heimatnetzwerk aufweist und vorübergehend an einer Gastadresse in einem Fremdnetzwerk verbunden ist, wobei das Fremdnetzwerk mit dem Mobilknoten assoziierte Mittel zum Erzeugen einer modifizierten Antwortnachricht mit einer Quellenadresse der Gastadresse des Mobilknotens und einer Zieladresse des Korrespondetenknotens aufweist.
Die Mittel können in dem Mobilknoten oder von dem Mobilknoten getrennt bereitgestellt werden.
Kurze Beschreibung der Figuren
1 zeigt einen Netzwerkaufbau mit einem Heimatnetzwerk, einem Korrespondentennetzwerk und einem Fremdnetzwerk;
2(a) bis 2(b) zeigen das Standardformat eines IP-Pakets;
3 zeigt schematisch einen Speicher eines Heimatagenten des Heimatnetzwerks;
4(a) zeigt ein durch das Korrespondentennetzwerk konstruiertes IP-Paket zur Übertragung zu einem Mobilknoten in dem Heimatnetzwerk und 4(b) zeigt die Modifikation dieses IP-Pakets, um es gemäß dem Stand der Technik zu dem Fremdnetzwerk umzuleiten;
5(a) zeigt ein durch das Korrespondentennetzwerk konstruiertes IP-Paket zur Übertragung zu einem Mobilknoten in dem Heimatnetzwerk und 5(b) zeigt die Modifikation diese IP-Pakets, um es gemäß einer alternativen Technik zu dem Fremdnetzwerk umzulenken;
6(a) zeigt die IP-Pakete einer Wegnachricht eines ersten Teils einer Dienstqualitätssitzung im Standard-Mobil-IP;
6(b) zeigt die IP-Pakete einer Wegnachricht eines zweiten Teils einer Dienstqualitätssitzung im Standard-Mobil-IP;
6(c) zeigt die allgemeine Ende-zu-Ende-Struktur einer Reservierungsnachricht im allgemeinen IP;
6(d) zeigt die allgemeine Ende-zu-Ende-Struktur einer Reservierungsnachricht eines zweiten Teils einer Dienstqualitätssitzung beim Mobil-IP mit Unterstützung von RSVP;
6(e) zeigt die allgemeine Ende-zu-Ende-Struktur einer Reservierungsnachricht eines ersten Teils einer Dienstqualitätssitzung beim Mobil-IP mit Unterstützung von RSVP;
7 zeigt die Netzwerkanordnung von 1, zur Unterstützung von RSVP im Mobil-IP ausgelegt; und
8 zeigt die Schritte der Durchführung einer bevorzugten Implementierung einer RSVP-Operation im Mobil-IP.
Beschreibung der bevorzugten Ausführungsform
Mit Bezug auf 1 ist ein typischer Netzwerkaufbau gezeigt. Ein Mobilknoten MN 8, zu dem eine Nachricht gesendet werden soll, befindet sich normalerweise in einem Heimatnetzwerk 2. Der Mobilknoten MN 8 ist normalerweise in dem Heimatnetzwerk 2 an einer bestimmten Adresse verankert. Diese Adresse ist nicht unbedingt eine statische IP-Adresse: der Mobilknoten kann sich an einem beliebigen physischen Punkt in dem Netzwerk befinden, aber eine bestimmte IP-Adresse ist (anstatt mit dem physischen Verbindungspunkt) mit dem Mobilknoten selbst assoziiert. Das Heimatnetzwerk kann physisch eine kleine Büroumgebung oder auch eine Anzahl von Ländern überspannen.
Der Mobilknoten MN 8 kann durch ein drahtloses LAN, eine Infrarotstrecke, eine drahtlose Telefonstrecke oder über direktes Ethernet oder Token-Ring-Netzwerk-Hook-up mit dem Heimatnetzwerk 2 verbunden sein. Der Ausdruck „Mobilknoten" impliziert nicht, daß der Knoten über eine drahtlose Strecke mit dem Netzwerk verbunden ist: statt dessen impliziert er, daß sich der Mobilknoten aus dem Heimatnetzwerk heraus in ein Fremdnetzwerk bewegen kann, wie zum Beispiel das Fremdnetzwerk 6 von 1, wie später ausführlicher besprochen werden wird.
Die Anordnung von 1 zeigt außerdem ein Korrespondentennetzwerk 4 mit einem Korrespondentenknoten CN 10. Zur Veranschaulichung der vorliegenden Erfindung wird angenommen, daß der Korrespondentenknoten CN 10 des Korrespondentennetzwerks eine Nachricht zu dem Mobilknoten 8 des Heimatnetzwerks 2 sendet. Der Korrespondentenknoten kann sich auch in einem Fremdnetzwerk befinden, das heißt, einem von dem Heimatnetzwerk 2 unabhängigen und verschiedenen Netzwerk. Der Ausdruck Fremdnetzwerk ist jedoch dafür reserviert, ein Netzwerk zu bedeuten, das Host für einen Mobilknoten ist, der normalerweise in einem anderen Netzwerk (seinem Heimatnetzwerk) verankert ist. Für die Zwecke dieses veranschaulichenden Beispiels hat sich der Mobilknoten 8 des Heimatnetzwerks 2 zu dem Fremdnetzwerk 6 bewegt. Somit ist der Mobilknoten MN 8 in dem Heimatnetzwerk 2 gestrichelt gezeigt, um anzuzeigen, daß er normalerweise dort präsent ist, und ist in dem Fremdnetzwerk FN 6 durchgezogen gezeigt, um anzuzeigen, daß er vorübergehend in dem Fremdnetzwerk 6 präsent ist.
Die Ausdrücke Korrespondentenknoten und Korrespondentennetzwerk sind dafür reserviert, Kommunikations-Peers des Mobilknotens 8 zu beschreiben. Ein Korrespondentenknoten ist ein Knoten (der ein weiterer Mobilknoten sein kann), mit dem ein Mobilknoten gerade kommuniziert: d.h. entweder ein IP-Paket empfängt oder ein IP-Paket sendet. Mit einem Korrespondentennetzwerk ist das Netzwerk gemeint, mit dem der Korrespondentenknoten verbunden ist. Es versteht sich, daß der Mobilknoten mit einem Korrespondentenknoten in seinem eigenen Heimatnetzwerk kommunizieren kann und deshalb das Korrespondentennetzwerk das Heimatnetzwerk selbst sein kann.
Wie aus 1 zu sehen ist und später ausführlicher besprochen wird, enthält das Heimatnetzwerk 2 ferner einen Heimatagenten 12.
Es wird nun ein kurzes Beispiel für die „normale" Kommunikation zwischen den Korrespondentenknoten CM 10 und dem Mobilknoten MN 8 gegeben. Mit Bezug auf 2(a) ist eine allgemeine Struktur eines IP-Pakets 14 gezeigt, das von dem Korrespondentenknoten CN 10 zu dem Mobilknoten MN 8 gesendet wird.
Ein zwischen Netzwerken gesendetes IP-Paket, das allgemein mit der Bezugszahl 14 bezeichnet wird und in 2(a) dargestellt ist, umfaßt einen IP-Kopfteil 30 und ein IP-Nutzsignal 22. Das IP-Nutzsignal 22 ist der Informationsteil des IP-Pakets, der an dem Mobilknoten 8 abgeliefert werden soll. Die für die vorliegende Besprechung relevanten Teile des IP-Pakets sind in 2(b) und 2(c) dargestellt. Der in 2(b) gezeigte IP-Kopfteil 30 enthält einen Quellenadressenteil 16, einen Zieladressenteil 18 und einen Protokoll-ID-Teil 20. Der IP-Kopfteil 30 enthält weitere Felder, die in 2(b) nicht gezeigt sind, da sie für die vorliegende Erläuterung nicht relevant sind.
Mit Bezug auf 2(c) enthält das IP-Nutzsignal 32 eine Quellenportnummer 34 und eine Zielportnummer 36. Wieder enthält das IP-Nutzsignal weitere Felder, die für die Zwecke der vorliegenden Erläuterung nicht relevant sind.
Die Quellenadresse 16 ist die IP-Adresse des Hostendgeräts (des Korrespondentenknotens), von dem aus das IP-Paket gesendet wird, und die Zieladresse 18 ist die IP-Heimatadresse des Hostendgeräts (Mobilknotens), an den das IP-Paket gesendet werden soll. Die Quellenportnummer 34 ist die Portnummer, die von einer Anwendung an dem mit dem IP-Paket 14 assoziierten Korrespondentenknoten 10 verwendet wird. Die Ziel portnummer ist die Portnummer, die von einer Anwendung an dem Mobilknoten 8, zu dem das IP-Paket gesendet wird, verwendet wird. Zusätzlich zu anderen Verwendungszwecken ist die Protokoll-ID 20 eine der Anzeigen der Dienstqualität, die bei der Zeichengabe des IP-Pakets von den Quellenanwendungen zu den Zielanwendungen unterstützt werden sollen. Wie für Fachleute ersichtlich ist, werden die Ziel- und Quellenadressen von Routing-Vermittlungen zwischen dem Korrespondentenknoten und dem Mobilknoten in dem Heimatnetzwerk zum Routing des IP-Pakets zusammen verwendet.
Wenn die Router oder Routing-Vermittlungen Dienstqualität (QoS) unterstützen, wird bei bestimmten QoS-Steuervorkehrungen, wie zum Beispiel RSVP und Intserv die Protokoll-ID 20 zusammen mit den Quellen- und Zieladressen 16 und 18 plus den Kommunikationsportnummern von Endanwendungen (d.h. der Quellenportnummer 34 und der Zielportnummer 36) zur Differenzierung von Flüssen und zum Auferlegen der notwendigen QoS-Steuerung verwendet.
Die den Datenverkehrsflüssen in den Zwischenroutern auferlegte QoS-Steuerung ist systemabhängig. Zum Beispiel kann es sich um das sogenannte WFQ (gewichtete faire Warteschlangen) oder CBQ (klassenbasierende Warteschlangen) handeln. Sie sind nicht standard- und vertreiberspezifisch, sondern gewöhnlich von der Protokoll-ID des tatsächlichen Benutzers unabhängig.
Der IntSer/RSVP-Standard von IETF wird definiert, um eine QoS-Spezifikation und einen Zeichengabemechanismus, nicht aber einen QoS-Steuermechanismus bereitzustellen. Intserve/RSVP ist von den tatsächlichen QoS-Steuermechanismen, wie zum Beispiel WFQ, CBQ usw., unabhängig.
Der Status, basierend darauf, welche QoS-Steuerung durchgeführt wird, wird in den Routing-Vermittlungen vor der Datenübertragung mittels des spezifischen Dienstqualitäts-Zeichengabeprotokolls, wie zum Beispiel RSVP, eingerichtet.
Ein bekanntes Verfahren zum Routing eines IP-Pakets von dem Korrespondentenknoten zu dem Mobilknoten MN 8, wenn er sich zu einer Position in dem Fremdnetzwerk bewegt hat, wird nun beschrieben. Wenn sich der Mobilknoten MN 8 zu einem Fremdnetzwerk bewegt, muß er sich bei dem Heimatagenten HA 12 des Heimatnetzwerks registrieren, um so immer noch in der Lage zu sein, seine Nachrichten zu empfangen, wenn er in dem Fremdnetzwerk verankert ist. Dies läßt sich dadurch erzielen, daß der Mobilknoten eine Registrationsnachricht zu dem Heimatagenten HA 12 sendet, nachdem er seine Position in dem Fremdnetzwerk eingenommen hat. Ein Mobilknoten kann als seine Position in dem Fremdnetzwerk eingenommen betrachtet werden, nachdem er mit dem Fremdnetzwerk verbunden wurde und eine Gastadresse zugeteilt bekommen hat.
Mit Bezug auf 3 enthält der Heimatagent HA 12 einen Speicher oder eine Nachschlagetabelle mit der allgemeinen Bezugszahl 24. In einer Spalte des Speichers speichert der Heimatagent HA 12 die Adressen der normalerweise in dem Heimatnetzwerk verankerten Mobilknoten, die sich als vorübergehend in einem Fremdnetzwerk verankert bei dem Heimatagenten registriert haben. In einer weiteren Spalte 28 des Speichers 24 speichert der Heimatagent die Gastadresse, zu der sich der Mobilknoten in dem Fremdnetzwerk bewegt hat, sowie weitere assoziierte Zustände wie etwa SPI (Sicherheitsparameterindex).
Die Technik, durch die der Heimatagent die aktuelle Gastadresse des Mobilknotens und seine Heimatadresse (d.h. die Mobilknotenadresse in dem Heimatnetzwerk) verzeichnet, ist gewöhnlich implementierungsabhängig. Die vorliegende Erfindung schließt nicht verschiedene Ansätze zur Erzielung der Positionsbewußtheit eines Mobilknotens in dem Heimatagenten aus.
Es wird nun die Funktionsweise des Heimatagenten bei dem Leiten eines IP-Pakets von dem Korrespondentenknoten zu dem Mobilknoten in dem Fremdnetzwerk gemäß einer zur Zeit bekannten Technik beschrieben.
Der Korrespondentenknoten CN 10 konstruiert ein IP-Paket mit einem mit dem in 2(a) gezeigten identischen Format. Das so konstruierte IP-Paket von dem Korrespondentenknoten ist durch das IP-Paket 50 in 4(a) dargestellt und enthält eine Quellenadresse 60, die die Korrespondentenknotenadresse identifiziert, eine Zieladresse 62, die die Heimatadresse des Mobilknotens in dem Heimatnetzwerk identifiziert, und eine Protokoll-ID 66, die nominal als Protokoll „A" bezeichnet wird. Die Quellenportnummer und Zielportnummer sind in 4 und 5 nicht gezeigt, da sie für die Erläuterung nicht relevant sind.
In dem in 1 gezeigten Beispiel wird nach der Bewegung zu dem Fremdnetzwerk 6 dem Mobilknoten 8 eine eindeutige eigene Gastadresse zugeteilt und er registriert sich direkt bei dem Heimatagenten 12 in dem Heimatnetzwerk. Dies ist als der Arbeitsmodus CO-COA (zusammen angeordnete Gastadresse) bekannt. Ein alternativer Arbeitsmodus ist als FA-COA (Fremdagent-Gastadresse) bekannt. Wie sich der Mobilknoten bei dem Heimatagenten registrieren kann, ist im Mobil-IP wohlbekannt und für die vorliegende Erfindung nicht relevant und wird deshalb hier nicht besprochen.
Das von dem Korrespondentenknoten 10 konstruierte IP-Paket ist identisch, gleichgültig, ob der Mobilknoten in seinem Heimatnetzwerk 2 oder in dem Fremdnetzwerk 6 positioniert ist, da der Korrespondentenknoten keine Kenntnis über die Bewegung des Mobilknotens haben muß. Mobil-IP mit Routenoptimierung erfordert jedoch, daß sich der Korrespondentenknoten über die aktuelle Position des Mobilknotens bewußt ist.
Nachdem sich ein Mobilknoten unter Verwendung seiner aktuellen Gastadresse bei dem Heimatagenten registriert, betrachtet der Heimatagent einen Mobilknoten als in einem Fremdnetzwerk befindlich und beginnt mit dem Abfangen der IP-Pakete 50, die für diese Mobilknoten-Heimatadresse bestimmt sind, und mit dem Tunneln dieser IP-Pakete zu der aktuellen Gastadresse des Mobilknotens.
Der Heimatagent überwacht alle in das Heimatnetzwerk kommenden IP-Pakete, um zu sehen, ob die Zieladresse in dem Heimatnetzwerk (Teil 62 der IP-Kopfteilfelder 52) mit einer der in der Spalte 26 des Heimatagentenspeichers 24 gespeicherten Mobilkonten-Heimatadressen übereinstimmt.
Wenn eine Übereinstimmung erkannt wird, erzeugt der Heimatagent ein neues IP-Paket, das in 4(b) dargestellt ist. Das von dem Korrespondentenknoten gesendete ursprüngliche IP-Paket einschließlich der Zieladresse, Quellenadresse, Protokoll-ID und anderer IP-Kopfteilfelder und des Nutzsignals dient zur Bildung eines Teils des Nutzsignals des neuen IP-Pakets. Das heißt, das ursprüngliche IP-Paket wird von dem Heimatagenten überhaupt nicht verarbeitet, sondern wird lediglich völlig unverändert als das Nutzsignal 32 des neuen IP-Pakets 30 integriert.
Der Heimatagent fügt dann die Zieladresse 36, die Quellenadressen 38 und die Protokoll-ID 40 zu dem neuen IP-Paket 30 hinzu.
Die Zieladresse 36 ist die Adresse in dem Fremdnetzwerk, zu der das IP-Paket gesendet werden soll, das heißt, die Gastadresse des Mobilknotens MN 8. Die Quellenadresse 38 ist die Adresse des Heimatagenten, von der aus das neue IP-Paket 30 gesendet wird, d.h. der Heimatagent.
Die Heimatagent-Protokoll-ID ist die Protokoll-ID, die von dem Heimatagenten selbst bestimmt wird. Der Heimatagent fügt immer dieselbe Protokoll-ID an das neue IP-Paket 30 an, ungeachtet der durch den Korrespondentenknoten in das ursprüngliche IP-Paket eingefügten Protokoll-ID 20, da der Heimatagent die Protokoll-ID 20 des ursprünglichen IP-Pakets 14 nicht betrachtet. Die Protokoll-ID 40 wird nominal als Protokoll „X" gekennzeichnet. Für die Verkapselung von IP-in-IP des herkömmlichen Mobil-IP wird die Protokoll-ID von dem Heimatagenten immer in „1" umgeändert.
Somit wurden die „realen" Quellen- und Zieladressen (60 und 62 in 4(a)) in das Nutzsignal des neuen IP-Pakets verschoben und die anderen notwendigen Flußidentifikationsinformationen, wie zum Beispiel Quellen- und Zielportnummern in dem ursprünglichen IP-Nutzsignal wurden auch in dem Nutzsignal des neuen IP-Pakets eingewickelt.
Somit geht die ursprüngliche Identität eines Flusses von dem Korrespondentenknoten zu dem Mobilknoten verloren und Dienstqualität versagt, wenn das IP-Paket von dem Heimatagenten zu dem Fremdnetzwerk geroutet wird.
Das IP-Paket 30 wird dann durch den Heimatagenten gesendet und wird so geroutet, daß es an der Gastadresse des Mobilknotens in dem Fremdnetzwerk ankommt. Nachdem das IP-Paket 30 an der Gastadresse angekommen ist, entfernt der Mobilknoten die äußeren Schichten des neuen IP-Pakets 30, um das ursprüngliche IP-Paket 50 zu enthüllen.
Es ist also ersichtlich, daß bei dieser bekannten Anordnung die erforderlichen Flußidentifikationsinformationen, einschließlich der Protokoll-ID in dem ursprünglichen IP-Paket von dem Heimatagenten abgeschirmt und somit für die Routing-Vermittlungen (oder IP-Router) zur QoS-Bereitstellung zwischen dem Heimatagenten und der Gastadresse der Mobilknoten unkenntlich werden.
Das Routing eines IP-Pakets von dem Korrespondentenknoten zu der Gastadresse des Mobilknotens gemäß einer alternativen bevorzugten Implementierung wird nun beschrieben. Bei dem Schema gemäß dieser alternativen bevorzugten Implementierung bleiben die Flußidentifikations- und Differenzierungsinformationen, wie zum Beispiel die ursprüngliche Quellenadresse, die ursprüngliche Quellen- und Zielportnummer und die Quellenprotokoll-ID, die durch den Korrespondentenknoten in das ursprüngliche IP-Paket eingesetzt wird, unverändert und sind somit vorteilhafterweise allen Routing-Vermittlungen zwischen dem Korrespondentenknoten und der Gastadresse der Mobilknoten verfügbar.
Der Korrespondentenknoten konstruiert das IP-Paket 50 identisch wie zuvor in 5(a) gezeigt. Bei der Ankunft in dem Heimatnetzwerk bestimmt der Heimatagent 12, ob der Mobilknoten, an den das IP-Paket adressiert ist, als sich zu einem Fremdnetzwerk bewegt habend registriert ist, indem wie zuvor der Inhalt seines Speichers 24 geprüft wird. Bei Erkennung der Zieladresse in seiner Speicherspalte 26 fängt der Heimatagent das IP-Paket ab.
Bei dieser Implementierung paßt der Heimatagent HA das IP-Paket 14 an, indem er die Zieladresse 62 des Mobilknotens 8 in dem Heimatnetzwerk 2 entfernt und sie mit der Zieladresse (d.h. der Gastadresse) des Mobilknotens MN 8 in dem Fremdnetzwerk 6 ersetzt. Das neue IP-Paket 42 umfaßt also das Nutzsignal 63 des ursprünglichen IP-Pakets 50, die Quelle 60 des ursprünglichen IP-Pakets 50 und die Protokoll-ID 66 des ursprünglichen IP-Pakets 50. Die Zieladresse 62 des ursprünglichen IP-Pakets wird durch die neue Zieladresse 41 (die Gastadresse des Mobilknotens) ersetzt.
Fachleute werden natürlich verstehen, daß es notwendig sein kann, im Hinblick auf die Änderung der Zieladresse eine etwaige in dem ursprünglichen IP-Paket 50 bereitgestellte Fehlerprüfung zu ergänzen. Das so konstruierte neue IP-Paket wird zu der Gastadresse in dem Fremdnetzwerk gesendet. Das IP-Paket wird also zu dem Mobilknoten mit den Flußinformationen, einschließlich der Quellenadresse des Korrespondentenknotens und der ursprünglichen Protokoll-ID sowie allen anderen ursprünglichen Flußidentifikationsinformationen zu dem Mobilknoten geroutet: Es ist ersichtlich, daß, da das Nutzsignal unverändert bleibt, die Quellen- und Zielportnummern an denselben Positionen in dem IP-Paket wie zuvor verfügbar sind.
Die Flußidentifikationsinformationen werden also erkannt, da das IP-Paket von demselben Korrespondentenknoten dieselben QoS-Anforderungen für die Router zwischen dem Heimatagenten und der Gastadresse sowie zwischen den Korrespondentenknoten und dem Heimatagenten bietet, ungeachtet der Bewegung des Mobilknotens. Bei dieser Anordnung (Arbeitsmodus der zusammen angeordneten Gastadresse) hat vorteilhafterweise das durch den Heimatagenten gemäß der vorliegenden Erfindung konstruierte neue IP-Paket 42 dieselbe Länge wie das von dem Korrespondentenknoten bereitgestellte ursprüngliche IP-Paket.
Bei dieser bevorzugten Implementierung des Tunnelns sind die Flußinformationen nicht verborgen, und deshalb wird die Dienstqualität offensichtlich unterstützt. Für RSVP-Dienstqualität ist dies jedoch nicht der Fall. Der Grund dafür besteht darin, daß, damit RSVP korrekt funktioniert, der Sendeweg, dem eine sogenannte Reservierungsnachricht (Resv) folgt (sprungweise geroutet, wobei dieselben Sprünge wie durch die sogenannte Wegnachricht angegeben befolgt werden), derselbe Weg, aber in der entgegengesetzten Richtung der Wegnachricht sein muß. Das heißt, die Quellenadresse der Wegnachricht muß mit der Zieladresse der Reservierungsnachricht (Resv) übereinstimmen, und die Zieladresse der Wegnachricht muß mit der Quellenadresse der Reservierungsnachricht übereinstimmen. Das nachfolgende Beispiel des Einrichtens einer RSVP-Sitzung in der Netzwerkstruktur von 1 illustriert, warum das oben beschriebene Nicht-Verkapselungs-Mobil-IP für die Unterstützung von Dienstqualität nicht ausreicht.
Um eine RSVP-Sitzung zu unterstützen, wenn sich der Mobilknoten wie in 1 gezeigt in ein Fremdnetzwerk bewegt hat, muß eine RSVP-Sitzung mit zwei Teilen eingerichtet werden: ein erster Teil der RSVP-Sitzung („Teil 1") zwischen dem Korrespondentenknoten 10 und dem Heimatagenten 12 und ein zweiter Teil der RSVP-Sitzung („Teil 2") zwischen dem Heimatagenten und dem Mobilknoten 8.
Der Korrespondentenknoten 10, von dem in diesem Beispiel angenommen wird, daß er eine Nachricht zu dem Mobilknoten 8 sendet, sendet eine Standard-RSVP-Wegnachricht, die IP-Pakete 70 mit dem in 6(a) auf Zeile 128 gezeigten allgemeinen Format enthält.
Die IP-Pakete der Nachrichten, die in einer RSVP-Sitzung verwendet werden, müssen nicht das in 2(a) bis 2(c) gezeigte Format aufweisen. Die IP-Pakete von 2(a) bis 2(c) sind IP-Pakete von Datennachrichten. Die IP-Pakete 70 der Wegnachricht von 6(a) weisen eine Quellenadresse 78 auf, die der Adresse des Korrespondentenknotens entspricht, und eine Zieladresse 80, die der Adresse des Mobilknotens 8 in dem Heimatnetzwerk (der Heimatadresse des Mobilknotens) entspricht.
Die IP-Pakete der Wegnachricht (und anderer RSVP-Nachrichten) enthalten zusätzlich weitere Flußidentifikationsinformationen in dem Nutzsignal der IP-Pakete. Fachleute werden mit den weiteren Flußidentifikationsinformationen vertraut sein.
Das IP-Paket der Wegnachricht wird von dem Korrespondentenknoten 10 über mehrere Routing-Vermittlungen, die durch die Routing-Vermittlung 132a, Zeilen 128 und 124 repräsentiert werden, zu dem Heimatnetzwerk 2 geroutet.
Wenn die Routing-Vermittlung 132a Dienstqualität unterstützt, extrahiert sie die Flußidentifikationsinformationen in dem IP-Nutzsignal der Wegnachricht-IP-Pakete und speichert diese Flußidentifikationsinformationen. Zu diesen Flußidentifikationsinformationen gehören: die Quellenadresse, die Zieladresse, die Quellenportnummer, die Zielportnummer und die Protokoll-ID, die in alle IP-Datenpakete eingefügt wird, die von Quelle zum Ziel gesendet werden, nachdem die Dienstqualitätssitzung eingerichtet wurde. Die Routing-Vermittlung 132a routet die IP-Pakete der Wegnachricht zu einer anderen Routing-Vermittlung und speichert dann zusätzlich mit den Flußidentifikationsinformationen, die aus dem IP-Paket extrahiert wurden, die Adresse der Routing-Vermittlung, zu der sie die Nachricht gesendet hat (nächster Sprung), und die Adresse der Routing-Vermittlung, von der sie die Nachricht empfangen hat (vorheriger Sprung). Obwohl in 1 nicht dargestellt ist, daß die IP-Pakete das Heimatnetzwerk 2 über eine Routing-Vermittlung 132a erreichen, können in der Praxis die IP-Pakete das Heimatnetzwerk über mehrere Routing-Vermittlungen erreichen, und jede Routing-Vermittlung speichert die aus den IP-Paketen der Wegnachricht extrahierten Flußidentifikationsinformationen zusammen mit der Identität der Routing-Vermittlung, von der das IP-Paket gesendet wurde, und der Routing-Vermittlung, zu der das IP-Paket gesendet wurde.
Somit erreichen die IP-Pakete der Wegnachricht das Heimatnetzwerk aus dem Korrespondentenknoten durch das Routing-Netzwerk. Jede Routing-Vermittlung behält die Adresse des vorherigen Sprungs, woher das IP-Paket gesendet wurde, zusammen mit dem nächsten Sprung, zu dem das IP-Paket gesendet wurde, und zusätzlich die Flußidentifikationsinformationen für das IP-Paket. Außerdem verarbeiten die Routing-Vermittlungen die anderen verkehrsbezogenen Informationen in der Wegnachricht, deren Beschaffenheit für eine Besprechung der vorliegenden Erfindung nicht relevant ist.
Nachdem die Dienstqualitätssitzung eingerichtet wurde, und wenn ein anderes IP-Paket an einer bestimmten Routing-Vermittlung mit denselben Flußidentifikationsinformationen, die in dem Routing-Vermittlungsspeicher gespeichert wurden, ankommt, leitet die Routing-Vermittlung es zu genau demselben nächsten Sprung weiter, dessen Adresse in dem Speicher gespeichert ist.
Bei nachfolgenden Sprüngen ruft also jede Routing-Vermittlung (so lange sie RSVP-Dienstqualität unterstützt) die Flußidentifikationsinformationen von den festen Positionen der IP-Pakete der Wegnachricht ab und speichert diese zusammen mit den Adressen des nächsten und des vorherigen Sprungs im Speicher. Die Flußidentifikationsinformationen in den IP-Paketen helfen also dabei, einen Nachrichtenfluß eindeutig zu identifizieren, so daß alle mit diesem Nachrichtenfluß assoziierten IP-Pakete durch genau denselben Netzwerkweg von der Quelle zu dem Ziel geroutet werden können.
Der Heimatagent fängt dann die IP-Pakete der Wegnachricht, die für den Mobilknoten bestimmt ist, ab. Wenn der Heimatagent die IP-Pakete der für den Mobilknoten 8 bestimmten Wegnachricht abfängt, leitet er sie zu dem Fremdnetzwerk weiter. In diesem Beispiel wird ein Nicht-Verkapselungs-Mobil-IP verwendet, und neue IP-Pakete werden zur Übertragung zu dem Fremdnetzwerk als eine neue oder modifizierte Wegnachricht erzeugt. Die IP-Pakete 74 der von dem Heimatagenten gesendeten modifizierten Wegnachricht sind in 6(b) gezeigt. Der Heimatagent ersetzt die Zieladresse der IP-Pakete der Wegnachricht dergestalt, daß die Zieladresse 106 der IP-Pakete 74 der modifizierten Wegnachricht die Gastadresse des Mobilknotens in dem Fremdnetzwerk ist. Wie oben besprochen, bleiben bei Nicht-Verkapselungs-Mobil-IP alle anderen Elemente der IP-Pakete 70 unverändert.
Diese modifizierte Wegnachricht wird über Routing-Vermittlungen, die durch die einzige Routing-Vermittlung 132b (Zeilen 126 und 130) repräsentiert werden, zu der Gastadresse des Mobilknotens geroutet.
Wie oben in bezug auf den ersten Teil der Wegnachricht beschrieben, werden in dem zweiten Teil der Wegnachricht die IP-Pakete der modifizierten Wegnachricht ähnlich auf der Basis der Flußidentifikationsinformationen darin gesendet. Die Routing-Vermittlungen speichern ähnlich die nächsten und vorherigen Sprünge.
Der Mobilknoten empfängt die modifizierte Wegnachricht und leitet die Reservierungsnachricht (RESV) für den zweiten Teil ein, indem er eine Reservierungsnachricht für die Übertragung mit den IP-Paketen 76 des allgemeinen, in 6(c) dargestellten Formats erzeugt.
Für Fachleute ist erkennbar, daß die IP-Pakete einer Reservierungsnachricht (Resv) sprungweise entlang des identischen Netzwerkweges wie die IP-Pakete der Wegnachricht zurückgesendet werden. Somit sind die Quellen- und Zieladressen der IP-Pakete der Reservierungsnachrichten tatsächlich die letzten und vorherigen Sprünge. Der Wert der Quellen- und Zieladressen wird somit dynamisch bestimmt, während die Reservierungsnachrichten den Weg durchlaufen. Die Struktur der IP-Pakete 76 der Reservierungsnachricht (siehe 6(c)) repräsentiert somit tatsächlich die Transportschicht der Reservierungsnachrichten. Die in 6(c) gezeigte Struktur zeigt also das allgemeine Konzept einer Reservierungsnachricht, das heißt, die Ursprungsquellenadresse und die Endzieladresse. Diese Analyse der Reservierungsnachricht ist etwas künstlich, dient aber zur besten Veranschaulichung des Prinzips von RSVP.
Der Mobilknoten 8 identifiziert die Quellenadresse 114 als die Heimatadresse des Mobilknotens. Das Standard-Mobil-IP sieht vor, daß sich die Anwendungen auf einem Mobilknoten selbst nicht über die Änderung der Netzwerkanschlußpunkte der Mobilknoten bewußt sein sollen. Ungeachtet der Position des Mobilknotens (gleichgültig ob in dem Heimatnetzwerk oder in einem Fremdnetzwerk) erzeugt der Mobilknoten deshalb immer IP-Pakete, die die Quellenadresse als die Heimatadresse des Mobilknotens identifizieren. Der Mobilknoten fügt eine Zieladresse in die Reservierungsnachricht der Korrespondentenknotenadresse ein. Der Grund dafür besteht darin, daß gemäß dem Standard-Mobil-IP sich der Mobilknoten darüber bewußt ist, daß die Nachricht von dem Korrespondentenknoten kam, und sich nicht über die Umlenkung über den Heimatagenten bewußt ist. Für IP-Pakete, die im Standard-Mobil-IP von dem Mobilknoten zu dem Korrespondentenknoten gesendet werden, werden sie so als normale IP-Pakete geroutet, als ob sich der Mobilknoten „zu Hause" in dem Heimatnetzwerk befände.
Ein Vergleich der IP-Pakete der Weg- und Reservierungsnachrichten von 6(b) und 6(c) zeigt, daß die Bedingungen für eine erfolgreiche RSVP-Sitzung nicht existieren. Die Quellenadresse der Reservierungs nachricht 76 ist von der der Zieladresse der Wegnachricht 74 verschieden.
Dies führt zu dem Erfolglosbleiben des Routings der Reservierungsnachricht (Resv) sprungweise unter Befolgung desselben Netzwerkweges wie dem, der von den IP-Paketen der Wegnachricht gesetzt wird. Die Reservierungsnachricht für den ersten Teil (zwischen dem Heimatagenten und dem Korrespondentenknoten) wird niemals eingeleitet, weil der zweite Teil erfolglos bleibt.
Mit Bezug auf 7 ist die Netzwerkanordnung von 1 gezeigt, die so ausgelegt ist, daß sie es dem Nicht-Verkapselungs-Mobil-IP erlaubt, RSVP zu unterstützen. In der gezeigten Anordnung wird ein Proxy-Server in das Korrespondentennetzwerk und das Fremdnetzwerk eingeführt. Aus der folgenden Beschreibung sollte jedoch hervorgehen, daß die Funktionalität des Proxy-Servers in der Praxis in die Hostendgeräte integriert werden kann, mit denen die Proxy-Server verbunden sind. Es folgt eine weitere Erläuterung im Anschluß an die Erläuterung der Anordnung von 7.
Mit Bezug auf 7 sind die Netzwerke von 1 so ausgelegt, daß das Korrespondentennetzwerk 4 zusätzlich einen Korrespondentennetzwerk-Proxy-Server 142 und das Fremdnetzwerk 6 zusätzlich einen Fremdnetzwerk-Proxy-Server 144 enthält. Der Korrespondentenknoten 10 ist über eine Netzwerkstrecke 138 mit dem Korrespondentenknoten-Proxy-Server 142 verbunden. Der Korrespondentennetzwerk-Proxy-Server ist über eine Netzwerkstrecke 128 an die Routing-Vermittlungen angeschlossen. Der Fremdnetzwerk-Proxy-Server 144 ist über eine Netzwerkstrecke 146 mit dem Mobilknoten 8 in dem Fremdnetzwerk 6 verbunden. Der Fremdnetzwerk-Proxy-Server ist über die Netzwerkstrecke 136 an die Routing-Vermittlung 132b angeschlossen.
Es wird nun ein Beispiel für die Funktionsweise des angepaßten Netzwerks von 8 zum Senden einer Nachricht von dem Korrespondentenknoten 10 zu dem Mobilknoten 8 in dem Fremdnetzwerk unter Verwendung des Nicht-Verkapselungs-Mobil-IP, worin RSVP unterstützt wird, beschrieben.
Jedes Host-Endgerät, das Dienstqualitätvorkehrungen in einem Netzwerk erfordert, muß sich über die Existenz eines Proxy-Servers in dem Netzwerk bewußt sein. Das heißt, es muß einen Prozeß geben, durch den die Hostendgeräte Proxy-Server entdecken können. Dies kann effektiv auf zwei Weisen geschehen. Auf eine erste Weise senden Hostendgeräte in dem Netzwerk eine Server-Verhandlungsnachricht (SSM – server soliciting message) rund. Ein Proxy-Server in dem Netzwerk antwortet, indem er eine Server-Antwortnachricht (SRM) zu dem Hostendgerät zurücksendet. Auf eine zweite Weise sendet der Proxy-Server in einem Netzwerk eine Client-Anforderungsnachricht (CRQM) auf das lokale Netzwerk rund. Als Reaktion darauf senden Hostendgeräte (die als Proxy-Server-Clients betrachtet werden können) eine Client-Registrationsnachricht (CRGM) zurück. Auf diese Weise wird die Anwesenheit der Proxy-Server in den Netzwerken durch Hostendgeräte in den Netzwerken auf ähnliche Weise registriert wie die Anwesenheit von Agenten (Heimatagenten, Fremdagenten) zur Zeit im Standard-Mobil-IP registriert wird. Die Implementierung der Technik, durch die sich Knoten bei Proxy-Servern registrieren, wird in den Kenntnisstand von Fachleuten fallen.
Um erfolgreich eine Dienstqualitätssitzung zwischen dem Korrespondentenknoten und dem Mobilknoten einzurichten, wenn der Korrespondentenknoten eine Nachricht zu dem Mobilknoten sendet, ist es wie oben besprochen notwendig, eine RSVP-Sitzung mit zwei Teilen einzurichten. Allgemein ausgedrückt muß zwischen dem Korrespondentennetzwerk und dem Heimatnetzwerk des Mobilknotens ein erster Teil der Dienstqualitätssitzung und zwischen dem Heimatnetzwerk und dem Fremdnetzwerk ein zweiter Teil der Dienstqualitätssitzung hergestellt werden.
Die Technik zur Einrichtung der ersten Dienstqualitätssitzung und insbesondere einer RSVP-Sitzung im Mobil-IP für die Netzwerkanordnung von 7 wird nun mit Hilfe des Flußdiagramms von 8 beschrieben. Gemäß der vorliegenden Erfindung sendet in einem Schritt 150 der eine Dienstqualitätssitzung einleitende Korrespondentenknoten 14a auf der Netzwerkstrecke 138 eine Dienstqualitätsanforderung zu dem Korrespondentennetzwerk-Proxy-Server 142.
Die Dienstqualitätsanforderung kann implizit oder explizit sein. Eine explizite Dienstqualitätsanforderung von dem Korrespondentenknoten spezifiziert eine exakte Dienstqualitätsanforderung. Eine explizite Dienstqualitätsanforderung kann also nur von einem Korrespondentenknoten bereitgestellt werden, der die Funktionalität zur Unterstützung des expliziten Statements einer bestimmten Dienstqualität aufweist. Eine implizite Dienstqualitätsanforderung von dem Korrespondenten spezifiziert nur die Beschaffenheit der durchzuführenden Übertragung. Zum Beispiel kann eine implizite Dienstqualitätsanforderung angeben, daß die zu sendenden Daten Videodaten sind. Der Proxy-Server bestimmt dann die entsprechende Dienstqualität abhängig von der Angabe der Art von Daten.
Der Korrespondentennetzwerk-Proxy-Server 142 sendet dann im Schritt 152 eine Standard-RSVP-Wegnachricht. Diese Wegnachricht wird über die Routing-Vermittlung 132a auf den Leitungen 128 und 124 zu dem Heimatnetzwerk-Proxy-Server übermittelt.
Die IP-Pakete der von dem Korrespondentenknoten-Proxy-Server gesendeten Wegnachricht entsprechen identisch den IP-Paketen 70 von 6(a) und werden durch das Routing-Netzwerk, das die Routing-Vermittlungen 132 umfaßt, zu dem Heimatagenten 12 geroutet. Das Routing findet genauso wie zuvor beschrieben statt.
In einem Schritt 154 fängt der Heimatagent die IP-Pakete der Wegnachricht ab und paßt die IP-Pakete wie oben beschrieben an, um die IP-Pakete für die modifizierte Wegnachricht zu erzeugen.
Die IP-Pakete der modifizierten Wegnachricht entsprechen identisch den IP-Paketen 74 von 6(b). In einem Schritt 156 werden die den zweiten Teil der Wegnachricht 74 umfassenden IP-Pakete durch den Heimatagenten gesendet und über das durch die Routing-Vermittlung 132b repräsentierte Routing-Netzwerk zu dem Fremdnetzwerk 144 gesendet.
Der Fremdnetzwerk-Proxy-Server empfängt den zweiten Teil der Wegnachricht und in einem Schritt 158 sendet der Fremdnetzwerk-Proxy-Server 144 auf der Leitung 146 ein Dienstqualitäts-Anzeigesignal zu dem Mobilknoten, das die von dem Korrespondentenknoten 10 angeforderte Dienstqualität angibt. Wenn der Dienstqualitätsgrad für das Mobilendgerät annehmbar ist, sendet das Mobilendgerät eine Dienstqualitätsantwort als Bestätigung zu dem Fremdnetzwerk-Proxy-Server 144 in einem Schritt 160 auf der Netzwerkstrecke 146.
In einem Schritt 162 sendet der Fremdnetzwerk-Proxy-Server dann eine modifizierte Reservierungsnachricht (d.h. modifiziert relativ zu der mit Standard-Mobil-IP gesendeten Reservierungsnachricht), die die Dienstqualitätssitzung bestätigt. Die modifizierte Reservierungsnachricht folgt der identischen Route wie die Wegnachricht (rückwärts) über die Leitungen 136 und 126.
Das Format der modifizierten Reservierungsnachricht 79 für die zweite RSVP-Sitzung, die durch den Fremdnetzwerk-Proxy-Server zurückgesendet wird, ist in 6(d) dargestellt. Wie ersichtlich ist, ist aufgrund der Verwendung des Fremdnetzwerk-Proxy-Servers 144 die Quellenadresse 115 die Mobilknoten-Gastadresse und die Zieladresse ist die Adresse des Korrespondentenknotens. Somit besteht die korrekte Korrelation zwischen Quellen- und Zieladressen von Weg- und Reservierungsnachrichten in der zweiten RSVP-Sitzung, so daß die RSVP-Sitzung unterstützt wird.
Wieder repräsentiert die in 6(c) gezeigte Nachricht die Ende-zu-Ende-Nachricht zwischen dem Fremdnetzwerk und dem Heimatnetzwerk. Das in 6(d) gezeigte Format repräsentiert die IP-Pakete der Reservierungsnachricht, die, wie oben besprochen, dem vorherigen und nächsten Sprung entsprechende Quellen- und Zieladressen aufweisen.
In einem Schritt 164 empfängt der Heimatagent die modifizierte Reservierungsnachricht. Der Heimatagent paßt die Reservierungsnachricht auf die in 6(e) gezeigte Form an, die eine weitere modifizierte Reservierungsnachricht bildet. Um diese Anpassung durchzuführen, wird der Heimatagent mit der Funktionalität eines Proxy-Servers darin ausgestattet. Als Alternative kann in dem Heimatnetzwerk ein Heimatnetzwerk-Proxy-Server, der dem Korrespondentennetzwerk- und Fremdnetzwerk-Proxy-Server äquivalent ist, bereitgestellt und mit dem Heimatagenten assoziiert werden.
Die RSVP-Sitzung wird dadurch abgeschlossen, daß der Heimatagent die weiter modifizierte Reservierungsnachricht über die Routing-Vermittlung 132a und die Netzwerkstrecken 124 und 128 zu dem Korrespondentennetzwerk zurücksendet. Wie in 6(e) gezeigt, besitzt die Reservierungsnachricht als die Quellenadresse 88 die Heimatadresse des Mobilknotens und als die Zieladresse die Adresse des Korrespondentenknotens.
Somit ist der Teil der RSVP-Sitzung zwischen dem Korrespondentennetzwerk und den Heimatnetzwerk einer statischen Standard-RSVP-Sitzung äquivalent. Die von den Routing-Vermittlungen in den Routing-Netzwerken zur Unterstützung von RSVP erforderlichen Flußinformationen sind vollständig verfügbar. Die Quellen- und Zieladressen werden in der weitermodifizierten Reservierungsnachricht in bezug auf die Wegnachricht „umgewechselt".
In einem Schritt 166 sendet der Heimatagent dann die Reservierungsnachricht für den ersten Teil. Die weitermodifizierte Reservierungsnachricht wird dann zu dem Korrespondentennetzwerk 4 gesendet und dort durch den Korrespondentennetzwerk-Proxy-Server 142 empfangen.
Der Korrespondentennetzwerk-Proxy-Server sendet dann in einem Schritt 168 auf der Netzwerkstrecke 138 eine Dienstbestätigungsnachricht als Bestätigung zu dem Korrespondentenknoten 10, die anzeigt, daß die Dienstqualitätssitzung eingerichtet wurde.
Der Korrespondentenknoten 10 beginnt dann mit dem Senden von Datennachrichtenpaketen zu dem Mobilendgerät. Die Datennachrichtenpakete laufen jedoch nicht über den Korrespondentennetzwerk-Proxy-Server oder den Fremdnetzwerk-Proxy-Server. Die Proxy-Server werden nur während des Einrichtens der RSVP-Sitzung benutzt.
Nachdem die RSVP-Sitzung wie beschrieben eingerichtet wurde und Nachrichten von dem Korrespondentenknoten zu dem Mobilknoten gesendet werden, ist es entscheidend, daß die von den IP-Paketen der Datennachricht geführten Flußidentifikationsinformationen mit den beim Einrichten der RSVP-Sitzung verwendeten übereinstimmen. Die IP-Datenpakete, die das in 2 gezeigte allgemeine Format aufweisen, müssen also dieselbe Quellenportnummer, Zielportnummer und Protokoll-ID enthalten, die in dem Nutzsignal der RSVP-Nachricht enthalten sind, sowie die Quellen- und Zieladressen. Auf diese Weise werden die Daten-IP-Pakete eindeutig als mit dem durch die RSVP-Sitzung konfigurierten Fluß assoziiert identifiziert. Die Bereitstellung des Fremdnetzwerk-Proxy-Servers stellt also sicher, daß die RSVP-Dienstqualität im Mobil-IP unterstützt wird. Die in 7 gezeigten Proxy-Server können also als „RSVP-Proxy-Server" betrachtet werden. Die Proxy-Server passen das Ziel der RSVP-Nachrichten dynamisch an, um der Bewegung des Mobilknotens zu folgen, und garantieren in der Zwischenzeit, daß die Flußidentifikationsinformationen und die Dienstqualitätsinformationen mit den gemäß dem Nicht-Verkapselungs-Mobil-IP (NEMIP) geleiteten Datenflüssen übereinstimmen.
Aus der obigen Beschreibung ist ersichtlich, daß es entscheidend ist, daß der Proxy-Server (oder die äquivalente Funktionalität des Proxy-Servers) in dem Fremdnetzwerk bereitgestellt ist, das heißt, einem Netzwerk, das für normalerweise in anderen Netzwerken verankerte Hostendgeräte sorgt, wenn Dienstqualität im Mobil-IP unterstützt werden soll.
Die Bereitstellung des RSVP-Proxy-Servers (oder seines funktionalen Äquivalents) in dem Fremdnetzwerk garantiert, daß die eingerichtete RSVP-Sitzung (insbesondere der zweite Teil der RSVP-Sitzung) der Bewegung des Mobilknotens folgt und gleichzeitig die korrekten Flußinformationen aufzeichnet, die mit denen der Datenflüsse übereinstimmen, die demselben Weg der RSVP-Sitzung folgen, ungeachtet der Änderung des Punkts des Netzwerkanschlusses des Mobilknotens.
Kein Hostendgerät weiß beim Senden, ob das Hostendgerät, zu dem es sendet, ein Mobilknoten ist, oder ob er sich in einem Fremdnetzwerk mit einem RSVP-Proxy-Server befindet. Um Unterstützung von RSVP mit Mobil-IP sicherzustellen, sollte jedes Netzwerk, das dazu fähig ist, als Fremdnetzwerk für Hostmobilknoten zu wirken, mit einem Proxy-Server (oder seiner äquivalenten Funktionalität) mit den hier beschriebenen Funktionen ausgestattet sein. Die obige Beschreibung der funktionalen Steuerung, die durch den Proxy-Server in einem Fremdnetzwerk durchgeführt wird, ist für die Unterstützung von Dienstqualität in einer Mobilumgebung entscheidend.
Mit Bezug auf 7 besteht die wesentliche Anforderung zur Unterstützung einer Dienstqualitätssitzung für einen Korrespondentenknoten in dem Korrespondentennetzwerk, der Datennachrichten zu dem Mobilknoten senden möchte, darin, daß das Fremdnetzwerk, in dem sich der Mobilknoten befindet, einen Proxy-Server oder sein funktionales Äquivalent besitzen muß. Der Korrespondentenknoten kann dann direkt die RSVP-Sitzung selbst einrichten, ohne daß der Korrespondentenknoten-Proxy-Server notwendig ist.
Die Bereitstellung des Korrespondentenknoten-Proxy-Servers hat jedoch den Vorteil, daß sie es Endgeräten in dem Korrespondentenknoten, die keine RSVP-Funktionalität besitzen, ermöglicht, RSVP-Sitzungen einzuleiten. Der Proxy-Server liefert eine Technik zum Konfigurieren einer Dienstqualitätssitzung, die sowohl plattform- als auch anwendungsunabhängig ist. Durch Bereitstellung eines speziellen Mittels zum Einrichten von Dienstqualitätssitzungen können dann für derzeitige und zukünftige, zu Dienstqualität unfähige Hostendgeräte Dienstqualitätssitzungen eingerichtet werden, und somit wird ihre Dienstqualitätssteuerung über den Sendeweg hinweg zu ihren Kommunikations-Peers ermöglicht. Die Anforderungen bezüglich komplizierter und intensiver Datenverarbeitung, die in vielen Dienstqualitätssteuer-Zeichengabe- und -steuermechanismen entstehen und die Belastung der Batterieleistung für drahtlose/Mobilendgeräte wird vermieden.
Bei einer alternativen Anwendung kann, wie durchweg bereits erwähnt wurde, die Funktionalität des Proxy-Servers, die in dem Fremdnetzwerk durchgeführt wird, in dem Mobilknoten selbst durchgeführt werden. Bei einer solchen Anwendung ist der Mobilknoten bereits RSVP-fähig und besitzt einen RSVP-Dämon zur Unterstützung von Standard-RSVP-Sitzungen. Bei einer solchen Anwendung erzeugt als Reaktion auf die modifizierte Wegnachricht von dem Heimatnetzwerk der Mobilknoten das in 6(c) gezeigte Standard-RSVP-Nachrichtenformat. Die in den RSVP-Dämon des Mobilknotens eingebettete Proxy-Server-Funktionalität modifiziert dann diese Reservierungsnachricht, um die modifizierte Reservierungsnachricht von 6(d) zu erzeugen. Die modifizierte Reservierungsnachricht wird dann direkt von dem Mobilknoten gesendet.
Es sollte beachtet werden, daß die hier im gesamten Text beschriebenen Beispiele Standard-RSVP verwenden. Es wird keine Änderung des Standard-RSVP/IntServ in Betracht gezogen oder vorgeschlagen.
Die Erfindung wurde hier mit Bezug auf ein konkretes Beispiel für eine RSVP-Dienstqualitätssitzung beschrieben, die Weg- und Reservierungsnachrichten verwendet. Die Erfindung ist jedoch allgemeiner auf jede beliebige Dienstqualitätssitzung anwendbar, die Anforderungs- und Antwortnachrichten zwischen zwei Endgeräten zur Konfiguration einer Dienstqualitätssitzung verwendet und bei der es eine Anforderung ist, das hier identifizierte Problem zu überwinden.

Claims

Verfahren zum Herstellen einer Dienstqualitätssitzung zwischen einem Korrespondentenknoten (10) und einem Mobilknoten (8), wobei der Mobilknoten (8) eine Heimatadresse in einem Heimatnetzwerk (2) aufweist und vorübergehend an einer Gastadresse in einem Fremdnetzwerk (6) verbunden ist, wobei das Verfahren die folgenden Schritte umfaßt: Erzeugen, in dem Fremdnetzwerk (6), einer modifizierten Antwortadresse (79) mit einer Zieladresse (117) des Korrespondentenknotens und einer Quellenadresse; und Senden der modifizierten Antwortadresse, dadurch gekennzeichnet, daß die modifizierte Antwortadresse (79) anstelle der Heimatadresse (114) des Mobilknotens eine Quellenadresse (115) der Gastadresse des Mobilknotens aufweist.
Verfahren nach Anspruch 1, ferner mit den folgenden Schritten: Empfangen, in dem Heimatnetzwerk (2), einer Anforderungsnachricht (70) mit einer Quellenadresse (78) des Korrespondentenknoten und einer Zieladresse (106) der Heimatadresse des Mobilknotens; Erzeugen einer modifizierten Anforderungsnachricht (74) durch Ersetzen der Zieladresse (80) der Anforderungsnachricht mit der Gastadresse (106) des Mobilknotens; und Senden der modifizierten Anforderungsnachricht (74) zu dem Fremdnetzwerk (6), wodurch die modifizierte Antwortnachricht (79) als Reaktion auf die modifizierte Anforderungsnachricht (74) erzeugt wird.
Verfahren nach Anspruch 1 oder Anspruch 2, ferner mit den folgenden Schritten: Empfangen, in dem Heimatnetzwerk (2), der modifizierten Antwortnachricht (79); Erzeugen einer weiteren modifizierten Anforderungsnachricht (81) durch Ersetzen der Quellenadresse (115) mit der Heimatadresse (119) des Mobilknotens; und Senden der weiteren modifizierten Antwortnachricht (81).
Verfahren nach einem der Ansprüche 1 bis 3, bei dem der Schritt des Erzeugens der modifizierten Antwortnachricht (79) in dem Mobilknoten (8) ausgeführt wird.
Verfahren nach Anspruch 4, wobei der Schritt des Erzeugens der modifizierten Antwortnachricht (79) folgendes umfaßt: Erzeugen einer Antwortnachricht (76) mit einer Quellenadresse (114) der Heimatadresse des Mobilknotens und einer Zieladresse (116, 117) des Korrespondentenknotens; und Ersetzen der Quellenadresse mit der Gastadresse des Mobilknotens, wodurch die modifizierte Antwortnachricht (79) erzeugt wird.
Verfahren nach einem der Ansprüche 1 bis 3, bei dem der Schritt des Erzeugens der modifizierten Antwortnachricht (79) durch Proxy-Mittel (144) in dem mit dem Mobilknoten (8) assoziierten Fremdnetzwerk (6) ausgeführt wird.
Verfahren nach Anspruch 6 bei Abhängigkeit von Anspruch 2, ferner mit den folgenden Schritten: als Reaktion auf den Empfang der modifizierten Anforderungsnachricht (74) in den Proxy-Mitteln (144), Senden eines Dienstqualitäts-Anzeigesignals zu dem Mobilknoten (2), wodurch die modifizierte Antwortadresse (79) als Reaktion auf den Empfang einer Dienstqualitäts-Bestätigung aus dem Mobilknoten (8) erzeugt wird.
Verfahren nach einem der Ansprüche 3 bis 7, bei dem der Korrespondentenknoten (10) die Anforderungsnachricht (70) erzeugt und die weiter modifizierte Anforderungsnachricht (81) empfängt.
Verfahren nach einem der Ansprüche 3 bis 7, bei dem der Korrespondentenknoten (10) mit einem Korrespondenten-Proxy-Mittel (142) assoziiert ist, wodurch das Korrespondenten-Proxy-Mittel (142) die Anforderungsnachricht (70) als Reaktion auf eine Dienstqualitätsanforderung aus dem Korrespondentenknoten (10) erzeugt und das Korrespondenten-Proxy-Mittel (142) als Reaktion auf den Empfang der weiteren modifizierten Anforderungsnachricht (81) eine Dienstqualitäts-Bestätigung erzeugt.
Mobil-IP-System, das so ausgelegt ist, daß es eine Dienstqualitätssitzung unterstützt, mit einem Korrespondentenknoten (10) und einem Mobilknoten (8), wobei der Mobilknoten (8) eine Heimatadresse in einem Heimatnetzwerk (2) aufweist und so ausgelegt ist, daß er vorübergehend an einer Gastadresse in einem Fremdnetzwerk (6) verbunden wird, wobei das Fremdnetzwerk (6) mit dem Mobilknoten (8) assoziierte Mittel (144) aufweist, die so ausgelegt sind, daß sie eine Antwortnachricht (79) erzeugen, die eine Zieladresse (117) des Korrespondentenknotens und eine Quellenadresse aufweist, dadurch gekennzeichnet, daß die modifizierte Antwortadresse anstelle der Heimatadresse (115) des Mobilknotens eine Quellenadresse (119) der Gastadresse des Mobilknotens aufweist.
Mobil-IP-System nach Anspruch 10, bei dem die Mittel in dem Mobilknoten vorgesehen sind.
Mobil-IP-System nach Anspruch 10, bei dem die Mittel (144) getrennt von dem Mobilknoten vorgesehen sind.
Verfahren oder System nach einem der vorhergehenden Ansprüche, bei dem die Dienstqualitätssitzung eine RSVP-Sitzung, die Anforderungsnachricht eine Wegnachricht und die Antwortnachricht eine Reservierungsnachricht ist.