DE112005003194B4

DE112005003194B4 - Verteilter Domain Name Service

Info

Publication number: DE112005003194B4
Application number: DE112005003194.2T
Authority: DE
Inventors: Anthony R. Metke; Robert D. LoGalbo; Aparna Pandey
Original assignee: Motorola Solutions Inc
Current assignee: Arris Enterprises LLC
Priority date: 2004-12-21
Filing date: 2005-11-18
Publication date: 2017-10-26
Anticipated expiration: 2025-11-19
Also published as: KR100987576B1; US20060135205A1; DE112005003194T5; WO2006068747A2; KR20070097531A; US7562148B2; WO2006068747A3

Abstract

Verfahren für verteiltes Domain Name Service (DNS) in einem drahtlosen Kommunikationsnetzwerk (100) mit den Schritten: Senden (408; 708) einer DNS Anfrage-Nachricht (208; 608) als Broadcast von einem ersten Knoten (102) an einen zweiten Knoten (108), wobei die DNS Anfrage-Nachricht (208; 608) einen Host-Namen des zweiten Knotens (108) und Informationen über den ersten Knoten (102) umfasst, wobei die Informationen mindestens eine einer Netzwerkadresse oder einer Media Access Control (MAC) Adresse aufweisen; Weiterleiten der DNS Anfrage-Nachricht (208; 608) von dem ersten Knoten (102) an den zweiten Knoten (108) durch Zwischenknoten (104, 106, 110, 114) in dem drahtlosen Kommunikationsnetzwerk (100); und Übertragen (508; 808) einer DNS Antwort-Nachricht (212; 612) von dem zweiten Knoten (108) an den ersten Knoten (102), wobei die DNS Antwort-Nachricht (212; 612) eine MAC-Adresse des zweiten Knotens (108) umfasst; Zuordnen (610, 804) einer an dem zweiten Knoten (108) zu speichernden lokalen Netzwerkadresse des ersten Knotens (102) durch den zweiten Knoten (108); Empfangen eines Datenpaketes an dem zweiten Knoten (108) durch (i) Bestimmen (908) ob die MAC-Adresse des ersten Knotens (102) in einer Adressübersetzungstabelle des zweiten Knotens (108) ist; (ii) Ersetzen einer Quellnetzwerkadresse von dem Datenpaket mit der lokalen Netzwerkadresse des ersten Knotens (102), wenn sie gefunden wird (910); (iii) Ersetzen (910) einer Zielnetzwerkadresse von dem Datenpaket mit der Netzwerkadresse des zweiten Knotens (108); und (iv) Übergeben (912) des Datenpaketes an einen Netzwerkstapel.

Description

Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich allgemein auf drahtlose Kommunikationssysteme und insbesondere auf das Gebiet des verteilten Domain Name Service in einem drahtlosen Netzwerk.
Hintergrund
Autonome Ad-hoc-Netzwerke sind Netzwerke, die keine Verbindung zu einer Infrastruktur haben und als solche keinen Zugang zu den Diensten haben, welche eine Infrastruktur bereitstellt, wie z. B. ein Server, der einen Domain Name Service (DNS) bereitstellt. Existierende auf dem Internet Protocol (IP) basierende Anwendungen sind auf einen DNS-Server angewiesen, um richtig zu funktionieren. Ohne Zugang zu einem DNS-Server können existierende IP-Anwendungen in einem Ad-hoc-Netzwerk nicht arbeiten. Da moderne Kommunikation zunehmend ad-hoc und mobil ist gibt es einen Bedarf danach, DNS-Funktionalität für ein Ad-hoc-Netzwerk bereitzustellen.
Dementsprechend existiert ein Bedürfnis nach einem Verfahren des Bereitstellens der DNS-Funktionalität für ein Ad-hoc-Netzwerk.
Mit dieser Problematik beschäftig sich auch das Dokument ENGELSTAD, P. A. [et al.]: Name Resolution in on-demand MANETS and over external IP Networks. Mobile Ad Hoc Networking Working Group, Internet Draft [online], Januar 2004 [recherchiert am 09.06.2011]. Im Internet: <URL:http://tools.ietf.org/html/draft-engelstad-manet-name-resolution-01>.
Ferner betrifft das Dokument PERKINS, C. E. [et al.]: Ad hoc On-Demand Distance Vector (AODV) Routing. Mobile Ad Hoc Networking Working Group, Internet Draft [online], November 2002 [recherchiert am 14.06.2011]. Im Internet: <URL:http://tools.ietf.org/html/draft-ietf-manet-aodv-12> die Verwendung des AODV-Routingprotokolls (AODV = Ad Hoc On-Demand Distance Vector) durch Mobilfunkknoten in einem Ad-Hoc-Netzwerk.
Kurze Beschreibung der Figuren
Die vorliegende Erfindung wird als Beispiel dargestellt und nicht als Beschränkung in den begleitenden Figuren, in denen gleiche Bezugszeichen gleiche Elemente bezeichnen, und in denen:
1 ein Beispiel eines einfachen Blockdiagramms ist, das ein drahtloses Kommunikationssystem gemäß einigen Ausführungsformen der Erfindung darstellt;
2 eine Nachrichtensequenz ist, die ein Verfahren für verteiltes DNS gemäß einigen Ausführungsformen der Erfindung darstellt;
3 ein Flussdiagramm für eine Funktion ist, die von einem Knoten in dem drahtlosen Kommunikationssystem gemäß einigen Ausführungsformen der Erfindung aufgerufen wird;
4 ein Flussdiagramm für die Funktionalität ist, die von einem Client in dem drahtlosen Kommunikationssystem gemäß einigen Ausführungsformen der Erfindung durchgeführt wird;
5 ein Flussdiagramm für die Funktionalität ist, die von einem Server in dem drahtlosen Kommunikationssystem gemäß einigen Ausführungsformen der Erfindung durchgeführt wird;
6 eine Nachrichtensequenz ist, die ein Verfahren für den verteilten DNS gemäß einigen Ausführungsformen der Erfindung darstellt;
7 ein Flussdiagramm für die Funktionalität ist, die von einem Client in dem drahtlosen Kommunikationssystem gemäß einigen Ausführungsformen der Erfindung durchgeführt wird;
8 ein Flussdiagramm für die Funktionalität ist, die von einem Server in dem drahtlosen Kommunikationssystem gemäß einigen Ausführungsformen der Erfindung durchgeführt wird; und
9 ein Flussdiagramm für die Funktionalität ist, die von einem Server in dem drahtlosen Kommunikationssystem gemäß einigen Ausführungsformen der Erfindung durchgeführt wird.
Fachleute werden einsehen, dass Elemente in den Figuren orientiert an der Einfachheit und Klarheit dargestellt sind und nicht notwendigerweise maßstabsgetreu gezeichnet wurden. Zum Beispiel können die Abmessungen einiger Elemente in den Figuren relativ zu den anderen Elementen übertrieben sein, um das Verständnis von Ausführungsformen der vorliegenden Erfindung zu fördern.
Detaillierte Beschreibung
Vor dem Beschreiben des verteilten DNS gemäß der vorliegenden Erfindung im Detail sollte beachtet werden, dass die vorliegende Erfindung vornehmlich in Kombinationen von Verfahrensschritten und Vorrichtungsbestandteilen besteht, die sich auf den verteilten DNS beziehen. Dementsprechend wurden gegebenenfalls Vorrichtungsbestandteile und Verfahrensschritte durch herkömmliche Symbole in den Zeichnungen dargestellt, die nur diejenigen Einzelheiten zeigen, die für das Verstehen der vorliegenden Erfindung relevant sind, um die Offenbarung nicht mit Einzelheiten zu verschleiern, die für Fachleute ohnehin offensichtlich sind, wenn sie den Nutzen der Beschreibung hierbei haben.
In diesem Dokument können relationale Begriffe, wie z. B. erstes (bzw. erste, erster) und zweites (bzw. zweite, zweiter), oberes (bzw. obere, oberer) und unteres (bzw. untere, unterer) und dergleichen ausschließlich dafür verwendet werden, um eine Einheit bzw. einen Vorrang von einer anderen Einheit bzw. einem anderen Vorgang zu unterscheiden, ohne notwendigerweise irgendeinen solchen Zusammenhang oder eine solche Reihenfolge zwischen solchen Einheiten bzw. Vorgängen zu erfordern oder zu implizieren. Die Begriffe „umfasst”, „umfassend” oder andere Abwandlungen davon sind dazu gedacht, ein nicht ausschließliches Enthalten abzudecken, so dass ein Prozess, ein Verfahren, ein Artikel oder eine Vorrichtung, der/das/die ein Aufzählung von Elementen umfasst, nicht notwendigerweise nur diese Elemente enthält, sondern andere nicht ausdrücklich aufgezählte oder einem solchem Prozess, Verfahren, Artikel oder Vorrichtung inhärente Elemente enthalten kann. Ein Element, dem „umfassend ein...” vorhergeht, schließt ohne weitere Einschränkungen das Vorhandensein von zusätzlichen identischen Elementen in dem Prozess, Verfahren, Artikel oder der Vorrichtung, der/das/die das Element umfasst, nicht aus.
Bezug nehmend auf 1 beinhaltet ein drahtloses Kommunikationssystem 100 gemäß der vorliegenden Erfindung veranschaulichend eine Mehrzahl von Knoten, die mit durch gerade Linien angedeutete drahtlose Kommunikationsverbindungen, z. B. 112, verbunden sind. Bei einer veranschaulichenden Ausführungsführungsform ist das drahtlose Kommunikationssystem ein Ad-hoc-Netzwerk mit drahtlosen Kommunikationsvorrichtungen, die ein temporäres Netzwerk bilden ohne die Hilfe von irgendeiner zentralisierten Administration oder von Standardbetreuungsdiensten. Die Knoten können irgendein geeigneter Typ einer drahtlosen Kommunikationsvorrichtung sein, die in der Lage ist, innerhalb eines Ad-hoc-Netzwerkes zu kommunizieren, wie z. B. Computer, persönliche Datenassistenten (PDAs) usw., mit Funkmodems und anderen wie von Fachleuten gewürdigt werden wird. Bestimmte der Knoten können außerdem gegebenenfalls mit einer festen Kommunikationsinfrastruktur verbunden sein.
In 1 wird Knoten A 102 als ein Client und Knoten B als ein Server bezeichnet. Die anderen Knoten B 104, C 110, D 106, E 114 werden als Zwischenknoten bezeichnet und leiten Datenübertragungen von einem Client, z. B. Knoten A 102, zu einem Server, z. B. Knoten F 108, weiter. Ein Client ist ein Endpunkt einer Datenübertragung, die eine Dienstanfrage (request for service) an einem Server initiiert, wobei der Server der Empfänger der Anfrage ist. Zum Zwecke der Veranschaulichung ist der Knoten A 102 als der Client gewählt und ist der Knoten F 108 als der Server gewählt; jedoch kann irgendein anderer Knoten in dem drahtlosen Kommunikationssystem 100 der Client sein und kann irgendein anderer Knoten in dem drahtlosen Kommunikationssystem 100 der Server sein.
Bezug nehmend auf 3 fährt anfänglich ein Knoten, z. B. Knoten A 102, hoch und versucht auf die Infrastruktur zuzugreifen (Block 302). Während dieses Hochfahrprozesses fordert der Knoten eine Netzwerkadresse an. Wie hierin beschrieben ist die offenbarte Netzwerkadresse eine IP-Adresse, aber wie auf dem Fachgebiet bekannt können andere Arten von Netzwerkadressen hierbei an dessen Stelle gesetzt werden. Somit sind Bezugnahmen auf IP-Adressen nur Bezugnahmen auf Ausführungsformen der vorliegenden Erfindung.
Zum Beispiel sendet bei einer Ausführungsform der Knoten ein Dynamic Host Configuration Protocol(DHCP)-Paket an einen DHCP-Server. Wenn eine Antwort auf das DHCP-Paket nicht innerhalb einer bestimmten Zeitspanne und/oder innerhalb einer bestimmten Anzahl von Versuchen empfangen wird, dann bestimmt der Knoten, dass DHCP fehlgeschlagen ist. Nachdem bestimmt wurde, dass DHCP fehlgeschlagen hat besitzt der Knoten keine IP-Adresse für sich selbst und ordnet eine IP-Adresse für sich selbst zu (Block 304). Wie in dem Fachgebiet bekannt kann das dem Knoten eine IP-Adresse Zuordnen mehrmals durchgeführt werden. Zum Beispiel kann die IP-Adresse zufällig gewählt werden und wenn der Knoten bestimmt, dass ein anderer Knoten in dem drahtlosen Kommunikationssystem 100 die gleiche IP-Adresse gewählt hat, dann wählt der Knoten eine andere IP-Adresse. In jedem Fall kann das dem Knoten eine IP-Adresse Zuordnen auf dem Wissen von IP-Adressen beruhen, die für den Knoten zum Verwenden nicht verfügbar sind. Dann tritt der Knoten in einen autonomen Ad-hoc-Modus ein, wobei autonom ad-hoc bedeutet, dass der Knoten keinen Zugang zu der Infrastruktur besitzt (Block 306).
Eine erste Ausführungsform eines Verfahrens für verteiltes DNS in dem drahtlosen Kommunikationssystem 100 wird nun beschrieben werden mit Bezug auf das Nachrichtensequenzdiagramm aus 2 und die Flussdiagramme aus den 4 und 5. Nachdem er bestimmt hat, dass DHCP fehlgeschlagen ist (Block 202) und den Modus des Client auf den autonomen Ad-hoc-Modus gesetzt hat, ordnet der Client sich selbst eine IP-Adresse, z. B. IP-c, zu (Block 204). Eine Anwendung, wie z. B. ein Web-Browser, wird auf dem Client gestartet und die Anwendung benötigt Zugang zu einem Host, wobei der Host durch einen Host-Namen, wie z. B. server.com, bekannt ist. Die Anwendung ruft eine gethostbyname genannte Funktion auf (Block 206). Wenn der Client nicht in einem autonomen Ad-hoc-Modus ist (Block 402), nämlich der Knoten Zugang zu der Infrastruktur besitzt, dann werden DNS-Dienste von der Infrastruktur bereitgestellt (Block 416). Andernfalls frägt der Client seine Hosts-Tabelle nach dem gewünschten Host-Namen ab (Block 404). Wenn der gewünschte Host-Name in der Hosts-Tabelle des Client ist, dann wird die entsprechende IP-Adresse für den Host-Namen zu der Anwendung zurückgegeben (Block 418). Ansonsten sendet der Client eine Anfragenachricht als Broadcast, um eine MAC-Adresse des Host zu empfangen. Bei einer Ausführungsform wird die Anfragenachricht eine DNS-Routenanfrage (DNS-RREQ) genannt. Die DNS-RREQ wird als Broadcast in dem drahtlosen Kommunikationssystem gesendet und wird an einen Nachbarknoten gesendet (Nachricht 208, Block 408). Die DNS-RREQ wird als eine Broadcast-Nachricht von Knoten zu Knoten gesendet bis sie den Server, z. B. den Knoten F 108, findet. Bei einer Ausführungsform basiert das Protokoll, dass zum Senden der DNS-RREQ von Knoten zu Knoten verwendet wird, auf dem gut bekannten Ad-hoc On Demand Distance Vector(AODV)-Protokoll. Bei einer Ausführungsform beinhaltet die DNS-RREQ den Host-Namen des Servers, z. B. server.com, und die IP-Adresse des Client (Nachricht 208).
Der Server hat in ähnlicher Art und Weise versucht, auf die Infrastruktur zuzugreifen und eine IP-Adresse durch Senden eines DHCP-Paketes an den DHCP-Server angefordert. Wenn eine Antwort auf das DHCP-Paket nicht innerhalb einer bestimmten Zeitspanne empfangen wird, dann bestimmt der Server, dass DHCP fehlgeschlagen ist (Block 203). Nachdem er bestimmt hat, dass DHCP fehlgeschlagen ist, besitzt der Server keine IP-Adresse für sich selbst und tritt in einen autonomen Ad-hoc-Modus ein, wobei autonom ad-hoc bedeutet, dass der Server keinen Zugriff auf die Infrastruktur besitzt. Der Server teilt sich selbst eine IP-Adresse, z. B. IP-s, zu (Block 205), ähnlich dem von dem Client gefolgten.
Weiter, wenn der Server die DNS-RREQ von dem Client empfängt (Nachricht 208) überprüft er erst, um zu sehen ob die DNS-RREQ für ihn ist (Block 502). Wenn sie es nicht ist, dann wird die Anfrage mit normaler AODV-Verarbeitung behandelt (Block 510). Ansonsten dekodiert der Server die DNS-RREQ für den Host-Namen und die MAC-Adresse des Client (Block 504) und führt eine Zuordnung (Mapping) des Namens des Clients zu der IP-Adresse des Client durch (Block 210, 504). Dann wird die Hosts-Tabelle des Servers mit dem Host-Namen und der IP-Adresse des Client aktualisiert. Weiter kann bei einer Ausführungsform eine IP-Routing-Tabelle bei dem Server aktualisiert werden, um das Vorhandensein einer für den Host spezifischen Route zu dem Client anzuzeigen. Es sei bemerkt, dass wie in dem Fachgebiet bekannt das Aktualisieren der IP-Routing-Tabelle bei dem Server nicht notwendig ist, wenn die IP-Adresse des Client als Teil des lokalen Teilnetzes des Servers ausgewählt wird. Die IP-Adresse und die MAC-Adresse des Client werden in dem ARP-Cache gespeichert. Die IP-Adresse und die MAC-Adresse des Client werden in der Address-Translation-Tabelle gespeichert (Blöcke 210, 506). Die Senderadresse wird in der Ad-hoc-Routing-Tabelle als der nächste Hop zurück zu dem Client gespeichert. Zum Beispiel, für die von dem Knoten A 102 zu dem Knoten F 108 als Broadcast zu sendende DNS-RREQ, kann die Senderadresse für den nächsten Hop zurück zu dem Client der Knoten D 106 sein. Schließlich wird die MAC-Adresse und der Host-Name des Servers an den Client als eine Antwortnachricht gesendet. Bei einer Ausführungsform wird die Antwortnachricht eine DNS-Routenantwort (DNS-RREP) genannt (Nachricht 212, Block 508). Die DNS-RREP wird von Knoten zu Knoten übertragen bis sie den Client, z. B. Knoten A 102, erreicht. Bei einer Ausführungsform basiert das zum Senden der DNS-RREP von Knoten zu Knoten verwendete Protokoll auf AODV. Bei einer Ausführungsform beinhaltet die DNS-RREP die Host-IP-Adresse, z. B. 10.1.5.148 und die IEEE-MAC-Adresse, z. B. A0 21 3F C8 D6 14.
Wenn aus irgendeinem Grund die DNS-RREP nicht innerhalb einer vorbestimmten Timeout-Zeitspanne empfangen wird, dann wird die DNS-RREQ erneut an den Server übertragen (Block 420) bis eine vorbestimmte Anzahl an Wiederholungen verbraucht wurden (Block 422). Wenn der Client die DNS-RREP empfängt, dann verarbeitet der Client diese. So aktualisiert der Client seine Hosts-Tabelle mit dem Host-Namen und der IP-Adresse des Servers (Blöcke 214, 412). Bei einer Ausführungsform kann der Client seine IP-Routing-Tabelle derart aktualisieren, dass das Vorhandensein einer hostspezifischen Route zu dem Server angegeben wird. Der Client aktualisiert den Address Resolution Protocol(ARP)-Cache mit der empfangenen MAC-Adresse (Blöcke 214, 414). Weiter wird die Senderadresse von der DNS-RREP in der Ad-Hoc-Routing-Tabelle als der nächste Hop zurück zu dem Server gespeichert. Zum Beispiel für die von dem Knoten F 108 zu Knoten A 102 als Broadcast zu sendende DNS-RREP kann die Senderadresse für den nächsten Hop zurück zu dem nächsten Client Knoten B 104 sein. Schließlich wird die IP-Adresse des Servers durch die gethostbyname-Funktion an die aufrufende Anwendung zurückgegeben. Mit dieser Information kann die Anwendung fortfahren zu arbeiten.
Wie auf dem Fachgebiet bekannt wird die IP-Routing-Tabelle des Client zum Routen des Pakets in Schicht 3 verwendet, wenn der Client ein IP-Datenpaket an den Server zu senden hat (Nachricht 216). Weiter wird der ARP-Cache des Client verwendet zum Abrufen der MAC-Adresse des Servers, und die Ad-Hoc-Routing-Tabelle des Client wird verwendet zum Bestimmen des nächsten Hop, zu dem der MAC-Schicht-Rahmen weitergeleitet werden wird (Block 218, Nachricht 220). Der MAC-Schicht-Rahmen wird durch das drahtlose Kommunikationssystem 100 geroutet unter Verwendung der Routing-Information, die von der ADOV-Funktion während des DNS-RREQ/DNS-RREP-Austausches erzeugt wurde, bis das IP-Datenpaket von dem Server empfangen wird. An dem Server wird die Ziel-IP-Adresse verarbeitet (Block 222). Wenn ein IP-Datenpaket zurück zu dem Client gesendet wird (Nachrichten 224, 228), verarbeitet der Server das Paket normal (Block 226). Das bedeutet, dass Standardverfahren genutzt werden können in jeder Schicht des OSI- oder ARPANET-Modells und keine besonderen Abwandlungen irgendeiner der durch jede Schicht definierten Funktionen erforderlich sind. Sobald der Client das IP-Datenpaket empfängt verarbeitet der Client dieses (Block 230). Zur Wiederholung, bei dieser ersten Ausführungsform wird das Senden und Empfangen von IP-Paketen und/oder MAC-Rahmen wie in dem Fachgebiet bekannt, gehandhabt. Dies wird erreicht, da die Tabellen (z. B. die IP-Routing-Tabelle, der ARP-Cache und die Ad-hoc-Routing-Tabelle), die für das Senden und Empfangen von IP-Paketen und/oder MAC-Rahmen notwendig sind, während des DNS-RREQ/DNS-RREP Austausches erstellt werden.
Eine zweite Ausführungsform eines Verfahrens für verteilten DNS in dem drahtlosen Kommunikationssystem 100 wird nun beschrieben werden mit Bezug auf das Nachrichtensequenz-Diagramm in 6 und die Ablaufdiagramme in 7 und 8. Bestimmt habend, dass das DHCP fehlgeschlagen ist (Block 602), und den Modus des Client auf einen autonomen Ad-hoc-Modus festgesetzt habend, ordnet sich der Client selbst eine IP-Adresse, z. B. IP-C, zu (Block 604). Eine Anwendung wie z. B. ein Web-Browser, wird auf dem Client gestartet, und die Anwendung erfordert Zugang zu einem Host, wobei der Host durch einen Host-Namen, wie z. B. server.com, bekannt ist. Die Anwendung ruft eine gethostbyname genannte Funktion auf (Block 606). Wenn der Client nicht in dem autonomen Ad-hoc-Modus ist (Block 702), nämlich der Knoten Zugang zu der Infrastruktur besitzt, dann werden DNS-Dienste durch die Infrastruktur bereitgestellt (Block 716). Ansonsten fragt der Client seine Hosts-Tabelle nach dem gewünschten Host-Namen ab (Block 704). Wenn der gewünschte Host-Name in der Hosts-Tabelle des Client ist, dann wird die entsprechende IP-Adresse für den Host-Namen an die Anwendung zurückgegeben (Block 718). Ansonsten sendet der Client eine DNS-Routen-Anfrage (DNS-RREQ) als Broadcast an einen Nachbarknoten in dem drahtlosen Kommunikationssystem 100 (Nachricht 608, Block 708). Die DNS-RREQ wird als eine Broadcast-Nachricht von Knoten zu Knoten gesendet bis sie den Server findet, z. B. Knoten F 108. Bei einer Ausführungsform wird das zum Senden der DNS-RREQ von Knoten zu Knoten verwendete Protokoll Ad-hoc On Demand Distance Vector(AODV)-Protokoll genannt. Bei einer Ausführungsform beinhaltet die DNS-RREQ den Host-Namen, z. B. server.com.
Der Server hat auf ähnliche Art und Weise versucht, Zugang zu der Infrastruktur zu bekommen, und eine IP-Adresse angefordert durch Senden eines DHCP-Paketes an den DNS-Server. Wenn innerhalb einer bestimmten Zeitspanne keine Antwort auf das DHCP-Paket empfangen wird, dann bestimmt der Server, dass DHCP fehlgeschlagen ist (Block 603). Bestimmt habend, dass DHCP fehlgeschlagen ist, hat der Server keine IP-Adresse für sich selbst und tritt in einen autonomen Ad-hoc-Modus ein, wobei autonom ad-hoc bedeutet, dass der Server keinen Zugang zu der Infrastruktur hat. Der Server ordnet sich selbst eine IP-Adresse, z. B. IP-s, zu (Block 605), ähnlich zu dem von dem Client gefolgten.
Im folgenden, wenn der Server die DNS-RREQ von dem Client empfängt (Nachricht 608), überprüft er zunächst, um zu sehen, ob die DNS-RREQ für ihn ist (Block 802). Wenn sie es nicht ist, dann wird die Anfrage durch AODV-Verarbeitung behandelt, die von einer Ausführungsform der vorliegenden Erfindung nicht abgewandelt wird (Block 810). Ansonsten dekodiert der Server die DNS-RREQ für den Host-Namen und die MAC-Adresse des Client (Block 804). Der Server ordnet dem Client eine lokale IP-Adresse zu und führt ein Mapping des Namens des Client zu der IP-Adresse des Client durch (Blöcke 610, 804). Wie hierbei verwendet, bedeutet lokal, dass nur der Knoten, der die IP-Adresse zugeordnet hat, die IP-Adresse für seine lokale Verarbeitung benötigt und die IP-Adresse besitzt keine Bedeutung über den Knoten hinaus, der die Adresse zugeordnet hat. Dann wird die Hosts-Tabelle des Servers aktualisiert mit dem Host-Namen und der lokal zugeordneten IP-Adresse des Client. Die lokal zugeordnete IP-Adresse des Client kann in der IP-Routing-Tabelle des Servers gespeichert werden. Wie in dem Fachgebiet bekannt, muss die IP-Adresse des Client nicht in der IP-Routing-Tabelle des Servers gespeichert werden, wenn die IP-Adresse des Client als ein Teil des lokalen Teilnetzes des Servers ausgewählt wird. Die IP-Adresse und die MAC-Adresse des Client werden in dem ARP-Cache gespeichert. Die Ad-hoc-Routing-Tabelle wird auch mit der MAC-Adresse des Knotens aktualisiert, der die DNS-RREQ übertragen hat, als den nächsten Hop zurück zu dem Client. Z. B. für die von einem Knoten A 102 zu Knoten F 108 als Broadcast zu übertragende DNS-RREQ kann die Senderadresse für den nächsten Hop zurück zu dem Client der Knoten D 106 sein. Die IP-Adresse und MAC-Adresse des Client werden in der Adressübersetzungstabelle (Address Translation Table) gespeichert (Blöcke 610, 806). Schließlich wird die MAC-Adresse und der Host-Name des Servers an den Client in einer DNS-Routenantwort (DNS-RREP) gesendet (Nachricht 612, Block 808). Die DNS-RREP wird von Knoten zu Knoten übertragen bis sie den Client findet, z. B. Knoten A 102. Bei einer Ausführungsform wird das zum Senden der DNS-RREP von Knoten zu Knoten verwendete Protokoll AODV genannt. Bei einer Ausführungsform beinhaltet die DNS-RREP die Host-IP-Adresse, z. B. 105.7.21.1, und die MAC-Adresse, z. B. 64 21 CA A4 F0 DC.
Wenn aus irgendeinem Grund die DNS-RREP nicht innerhalb einer vorbestimmten Timeout-Zeitspanne empfangen wird, dann wird die DNS-RREQ durch den Server als Broadcast erneut gesendet (Block 720), bis eine vorbestimmte Anzahl von Wiederholungen verbraucht wurde (Block 722). Wenn der Client die DNS-RREP empfängt, dann verarbeitet der Client diese. So ordnet der Client dem Server eine lokale IP-Adresse zu, aktualisiert seine Hosts-Tabelle mit der lokal zugeordneten IP-Adresse des Servers und dem Host-Namen des Servers (Blöcke 614, 712). Der Client aktualisiert den Address Resolution Protocol(ARP)-Cache mit der empfangenen MAC-Adresse (Blöcke 614, 714). Die Ad-hoc-Routing-Tabelle wird mit der MAC-Adresse des Knotens aktualisiert, der die DNS-RREP übertragen hat, als den nächsten Hop zurück zu dem Server. Mit dem Wissen der Information in der IP-Routing-Tabelle, dem ARP-Cache und in der Ad-hoc-Routing-Tabelle kann die Anwendung weiter arbeiten.
Wie in dem Fachgebiet bekannt, verwendet der Client, wenn der Client ein IP-Datenpaket an den Server zu senden hat (Nachricht 616), die lokal zugeordnete IP-Adresse des Servers zum Abfragen der MAC-Adresse des Servers von seinem ARP-Cache (Block 618) und überträgt einen das IP-Paket enthaltenden MAC-Rahmen. Der Client muss nicht länger Kenntnis von der aktuellen IP-Adresse des Servers besitzen zum Senden eines IP-Datenpaketes an den Server. Der MAC-Rahmen wird durch das drahtlose Kommunikationssystem 100 geroutet bis das IP-Datenpaket von dem Server empfangen wird. An dem Server wird die Ziel-IP-Adresse überprüft, um zu sehen, ob sie entweder ein Multicast oder gleich der IP-Adresse des Servers ist (Blöcke 904, 906). Wenn sie es ist, leitet der Server das IP-Datenpaket zum Verarbeiten an den Netzwerkstapel weiter, z. B. an den IP-Stapel. Ansonsten wird der Server die Adressübersetzungstabelle (Address Translation Table) auf die Quell-MAC-Adresse des empfangenen Rahmens hin überprüfen (Block 908). Wenn die Quell-MAC-Adresse in der Adressübersetzungstabelle gefunden wird, wird der Server die IP-Adresse von dem IP-Datenpaket mit der in der Adressübersetzungstabelle gespeicherten IP-Adresse austauschen. Die Zieladresse in dem IP-Datenpaket wird mit der IP-Adresse der Schnittstelle ausgetauscht, an der das IP-Datenpaket empfangen wurde (Blöcke 910). Dann wird das Datenpaket bis zu dem IP-Stapel weitergeleitet, der das Paket verarbeiten wird (Block 912).
Der Server kennt den Client durch die lokal zugeordnete IP-Adresse. Wenn der Server ein Paket an den Client senden will, wird der Server die MAC-Adresse des Client von dem ARP-Cache abrufen. Der Server überträgt dann den Rahmen an den in der Ad-hoc-Tabelle gefundenen nächsten Hop. Es sei bemerkt, dass die Datenpakete auf dem Client und dem Server identisch verarbeitet werden. Empfangene Datenpakete werden auch auf dem Client und auf dem Server identisch behandelt. Wie in dem Fachgebiet bekannt, werden die übermittelten Datenpakete gemäß Standardverfahren verarbeitet und die empfangenen Pakete durchlaufen die oben beschriebenen Adressübersetzungsfunktionen.
Es wird ersichtlich sein, dass der hierin beschriebene verteilte DNS aus einem oder mehreren herkömmlichen Prozessoren und einzelnen gespeicherten Programmanweisungen bestehen kann, welche den einen oder die mehreren Prozessoren derart steuern, dass im Zusammenhang mit den bestimmten Nicht-Prozessorschaltungen einige, die meisten oder alle der Funktionen des hierin beschriebenen verteilten DNS implementiert werden. Die Nicht-Prozessorschaltungen können enthalten, aber sind nicht beschränkt auf: einen Funkempfänger, einen Funksender, Signaltreiber, Taktschaltungen, Leistungsversorgungsschaltungen und Benutzereingabevorrichtungen. Als solches können diese Funktionen interpretiert werden als Schritte eines Verfahrens zum Durchführen von verteiltem DNS. Alternativ könnten einige oder alle Funktionen implementiert werden durch eine Zustandsmaschine, die keine gespeicherten Programmanweisungen aufweist, oder in einer oder mehreren anwendungsspezifischen integrierten Schaltungen (ASICs), bei denen jede Funktion oder einige Kombinationen der Funktionen als kundenspezifische Logik implementiert sind. Selbstverständlich kann eine Kombination dieser beiden Ansätze verwendet werden. Somit wurden Verfahren und Mittel für diese Funktionen hierin beschrieben. Weiter wird erwartet, dass ein Fachmann ungeachtet möglicher, beachtlicher Bemühung und vieler Entwurfsentscheidungsmöglichkeiten, motiviert von z. B. der zur Verfügung stehenden Zeit, der gegenwärtigen Technologie und ökonomischen Überlegungen, leicht dazu in der Lage sein wird, solche Softwareanweisungen- und programme und ICs mit minimalem Experimentieren hervorzubringen, wenn er von den hierin offenbarten Konzepten und Prinzipien geleitet ist.
Bei der vorhergehenden Beschreibung sind spezifische Ausführungsformen der vorliegenden Erfindung beschrieben worden. Für den Fachmann ist jedoch offensichtlich, dass zahlreiche Abwandlungen und Veränderungen daran vorgenommen werden können, ohne von dem Umfang der Erfindung wie er in den anschließenden Ansprüchen dargelegt ist, abzuweichen. Demgemäß sind die Beschreibung und die Figuren mehr in einem veranschaulichenden als in einem beschränkenden Sinn aufzufassen, und alle derartigen Abwandlungen sind als innerhalb des Umfangs der vorliegenden Erfindung enthalten aufzufassen. Der Nutzen, die Vorteile und Lösungen der Probleme und beliebige Elemente, die einen solchen Vorteil oder Lösung bewirken oder vorhersagen, sind nicht als kritische, erforderliche oder essentielle Merkmale oder Elemente für irgendeinen oder alle Ansprüche auszulegen. Die Erfindung wird lediglich durch die beigefügten Ansprüche einschließlich von Änderungen, die während der Anhängigkeit dieser Anmeldung gemacht werden, und allen Äquivalenten zu diesen Ansprüchen, wie ausgegeben, bestimmt.

Claims

Verfahren für verteiltes Domain Name Service (DNS) in einem drahtlosen Kommunikationsnetzwerk (100) mit den Schritten: Senden (408; 708) einer DNS Anfrage-Nachricht (208; 608) als Broadcast von einem ersten Knoten (102) an einen zweiten Knoten (108), wobei die DNS Anfrage-Nachricht (208; 608) einen Host-Namen des zweiten Knotens (108) und Informationen über den ersten Knoten (102) umfasst, wobei die Informationen mindestens eine einer Netzwerkadresse oder einer Media Access Control (MAC) Adresse aufweisen; Weiterleiten der DNS Anfrage-Nachricht (208; 608) von dem ersten Knoten (102) an den zweiten Knoten (108) durch Zwischenknoten (104, 106, 110, 114) in dem drahtlosen Kommunikationsnetzwerk (100); und Übertragen (508; 808) einer DNS Antwort-Nachricht (212; 612) von dem zweiten Knoten (108) an den ersten Knoten (102), wobei die DNS Antwort-Nachricht (212; 612) eine MAC-Adresse des zweiten Knotens (108) umfasst; Zuordnen (610, 804) einer an dem zweiten Knoten (108) zu speichernden lokalen Netzwerkadresse des ersten Knotens (102) durch den zweiten Knoten (108); Empfangen eines Datenpaketes an dem zweiten Knoten (108) durch (i) Bestimmen (908) ob die MAC-Adresse des ersten Knotens (102) in einer Adressübersetzungstabelle des zweiten Knotens (108) ist; (ii) Ersetzen einer Quellnetzwerkadresse von dem Datenpaket mit der lokalen Netzwerkadresse des ersten Knotens (102), wenn sie gefunden wird (910); (iii) Ersetzen (910) einer Zielnetzwerkadresse von dem Datenpaket mit der Netzwerkadresse des zweiten Knotens (108); und (iv) Übergeben (912) des Datenpaketes an einen Netzwerkstapel.
Verfahren nach Anspruch 1, wobei die DNS Anfrage-Nachricht (208; 608) eine modifizierte Ad-Hoc On Demand Distance Vector(AODV)-Routen-Anfrage-Nachricht ist.
Verfahren nach Anspruch 1, weiter mit dem Schritt (614, 712) des Zuordnens einer bei dem ersten Knoten (102) zu speichernden lokalen Netzwerkadresse des zweiten Knotens (108) durch den ersten Knoten (102).
Verfahren für verteiltes DNS in einem drahtlosen Ad-hoc-Kommunikationsnetzwerk, wobei das drahtlose Ad-hoc-Kommunikationsnetzwerk (100) einen Client (102), einen Server (108) und Zwischenknoten (104, 106, 110, 114) zwischen dem Client (102) und dem Server (108) umfasst, und wobei das Verfahren die folgenden Schritte umfasst: bei dem Client (102): Zuordnen (204; 304; 604) einer IP-Adresse an den Client (102); Senden (408; 708) einer DNS Anfrage-Nachricht (208; 608) als Broadcast an das drahtlose Ad-hoc-Kommunikationsnetzwerk (100), wobei die DNS Anfrage-Nachricht (208; 608) einen Host-Namen des Servers (108), einen Host-Namen des Client (102) und die zugeordnete IP-Adresse des Client (102) umfasst; und Empfangen einer DNS Antwort-Nachricht (212; 612) wobei die DNS Antwort-Nachricht (212; 612) eine MAC-Adresse des Servers (108) umfasst; Zuordnen (614; 712) einer in einer Adressübersetzungstabelle zu speichernden lokalen IP-Adresse für den Server (108) bei dem Client (102); und Erhalten von Information über den Server (108) aus der Antwort-Nachricht, wobei die Information zumindest einen Host-Namen, eine MAC-Adresse oder eine IP-Adresse umfasst; und Aktualisieren (614; 714) von zumindest einer Tabelle des Client (102) mit der erhaltenen Information, wobei die zumindest eine Tabelle zumindest eine Hosts-Tabelle, eine IP-Routing-Tabelle, einen Address Resolution Protokoll(ARP)-Cache, eine Ad-hoc-Routing-Tabelle oder eine Adressübersetzungstabelle umfasst, um das Routen eines Datenpakets zum Server zu ermöglichen.
Verfahren nach Anspruch 4, weiter mit den Schritten: am Server: Zuweisen einer Internet Protocol (IP) Adresse zum Server (108) in dem Ad-Hoc-drahtlosen Kommunikationsnetzwerk (100); Empfangen der DNS Anfrage-Nachricht (208; 608); und Broadcasten der DNS Antwort-Nachricht (212; 612).
Verfahren nach Anspruch 5, weiter mit den Schritten: Erhalten von Information über den Client (102) aus der Anfrage-Nachricht, wobei die Information zumindest einen Host-Namen, eine MAC-Adresse oder eine IP-Adresse umfasst; Zuordnen einer in einer Adressübersetzungstabelle zu speichernden lokalen IP-Adresse für den Client (102) bei dem Server (108); und Aktualisieren von zumindest einer Tabelle des Servers (108) mit der erhaltenen Information, wobei die zumindest eine Tabelle zumindest eine Hosts-Tabelle, eine IP-Routingtabelle, einen ARP-Cache, eine Ad-hoc-Routing Tabelle oder eine Adressübersetzungstabelle umfasst, um das Routen eines Datenpakets zum Server zu ermöglichen.
Verfahren für verteiltes DNS in einem drahtlosen Ad-hoc Kommunikationsnetzwerk (100), wobei das drahtlose Ad-hoc-Kommunikationsnetzwerk (100) einen Client (102), einen Server (108) und Zwischenknoten (104, 106, 110, 114) zwischen dem Client (102) und dem Server (108) umfasst, und wobei das Verfahren die folgenden Schritte umfasst: bei dem Client (102): Senden einer DNS-RREQ-Nachricht (206; 608) als Broadcast von einem Client (102) an das drahtlose Ad-hoc-Kommunikationsnetzwerk (100), wobei die DNS-RREQ-Nachricht (206; 608) einen Host-Namen des Servers (108) umfasst; und Empfangen einer DNS-RREP-Nachricht (212; 612), wobei die DNS-RREP-Nachricht (212; 612) eine MAC-Adresse des Servers (108) umfasst; Zuordnen (614; 712) einer in einer Adressübersetzungstabelle zu speichernden lokalen IP-Adresse für den Server (108) bei dem Client (102); und Erhalten von Information über den Server (108) aus der Antwort-Nachricht, wobei die Information zumindest einen Host-Namen, eine MAC-Adresse oder eine IP-Adresse umfasst; und Aktualisieren (614; 714) von zumindest einer Tabelle des Client (102) mit der erhaltenen Information, wobei die zumindest eine Tabelle zumindest eine Hosts-Tabelle, eine IP-Routing-Tabelle, einen ARP-Cache, eine Ad-hoc-Routing-Tabelle oder eine Adressübersetzungstabelle umfasst, um das Routen eines Datenpakets zum Server zu ermöglichen.
Verfahren nach Anspruch 7, weiter aufweisend: am Server: Empfangen der DNS-RREQ-Nachricht; und Broadcasten der DNS-RREP.
Verfahren nach Anspruch 8 weiter mit den Schritten: Erhalten von Information über den Client (102) aus der Anfrage-Nachricht, wobei die Information zumindest einen Host-Namen, eine MAC-Adresse oder eine IP-Adresse umfasst; Zuordnen einer in einer Adressübersetzungstabelle zu speichernden lokalen IP-Adresse für den Client (102) bei dem Server (108); und Aktualisieren von zumindest einer Tabelle des Servers (108) mit der erhaltenen Information, wobei die zumindest eine Tabelle zumindest eine Hosts-Tabelle, eine IP-Routingtabelle, einen ARP-Cache, eine Ad-hoc-Routing Tabelle oder eine Adressübersetzungstabelle umfasst, um das Routen eines Datenpakets zum Server zu ermöglichen.