-
GEBIET DER
ERFINDUNG
-
Die
vorliegende Erfindung bezieht sich auf die Übertragung von Paketen zu mehreren
Zielen in ad-hoc-Netzwerken, in denen sich sowohl Router als auch
Hauptrechner bewegen können
und in denen Router sowohl mit Hauptrechnern als auch mit Netzwerken
verbunden sein können.
-
HINTERGRUND
-
Vielsprung-Paketfunknetzwerke
oder ad-hoc Netzwerke bestehen aus mobilen Rechnern, die durch Router
verbunden sind, die sich ebenso bewegen können. Die Aufstellung von solchen
Routern ist ad-hoc und die Topologie des Netzwerkes ist wegen der
Mobilität
von Rechner und Router, Signalverlust und Störung und Energieausfällen sehr
dynamisch. Zusätzlich
ist die in ad-hoc Netzwerken verfügbare Bandbreite relativ beschränkt, verglichen
mit verkabelten Netzwerken, und nicht angeschlossene Router müssen möglicherweise mit
Einschränkungen
durch die Batterielebensdauer arbeiten. In diesen Netzwerken muss
das Routing unter Benutzung der minimal möglichen Anzahl von Kontrollnachrichten
durchgeführt
werden und Nachbar-zu-Nachbar-Handshake muss soweit wie möglich vermieden
werden, um Kanalbandbreite für
Benutzerdaten und die Batterielebensdauer von nicht verbundenen
Knoten zu bewahren. Wegen der Dynamik der Topologie in ad-hoc-Netzwerken
sind Rundruffunkverbindungen zum Verbinden von Routern, ohne die
Notwendigkeit die Topologie zu planen, vorzuziehen.
-
Mit
wenigen Ausnahmen beinhalten die heutzutage verwendeten Methoden
zum effizienten Unterstützen
von Vielen-zu-Vielen-Kommunikation (Multicasting) in Computernetzwerken
das Aufbauen von Multicast- Routingbäumen. Der
grundlegende Ansatz besteht im Aufbauen eines Routingbaumes für eine Gruppe von
Routingknoten (Router). Sobald ein Routingbaum für eine Gruppe von Routern aufgebaut
ist, durchläuft ein
Paket oder eine Nachricht, die zu allen Routern in den Baum gesendet
wird, jeden Router und jede Verbindung in dem Baum nur einmal.
-
Die
Multicast-Routing-Protokolle, die für das Internet entwickelt worden
sind, fallen heutzutage in zwei grundlegenden Kategorien, die zuerst
in „Host
Extensions for IP Multicasting" in
Internet Engineering Task Force (IETF) Request for Comments-112,
August 1989 von S. Deering beschrieben worden sind: Protokolle, die
auf vollständiger
Topologieinformation beruhen, die ebenso Verbindungszustand-Multicasting-Protokolle genannt
werden, und Protokolle, die auf Abstandsinformation beruhen. Multicast-OSPF
(MOSPF) ist ein Beispiel für
den auf Topologie basierenden Ansatz. In MOSPF kommuniziert jeder
Router mit jedem anderen Router in dem Netzwerk die Multicastgruppen,
zu denen eine gegebene Verbindung gehört, zusätzlich zu der Verbindungscharakteristik,
die in dem Open Shortest Path First (OSPF) Protocol verwendet wird.
Mit dieser Information kann jeder Router den Multicast-Routingbaum mit dem
kürzesten
Pfad von jeder Quelle einer gegebenen Multicast-Routergruppe zu
dem Rest der Router berechnen, die eine Verbindung gemeldet haben,
die zu der Multicastgruppe gehört.
Die Beschränkungen
dieses Ansatzes sind Verkehr-Overhead, der durch das Verbreiten
von Veränderungen
in der Gruppenzugehörigkeitsinformation
für jede
Verbindung in dem Netzwerk auftritt und der Verarbeitungs-Overhead, der durch
das Berechnen der Bäume
mit dem kürzesten
Pfad von jeder Quelle einer Multicastgruppe zu dem Rest der Gruppenmitglieder
auftritt.
-
Beispiele
für Protokolle,
die auf Abstandsinformation beruhen, sind das Distance Vector Multicast
Routing Protocol (DVMRP), das Core Based Tree (CBT) Protocol, das
Ordered Core Based Tree (OCBT) Protocol und das Protocol Independent
Multicast (PIM) Protocol. All diese Protokolle basieren auf der
Idee der Rückwärtspfadverfolgung.
In DVMRP flutet die Quelle einer Multicastgruppe das gesamte Netzwerk
mit einem Multicastpaket. Jeder Router, der das Paket empfängt, leitet
es an all seine anderen Schnittstellen weiter, wenn das Paket von
dem Nachbar empfangen wird, die seine Unicast-Router-Tabelle als
seinen nächsten
Sprung zu der Quelle des Paketes auflistet. Für eine gegebene Multicastgruppe
senden Router, die keine Gruppenmitglieder in einem der mit ihnen
verbundenen Netzwerke haben, ein Ausschneidesteuerpaket zu dem Nachbar,
der in seiner Routing-Tabelle als sein nächster Sprung zur Quelle der
Multicastgruppe aufgeführt
ist. Die Hauptbeschränkung
von DVMRP ist die Notwendigkeit, dass gesamte Netzwerk mit Multicastpaketen
zu fluten, bevor Router, die mit keinen Multicast-Mitgliedern verbunden
sind, den sich ergebenden Überbrückungsbaum
ausschneiden können.
-
CBT
beseitigt die Notwendigkeit, dass Netzwerk zu fluten und auszuschneiden
durch die Benutzung eines speziellen Routers, der der Kern genannt
wird, als Referenzpunkt für
Router, um einer gegebenen Multicastgruppe beizutreten. Router mit
Schnittstellen zu Netzwerken, in denen einer oder mehrere Rechner
verlangen, einer Multicastgruppe beizutreten, senden eine Beitrittsanforderung
zu dem bestimmten Kern dieser Multicastgruppe entlang ihren kürzesten
Pfaden zu dem Kern. Jeder Router, der schon Teil des Multicast-Routingbaumes
der Gruppe ist und solch eine Aufnahmeanforderung erhält, sendet
eine Bestätigung
zurück
an den Router, der die Anforderung gesendet hat; dementsprechend
werden neue Multicast-Baumzweige entlang kürzester Pfade von Empfängern zu
dem Kern der Multicastgruppe aufgebaut. Im Gegensatz zu DVMRP gibt es
in CBT nur einen Multicast-Routingbaum für jede Multicastgruppe. Der
gemeinsame Baum, der für
eine gegebene Multicastgruppe aufgebaut worden ist, ist bidirektional,
was beinhaltet, dass Multicastpakete in beiden Richtungen einer
Verbindung, die zwei Router in dem Multicastbaum verbindet, fließen können.
-
PIM
hat zwei Betriebsarten, dichte Betriebsart und dünne Betriebsart. In der PIM
dichten Betriebsart (PIM-DM) wird der in DVMRP genutzte Flut- und
Ausschneide-Ansatz verwendet, mit dem einzigen Unterschied, dass
PIM-DM sich auf die an den Routern verfügbaren Unicast-Routing-Tabellen verlässt, anstatt
zu fordern, dass die Router getrennte Routingtabellen mit Abständen zu
den Multicast-Quellen enthalten, wie es DVMRP tut. Die dünne PIM
Betriebsart (PIM-SM) benutzt die selbe Strategie, die in CBT eingeführt wurde,
um gemeinsame Bäume
aufzubauen; jedoch sind die gemeinsamen Bäume, die mit PIM-SM aufgebaut
worden sind, unidirektional und die Richtung der Verbindungen, in
dem Multicastbaum ist weg von der Wurzel des Multicastbaumes, der
Rendezvous-Punkt (RP) genannt wird. Dementsprechend senden Quellen
ihre Pakete an den RP und dann werden sie über den Multicastbaum an all
die Empfänger
verteilt.
-
Multicast-Routingbäume sind
auch für
drahtlose Multi-Hop-Netzwerke vorgeschlagen worden. Diese Ansätze bauen
Multicast-Routingbäume
durch Fluten von Steuerpaketen auf, die nach Mitgliedern der Multicastgruppe
suchen.
-
Da
ein Multicastbaum einen einzelnen Pfad zwischen zwei beliebigen
Routern in den Baum zur Verfügung
stellt, wird die minimale Anzahl von Kopien pro Paket benutzt, um
Pakete an alle Empfänger
einer Multicastgruppe zu verteilen. Für einen Baum aus N-Routern,
werden nur N-1 Verbindungen benutzt, um dieselbe Information an
alle Router in dem Multicastbaum in einem Netzwerk mit Punkt-zu-Punkt-Verbindungen
zu übertragen;
im Fall eines drahtlosen Netzwerkes mit Rundsendeverbindungen, die
einen einzelnen Kanal benutzen, braucht jedes Mitglied eines Multicastbaumes
ein Paket nur einmal zu übertragen.
Die Benutzung eines Routingbaumes ist natürlich sehr viel effizienter,
als der Ansatz brachialer Gewalt des individuellen N-1 maligen Sendens
derselben Information, von den Quellen zu jedem von den anderen.
Ein weiterer Vorteil des Benutzens von Bäumen für Multicast-Routing ist, dass
die Routingentscheidungen in jedem Router des Multicastbaumes sehr
einfach werden: ein Router in einem Multicastbaum, der ein Multicastpaket
für die
Gruppe über
eine Schnittstelle innerhalb des Baumes empfängt, leitet das Paket über den
Rest seiner Schnittstellen innerhalb des Baumes weiter.
-
Jedoch
erreichen Multicastbäume
die zuvor beschriebene Effizienz und Einfachheit durch Erzwingen eines
einzelnen Pfades zwischen jedem Paar von Routern. Dementsprechend
erfordert die Benutzung von Routingbäumen, wenn mehrere Quellen
Informationen an den gleichen Satz von Zielen übertragen müssen, dass entweder ein gemeinsamer
Multicastbaum für
alle Quellen benutzt wird, oder dass ein separater Multicastbaum
für jede
Quelle aufgebaut wird. Das Benutzen eines gemeinsamen Multicastbaumes
hat den Nachteil, dass Pakete zu der Multicastgruppe entlang Pfaden
verteilt werden, die viel länger
sein können
als die kürzesten
Pfade von den Quellen zu den Empfängern. Das Benutzen eines getrennten
Multicastbaumes für
jede Quelle der Multicastgruppe zwingt die Router, die in mehreren
Multicastgruppen teilnehmen, einen Eintrag für jede Quelle in jeder Multicastgruppe
aufrechtzuerhalten, was nicht skaliert, wenn die Anzahl der Gruppen
und Quellen per Gruppe zunimmt. Zusätzlich teilt der Ausfall einer
beliebigen Verbindung in den Baum die Gruppe und erfordert, dass
die beteiligten Router den Baum rekonfigurieren, da die Bäume minimale
Verbindung zwischen den Mitgliedern einer Multicastgruppe zur Verfügung stellen.
-
Obwohl
baumbasiertes Multicast-Routing aufgrund seiner Einfachheit sehr
attraktiv für
verdrahtete Netzwerke und das Internet ist, verursacht das Aufrechterhalten
von Multicast-Routing eine unerwünschte Menge
von Steuerverkehr, wenn sich die zugrunde liegende Topologie häufig ändert. Zusätzlich können Router
gezwungen sein, in Zeiträumen
der Instabilität
von Routingtabellen, die Weiterleitung von Paketen zu stoppen, während sie
darauf warten, dass der Multicast-Routingbaum rekonstruiert wird.
Unlängst
sind zwei Ansätze
zum Aufbau von Multi castnetzen an Stelle von Multicastbäumen vorgeschlagen
worden. Ein Multicastnetz ist ein verbundener Untersatz eines Netzwerkes,
der alle Mitglieder einer gegebenen Multicastgruppe enthält und der
wenigstens einen Pfad von jeder Quelle zu jedem Empfänger in
der Multicastgruppe zur Verfügung stellt.
-
Das „The Core
Assisted Mesh Protocol (CAMP)" vorgeschlagen,
von J. J. Garcia-Luna-Aceves und E. L. Madruga in „The Core
Assisted Mesh Protocol",
IEEE Journal on Selected Areas in Communications, Special Issue
on Ad-Hoc Networks, Vol 17, No. 8, pp. 1380-394, August 1999 und
in "A Multicast
Routing Protocol for Ad-Hoc Networks", INFOCOM 99, 21 März 1999, pp. 784–792 erweitert
den grundlegenden Empfänger ausgelösten Ansatz,
der in dem "Core-Based
tree (CBT) Protocol" für die Erzeugung
von Multicastgruppen eingeführt
worden ist, um die Erzeugung von Multicastnetzen zu ermöglichen.
Ein gemeinsames Multicastnetz wird für jede Multicastgruppe definiert.
Das Hauptziel des Benutzens solcher Netze ist es, die Verbundenheit von
Multicastgruppen selbst dann aufrechtzuerhalten, wenn Netzwerk-Router
sich häufig
bewegen. CAMP besteht aus dem Unterhalten von Multicastnetzen und
schleifenfreier Paketweiterleitung über solche Netze. Innerhalb
des Multicastnetzes einer Gruppe werden Pakete von jeder Quelle
in der Gruppe entlang des kürzesten
Rückwärtspfades
zu der Quelle weitergeleitet, so wie in einem traditionellen Multicast-Protokoll,
das auf einem quellenbasierten Baum basiert.
-
CAMP
garantiert, dass innerhalb einer endlichen Zeit jeder Empfänger einer
Multicastgruppe einen kürzesten
rückwärtigen Pfad
zu jeder Quelle einer Multicastgruppe hat. Multicastpakete für eine Gruppe
werden entlang der kürzesten
Pfade von Quellen zu Empfängern,
die innerhalb des Gruppennetzes definiert sind, weitergeleitet.
Kerne werden benutzt, um den Steuerverkehr, der benötigt wird,
damit Empfänger
der Multicastgruppe beitreten, zu begrenzen. Im Gegensatz zu CBT
können
einer oder mehrere Kerne für
jedes Netz definiert werden, Kerne müssen nicht Teil des Netzes
der Gruppe sein und Router können
selbst dann der Gruppe beitreten, wenn alle zugehörigen Kerne
unerreichbar werden. Ein Router sendet eine Aufnahmeanforderung an
einen Kern, wenn keiner seiner Nachbarn ein Mitglied der Gruppe
ist; sonst gibt er seine Mitgliedschaft einfach unter Benutzung
von entweder zuverlässigen
oder andauernden Aktualisierungen bekannt. Wenn Kerne von einem
Router, der einer Gruppe beitreten muss, nicht erreichbar sind,
verbreitet der Router seine Aufnahmeanforderung unter Benutzung
einer sich ausweitenden Ringsuche (ERS), die letztendlich einige
Gruppenmitglieder erreicht. Wenn eine oder mehrere Antworten an
den Router zurückgesandt
werden, wählt
er eine beliebige von diesen Antworten aus, um diese als Pfad zu
dem Netz zu verwenden. In den genannten Veröffentlichungen von Garcia-Luna-Aceves
et al. ist jedoch nicht beschrieben, wo ein empfangender Router
basierend wenigstens zum Teil auf der Aktualisierungsinformation
in der Routingbauminformation, die von dem ersten Router berichtet
wird, bestimmt, ob der zweite Router die Aktualisierungsinformation
an wenigstens einem Nachbarrouter von dem zweiten Router übertragen
muss, was ein wesentliches Merkmal der vorliegenden Erfindung ist.
-
Das „Forwarding
Group Multicast Protocol (FGMP)" und
das „Ondemand
Multicast Routing Protocol (ODMRP)" bauen ebenso eine Variation von Netzen
auf. Um jedoch Gruppennetze aufzubauen, erfordern FGMP und ODMRP
das Fluten von Steuerpaketen in einem ad-hoc Netzwerk in ziemlich
der gleichen Weise wie DVMRP und PIM-DM zunächst das Fluten von Multicast-Datapaketen
erfordern. Der Unterschied zwischen diesen beiden Protokollen liegt
darin, wer den Flutungsprozess startet – in ersterem die Empfänger und im
letzterem die Sender. Dieser Ansatz ist nur in kleinen Netzwerken
akzeptabel. Im Gegensatz dazu beseitigt die Benutzung von Kernen
in CAMP die Notwendigkeit des Flutens, es sei denn, dass alle Kerne
von einer verbundenen Komponente aus nicht erreichbar sind.
-
Im
Wesentlichen erfordert ODMRP, dass alle Sender, die aktiv Datenpakete übertragen,
periodisch das Netzwerk mit einem Senderankündigenden Paket fluten. Alle
Router, die direkt mit dem Rechner verbunden sind, der an der Multicastgruppe
teilnehmen möchte,
werden diese Ankündigungspakete
verarbeiten und eine Mitgliedstabelle aktualisieren. Diese Tabelle
führt alle
Sender auf, deren Ankündigungen
empfangen worden sind und die Nachbarrouter, die als nächster Sprung
zu diesen Sendern benutzt werden. Periodisch wird auch die Mitgliedstabelle
rund gesendet und zwischengeschaltete Router, die in Mitgliedstabellen
als nächster Sprung
zu einem Sender aufgeführt
sind, werden ein Datenweiterleitungs-Flag setzen, werden Gruppenmitglieder
und behalten/rund senden selbst eine Mitgliedstabelle. Genau wie
CAMP hält
ODMRP einen Datenpaketcache. Datenpakete werden weitergeleitet,
wenn das Weiterleitungs-Flag gesetzt ist und das Datenpaket nicht
schon in dem Paketcache ist. FGMP ist diesem Ansatz sehr ähnlich,
außer
in der oben erwähnten
Tatsache, dass die Receiver die Instanzen sind, die Mitgliedsankündigungspakete
fluten und Sender in der Mitgliedstabelle über Empfänger Buch führen.
-
Sowohl
ODMRP und FGMP haben Skalierungsprobleme aufgrund der Designentscheidung,
Steuerpakete zu fluten, und insbesondere FGMP aufgrund der Tatsache,
dass Sender über
alle Empfänger
in einer Multicastgruppe Buch führen
müssen.
-
Eine
Beschränkung
von CAMP ist die Notwendigkeit, einen Untersatz von Routern als
Kerne, die einer besonderen Gruppe dienen, zu definieren, da dies
erfordert, dass die Kerne als solche von einem Systemadministrator
konfiguriert werden. Weiterhin müssen
Router sich auf das Fluten des Netzwerkes mit Suchmeldungen verlassen,
um der vorgesehenen Multicastgruppe beizutreten, in dem Fall, dass
Kerne einer Multicastgruppe nicht erreichbar sind oder versagen.
-
Alle
Multicast-Routing-Protokolle aus dem Stand der Technik nehmen an,
dass: entweder vollständige Topologieinformation
an jedem Router verfügbar
ist (z. B. MOSPF), oder Entfernungsinformation zu Zielen verfügbar ist
(z. B. CBT, CAMP, PIM, SM) oder dass der Multicast-Routingbaum durch
Fluten und dann Ausschneiden aufgebaut werden kann (z. B. DVMRP,
FGMP, ODMRP) oder das Fluten von Suchnachrichten verwendet werden
kann, um Multicastgruppen beizutreten (z. B. AODV und Multicast-Routing-Protokolle,
die auf Routing auf Anforderung basieren).
-
Eine
Anzahl von Unicast-Routing-Protokollen im Stand der Technik basiert
auf dem, das wir den Quellbaum-Routingansatz nennen. In diesem Ansatz
kommunizieren Router entweder den Zustand (d.h. Kosten oder Länge) der
Verbindungen in einem Routingbaum mit dem kürzesten Pfad oder die Entfernung
von der Wurzel des Baumes und dem vorletzten Sprung in dem Routingbaum
für jeden
Knoten in dem Baum. Das erste von dieser Art von Protokollen wurde
in dem US-Patent Nr. 4,466,060 von Riddle vorgeschlagen. In Riddles Protokoll
kommuniziert ein Router verschiedene Bäume mit kürzestem Pfad zu verschiedenen
Nachbarn; diese Bäume
werden von Riddle „ausschließliche Bäume" genannt und spezifizieren
die bevorzugten Pfade zu Zielen unter Ausschluss jener Pfade, die
den Router beinhalten, zu dem die Aktualisierung gesendet wird.
Ein Aktualisierungspaket oder eine Aktualisierungsnachricht spezifizieren
einen gesamten ausschließenden Baum.
Das zweite Protokoll basiert auf dem Quellbaum Routing Ansatz, der
von Garcia-Luna-Aceves
in „A
Fail Save Routing Algorithm for Multihop Pocket-Radio Networks", Proc. IEEE Infocom
86, Miami, FL, April 1986 berichtet worden ist, und sich von Riddles
Protokoll dadurch unterscheidet, dass der gleiche Routingbaum mit kürzestem
Pfad taktweise von einem Router zu all seinen Nachbarn gesendet
wird. Humblet „Another
Adaptive Shortest-Path Algorithm" IEEE
Trans. Comm., Vol. 39, No. 6, June 1991, pp. 995-1003, Cheng et
al, "A Loop-Free
Extended Bellman-Ford Routing Protocol without Bouncing Effect", Proc. ACM SIGCOMM
89, pp. 224-236, Rajagopalan und Faiman "A Responsive Distributed Shortest-Path
Routing Algorithm within Autonomous Systems", Journal of Internetworking: Research
and Experience, Vol. 2, No. 1, March 1991, pp. 51-69 und Murthy
und Garcia-Luna-Aceves "An
Efficient Routing Protocol for Wireless Networks", ACM Mobile Networks and Applications
Journal, Special issue on Routing in Mobil Communication Networks,
1996 haben alle Protokolle vorgeschlagen, die auf Quell-Routingbäumen basieren,
in denen ein Router den selben Routingbaum mit kürzestem Pfad taktweise zu seinem
Nachbarn kommuniziert und sich von dem Protokoll von Garcia-Luna-Aceves
durch den Weg unterscheidet, auf dem ein Router seinen eigenen Routingbaum
mit kürzestem
Pfad von den Bäumen,
die von den Nachbarn berichtet worden sind, erhält.
-
Überraschenderweise
hat kein bis heute vorgeschlagenes oder implementiertes Multicast-Router-Protokoll
Nutzen aus den Routingbäumen
mit kürzestem
Pfad gezogen, welche die zuvor genannten Unicast-Routing-Protokolle zur Verfügung stellen.
Weiterhin verhindert keines der Multicastprotokolle aus dem Stand
der Technik, dass Fluten von entweder Steuer- oder Multicast-Datenpaketen
ohne die Benutzung von speziellen Routern (Kerne oder Rendezvous-Punkte).
-
Das „Adaptive
Internet Routing (AIR) Protokoll",
welches in der gemeinsam zugewiesenen Patentanmeldung Nr. 09/221,228,
die am 23. Dezember 1998 eingereicht worden ist und der WO 0039967
A2 entspricht, basiert ebenso auf dem Quellroutingbaum-Ansatz. Es
ermöglicht
die Verteilung von Verbindungszustandinformation und Knotenzustandinformation
in der Form von benannten Routingbäumen (LRTs). Mit AIR sendet
ein Router Aktualisierungen an seinen Nachbarn, welche die Verbindungen
und Knoten in seinen bevorzugten Pfaden zu Zielen betreffen. Die
Verbindungen und Knoten entlang der bevorzugten Pfade von einer Quelle
zu jedem gewünschten
Ziel erzeugen einen LRT, der implizit die kompletten Pfade von der
Quelle zu jedem Ziel und die Charakteristik von jeder Verbindung
und jedem Knoten, die in diesen Pfaden verwendet werden, spezifiziert.
Die Ansammlung von benachbar ten Verbindungen und Routingbäumen, die
von Nachbarn berichtet worden sind, bilden die einem Router bekannte
Teiltopologie. Die vorliegende Erfindung nutzt AIR, um Multicast-Routing
in ad-hoc Netzwerken zu ermöglichen,
ohne die Notwendigkeit Kontroll- oder Multicast-Datenpakete zu fluten
oder jeder Multicastgruppe spezielle Router (z. B. Kerne) zuzuordnen.
-
ZUSAMMENFASSUNG
DER ERFINDUNG
-
Die
vorliegende Erfindung besteht aus einem Verfahren für den Aufbau
und die Verwaltung von Multicastnetzen in ad-hoc Netzwerken. Die
hier offenbarte Methode beruht auf dem Ausweiten eines Unicast-Routing-Protokolls basierend
auf dem Austausch von Routingbäumen
zwischen Nachbarroutern mit einem Bezeichnungsmechanismus, der benutzt
wird, um Multicastgruppen Mitgliedsinformation zu verbreiten, ohne
Fluten von Kontroll- oder Datenpaketen zu erfordern, um entweder
den Multicast-Routingbaum einer Gruppe zu finden oder alle Empfänger einer
Multicastgruppe zu erreichen. Da die Routingbäume, die in der vorliegenden Erfindung
genutzt werden, in den Router, mit denen sie kommunizieren, verwurzelt
sind, nennen wir diese Bäume
Quellbäume.
Weiterhin beziehen wir uns auf die aktuelle Erfindung als das „Multicast
Over Source Trees (MOST)" Protokoll.
-
In
einer bevorzugten Ausführungsform
der vorliegenden Erfindung wird das „Adaptive Internet Routing (AIR)" Protokoll, das in „A Unified
Routing Scheme for Ad-Hoc Internetworking", einer gemeinsam zugeordneten Patentanmeldung
Nr. 091221,228, die am 23. Dezember 1998 eingereicht worden ist
und der WO 0039967 A2 entspricht, als ein integraler Bestandteil
von MOST zur Verteilung von Information, in Bezug auf den Zustand
jeder Verbindung und jedes Routers in den bevorzugten Pfaden von
dem Router zu den bekannten Zielen des Netzwerkes benutzt. In AIR
spezifiziert der Quellbaum eines Routers für jeden "Knoten in dem Quellbaum die Adresse
des Kopfes der Verbindung, die in den Knoten einführt, die
Zustandsparameter der Verbindung und die Zustandsparameter des Knotens.
In MOST wird die Information für
jeden Knoten des Quellbaumes eines Routers angepasst, um Multicastgruppen-Mitgliedschaftsinformation
für jeden
Knoten zu enthalten. Jede Gruppenmitgliedschaft besteht aus der
Adresse einer Multicastgruppe, in der der Router teilnehmen muss,
da er wenigsten eine Schnittstelle mit einem Rechner hat, der die
Mitgliedschaft in der Multicastgruppe fordert.
-
Die
zwei Hauptkomponenten von MOST sind das Verfahren, das benutzt wird,
um Information in Bezug auf die Multicastgruppen, zu denen Router
gehören,
zu verbreiten und das Verfahren, das benutzt wird, um Multicastdatenpakete
in einem ad-hoc Netzwerk weiterzuleiten.
-
Ein
Router, der MOST benutzt, kennt den Verbindungszustand jeder ausgehenden
Verbindung, die ihm benachbart ist, mittels eines zugrunde liegenden
Verbindungsleveldienstes und empfängt die taktweisen Aktualisierungen
der Quellbäume
seiner Nachbarn. Diese Aktualisierungen spezifizieren den Zustand
der Verbindungen und Knoten, die einen Teil des Quellbaumes des
Nachbarn bilden. Basierend auf dieser Teiltopologieinformation wählt ein
Router seine eigenen bevorzugten Pfade für Unicast-Routing und erhält dadurch
seinen eigenen Quellbaum, in dem er einen lokalen Pfadauswahlalgorithmus
benutzt.
-
In
MOST kommuniziert ein Router all seine Multicastgruppen-Mitgliedschaften
an all seine Nachbarn. Um in einem ad-hoc Netzwerk einer Multicastgruppe
beizutreten, gibt ein Router einfach seine Mitgliedschaft in der
Gruppe an seine unmittelbaren Nachbarn bekannt.
-
Ein
Router verlässt
die Gruppe einfach, in dem er seinen unmittelbaren Nachbarn ankündigt, dass
er nicht länger
ein Mitglied der Gruppe ist. Ein neuer und einfacher Mechanismus
wird in MOST benutzt, um das Fluten von Gruppenmitgliedschaftinformationen,
wie es in MOSPF getan wird, zu verhindern. Ein Router leitet Gruppenmitgliedschaftsaktualisierungen
nur weiter, wenn die Quellbauminformation, die auf dem Router verfügbar ist,
anzeigt, dass wenigstens einer seiner Nachbarn die Gruppenmitgliedschaftsaktualisierung
erhalten muss, um all seine Gruppenmitglieder in dem ad-hoc Netzwerk
verbunden zu halten. Dementsprechend werden nur die Gruppenmitgliedschaftsaktualisierungen
der ersten wenigen Router, die Mitgliedschaft in einer neuen Multicastgruppe
anzeigen, an alle anderen Router als Teil der Routingtableaktualisierungen
verbreitet.
-
In
MOST kann ein Router durch ein Weiterleitungsverfahren, das viel
weniger rechenintensiv ist, als das Verfahren, das in dem Verbindungszustand
Multicast-Ansatz, der in MOSPF eingesetzt wird, angewandt wird,
entscheiden, ob ein Multicastdatenpaket, das er empfängt, weiterzuleiten
ist oder nicht,. In MOSPF benutzt ein Router lokal Dijkstras kürzesten-Pfad-Algorithmus,
um den Multicastroutingbaum von der Quelle eines Multicastpaketes
zu allen bekannten Empfängern
der vorgesehenen Multicastgruppe zu berechnen. Dementsprechend erzeugt
dieses Verfahren zu viel Overhead, wenn das Netzwerk groß wird und
die Anzahl der Gruppen und Quellen pro Gruppe zunimmt, obwohl ein
Router weiß,
wann ein Multicast-Datenpaket weiterzuleiten ist, da er lokal die
Multicastroutingbauminformation für jede Quelle der Multicastgruppe
berechnet. Im Gegensatz dazu leitet ein Router, der MOST benutzt,
ein Multicastdatenpaket weiter, wenn (a) das Paket von dem Nachbar
empfangen wird, der der nächste
Sprung in dem kürzesten
Pfad zu der Quelle des Multicastpaketes ist und (b) der Quellbaum,
der von dem Nachbar, der das Paket weiterleitet, berichtet worden
ist, den Router in einem Unterbaum mit wenigstens einem Router,
der als Mitglied der vorgesehenen Multicastgruppe berichtet worden
ist, hat.
-
Die
Erfindung bezieht sich auch auf ein Gerät zum Kommunizieren von Information über die
Mitgliedschaft in einer Multicastgruppe in einem Netzwerk zwischen
einer Vielzahl von Routern in einer Multicastgruppe, wobei jeder
aus der Vielzahl von Routern Routingbauminformation an andere Router
aus der Vielzahl von Routern berichtet, wobei das Gerät einen
ersten Routen umfasst, wobei der erste Router zum Empfangen von Aktualisierungsinformation
vorgesehen ist, die von einem zweiten Router übertragen wird und Aktualisierungsinformation über eine
Multicastgruppe enthält,
wobei der erste Router, wenigstens zum Teil basierend auf der Aktualisierungsinformation
und der Routingbauminformation, die von dem zweiten Router berichtet
worden ist, bestimmt, ob der erste Router die Aktualisierungsinformation
an wenigstens einem Nachbarn des ersten Routers übertragen muss, so dass alle
Mitglieder der Multicastgruppe verbunden bleiben, und wobei der
erste Router in Reaktion auf eine positive Feststellung, dass der
erste Router die Aktualisierungsinformation übertragen muss, die Aktualisierungsinformation
zu dem wenigstens einen Nachbarrouter überträgt.
-
Gemäß einem
vorteilhaften Aspekt der Erfindung beinhaltet die Aktualisierungsinformation
eine Kennung der Multicastgruppe oder eine Netzwerkadresse des ersten
Routers oder einen Hinweis, dass der zweite Router ein Mitglied
der Multicastgruppe wird. Gemäß einem
vorteilhaften Aspekt der Erfindung umfasst die Routingbauminformation
einen Quellbaum für
ein Unicast-Routing-Protokoll, wobei der erste Router bestimmt, ob
der erste Router die Aktualisierungsinformation übertragen muss, durch Bestimmen,
ob der Quellbaum, der von dem zweiten Router berichtet worden ist,
den ersten Router als Wurzel eines Unterbaumes hat, aus dem der
zweite Router ausgeschlossen ist, und wenigstens ein Nachbarrouter
des ersten Routers in diesem Unterbaum kein Mitglied der Multicastgruppe
ist.
-
Gemäß einem
vorteilhaften Aspekt der Erfindung bestimmt der erste Router weiterhin
durch Bestimmen, ob der zweite Router kein Mitglied der Multicastgruppe
ist, ob der erste Router die Aktualisierungsinformation übertragen
muss.
-
Gemäß einem
vorteilhaften Aspekt der Erfindung beinhaltet die Aktualisieruugsinformation
einen Zeitstempel und der erste Router bestimmt weiterhin durch
Bestimmen, ob der Zeitstempel gültig
ist, ob der erste Router die Aktualisierungsinformation übertragen
muss.
-
Gemäß einem
vorteilhaften Aspekt der Erfindung speichert der erste Router weiterhin
einen Zeitstempel, der mit der Multicastgruppe und dem zweiten Router
verknüpft
ist, wobei der Zeitstempel einen ersten Zeitstempel umfasst und
wobei der erste Router bestimmt, ob dieser Zeitstempel gültig ist
durch Bestimmen, ob der erste Zeitstempel jünger ist als der zweite Zeitstempel.
-
Gemäß einem
vorteilhaften Aspekt der Erfindung beinhaltet die Aktualisierungsinformation
einen Hinweis, dass der zweite Router nicht mehr Mitglied der Multicastgruppe
ist.
-
Gemäß einem
vorteilhaften Aspekt der Erfindung umfasst die Routingbauminformation
einen Quellbaum für
ein Unicastrouterprotokoll, wobei der erste Router bestimmt, ob
der erste Router die Aktualisierungsinformation übertragen muss durch Bestimmen,
ob der Quellbaum, der von dem zweiten Router berichtet worden ist,
den ersten Router als Wurzel eines Unterbaumes hat, aus dem der
zweite Router ausgeschlossen ist und wenigstens ein Nachbarrouter
des ersten Routers in dem Unterbaum ein Mitglied der Multicastgruppe
ist.
-
Gemäß einem
vorteilhaften Aspekt der Erfindung bestimmt der erste Router weiterhin,
ob der erste Router die Aktualisierungsinformation übertragen
muss, durch Bestimmen, ob der zweite Router kein Mitglied der Multicastgruppe
ist.
-
Gemäß einem
vorteilhaften Aspekt der Erfindung beinhaltet die Aktualisierungsinformation
einen Zeitstempel, wobei der erste Router weiterhin durch Bestimmen,
ob der Zeitstempel gültig
ist, bestimmt, ob der erste Router die Aktualisierungsinformation übertragen
muss.
-
Gemäß einem
vorteilhaften Aspekt der Erfindung speichert der Router weiterhin
einen Zeitstempel, der mit der Multicastgruppe und dem zweiten Router
verknüpft
ist, wobei der Zeitstempel einen ersten Zeitstempel umfasst und
wobei der erste Router durch Bestimmen, ob der erste Zeitstempel
jünger
als der zweite Zeitstempel ist, bestimmt, ob der Zeitstempel gültig ist.
-
Die
Erfindung umfasst ebenso eine Vorrichtung zum Weiterleiten von Multicastpaketen
in einem Netzwerk, das eine Vielzahl von Routern in einer Multicastgruppe
umfasst, wobei jeder aus der Vielzahl von Routern Routingbauminformation
an andere Router aus der Vielzahl der Routern berichtet, wobei die
Vorrichtung einen ersten Router umfasst, wobei der erste Router
zum Empfangen eines Multicastpaketes von einem zweiten Router in
einem Netzwerk und zum Bestimmen, wenigstens zum Teil basierend
auf der Steuerinformation und der Routerbauminformation, die von
dem zweiten Router berichtet worden ist, ob das Multicastpaket durch den
ersten Router weiterzuleiten ist, vorgesehen ist, und wobei der
erste Router, in Reaktion auf eine positive Bestimmung, dass das
Multicastpaket weiterzuleiten ist, das Multicastpaket an wenigstens
einem dritten Router weiterleitet.
-
Gemäß einem
vorteilhaften Aspekt der Erfindung beinhaltet das Multicastpaket
eine Adresse der Multicastgruppe.
-
Gemäß einem
vorteilhaften Aspekt der Erfindung beinhaltet das Multicastpaket
eine Adresse der Quelle des Multicastpaketes.
-
Gemäß einem
vorteilhaften Aspekt der Erfindung beinhaltet das Multicastpaket
einen Zeitwert, wobei der Zeitwert benutzt wird, um die Zeit zu
begrenzen, die das Multicastpaket in dem System verbleiben darf.
-
Gemäß einem
vorteilhaften Aspekt der Erfindung beinhaltet der erste Router weiterhin
einen Multicast-Weiterleitungscache, wobei der Multicast-Weiterleitungscache
einen Eintrag beinhaltet, der anzeigt, dass ein Multicastpaket von
einer ausgewählten
Quelle und für
eine ausgewählte
Multicastgruppe von dem ersten Router weitergeleitet werden sollte
und wobei der erste Router diesen Eintrag erzeugt, nachdem er eine
positive Bestimmung gemacht hat, dass das Multicastpaket weiterzuleiten
ist, wenn das Multicastpaket von der ausgewählten Quelle und für die ausgewählte Multicastgruppe
ist.
-
Gemäß einem
vorteilhaften Aspekt der Erfindung umfasst der erste Router einen
Multicastpaket-Weiterleitungscache, wobei der Multicastpaket-Weiterleitungscache
einen Eintrag beinhaltet, der jedes Multicastpaket anzeigt, das
kürzlich
von dem Router weitergeleitet worden ist.
-
Gemäß einem
vorteilhaften Aspekt der Erfindung umfasst die Routingbaum-Information,
die von dem zweiten Router berichtet worden ist, einen Quellbaum
für ein
Unicast-Routing-Protokoll, wobei der Schritt des Bestimmens umfasst,
zu bestimmen, ob der zweite Router der nächste Sprung innerhalb des
kürzesten
Pfades von dem ersten Router zu der Quelle des Multicastpaketes
gemäß dem Quellbaum
ist, und ob der Quellbaum einen ersten Router in einem Unterbaum
hat, wobei wenigstens ein Router in diesem Unterbaum ein Mitglied der
Multicastgruppe ist.
-
Ausführungsbeispiele
der Erfindung werden nun in Bezug auf die Zeichnungen beschrieben,
wobei:
-
1 ein
ad-hoc Netzwerk gemäß einem
Ausführungsbeispiel
der Erfindung zeigt.
-
AUSFÜHRLICHE
BESCHREIBUNG
-
Hierin
ist ein Verfahren zum Multicast-Routing in ad-hoc Netzwerken offenbart.
Obwohl unter Bezugnahme auf ein spezifisches Unicastroutingprotokoll
und gewisse anschauliche Ausführungsbeispiele
offenbart, sollte die folgende Beschreibung der Ausführungsbeispiele
von MOST nur als exemplarisch betrachtet werden und sollte nicht
erachtet werden, den – Umfang
zu beschränken.
Der Fachmann wird erkennen, dass die vorliegende Erfindung in einer
Vielzahl von Wegen implementiert werden kann und in einer Vielzahl
von Systemen angewendet werden kann.
-
I. Grundlegender Betrieb
und Architektur
-
Die
vorliegende Erfindung ist gut geeignet für ein ad-hoc Netzwerk, das
eine nahtlose Erweiterung des IP Internets in die drahtlose ad-hoc
Umgebung zur Verfügung
stellt. MOST wird beschrieben werden in Begriffen seines Betriebes
in Internet-Funkstationen oder IRs, die drahtlose Router sind. Es
wird jedoch für
Fachleute offensichtlich sein, dass MOST sich auf Computernetzwerke
und Internetnetzwerke bezieht, die nicht auf drahtlosen Verbindungen
zur Routerverbindung basieren müssen.
-
1 zeigt
Aspekte von einem beispielhaften ad-hoc Netzwerk, die beim Verstehen
der restlichen Diskussion helfen werden. Das in der Abbildung dargestellte
Netzwerk besteht aus einer Anzahl von Unternetzwerken 20, 30, 40, 50,
die eine Erweiterung des Internets durch eine Anzahl von Internet-Funkstationen
(IRs) 100a–100i zur
Verfügung
stellen. Jede IR 100a–100i ist
ein drahtloser Router mit einer IP Adresse und einer MAC Adresse.
Das ad-hoc Netzwerk 10 ist über einen Zugangspunkt, der „AirHead" genannt wird und
die 100h, der durch ein lokales Gebietsnetzwerk (local
area network „LAN") 40 mit
dem Internetrouter 200 verbunden ist, beinhaltet, verbunden.
Im Allgemeinen arbeiten IRs 100a–100i über eine
Vielzahl von Radiokanälen 1–3 unter
Benutzung von drahtlosen Kommunikationstechniken mit einem breiten
Spektrum, wie es im Stand der Technik üblich ist. Zum Beispiel können die
IRs 100a–100i in
einem der unregulierten UHF Frequenzbänder arbeiten, wodurch die
Notwendigkeit von Betriebslizenzen vermieden wird. Router 200 kann
durch einen Internetserviceprovider (ISP) betrieben werden. Wie
gezeigt, kann ein einzelner ISP ein LAN 40 betreiben, mit dem
die IR verbunden ist. In solch einem Modell fungiert IR 100h als
ein „AirHead", der einen Netzübergangsservice
zum Internet 900 zur Verfügung stellt. Einige können mit
Rechnern verknüpft
sein, auf die von jedem Internetnutzer durch das ad-hoc Netzwerk 100 zugegriffen
werden kann. Wie jeder Router, verarbeitet jede IR 100a–100i alle
Nachrichten, Änderungen
der Kosten eines benachbarten Links, Versagen eines benachbarten Links
und Nachrichten über
neue Nachbarn eine nach der anderen und in der Reihenfolge, in der
er sie feststellt.
-
Jede
IR 100a–100i in 1 kann
eine andere IR als benachbart betrachten (wir nennen solch eine
IR einen „Nachbarn"), wenn eine Funkverbindung
zwischen den zwei IRs besteht, und IR, z. B. IR 100a, Pakete von
dem anderen IR, z. B. IR 100d, empfangen und bestätigen kann.
Dementsprechend ist eine physikalische Verbreitungsverbindung, die
eine Vielzahl von IRs verbindet, auf eine Vielzahl von Punkt-zu-Punkt
bidirektionalen Verbindungen abgeleitet, die für die gleichen IRs definiert
sind. Jedes Paar von benachbarten IRs definiert zwei bidirektionale
Punkt-zu-Punkt Verbindungen zwischen ihnen, eine in jeder Richtung.
Jede bidirektionale Punkt-zu-Punkt Verbindung hat einen Kopfknoten
des Links und einen Schwanzknoten des Links.
-
Die
Beschreibung der vorliegenden Erfindung nimmt an, dass die Multicastdaten
oder Kontrollpakete, die von einer IR übertragen werden, von allen
Nachbarn der IR gehört
werden.
-
Die
vorliegende Erfindung kann zusammen mit jedem Kanalzugangsprotokoll
zur Anwendung gebracht werden. Es werden jedoch Details von gewissen
Ausführungsformen
zur Verfügung
gestellt, für
den Fall, in denen das Kanalzugangsprotokoll eine kollisionsfreie
Aussendung von einer IR zu all ihren Nachbar-IRs selbst in Anwesenheit
von versteckten IRs unterstützt,
und ein zugrunde liegendes Protokoll, welches wir das Nachbarprotokoll
nennen, sicherstellt, dass jede IR
100a–
100i innerhalb einer
begrenzten Zeit die Existenz einer neuen Nachbarn IR und dem Verlust
der Verbindung mit einer Nachbar IR erkennt. Die in der gemeinsam
zugewiesenen US-Patentanmeldung Nr. 09/418,899, die am 15. Oktober
1999 eingereicht worden ist (
US
6 788 702 ) und Nr. 09/248,738, die am 10. Februar 1999
eingereicht worden ist (US 2006/104301), offenbarten Kanalzugangsprotokolle
sind Beispiele für
Ausführungsbeispiele,
in denen die vorliegende Erfindung praktisch angewandt werden kann.
Das Nachbarprotokoll, das in der vorliegenden Erfindung angenommen
ist, kann durch Benutzen von Verbindungsschicht-Widersendungsstrategien, wie sie im
Stand der Technik üblich
sind, zur Anwendung gebracht werden.
-
MOST
wendet dieselbe Basisarchitektur an, wie sie in IP Multicast verwendet
wird. Es wird angenommen, dass ein Abbildungsservice existiert,
welcher IRs des ad-hoc Netzwerkes mit Adressen von Gruppen versorgt,
die durch ihre Domainnamen identifiziert werden. Im Internet würde dieser
Service z. B. vom Domain Name System (DNS) zur Verfügung gestellt
werden. Rechner, die einer Multicastgruppe beitreten wollen, müssen zuerst
den Abbildungsservice anfragen, um eine Gruppenadresse zu erhalten
und dann mit ihrer lokalen IR über
ein Rechnerzu-Rechner IR-Protokoll zusammenwirken, um die Mitgliedschaft
in einer Multicastgruppe anzufordern. Ein Beispiel für solch
ein Rechnerzu-IR-Protokoll ist das Internetgruppenmanagementprotokoll (IGMP)
in IP Version 4.
-
Zusätzlich zu
dem Benennungsservice, der von den Rechnern benutzt wird, um Multicastgruppenadressen
zu erhalten, nimmt MOST die Verfügbarkeit
von Quellbauminformation von einem Unicast-Routing-Protokoll an. Wie
wir vorher gesagt haben, wird in einem bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung das adaptive Internetrouting (AIR) Protokoll
als integraler Bestandteil von MOST für die Verteilung von Information
in Bezug auf den Zustand jeder Verbindung und IR in den bevorzugten
Pfaden von der IR zu den bekannten Zielen des ad-hoc Netzwerkes
verwendet. AIR ist in „A
Unified Routing Scheme for Ad-Hoc Internetworking" offenbart, einer
gemeinsam zugewiesenen Patentanmeldung Nr. 09/221,228, die am 23.
Dezember 1998 eingereicht worden ist und die der WO 0039967 A2 entspricht,
die dem Anmelder der vorliegenden Erfindung zugewiesen ist.
-
In
AIR spezifiziert der Quellbaum einer IR für jeden Knoten im Quellbaum
die Adresse des Kopfes der Verbindung, die in den Knoten einfällt, die
Zustandsparameter der Verbindung und die Zustandsparameter des Knotens.
-
Der
grundlegende von MOST zur Verfügung
gestellte Service ist die Wartung von Multicastgruppenmitgliedsinformation
auf eine verteilte Weise und das Ermöglichen, Datenpakete basierend
auf solchen Informationen und der Quellbauminformation, die von
dem Unicast-Routing-Protokoll,
das als ein integraler Bestandteil von MOST benutzt wird, zur Verfügung gestellt
wird, weiterzuleiten. Multicastdatenpakete werden basierend auf
dem Rückwärtspfadweiterleitungsmodell,
das zuerst von Dalal eingeführt
worden ist, weitergeleitet, in dem eine IR ein Multicastdatenpaket
nur weiterleitet, wenn es von einer Nachbar-IR empfangen worden ist,
der der Nachfolger der Quelle des Paketes entsprechend der Unicast-Routing-Tabelle
ist, die von der IR verwaltet wird.
-
II. Information, die in
MOST ausgetauscht und verwaltet wird
-
IRs
kommunizieren Aktualisierungen ihrer Gruppenmitgliedschaften unter
Benutzung von Multicastzustandsaktualisierungen (MSU). In einem
bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung werden MSUs unabhängig von den Aktualisierungen
ausgetauscht, die als Teil des Unicast-Routing-Protokolls, das in ad-hoc
Netzwerken verwendet wird, gesendet werden. In diesem Fall besteht
eine MSU aus den folgenden Elementen:
- a) Der
Netzwerkadresse des IR, der die MSU erzeugt hat
- b) Ein Zeitstempel, der die MSU gültig macht
- c) Das Kennzeichen einer Multicastgruppe (z. B. die Multicastadresse
der Gruppe)
- d) Ein Mitgliedflag, das auf 1 gesetzt wird, wenn die IR ein
Mitglied der Multicastgruppe wird oder bleibt, oder 0, wenn die
IR aufhört,
ein Mitglied der Multicastgruppe zu sein.
-
In
einem anderen bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung werden MSUs als Teil von Aktualisierungsmitteilungen
durch das AIR Protokoll gesandt. In diesem Fall besteht eine MSU
aus einer Liste von Gruppenmitgliedstupeln, die als Zustandsparameter
des Schwanzes einer Verbindung enthalten sind, die in einer Routingzustandsaktualisierung
(RSU) in AIR berichtet wird.
-
Jede
an MOST teilnehmende IR verwaltet die folgende Information als Teil
des Unicast-Routing-Protokolls, das zusammen mit MOST verwendet
wird:
- 1. Eine Unicast Routing Tabelle (URT):
An IR i spezifiziert die RT, die MOST zugänglich gemacht worden ist,
für jedes
Ziel j den Nachfolger und die Entfernung zum Ziel.
- 2. Ein Topologiegraph (TG): Der TG wird mit dem Quellbaum (ST),
der von jeder Nachbar-IR berichtet worden ist, und Information über ausgehende
benachbarte Verbindungen gebaut.
- 3. Ein Quellbaum (ST), der von der TG erhalten wird, die einen
lokalen Pfadauswahlalgorithmus, wie z. B. Dijkstras erstem kürzestem
Pfadalgorithmus laufen lässt.
-
Der
Feldeintrag für
die Verbindung von u nach v in dem TG von IR i besteht aus dem Tupel
(u, v, ts, {rn}, {1},{n}), wobei u und v jeweils die Netzwerkadressen
des Kopfes und des Schwanzes der Verbindung sind, ts der jüngste Zeitstempel
ist, der für
die Verbindung erhalten worden ist (u, v), {rn}, die Liste von Nachbar-IRs ist,
die die Verbindung berichtet haben, {1} ist eine Abfolge von Typenwertpaaren,
welche die Verbindungsparameter spezifizieren und {n} eine Sequenz
von Typenwertpaaren ist, welche die Knotenparameter spezifizieren.
-
Die
einzige Anforderung, die an den lokalen Pfadauswahlalgorithmus in
dieser Erfindung gestellt wird, ist, dass ein Knoten beim Berechnen
seiner Unicast Nachfolger zu den Zielen Quellbäume erzeugen muss. Zum Beispiel
impliziert, dass, wenn IR A von IRs 100a–100i IR
B von IRs 100c–100i als
seinen Nachfolger für das
Ziel D wählt,
es ebenso IR B für
jede dazwischen liegende IR in den bevorzugten Pfad von IR A zum
Ziel D wählt.
Alle IRs benutzen dieselbe Kostenmetrik, um ihre Quellbäume zu berechnen,
und nutzen auch dieselben Regeln zum Aufbrechen eines Unentschiedens,
um einen Nachfolger zu einem Ziel zu wählen.
-
Die
Kosten für
eine versagende Verbindung werden für jeden Typ des Routens als
unendlich betrachtet. Der Weg, in dem Kosten Links zugeordnet werden
oder spezifische Typen von Parametern Links und Knoten zum Unicast-Routen
zur Verfügung
gestellt werden, liegt außerhalb
des Bereiches dieser Beschreibung.
-
Zusätzlich zu
der zuvor genannten Information, die von dem Unicast Routing Protokoll,
das zusammen mit MOST verwendet wird, erfordert die vorliegende
Erfindung, dass jede Mitgliedsinformation für jede IR in dem ad-hoc Netzwerk
verwaltet.
-
Die
Gruppenmitgliedschaftsinformation, die eine IR für sich selbst verwaltet, ist
in einer Gruppenmitgliedschaftstabelle (GMT) gespeichert. Die GMT
von einer IR beinhaltet null oder mehr Einträge und jeder Eintrag spezifiziert
die folgende Information:
- (a) Die Kennung einer
Multicastgruppe, zu der die IR gehört
- (b) Der jüngste
Zeitstempel, der von der IR benutzt worden ist, um seinen Wechsel
der Zugehörigkeit
zu der Gruppe anzuzeigen.
-
Die
Gruppenmitgliedschaftsinformation, die eine IR X von IRs 100a–100i für jeder
anderen IR in dem ad-hoc Netzwerk verwaltet, besteht aus einer GMT
mit null oder mehr Einträgen,
wobei jeder dieser Einträge aus
der folgenden Information besteht:
- (c) Der
Kennung einer Multicastgruppe, zu der die IR gehört
- (d) Der jüngste
Zeitstempel, der von der IR benutzt worden ist, um seinen Wechsel
der Zugehörigkeit
zu der Gruppe anzuzeigen.
-
IR
X weist dem Zeitstempel, der mit einem nicht existierenden Eintrag
für eine
Multicastgruppenmitgliedschaft in der GMT verknüpft ist, die mit einer benachbarten
IR oder einer entfernten IR verknüpft ist, den Fehlwert 0 zu.
-
Da
das Unicast-Routing-Protokoll, das zusammen mit MOST verwendet wird,
erfordert, einen Topologiegraphen zu verwenden, der alle erreichbaren
Knoten in dem ad-hoc Netzwerk enthält, kann eine IR die Gruppenmitgliedschaftstabelle
(GMT) von anderen IRs als integralem Bestandteil seines TG verwalten
und die GMT wird dann ein weiterer Knotenparameter in dem TG.
-
Die
Gruppenmitgliedschaftstabelle, die in IR X für eine benachbarte oder entfernte
IR Y verwaltet wird, spezifiziert die Adressen der Multicastgruppen,
denen IR Y bekanntermaßen
angehört
und den jüngsten
Zeitstempel, der in einer MSU gehört wurde, die von IR Y erzeugt
worden ist.
-
III. Verbreiten von Gruppenmitgliedschaftsinformation
-
MOST
benutzt ein vom Empfänger
ausgelöstes
Verfahren zum Beitreten von IRs zu Multicastgruppen, das weitaus
einfacher ist als die bisher vorgeschlagenen Verfahren, die nicht
auf vollständiger
Topologieinformation beruhen. Ein Rechner bestimmt zuerst die Adresse
der Gruppe, der er als Empfänger
beitreten muss. Der Rechner benutzt dann diese Adresse, um seine
angehängten
IR zu bitten, der Gruppe beizutreten. Der Mechanismus, der von dem
Rechner benutzt wird, um die Adresse der vorgesehenen Multicastgruppe
zu finden und um mit seiner angehängten IR zusammenzuwirken,
ist außerhalb
des Bereiches der vorliegenden Erfindung.
-
In
einem Ausführungsbeispiel
der vorliegenden Erfindung bestimmt die IR auf den Empfang der Anforderung
eines Rechners, einer Gruppe beizutreten, durch Nachsehen in seiner
eigenen Gruppenmitgliedschaftstabelle (GMT) ob er seine Mitgliedschaft
bereits in der Multicastgruppe bekannt gegeben hat. Wenn in der
GMT kein Eintrag gefunden wird, sendet IR eine MSU an seine Nachbarn,
die MSU bestimmt, dass ein Mitgliedschaftsflag für die Gruppe auf 1 gesetzt
wird, um anzuzeigen, dass die IR nun ein Mitglied der Gruppe wird. Ähnlich gibt
die IR eine MSU aus, in der ein Mitgliedschaftsflag auf 0 zurückgesetzt
worden ist, um anzuzeigen, dass die IR nicht länger ein Mitglied der Multicastgruppe
ist, wenn kein verbundener Rechner fordert, ein Mitglied einer Multicastgruppe
zu sein, in der die IR seine Zugehörigkeit angekündigt hat.
-
Wenn
wiederum IR X von IRs 100a–1001 eine MSU von
der Nachbar-IR Y empfängt
und die MSU ein auf 1 gesetztes Mitgliedschaftsflag hat, dann leitet
IR X die MSU durch erneutes Übertragen
der MSU an seine eigenen Nachbarn weiter, wenn die folgenden Bedingungen
erfüllt
sind:
- a) Die MSU ist gültig.
- b) IR X ist kein Mitglied derselben Multicastgruppe, die in
dem Tupel der von der Nachbar-IR Y weitergeleiteten MSU enthalten
ist.
- c) Der Quellbaum, der von der Nachbar-IR Y berichtet worden
ist, hat IR X als Wurzel eines Unterbaumes, so dass
(1) der
Unterbaum IR Y ausschließt
(2)
wenigstens ein Nachbar von IR X in dem Unterbaum kein Mitglied der
Multicastgruppe ist, die in der MSU berichtet worden ist.
-
Wenn
IR X eine MSU von der Nachbar-IR Y empfängt und die MSU ein auf 0 gesetztes
Mitgliedschaftsflag hat, dann leitet IR X die MSU an seine eigenen
Nachbarn weiter durch erneutes Übertragen
der MSU, wenn die folgenden Bedingungen erfüllt sind:
- (a)
Die MSU ist gültig.
- (b) IR X ist ein Mitglied derselben Multicastgruppe, die in
dem Tupel der von dem Nachbarn IR Y weitergeleiteten MSU spezifiziert
ist.
- c) Der Quellbaum, der von der Nachbar-IR Y berichtet worden
ist, hat IR X als Wurzel eines Unterbaumes, so dass
(1) der
Unterbaum IR Y ausschließt
(2)
wenigstens ein Nachbar von IR X in dem Unterbaum ein Mitglied der
Multicastgruppe ist, die in der MSU berichtet worden ist.
-
IR
X bestimmt, dass eine MSU, die von IR Y erzeugt worden ist, gültig ist,
wenn der Zeitstempel in der MSU jünger ist als der Zeitstempelwert,
den IR X für
die Gruppe hat, die in der MSU spezifiziert ist und die IR, welche
die MSU erzeugt hat.
-
Der
folgende Pseudocode veranschaulicht eine beispielhafte Ausführungsform
des Verfahrens mit dem ein IR entscheidet, von seinem Nachbarn empfangene
MSUs weiterzuleiten oder nicht.
-
Prozedur Process_MSU
-
-
- SIR:
- Knotenidentifikation
der IR, von dem die MSU emfangend wird,
- SNS:
- eigener Nachbar, der
im Vefahren als benutzt gesetzt ist
- MSU:
- von der Nachbar-IR
empfangene MSU
- MSU.ts:
- Zeitstempel in der
MSU
- MSU.group:
- in der MSU angekündigte Multicastgruppe
- MSU.source:
- IR, welche die MSU
erzeugt
- MSU.flag:
- Mitgliedschafts-Flag
in der MSU
- ST(x):
- von der Nachbar-IR
x berichteter Quellbaum
- GMT(x):
- für IR x gepflegte GMT
- GMT(x).ts:
- Zeitstempel in GMT
für IR
x
- self:
- IR, die das Verfahren
ausführt
-
-
-
-
Die
Prozedur Correct_MSU korrigiert einfach den Zeitstempel einer benachbarten
IR für
eine vorgegebene Multicastgruppe oder zwingt die IR, der eine MSU
empfängt,
seinen Zeitstempel für
eine vorgegebene Gruppe jünger
zu machen. Ein anderes vorteilhaftes Ausführungsbeispiel der vorliegenden
Erfindung kann die Überprüfung von
MSUs bearbeiten, in dem eine Vorgangsnummer und ein Alterungsmechanismus
benutzt werden, die in Verbindungszustands-Routingprotokollen nach
dem Stand der Technik üblich
sind.
-
Der
Ausfall von Verbindungen oder IRs hat in der vorliegenden Erfindung
keine Auswirkung auf die Verbreitung von Gruppenmitgliedschaftsinformation,
da die IRs einfach ihre eigenen Mitgliedschaften an ihre Nachbarn
bekannt geben und Gruppenmitgliedschaftsinformation nur dann an
ihre eigenen Nachbarn weiterleiten, wenn sie bestimmen, dass einige
von ihnen diese Information benötigen
könnten.
Im Gegensatz dazu unterbricht in baumbasierten Multicastroutingprotokollen,
die auf vom Empfänger
ausgelöstem
Verbinden beruhen (z. B. CBT und PIM-SM), der Ausfall des Kerns oder Rendezvouspunktes
den Multicastbaum und verhindert, dass neue Mitglieder beitreten,
bis ein neuer ausgewählt
ist und allen IRs bekannt gemacht worden ist. Weiterhin kann das
Versagen von Kernen in netzbasierten Multicastroutingprotokollen
wie CAMP ein Fluten veranlassen, um das Versagen aller Kerne zu überleben.
-
IV. Multicastpaket-Weiterleitung
-
Das
grundlegende Paketweiterleitungsschema in MOST besteht aus dem Weiterleiten
von Multicastdatenpaketen entlang der rückwärtigen kürzesten Pfade von der Quelle
der Pakete.
-
Die
Hauptsteuerinformation in einem Multicastpaket ist: Die Adresse
der vorgesehenen Multicastgruppe, die Adresse der Quelle des Paketes,
eine Abfolgenummer, die für
Steuerfunktionen benutzt wird, und eine Lebenszeit, die benutzt
wird, um die Zeit zu begrenzen, die jedem Paket erlaubt wird, in
dem Netzwerk zu verbleiben.
-
Ein
IR, der mit dem Quellrechner eines Paketes verbunden ist, überträgt das Paket
einfach an seinen Nachbarn.
-
Wenn
IR X von IRs 100a–100i ein
Muticastpaket ohne Fehler von der Nachbar-IR Y von IRs 100a–100i empfängt, leitet
IR X das Paket weiter, wenn die folgenden Bedingungen erfüllt sind:
- 1. Gemäß der Unicast
Routing Tabelle von IR X ist IR Y der Nachfolger (nächster Sprung)
zur Quelle des Paketes.
- 2. Der Unterbaum, der sich aus dem Ausschließen von IR Y und aller IRs
und aller Ziele, für
die Y der Nachfolger ist, ergibt, enthält wenigstens eine IR, die
ein Mitglied der Multicastgruppe ist, für die das Paket vorgesehen
ist.
-
Der
folgende Pseudocode veranschaulicht in einem beispielhaften Ausführungsbeispiel,
wie ein IR dies durch eine neue Modifikation von Dijkstras kürzester-Pfad-zu-erst
Algorithmus erreicht, möglich
gemacht, durch die Tatsache, dass die IRs Quellbäume verwalten. Die IR, welche
die Prozedur ausführt,
durchsucht einfach seinen Quellbaum, um zu versuchen, die nächste IR
zu finden, der kein Mitglied der Zielgruppe ist und in dem Quellbaum
durch einen Pfad erreicht wird, der den Nachbar IR, der das Multicastdatenpaket
weitergeleitet hat, nicht enthält.
-
Procedure Multicast_Forwarding
-
- {wird aufegrufen, wenn ein Multicastdatenpaket korrect empfangen
wird}
- URT:
- Unicast Routing Tabelle
- SIR:
- Knotenindentifikation
der IR, von der das Multicastpaket empfangen wird
- SOURCE:
- Quelle des Multicastpakets
- DEST:
- Zielgruppe des Multicastpakets
- URT(X):
- Reihe der von X spezifizierten
URT
- URT(X).s.
- Nachfolger (nächster Sprung)
zum Ziel X
-
-
Procedure Find_Members(root,group)
-
- {wird aufgerufen, wenn die IR Abkömmlinge in Quellbaum für eine Multicastgruppe
bestimmen muss}
- root:
- Wurzel des in der
Suche abzuschneidenen Unterbaumes
- group:
- in der Suche interessierende
Multicastgruppe
- ST:
- Quellbaum der das
Verfahrenen ausführenden
IR
- ST.n:
- Knoten in ST
- self:
- Knoten, der die Prozedur
ausführt
- D(self,n):
- Abstand vom Knoten "self" zum Knoten in ST
- P(self,n):
- Pfad entlang ST von "self" zu n
- l(x,y):
- Kosten der Verbindung
von x nach y
- CMF:
- nächstliegendes Mitglied, das
in dem Verfahren zuerst als benutzt gesetzt wird
-
-
-
Die
Prozedur Send_Packet verarbeitet einfach zusätzliche Paketkopfinformation,
wie z. B. Lebenszeit, um zu entscheiden, ob das Paket übertragen
werden soll oder nicht.
-
Die
Multicastpaketweiterleitung in MOST ist sehr viel effizienter als
in den Verbindungszustands-Multicastansätzen, wie sie im Stand der
Technik beschrieben werden, wie z. B. MOSPF. Dies beruht auf der
Tatsache, dass die Prozedur Find_Members sehr viel schneller ist
als der Ansatz, der in den Verbindungszustands-Multicastansätzen im
Stand der Technik verwendet wird. Erstens wird die Suche in der
Prozedur Find_Members über
eine Baumtopologie ausgeführt
(der Quellbaum der IR, der die Suche ausführt) statt über die gesamte Netzwerktopologie, wie
es in den Verbindungszustands-Multicastansätzen im Stand der Technik getan
wird. Zweitens, endet die Suche, die in der Prozedur Find_Members
implementiert ist, mit dem ersten Auftreten einer IR, die ein Mitglied
der vorgesehenen Multicastgruppe ist, statt erschöpfend nach
allen Knoten in der Topologie zu suchen, um einen Multicastroutingbaum
aufzubauen, wie es in den Verbindungszustands-Multicastansätzen gemäß dem Stand der Technik getan
wird.
-
Weiterhin
kann in einem anderen bevorzugten Ausführungsbeispiel der vorliegenden
Erfindung eine IR einen Multicastweiterleitungscache (MFC) verwalten.
Ein Eintrag in dem MFC der IR X spezifiziert die Adresse einer Multicastgruppe
und die Adresse einer Quelle in der Multicastgruppe. IR X fügt in dem
Cache einen Eintrag hinzu, wenn er bestimmt, dass ein Paket von
einer vorgegebenen Quelle S für
eine vorgegebene Multicastgruppe G weitergeleitet werden sollte,
da der Unterbaum, der sich aus dem Ausschließen von IR Y, von dem das Paket
empfangen worden ist und aller IRs und Ziele, für die Y der Nachfolger ist,
ergibt, wenigstens eine IR enthält,
die ein Mitglied der Multicastgruppe ist, für die das Paket vorgesehen
ist. Dementsprechend kann IR X ein Multicastdatenpaket, in dem Fall,
dass das Paket zu einer Quelle und einer Gruppe gehört, die
zu einem Eintrag in der MFC passen, mit weniger Verarbeitungs Overhead
weiterleiten.
-
Procedure
CACHE_Forwarding
-
- {wird aufgerufen, wenn das Multicastdatenpaket korrekt empfangen
wird}
- URT:
- Unicast Routing Tabelle
- SIR:
- Knotenidentifikation
des IR von dem das Multicastpaket empfangen wirf
- SOURCE:
- Quelle des Mulitcastpaketes
- DEST:
- Zielgruppe des Mulitcastpaketes
- URT(X):
- durch X spezifizierte
Reihe der URT
- URT(X).s:
- Nachfolger (nächster Sprung)
zum Ziel X
- MFC:
- Mulicastweiterleitungs-Cache
- MFC(X,Y):
- Quelle X und Gruppe
Y im MFC
- X.Y:
- Verknüpfung der
Identifikationen X und Y
-
-
In
einem bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung verwaltet eine IR auch einen Multicastpaketweiterleitungscache
(MPC), um zu vermeiden, dass irgendein Multicastdatenpaket mehr
als einmal weitergeleitet wird. Der MPC von IR i verwaltet einen
Eintrag für
jedes Multicastdatenpaket, das kürzlich weitergeleitet
worden ist. Die Information, die in dieser Datenstruktur gehalten
wird, wird von den Köpfen
der Multicastdatenpakete erhalten und sollte ausreichend sein, dass
die IR zwischen zwei beliebigen Multicastdatenpaketen unterscheiden
kann. In dem Fall, in dem Multicast IP Pakete in dem ad-hoc Netzwerk
verwendet werden, besteht diese Information aus der Quelladresse,
der Zieladresse (Gruppenadresse), Paketidentifikation und Teilversatz.
Die Adresse des Nachbarn, der das Paket weitergeleitet hat, ist
ebenso gespeichert. Die Hauptrolle des Paketweiterleitungscaches
ist es, die Wiederholung von Paketen durch Buch führen über Pakete,
die von dem IR bereits empfangen worden sind, zu verhindern. Das
Zwischenspeichern (Caching) von Paketen ist nur ausführbar für Kanäle mit geringer
Bandbreite und muss nur als Vorsichtsmaßnahme benutzt werden, wenn
die Topologie des ad-hoc Netzwerkes sehr dynamisch ist und die Routingtabelle
sehr instabil ist.
-
Obwohl
die Erfindung im Zusammenhang mit verschiedenen Ausführungsbeispielen
beschrieben worden ist, sollte vom Fachmann erkannt werden, dass
eine Anzahl von Modifikationen dieser Lehren auftreten kann. Während die
Erfindung insbesondere in Bezug auf diese speziellen Ausführungsbeispiele
gezeigt und beschrieben worden ist, ist zu verstehen, dass Änderungen
in der Ausgestaltung und Reichweite gemacht werden können, ohne
von dem Gültigkeitsbereich
der Erfindung, wie er durch die beigefügten Ansprüche definiert wird, abzuweisen.
