DE60122782T2

DE60122782T2 - Adressierungsverfahren und system zur verwendung einer anycast-adresse

Info

Publication number: DE60122782T2
Application number: DE60122782T
Authority: DE
Inventors: Jarno Rajahalme
Original assignee: Nokia Oyj
Current assignee: Intellectual Ventures I LLC
Priority date: 2001-03-02
Filing date: 2001-03-02
Publication date: 2007-08-30
Anticipated expiration: 2021-03-03
Also published as: EP1368947B1; US20040107234A1; DE60122782D1; WO2002071720A1; EP1368947A1

Description

GEBIET DER ERFINDUNG
Die vorliegende Erfindung betrifft ein Verfahren und ein System zum Adressieren einer Datenquelle in einem Datennetzwerk, wie zum Beispiel einem IP (Internet Protocol)-Netzwerk, durch Verwenden einer Adresse, zum Beispiel einer IP-Anycast-Adresse, die mehr als einer Schnittstelle zugewiesen ist.
HINTERGRUND DER ERFINDUNG
An vielen Stellen des Internets ist die für verschiedene Dienste benötigte Arbeitsbelastung auf einen Punkt angewachsen, an dem ein einzelnes System oft nicht mehr in der Lage ist, damit umzugehen. Anbieten desselben Dienstes unter einer Anzahl verschiedener Knotennamen ist eine Lösung, die durch einige Stellen, zum Beispiel seitens Netscape für ihre Dateiübertragungen verwendet worden ist.
Da das Netz (Web) heranwächst, wird die Fähigkeit auf Auslastungsungleichgewichte zu reagieren, zunehmend wichtig. Zu anfangs basierten die meisten durch Netzserver ausgelieferte Inhalte auf mehr oder weniger gleichmäßig kleinen Dateien bzw. Files. Folglich, wenn die Anzahl der Anforderungen gleichmäßig verteilt wäre, wäre die Auslastung der Server relativ gleichförmig. Jedoch heute und in der Zukunft zunehmend geben Netzserver mehr dynamisch erzeugte Ergebnisse mit wesentlichen graphischen Inhalten und einer breiten Variation bezüglich der benötigten Berechnung, um die Ergebnisse zu erzeugen, aus. Diese Variation des Inhalts und Aufwand machen es zunehmend schwierig, eine Gruppe von Servern gleichmäßig ausgelastet zu halten.
In „Network Dispatcher: a connection router for scalable Internet services" von Guerney D.H. Hunta und andere, IBM T.J. Watson Research Center, Yorktown Heights, New York, USA, wird das Problem, die Auslastung gleichmäßig verteilt oder ausgewogen auf einer Gruppe von Servern zu halten, durch einen Netz werkverteiler (bzw. Netzwerk Dispatcher), der in den TCP/IP (Übertragungssteuerungsprotokoll bzw. Transmit Control Protocol/Internetprotokoll) Stack eines einzelnen Systems integriert ist, gelöst. Er handelt als ein Verteiler (bzw. Dispatcher) für Verbindungen von Clients, die eine einzelne IP-Adresse für einen Dienst kennen, auf einen Satz von Servern, die tatsächlich die Arbeit leisten. Abweichend von anderen Ansätzen gehen nur die Datenpakete, die von den Clients zu dem Server gehen, durch den Netzwerk-Dispatcher; Pakete von dem Server an den Client können über andere Leitwege (bzw. Routen) gehen, die nicht einen Netzwerk-Dispatcher beinhalten müssen. Dies reduziert die Last auf den Netzwerk-Dispatcher, was ihm erlaubt, potenziell vor einer großen Anzahl von Servern zu stehen, umso die Last als ein Teil mehrerer Netzsennerkomplexe zu verteilen. Insbesondere umfasst der vorgeschlagene Netzwerk-Dispatcher einen Ausführer (bzw. Executor), der angepasst ist, Verbindungszuweisung und das Weiterleiten der Pakete für jede TCP-Verbindung zu handhaben. Der Netzwerk-Dispatcher unterstützt virtuell eingekapselte Cluster (bzw. Virtual Encapsulated Clusters) (VECs), die Zusammenstellungen von Hosts darstellen, die die Dienste auf einer einzelnen IP-Adresse bereitstellen. Der Executor verwaltet eine Verbindungstabelle, eine VEC-Tabelle für jeden VEC, eine Porttabelle für jeden VEC und eine Server-Tabelle für jeden Port innerhalb eines VEC. Lastteilung wird unterstützt durch einen Verwaltungsprozess auf Anwenderebene, der die Last auf den Servern überwacht und den Verbindungszuweisungsalgorithmus steuert.
Gemäß der Adressierungsarchitektur des IP-Version 6-Prokolls (IPv6), IPv6-Anycast-Adressen werden mehr als einer Schnittstelle (die typischerweise zu verschiedenen Netzwerkknoten gehören) zugewiesen werden, mit der Eigenschaft, dass ein Paket, das an ein Anycast-Adresse gesendet wurde, zu der „nächsten" Schnittstelle geroutet wird, die diese Adresse besitzt, gemäß der Abstandsmessung der Routing-Protokolle. Anycast-Adressen werden aus dem Unicast-Adressraum zugewiesen, wobei jedes der definierten Unicast-Adressformate verwendet wird. So sind Anycast-Adressen syntaktisch von Unicast-Adressen unterscheidbar, die einer einzigen Schnittstelle zugewiesen sind. Für jede zugewiesene Anycast-Adresse gibt es ein längstes Adress-Prefix P, das den topologischen Bereich kennzeichnet, in dem alle Schnittstellen, die zu dieser Anycast-Adresse gehören, liegen. Mögliche Verwendungen der Anycast-Adressen sind, den Satz an Routen zu kennzeichnen, die zu einem bestimmten Unternetz hin zugefügt sind oder den Satz an Routern, die Zugang zu einer bestimmten Routing-Domäne zur Verfügung stellen. Pakete, die an die Unternetz-Router-Anycast-Adresse gesendet werden, werden an einen Router in dem Unternetz ausgeliefert. Die Unternetz-Router-Anycast-Adresse ist vorgesehen, für Anwendungen verwendet zu werden, in denen ein Knoten mit einem von einem Satz Routern in einem entfernten Unternetz kommunizieren muss. Zum Beispiel, wenn ein mobiler Host mit einem der mobilen Agenten in seinem „Heimat"-Unternetz kommunizieren muss.
Im Moment jedoch kann Anycast-Adressierung im IPv6 nur von Unternetz-Routern verwendet werden, da Lösungen für eine generische Anycast-Verwendung für IP-Hosts im Moment nicht definiert ist. Zusätzlich ist die Verwendung von Anycast-Adressierung mit den bestehenden Verfahren für verbindungsorientierte Dienste (zum Beispiel Dienste, die TCP-Transport verwenden) nicht möglich, da die aktuelle IPv6-Spezifikation die Verwendung von Anycast-Adressen als Quelladresse in einem IP-Paket verbietet. Falls Anycast-Adressierung verwendet wurde, würde das nächste Paket von dem Client an die gleiche Server-Anycast-Adresse adressiert werden, könnte aber aufgrund des Anycast-Adressierungsverfahrens an einen anderen Server ausgeliefert werden. Deshalb muss der Server mit einer realen IPv6-Schnittstellenadresse als der IPv6-Quelladresse antworten. Dies jedoch würde den TCP-Verbindungsaufbau unterbrechen, der tatsächlich nicht weiß, dass die Anycast-Adresse eine Anycast-Adresse ist (Anycast-Adressen sehen ähnlich wie normale Unicast-Adressen aus) und er erwartet das Antwortpaket von der ursprünglichen Zieladresse der Verbindungsaufbaunachricht.
Ein anderes Problem bei Anycast-adressierten Diensten besteht in der Frage der Autorisierung: wie weiß der Client, der die Dienstanforderungen initiiert, dass der Server, der auf die Anycast-adressierte Anforderung antwortet, tatsächlich hierzu autorisiert ist? Ein bösartiger Server könnte dem Anycast-adressierten Verkehr auf dem Link belauschen oder unmittelbar dem Client antworten, wobei er vortäuscht, der echte Server zu sein und könnte einen Mann-in-der-Mitte-Angriff (bzw. Man-In-The-Middle-Attack) einrichten.
ZUSAMMENFASSUNG DER ERFINDUNG
Es ist eine Aufgabe der vorliegenden Erfindung, ein Verfahren und ein System bereitzustellen zum Adressieren einer Datenquelle in einem Datennetzwerk mittels denen eine Anycast-Server-Adressierung und -Autorisierung umgesetzt werden kann.
Diese Aufgabe erreicht durch ein Verfahren zum Adressieren einer Datenquelle in einem Datennetzwerk durch Verwenden einer Anycast-Adresse, die mehr als einer Schnittstelle zugeordnet ist, wobei das Verfahren umfasst die Schritte:
Bestimmen der Datenquelle in dem Datennetzwerk als einen möglichen Empfänger für Datenverkehr für die Anycast-Adresse;
Abbilden der Anycast-Adresse auf eine reale Adresse der Datenquelle; und
Bereitstellen einer Bindungsaktualisierungsfunktion (bzw. Binding Update Funktion) zum Aufrechterhalten bzw. Verwalten einer Abbildung zwischen der Anycast-Adresse und der realen Adresse der Datenquelle zwischen der Datenquelle und entweder einem Client oder einem Netzwerkknoten mit einer Anycast-Agentenfunktionalität, oder beidem.
Darüber hinaus wird die obige Aufgabe gelöst durch ein System zum Adressieren einer Datenquelle in einem Datennetzwerk durch Verwenden einer Anycast-Adresse, die mehreren als einer Schnittstelle zugeordnet ist, wobei das System umfasst:
Abbildungsmittel zum Abbilden bzw. Verwalten der Anycast-Adresse auf die reale Adresse der Datenquelle; und
Bindungsaktualisierungsmittel zum Bereitstellen einer Bindungsaktualisierungsfunktion zum Aufrechterhalten bzw. Verwalten einer Adress-Beziehung zwischen einem Client, der die Anycast-Adresse und die Datenquelle verwendet hat.
Zusätzlich wird die obige Aufgabe gelöst durch einen Netzwerkknoten zum Adressieren einer Datenquelle in einem Netzwerk durch Verwenden einer Anycast-Adresse, die mehreren als eine Schnittstelle zugeordnet ist, wobei der Netzwerkknoten umfasst Bindungsaktualisierungsmittel zum Bereitstellen einer Bindungsaktualisierungsfunktion zum Aufrechterhalten bzw. Verwalten einer Adress- Beziehung zwischen einem Client, der die Anycast-Adresse und die Datenquelle verwendet hat.
Entsprechend müssen Dienstanwender die Identität eines individuellen Servers nicht kennen, wenn sie eine Dienstanforderung initiieren, das heißt eine TCP-Verbindungsanforderung, sondern können die Dienstanforderung an jede Anycast-Adresse adressieren, die alle die Server für den fraglichen Dienst repräsentiert. Der Anycast-Adressierungsmechanismus wird dann die Dienstanforderung an den nächsten Server liefern, der den Dienst zur Verfügung stellt.
Gemäß einer vorteilhaften Weiterentwicklung sind die Abbildungs- und/oder Bindungsaktualisierungsfunktion durch Verwendung von Merkmalen bzw. Fähigkeiten oder Signalisierung des mobilen IP-Protokolls bzw. (Mobile IP Protocol) umgesetzt. Insbesondere können die Merkmale des mobilen IP-Protokolls umfassen eine Heimatadressenzieloption, eine Bindungsaktualisierungszieloption, eine Bindungsbestätigungszieloption und einen mobilen IP-Routing-Kopf bzw. (Routing Header). Die Bindungsaktualisierungsfunktion kann ein Verfahren für Adressabbildungsautorisierung einschließen. Darüber hinaus kann die mobile Verwaltungsfunktion des mobilen IP verwendet werden, um Clients von einer Datenquelle zu einer anderen oder von einer Netzwerkschnittstelle oder Link zu einer bzw. einem anderen zu übergeben.
Für den Fall, dass die Bindungsaktualisierungsfunktion an dem Netzwerkknoten mit der Anycast-Agentenfunktionalität durchgeführt wird, kann die Datenquelle mit dem Netzwerkknoten verbunden werden, um seine Verfügbarkeit bekannt zu machen. Die Bindung kann durchgeführt werden mittels der mobilen IP-Heimatbindungsprozedur (bzw. Mobile IP Home Binding Procedure). Darüber hinaus können durch den Netzwerkknoten Mehrfachbindungen für dieselbe Anycast-Adresse zu verschiedenen Datenquellen aufrechterhalten werden. Die Datenquelle kann Bindungen über mehrere verschiedene IP-Adressen initiieren. Die Anycast-Adresse kann zu dem Netzwerkknoten geroutet bzw. geleitet werden, entsprechend einer Anycast-Gruppe, die durch die Anycast-Adresse definiert ist, und eine Datenquelle, die sich der Anycast-Gruppe anschließen will, kann eine Bindungsaktualisierungsnachricht an den Netzwerkknoten senden. Dies kann gelöst werden durch Verwenden einer getrennten Unicast- oder Multicast- Adresse für die Bindungsaktualisierungsnachricht. Als eine Alternative kann das mobile IP-dynamische Heimatagentenausforschungsverfahren (bzw. Mobile IP Dynamic Home Agent Discovery) verwendet werden, um die Adresse des Netzwerkknotens zu bestimmen.
Darüber hinaus kann eine Dienstübergabe bzw. -Handover von einem fehlgeschlagenen Link zu einem aktiven durch eine neue Bindungsaktualisierung zu dem Netzwerkknoten und/oder zu den Clients durchgeführt werden. Eine Auslastungs- oder Kapazitätsinformation, die durch die Bindungsaktualisierungsfunktion bereitgestellt wird, oder eine Netzwerktopologieinformation kann verwendet werden zum Auswählen einer Datenquelle für einen Client, der eine Anforderung sendet. Zusätzlich kann eine Bindungsaktualisierung mit Null-Lebensdauer an den Netzwerkknoten für jede Bindung, die durch eine Datenquelle initiiert ist, gesendet werden, falls die Datenquelle abgeschaltet werden muss.
Mehrere der Netzwerkknoten können verwendet werden, um die Anycast-Adresse zu bedienen und eine Anycast-Adressauslieferung kann verwendet werden, um einen der mehreren Netzwerkknoten für eine Anycast-adressierte Dienstanforderung zu erreichen. Eine der vielen Netzwerkknoten kann eine empfangene Bindungsinformation mit anderen der mehreren Netzwerkknoten synchronisieren.
Darüber hinaus kann eine Zwischenspeicherung einer Client-zu-Server-Zuordnung gelöscht werden, die keine Datenpakete an die Datenquelle über den Netzwerkknoten senden. Der Netzwerkknoten kann Datenquellen, die durch die Anycast-Adresse adressiert sind, überwachen, um eine Failover- bzw. Ausfallsicherungsunterstützung bereitzustellen.
Eine Kurzzeitregistrierung kann zur Verfügung gestellt werden dadurch, dass sich die Datenquelle periodisch an dem Netzwerkknoten registriert oder dass der Netzwerkknoten Bindungs-Anforderungen an die Datenquelle sendet. Der Netzwerkknoten kann annehmen, dass die Datenquelle abgeschaltet ist, sobald er keine Datenpakete über einen Rücktunnel für Antwortpakete von der Datenquelle enthält und er dies durch Senden einer Bindungsanforderung an die Datenquelle überprüft. Eine Dienstanforderung an eine Anycast-Adresse von einem Client kann an verschiedene Datenquellen gerichtet werden, falls der Client mit einer fehlgeschlagenen Datenquelle an derselben Anycast-Adresse am Kommunizieren war.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Im Folgenden wird die vorliegende Erfindung in größerem Detail basierend auf den bevorzugten Ausführungsbeispielen unter Bezugnahme auf die begleitenden Zeichnungsfiguren beschrieben, in denen
1 ein Szenario eines mobilen IP-Schemas für Anycast-Serveradressierung gemäß einem ersten bevorzugten Ausführungsbeispiel zeigt;
2 ein Szenario einer Server-Registrierung mit einem Anycast-Agenten gemäß einem zweiten bevorzugten Ausführungsbeispiel zeigt; und
3 ein Szenario des mobilen IP-Schemas für Anycast-Serveradressierung mit dem Anycast-Agenten gemäß dem zweiten bevorzugten Ausführungsbeispiel zeigt.
BESCHREIBUNG DES BEVORZUGTEN AUSFÜHRUNGSBEISPIELS
Die bevorzugten Ausführungsbeispiele der vorliegenden Erfindung werden nun basierend auf einer neuen Verwendung des mobilen IP-Protokolls in Verbindung mit Anycast-adressierten Diensten beschrieben, die verbindungsorientiert sein können.
Das Autorisierungsproblem kann gelöst werden mit dem IPsec-Merkmal durch den Server, der einen Beweis bereitstellt dafür, dass er tatsächlich autorisiert ist, auf die Anforderung, die an die Anycast-Adresse adressiert ist, zu antworten.
Der Sicherheitsaspekt der vorliegenden Erfindung basiert auf einem Schlüsselaustausch, wie in der mobilen IPv6-Spezifikation vorgeschlagen. Während ein mobiler Knoten des mobilen IPv6 Bereitstellung eines Beweises benötigen, dass er autorisiert ist, die behauptete Heimatadresse zu verwenden, benötigt ein Any cast-Server die Bereitstellung eines Beweises, dass er autorisiert ist, die Anycast-Adresse zu verwenden.
Um dies zu erreichen, sind die Anycast-adressierten Server angepasst, ihre echte Unicast-IPv6-Adresse („care-of-address") an die Anycast-Adresse („Heimatadresse") zu binden. Zum Beispiel kann dies erreicht werden durch Verwendung der entsprechenden mobilen IP-Spezifikationsmerkmale. Die Bindungsaktualisierung (bzw. Binding Update) ist in dem ersten Paket enthalten, das als Antwort auf die Anycast-adressierte Dienstanforderung gesendet wurde. In dasselbe Paket fügt der Server eine Heimatadressenzieloption (bzw. Home Address Destination Option) ein, die die Anycast-Adresse enthält und verwendet die echte Schnittstellen-IPv6-Adresse als die Quelladresse in dem Paket. Dann empfängt der Client (der „korrespondierende Knoten") die Antwort, die Heimatadressoption wird verarbeitet, wobei dem TCP-Stack (als Beispiel) ermöglicht wird, weitere die ursprüngliche Anycast-Adresse zu verwenden, wie durch die aktuellen TCP-Spezifikation erfordert.
Als nächstes würde der Client (der „korrespondierende Knoten") die Bindungsaktualisierung verarbeiten, wobei er einen Eintrag in einen Bindungszwischenspeicher (bzw. Binding Cache), der die Anycast-Adresse auf die echte IPv6-Adresse des Servers abbildet, erzeugt. Es sei angemerkt, dass diese Bindung für den betroffenen Client privat ist und benachbarte Clients Bindungen zu unterschiedlichen Servern besitzen können, während sie den Dienst adressieren, der die gleiche Anycast-Adresse verwendet. Die Bindung wird gesichert durch einen Authentisierungskopf (bzw. Authentication Header), der wie durch das mobile IP-Protokoll gefordert, enthalten ist. Alle Sicherheitsaspekte werden in Übereinstimmung mit dem mobilen IP-Protokoll gehandhabt. Das nächste (zum Beispiel TCP)-Paket, das an den Server zu senden ist, würde dann die Bindungsbestätigung (falls seitens des Servers angefordert) enthalten.
1 zeigt ein Beispielsszenario für eine Anycast-Adressierung gemäß dem ersten bevorzugten Ausführungsbeispiel. Zwei Clients C₁ 11 und C₂ 12 sind über ein IP-Netzwerk 4 mit einem Router 5 verbunden, der eingerichtet ist, einen Anycast-Link zu Datenquellen aufzubauen, wie zum Beispiel drei Servern S₁ bis S₃ 21 bis 23 oder ähnlichem. In 1 initiiert ein Client C₁ 11 Kommunikation über den Router 5 an einer Anycast-Adresse A. Falls TCP verwendet wird, würde dies eine TCP SYN-Nachricht und möglicherweise Daten einschließen. Der Client C₁ 11 empfängt eine Nachricht von einem Server S₁ 21, die sowohl eine Heimatadresszieloption als auch eine Bindungsaktualisierungs-Zieloption enthält. Falls TCP verwendet wird, würde dies eine ACK-Nachricht und eine SYN-Nachricht und möglicherweise Daten einschließen. Der Client C₁ 11 antwortet mit einem Paket, welches direkt an den Server S₁ 21 gesendet wurde, einschließlich einer Bindungsbestätigungszieloption (falls durch den Server angefordert) und einem Routing-Header bzw. Routing-Kopf, zum Beispiel den durch das mobile IP-spezifizierten Routing-Header, der die Anycast-Adresse A enthält. 1 zeigt auch einen anderen Client C₂ 12, der mit einem anderen Server S₂ 22 kommuniziert, wobei dieselbe Anycast-Adresse A verwendet wird.
Da das mobile IPv6 vorgesehen ist, die Mobilität eines mobilen Knotens aufrechtzuerhalten, kann der Server (der einen mobilen Knoten darstellt), der den Dienst zur Verfügung stellt, auch mobil sein. Zusätzlich könnte die Mobilitätsverwaltungsfunktion (bzw. Mobility Management Function) verwendet werden, um Clients von einer Schnittstelle oder einem Link zu einer anderen, oder von einem Server zu einem anderen (zum Beispiel zur Ausgleichung der Auslastung, um den Server für Wartungsarbeiten abzuschalten und so weiter) zu übergeben.
Oben wurde angenommen, dass es in dem IP-Router 5 natives Anycast-Routing gibt, wobei die Anycast-adressierte Dienstanforderung an jeden der Server S₁ 21 bis S₃ 23, die den Dienst bereitstellen, geliefert wird. Jedoch würde dies mit den aktuellen Verfahren typischerweise eine manuelle Router-Konfiguration erfordern, die sowohl fehleranfällig sein kann, als auch nicht notwendigerweise auf Serverauslastungssituationen und so weiter reagieren kann. Die Lösung, in der auf den Servern S₁ 21 bis S₃ 23 aktuelle Routing-Protokolle laufen würden, um die Anycast-Leitwege bekannt zu machen, während möglich, wäre nicht praktisch, da die Servercomputer typischerweise nicht mit Routing-Protokollstacks konfiguriert sind, und vielleicht nicht betraut werden können, um Leitwege zu dem Netzwerk 4 einzufügen. Auch, wenn nur „natives" Anycast-Routing verwendet wird, sind die Anforderungen für Bindungsaktualisierungserzeugung und – verarbeitung, wie oben beschrieben streng: falls nicht befolgt, kann der Dienstaufbau fehlschlagen.
Um die oben erkannten Probleme zu lösen, umfasst das zweite bevorzugte Ausführungsbeispiel einen Netzwerkknoten (Anycast Agent 6) mit einer Anycast-Agentenfunktionalität (ähnlich dem „Heimatagenten" bzw. „Home Agent") des mobilen IPv6, die zu der Anycast-Architektur hinzugefügt ist. 2 zeigt ein Szenario eines Servers, der sich bei dem Anycast-Agenten 6 registriert. Im Vergleich zu 1 wurde der Router 5 durch den Anycast-Agenten 6 ersetzt, der zwischen einem ersten Netzwerkteil oder Netzwerk 41 oder einem zweiten Netzwerkteil oder Netzwerk 42 angeordnet ist. Jeder einzelne der Server S₁ 21 bis S₃ 23 würde eine Bindung mit dem Anycast-Agenten 6 herstellen, um den Anycast-Agenten wissen zu lassen, dass er verfügbar ist. Eine Bindungsprozedur, wie zum Beispiel die Standard-Heimatbindungsprozedur des mobilen IP (bzw. Mobile IP Home Binding Procedure) kann zu diesem Zweck verwendet werden. Ein wesentlicher Unterschied liegt in der Tatsache, dass der Anycast-Agent mehrere gleichzeitige Bindungen für dieselbe Anycast-Adresse aufrechterhalten würde, die an unterschiedliche Server-IP-Adressen gebunden sind.
Zusätzlich kann derselbe Server Bindungen über mehrere unterschiedliche IP-Adressen initiieren, die unterschiedliche physikalische Schnittstellen repräsentieren, und mögliche Links, und ganze Routen, um eine Fehlertoleranzmaßnahme für den Dienstzugriff zur Verfügung zu stellen. In diesem Szenario wird auch möglich, Dienste von fehlgeschlagenen Links auf aktive Links mittels einer neuen Bindungsaktualisierung zu dem Anycast-Agenten 6 und/oder zu dem Clients („korrespondierende Knoten"), zu übergeben.
Bei diesem Anycast-Agenten-Szenario wird die betroffene Anycast-Adresse durch die (anderen) Routen zu dem Anycast-Agenten, der die „Anycast-Gruppe", die durch diese Adresse definiert wird, verwaltet, geroutet bzw. geleitet. Die einzelnen Server, die wünschen, sich der Anycast-Gruppe anzuschließen, werden dann eine Bindungsaktualisierungs-Nachricht an den Anycast-Agenten 6 senden, wobei möglicherweise die Anycast-Adresse selbst als die Zieladresse der Bindungsaktualisierung verwendet wird. Alternativ könnte eine separate Unicast- oder Multicast-Adresse für die Heimatbindungsaktualisierungen verwendet werden. Optional könnte ein dynamisches Heimatagentenausforschungsverfahren (bzw. Dynamic Home Agent Discovery Method), zum Beispiel das dynamische Heimatagentenausforschungsverfahren des mobilen IPv6, verwendet werden, um die Anycast-Agentenadresse herauszufinden. Wenn das Paket zu dem Anycast-Agenten 6 gelangt, wird er die Heimatbindung in dem Paket erkennen und diese zum Beispiel, wie ein mobiler IPv6-Heimatagent verarbeiten, aber mehrere Bindungen für jede unterschiedliche Anycast-Adresse aufrechterhalten.
Zusätzlich können die Server S₁ 21 bis S₃ 23 bestimmte Optionen in der Bindungsaktualisierung enthalten, die dem Anycast-Agenten 6 über Informationen betreffend Auslastung, Kapazität, etc. des Dienstes bzw. der Dienste, die durch den Server bereitgestellt werden, informieren. Dies könnte durch den Anycast-Agenten 6 beim Entscheiden, welchen Server er jedem Client zuordnet, zunutze gemacht werden. Der Anycast-Agent 6 könnte außerdem die Informationen über die Netzwerktopologie verwenden, die ihm vorliegen können, wenn er einen Server für einen Client, der eine Anforderung sendet, auswählt.
Falls ein individueller Server abgeschaltet werden muss (für Reparatur und so weiter) wird eine Bindungsaktualisierung, zum Beispiel die Bindungsaktualisierung des IPv6 (bzw. Mobile IPv6 Binding Update), mit einer Null-Lebensdauer an den Anycast-Agenten 6 gesendet und an jeden Client, mit dem eine Bindung durch den betroffenen Server aufgebaut worden ist. Auch könnten individuelle Schnittstellen von den Servern mittels derselben Methode abgeschaltet werden.
Es ist zu bemerken, falls es nur einen Anycast-Agenten gibt, dass keine echte auf Anycast-Adressierung basierende Routing-Auslieferung, verwenden wird. Jedoch könnte es mehrere Anycast-Agenten geben, die dieselbe Anycast-Adresse bedienen und Anycast-Adressauslieferung würde in diesem Fall, verwendet werden, um einen Anycast-Agenten für jede Anycast-adressierte Dienstanforderung zu erreichen. Falls mehrere Anycast-Agenten verwendet werden, um dieselbe Anycast-Adresse zu bedienen, müsste sich der Anycast-Agent, der die „Heimatbindung" von dem Server empfängt, mit dieser Bindungsinformation mit anderen Anycast-Servern synchronisieren, da jeder der Agenten Anycastadressierte Serviceanforderungen für die betroffene Anycast-Adresse empfangen kann.
3 zeigt ein Beispielszenario für eine Anycast-Adressierung für einen Anycast-Agenten 6. Der Anycast-Agent 6 empfängt die Anycast-adressierten Dienst anforderungen, die von Clients gesendet wurden, zum Beispiel dem Client C₁ 11 (3, Schritt 1). Er konsultiert dann seine Bindungsdatenbank, die möglicherweise zusätzliche Informationen enthält (Auslastung, Kapazität, Netzwerktopologie) und wählt einen Server aus, an den die Anforderung weiterzuleiten ist, zum Beispiel den Server S₁ 21 (3, Schritt 2). Zum Beispiel können alle üblichen Verfahren für Heimatagenten des mobilen IPv6 zum Ausliefern von Datagrammen an mobile Knoten (zum Beispiel IP-in-IP-Tunneln) für die Anforderungsauslieferung verwendet werden. Der Anycast-Agent 6 müsste die Client/Server-Abbildung für einige Zeit zwischenspeichern bzw. cachen, da der Client nicht in der Lage sein könnte, die seitens des gewählten Server gesendeten Bindungsaktualisierungen, in einer zeitgerechten Weise (oder überhaupt) zu verarbeiten. Dies bedeutet, dass mehrere Pakete von dem Client an denselben Server ausgeliefert werden könnten, über den Anycast-Agenten 6, aber sobald die Bindungsaktualisierung seitens des Clients verarbeitet wird, wird der Anycast-Agent 6 von der Paketauslieferungsroute bzw. Paketauslieferungsleitweg von dem Client C₁ 11 an den Server S₁ 21 (3, Schritt 4) abgeschnitten. Dies lockert die Anforderung seitens des Clients C₁ 11, unmittelbar die Bindungsaktualisierung, die seitens des Servers S₁ 11 gesendet wurde, zu verarbeiten. In jedem Fall wird der Server S₁ 21 die Heimatadresszieloption einfügen und ein Antwortpaket an den Client C₁ 11 direkt (3, Schritt 3) ausliefern, falls kein bestimmter Grund vorliegt, die Antworten über den Anycast-Agenten 6 auszuliefern. Die Heimatadresszieloption erlaubt dem Client C₁ 11, die ankommenden Pakete der Anycast-Adresse zuzuordnen, die verwendet wurde, als die Startanforderung ausgesendet wurde.
Die Zwischenspeicherung (bzw. das Caching) der Client-zu-Server-Zuordnung kann für Clients gelöscht werden, die keine Pakete an einen Server über den Anycast-Agenten 6 senden. Diese Situation kann als eine von zwei Arten interpretiert werden: 1) Der Client hat eine Bindungsaktualisierung mit dem Server bearbeitet und kommuniziert mit den Server direkt, oder 2) der Client greift auf den Dienst nicht mehr zu. Zusätzlich könnte für verbindungsorientierte Transportprotokolle der Anycast-Agent 6 die Verbindungsbeendung zwischen dem Client und dem Server erkennen und die Zuordnung an diesem Punkt löschen. Jede neue Verbindung zu demselben Anycast-Dienst könnte dann direkt zu anderen Servern geleitet werden.
Zusätzlich kann der Anycast-Agent 6 eine Fehlertoleranz- und Ausfallsicherungsunterstützung bereitstellen durch Überwachung der Server S₁ 21 bis S₃ 23. Dies kann erreicht werden auf die folgenden Weisen:

1) In dem nur Kurzzeitregistrierungen (Bindungen bzw. Bindings) angenommen werden, die erfordern, dass sich die Server S₁ 21 bis S₃ 23 periodisch registrieren (angenommen, dass Dienstprozess die gesendeten Bindungsaktualisierungen steuern kann). Alternativ durch Senden von Bindungsanforderungen an den Server, wann immer dem Anycast-Agenten 6 danach ist, die Verfügbarkeit eines Servers zu überprüfen.
2) Indem die Server S₁ 21 bis S₃ 23 aufgefordert wurden, initiale Dienstantwortpakete über den Anycast-Agenten 6 zu tunneln. Falls der Anycast-Agent 6 keinerlei Pakete über diesen Rücktunnel erhält, wird er vermuten, dass der betroffene Server abgeschaltet ist. Der Anycast-Agent 6 könnte dies überprüfen durch Sendens einer bestimmten Bindungsanforderung an den betroffenen Server, um zu überprüfen, ob der Server antwortet. Falls der Server abgeschaltet ist, wird seine Bindung entfernt, so dass keine Clients mehr an den fehlgeschlagenen Server geleitet werden. Falls ein Client mit einem fehlgeschlagenen Server am Kommunizieren war, wird seine nächste Dienstanforderung an dieselbe Anycast-Adresse an einen anderen Server, falls verfügbar, geleitet.

Mittels reverser Tunneln von einem Server (S₁ 21 bis S₃ 23) an den Anycast-Agenten 6 ist es möglich, Pakete an den Client (C₁ 11, C₂ 12) auszuliefern ohne die Heimatadressoption einzufügen und ohne die Anycast-Adresse als die Quelladresse in diese Pakete einzufügen. Es ist außerdem möglich, die Heimatadressoption wegzulassen und die Anycast-Adresse als die Paketquelladresse ohne reverse Tunneln zu verwenden, falls der Anycast-Agent 6 (oder eine Gruppe von koordinierten Anycast-Agenten) eine stimmige Auslieferung der Pakete von einem bestimmten Client an denselben Server einrichtet und falls das Netzwerk, das die Server enthält, den Servern ermöglicht, die Anycast-Adresse als eine Paketquelladresse zu verwenden.
Noch eine andere Alternative zum Überprüfen der Serververfügbarkeit besteht in einer periodischen Abfrage (bzw. periodischen Polling) der Verfügbarkeit von jedem registrierten Server S₁ 21 bis S₃ 23. Das Polling kann durchgeführt werden indem der Verfügbarkeit des Knotens selbst innerhalb des Netzwerks oder eines Dienstes, der der Anycast-Adresse entspricht, überprüft wird.
Eine Möglichkeit zum Überprüfen der Verfügbarkeit des Knotens innerhalb des Netzwerks besteht in der ICMP (Internetsteuernachrichtenprotokoll bzw. Internet Control Message Protocol)-Echoprozedur. Die ICMP ist ein Teil des IP, die verwendet wird, um Fehler und Steuernachrichten auf der IP Schicht zu bearbeiten. Die Überprüfung der Verfügbarkeit eines Dienstes in dem Knoten kann unter Verwendung anwendungsspezifischer Mittel durchgeführt werden.
Der Anycast-Agent 6 kann oben auf einer Routerplattform aufgesetzt werden, wobei möglicherweise die Umsetzung ausgehend von einer bestehenden Heimatagentenimplementierung des mobilen IP beginnt. Die Netzwerkserver können als „mobile Knoten" konfiguriert werden, wobei die Anycast-Adresse als Heimatadresse verwendet wird und sowohl dieselbe Anycast-Adresse als auch die Anycast-Agenten-Adresse oder eine separate IP-Adresse als die Anycast-Agenten-Adresse verwendet wird. Optional könnte das dynamische Heimatagentenausforschungsverfahren des mobilen IPv6 verwendet werden, um die Anycast-Agenten-Adresse herauszufinden. Sobald die Dienstclients die Antwortpakete von dem Anycast-adressierten Server empfangen, wird das Paket mit der Heimatadressoption und (optional) der Bindungsaktualisierung ausgestattet. Im Falle der Verwendung der Signalisierung des mobilen IP sieht dies für den Dienstclient wie gewöhnliches mobiles IP aus und er wird sich entsprechend verhalten. Falls der Client die Bindungsaktualisierung nicht verarbeitet, werden alle Pakete von ihm an den Server durch den Anycast-Agenten 6 gehen, der die Zuordnung zu dem gewählten Server aufrecht erhält, sodass die Pakete von einem bestimmten Client an denselben Server gehen werden.
Zusammenfassend löst die vorliegende Erfindung das adressierungs- und autorisierungsbezogene Problem, dadurch dass der Serverknoten mit der echten Adresse als die Quelladresse antwortet. Das Paket umfasst außerdem eine Heimatadresszieloption und eine Bindungsaktualisierungszieloption. Der Client setzt in die Quelladresse die Anycast-Adresse ein, die in den Heimatadresszieloptionen transportiert wird. Dann wird das Paket an höhere Protokollschichten über geben. Ein Antwortpaket von dem Client an den Serverknoten wird direkt an den Serverknoten gesendet, wobei das Paket eine Bindungsbestätigungszieloption und einen Routingheader enthält. Der Routingheader enthält die Anycast-Adresse. Alternativ kann ein Anycast-Agent 6 im Netzwerk vorgesehen sein. Pakete, die an die Anycast-Adresse adressiert sind, werden durch den Anycast-Agenten 6 empfangen. Der Anycast-Agent 6 wählt unter den Serverknoten aus, die zu der Anycastgruppe gehören. Die Serverknoten werden an der Anycast-Gruppe registriert, unter Verwendung einer Bindungsprozedur. Darüber hinaus schließt die Erfindung die Idee der Verwendung von Auslastungsausgleich über den Anycast-Agenten ein. Der Anycast-Agent kann periodisch Re-Registrierungen oder anfordern, um den Status der Serverknoten zu bestimmen.
Während die vorliegende Erfindung für IPv6 mobiles IPv und verbindungsorientierte Dienste (z.B. TCP Transport) beschrieben worden ist, ist das Verfahren genauso gut auf andere Fälle anwendbar. Beispiele für andere geeignete Fälle/Szenarios schließen Dienste ein, die unterschiedliche Transportprotokolle (wie z.B. Media-Streaming, NFS, und so weiter, die UDP, SCTP, RTP etc. verwenden) und alle möglichen zukünftigen Versionen einschließen. Von jeder Erweiterung oder Modifikation des mobilen IP-Protokolls wird erwartet, dass es mit dieser Lösung arbeitet. Die erwähnten Mechanismen des mobilen IP sind lediglich als Beispiele genannt worden. Darüber hinaus ist die Erfindung nicht vom mobilen IP abhängig, sondern deckt Signalisierungsverfahren ab, in denen Anycast-Server optional sich an Netzwerkgeräten registrieren können, um mögliche Empfänger für Anycast-Verkehr für eine bestimmte Anycast-Adresse zu werden und in denen der Client die Anycast-Adresse auf die echte Adresse des Servers abbildet und optional diese Abbildung verwendet, um transparenten Gebrauch von der Anycast-Adresse zu machen. Der Anycast-Server kann Authentisierungsdaten für den Client bereitstellen, die einen Beweis zur Verfügung stellen, dass der Server in der Tat autorisiert ist, auf die verwendete Anycast-Adresse zu antworten. Dieser Beweis kann entweder direkt zwischen dem Server und dem Clienten bereitgestellt werden oder via Zwischenknoten oder Systeme, wie zum Beispiel einem DNS (Domain Name System), Zertifizierungsautoritäten etc.
Jedoch deckt diese Erfindung zusätzlich die Verwendung des mobilen IP Protokolls (v4, v6) für diesen Zweck ab.

Claims

Verfahren zum Adressieren einer Datenquelle (21 bis 23) in einem Datennetzwerk durch Verwendung einer Anycast-Adresse, die mehr als einer Schnittstelle zugeordnet ist, wobei das Verfahren die Schritte umfasst: a) Bestimmen der Datenquelle (21 bis 23) in dem Datennetzwerk als möglicher Empfänger für Datenverkehr für die Anycast-Adresse; und wobei das Verfahren dadurch gekennzeichnet ist, dass es weiter die Schritte umfasst: b) Abbilden der Anycast-Adresse auf eine reale Adresse der Datenquelle (21 bis 23); und c) Bereitstellen einer Verbindungsaktualisierungsfunktion zum Aufrechterhalten einer Zuordnung zwischen der Anycast-Adresse und der realen Adresse der Datenquelle (21 bis 23) zwischen der Datenquelle (21 bis 23) und entweder einem Client (11, 12) oder einem Netzwerkknoten (6) mit einer Anycast-Agenten-Funktionalität, oder beidem.
Verfahren gemäß Anspruch 1, wobei der Zuordnungsschritt und/oder die Verbindungsaktualisierungsfunktion durch Verwendung von Fähigkeiten des mobilen IPv6-Protokolls umgesetzt sind.
Verfahren gemäß Anspruch 2, wobei die Fähigkeiten des Protokolls Mobile IPv6 umfassen eine Heimatadressenzieloption, eine Verbindungsaktualisierungszieloption, eine Verbindungsbestätigungszieloption und einen Routing-Header des Mobile IPv6.
Verfahren gemäß Anspruch 2 oder 3, wobei die Verbindungsaktualisierungsfunktion ein Verfahren zur Adresszuordnungsautorisierung enthält.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei eine Mobilitätsverwaltungsfunktion des Mobile IP verwendet wird, um Clients von einer Datenquelle an eine andere oder von einer Netzwerkschnittstelle oder Verbindung zu einer anderen zu übergeben.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei sich die Datenquelle (21 bis 23) mit dem Netzwerkknoten (6) verknüpft, um ihre Verfügbarkeit anzuzeigen.
Verfahren gemäß Anspruch 6, wobei das Verknüpfen durch die Heimatverbindungs-Prozedur des Mobile IP durchgeführt wird.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei mehrere Verbindungen für dieselbe Anycast-Adresse mit verschiedenen Datenquellen (21 bis 23) von dem Netzwerkknoten (6) verwaltet werden.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei die Datenquelle (21 bis 23) Verbindungen über mehrere verschiedene IP-Adressen initiiert.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei eine Dienstübergabe von einer fehlgeschlagenen zu einer betriebsbereiten Verbindung durch eine neue Verbindungsaktualisierung zu dem Netzwerkknoten (6) und/oder zu den Clients (11, 12) durchgeführt wird.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei die Anycast-Adresse zu den Netzwerkknoten (6) gemäß einer durch die Anycast-Adresse bestimmten Anycast-Gruppe geleitet wird und wobei eine Datenquelle, die wünscht, sich der Anycast-Gruppe anzuschließen, eine Verbindungsaktualisierungsnachricht an den Netzwerkknoten (6) sendet.
Verfahren gemäß Anspruch 11, wobei eine separate Unicast- oder Mulitcast-Adresse für die Verbindungsaktualisierungsnachricht verwendet wird.
Verfahren gemäß Anspruch 11, wobei das Dynamic Home Agent Discovery Verfahren des Mobile IP verwendet wird, um die Adresse des Netzwerkknoten (6) zu bestimmen.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei eine durch die Verbindungsaktualisierungsfunktion bereitgestellte Last- oder Kapazitätsinformation oder eine Netzwerktopologieinformation zum Auswählen einer Datenquelle (21 bis 23) für einen eine Anforderung sendenden Client (11, 12) verwendet wird.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei eine Verknüpfungsaktualisierung mit Null-Lebensdauer an den Netzwerkknoten (6) für jede Verbindung, die durch eine Datenquelle (21 bis 23) initiiert worden ist, gesendet wird, falls die Datenquelle (21 bis 23) es erfordert heruntergenommen zu werden.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei mehrere von dem Netzwerkknoten (6) verwendet werden, um die Anycast-Adresse zu bedienen, und wobei eine Anycast-Adressen-Zustellung verwendet wird, um einen von den mehreren Netzwerkknoten (6) für eine Anycast-adressierte Dienstanforderung zu erreichen.
Verfahren gemäß Anspruch 16, wobei der eine der mehreren Netzwerkknoten (6) eine empfangene Verbindungsinformation mit anderen von den mehreren Netzwerkknoten (6) synchronisiert.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei ein Zwischenspeichern einer Client-zu-Server-Zuordnung für Clients gelöscht wird, die keine Datenpakete an die Datenquelle (21 bis 23) über den Netzwerkknoten (6) senden.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei der Netzwerkknoten (6) Datenquellen (21 bis 23) überwacht, die durch die Anycast-Adresse adressiert sind, um eine Fehlertoleranz und/oder Ausfallsicherungsunterstützung bereitzustellen.
Verfahren gemäß einem der Ansprüche 5 bis 18, wobei die Datenquelle (21 bis 23) sich periodisch mit dem Netzwerkknoten (6) registriert oder der Netzwerkknoten (6) Verbindungsanfragen an die Datenquelle (21 bis 23j sendet, um eine kurzfristige Registrierung bereitzustellen, und wobei die Datenquelle als fehlgeschlagen oder als außer Dienst genommen angenommen wird, falls sie darin fehlgeschlagen hat, ihre Registrierung zu erneuern, was durch eine Verbindungsanforderung verifiziert wird.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei der Netzwerkknoten (6) annimmt, dass die Datenquelle (21 bis 23) abgeschaltet ist, wenn er nicht irgendwelche Datenpakete über einen Rückwärtstunnel für Antwortpakete von der Datenquelle (21 bis 23) empfängt, und dies durch Senden einer Verbindungsanforderung an die Datenquelle (21 bis 23) verifiziert.
Verfahren gemäß einem der Ansprüche 19 bis 21, wobei eine Dienstanforderung an eine Anycast-Adresse von einem Client (11, 12) an eine unterschiedliche Datenquelle gerichtet wird, falls der Client mit einer fehlgeschlagenen Datenquelle unter derselben Anycast-Adresse am Kommunizieren war.
Ein System zum Adressieren einer Datenquelle (21 bis 23) in einem Datennetzwerk durch Verwenden einer Anycast-Adresse, die mehreren als einer Schnittstelle zugeordnet ist, dadurch gekennzeichnet, dass das System umfasst: a) Abbildungsmittel (11, 12; 6) zum Abbilden der Anycast-Adresse auf die reelle Adresse der Datenquelle (21 bis 23); und b) Verbindungsaktualisierungsmittel (11, 12; 6) zum Aufrechterhalten einer Verbindung zwischen der Anycast-Adresse und der realen Adresse der Datenquelle (21 bis 23) zwischen der Datenquelle (21 bis 23) und entweder einem Client (11, 12) oder einem Netzwerkknoten (6) mit einer Anycast-Agenten-Funktionalität, oder beidem.
Ein System gemäß Anspruch 23, wobei die Zuordnungsmittel (11, 12; 6) und/oder die Verbindungsaktualisierungsmittel (11, 12; 6) eingerichtet sind, um eine Signalisierung des IP zu verwenden.
System gemäß Anspruch 23 oder 24, wobei die Verbindungsaktualisierungsmittel an einem Netzwerkknoten (6) mit einer Anycast-Agenten-Funktionalität bereitgestellt sind.
System gemäß Anspruch 25, wobei die Datenquelle (21 bis 23) eingerichtet ist, um sich mit dem Netzwerkknoten (6) zu verbinden, um seine Verfügbarkeit anzuzeigen.
System gemäß Anspruch 26, wobei die Datenquelle eingerichtet ist, die Verknüpfung durch Verwenden der Home Binding Prozedur des Mobile IP durchzuführen.
System gemäß einem der Ansprüche 25 bis 27, wobei die Datenquelle (21 bis 23) Mittel bereitstellt zum Initiieren von Verbindungen über mehrere verschiedene IP-Adressen.
System gemäß einem der Ansprüche 25 bis 28, wobei das System eingerichtet ist, die Anycast-Adresse an den Netzwerkknoten (6) gemäß einer durch die Anycast-Adresse bestimmten Anycast-Gruppe zu leiten.
System gemäß einem der Ansprüche 25 bis 29, wobei mehrere von dem Netzwerkknoten (6) bereitgestellt sind, um die Anycast-Adresse zu bedienen, und wobei das System eingerichtet ist, eine Anycast-Adressen-Zustellung zu verwenden, um einen der mehreren von dem Netzwerkknoten (6) für eine Anycast-adressierte Dienstanforderung zu erreichen.
System gemäß Anspruch 30, wobei einer von den mehreren Netzwerkknoten (6) eingerichtet ist, um eine empfangene Verbindungsinformation mit anderen von den mehreren Netzwerkknoten (6) zu synchronisieren.
System gemäß einem der Ansprüche 25 bis 31, wobei die Datenquelle (21 bis 23) eingerichtet ist, um sich periodisch mit dem Netzwerkknoten (6) zu registrieren oder der Netzwerkknoten (6) eingerichtet ist, um Verbindungsanforderungen an die Datenquelle (21 bis 23) zu senden, um eine kurzfristige Registrierung bereitzustellen.
System gemäß einem der Ansprüche 25 bis 32, wobei der Netzwerkknoten (6) eingerichtet ist, um eine Last- oder Kapazitätsinformation zu verwenden, die durch die Verbindungsaktualisierungsfunktion bereitgestellt ist, oder eine Netzwerktopologieinformation zum Auswählen einer Datenquelle (21 bis 23) für einen Client (11, 12), der eine Anforderung sendet.
System gemäß einem der Ansprüche 25 bis 33, wobei der Netzwerkknoten (6) eingerichtet ist, um mehrere Verbindungen für dieselbe Anycast-Adresse zu verschiedenen Datenquellen (21 bis 23) aufrechtzuerhalten.
Netzwerkknoten zum Adressieren einer Datenquelle (21 bis 23) in einem Datennetzwerk durch Verwenden einer Anycast-Adresse, die mehreren als einer Schnittstelle zugeordnet ist, dadurch gekennzeichnet, dass der Netzwerkknoten (6) umfasst Verbindungsaktualisierungsmittel zum Bereitstellen einer Verbindungsaktualisierungsfunktion zum Aufrechterhalten einer Abbildung zwischen der Anycast-Adresse und der realen Adresse von der Datenquelle (21 bis 23) zwischen der Datenquelle (21 bis 23) und entweder einem Client (11, 12) oder einem Netzwerkknoten (6) mit einer Anycast-Agenten-Funktionalität, oder beidem.
Netzwerkknoten gemäß Anspruch 35, wobei die Verbindungsaktualisierungsmittel eingerichtet sind, eine Signalisierung des Mobile IP zum Bereitstellen der Verbindungsaktualisierungsfunktion zu verwenden.
Netzwerkknoten gemäß Anspruch 35 oder 36, wobei der Netzwerkknoten (6) eingerichtet ist, Datenquellen (21 bis 23) zu überwachen, die durch die Anycast-Adresse adressiert sind, um eine Fehlertoleranz- und/oder Ausfallsicherungsunterstützung bereitzustellen.
Netzwerkknoten gemäß einem der Ansprüche 35 bis 37, wobei der Netzwerkknoten (6) eingerichtet ist, anzunehmen, dass die Datenquelle (21 bis 23) abgeschaltet ist, wenn er keine Datenpakete über einen Rücktunnel für Antwortpakete von der Datenquelle (21 bis 23) empfängt, und um dies durch Senden einer Verknüpfungsanforderung an die Datenquelle (21 bis 23) zu verifizieren.
Netzwerkknoten gemäß Anspruch 37 oder 38, wobei der Netzwerkknoten (6) eingerichtet ist, um eine Dienstanforderung an eine Anycast-Adresse von einem Klienten (11, 12) an eine andersartige Datenquelle zu richten, falls der Client mit einer fehlgeschlagenen Datenquelle an der selben Anycast-Adresse am Kommunizieren war.