-
TECHNISCHES FELD
-
Die
vorliegende Erfindung betrifft eine Netzverbindung und Kommunikationstechnologie,
insbesondere Multicasting von Informationen von einer Quelle zu
einem oder zu mehreren Hosts in einem digitalen Kommunikationsnetz.
-
HINTERGRUND
-
Digitale
Kommunikationsnetze, wie das Internet, sind wohlbekannte Systeme,
die es erlauben, Informationen, die in einem Standort gespeichert
sind, an einen oder mehrere sich an geographisch unterschiedlichen
Standorten befindlichen Benutzer zu verteilen. Die Information (auch
hierin als eine "Nachricht" bezeichnet) kann
eine Anzahl von Formen einschließlich, aber nicht einschränkend, Text,
Tonstillimage, und Videoinformationen annehmen.
-
Während es
nicht ungewöhnlich
ist ein digitales Kommunikationsnetz für den Transport von Informationen
(wie zum Beispiel eine Datei) von einer Quelle zu einer Bestimmung
zu nutzen, wird es zunehmend wünschenswert
die gleichen Informationen von einer Quelle zu mehreren Bestimmungen
zu kommunizieren. Zum Beispiel ist es üblich, dass mehrere Empfänger die
gleiche Information, wie Streamingvideo, die von einer einzelnen
Internetseite stammt, ansehen.
-
Eine
Technik, die es erlaubt, Informationen zwischen einer Mehrheit von
Quellen und Bestimmungen zu kommunizieren, wird "Multicasting" genannt. Beispielsweise, Multicasting,
wie vom Internet-Protokoll (IP) unterstützt, ist folgendermaßen definiert
worden: "IP Multicast
ist die effiziente Übermittlung
eines IP Datagram zu einer Gruppe aufweisend keine oder mehrere
Hosts, identifiziert mittels einer einzelnen IP-Zieladresse." (Deering, 1989).
Dies wird im Folgenden detailliert diskutiert.
-
In
dem Folgenden wird das IP-Multicasting behandelt. IP (und andere
Typen von) Multicast unterstützt effizient
eine eins-zu-mehreren und mehrere-zu-mehreren Übermittlung durch das Verschicken
einer einzelnen Kopie einer Nachricht von der Quelle an mehrere
Empfänger,
die mittels einer indirekten einzelnen IP Klasse D Multicast Adresse
identifiziert werden, wer ausdrücklich
die Informationen empfangen will. Dieser Mechanismus ist viel effizienter
als das gleichzeitige vielfache Verschicken von Nachrichten an jeden
Empfänger
oder als Broadcasting der Nachricht an alle Knoten in dem Netz.
IP-Multicasting ist eine natürliche
Lösung
für Multiparty-Konferenz wegen der
Leistungsfähigkeit
der Datenauslieferungsbäume,
wie zum Beispiel die Spanning Bäume,
in denen die Daten eher an angemessenen Punkten im Netz als in Endsystemen
reproduziert werden.
-
Multicasting
basiert auf einer Serie von bestimmten Protokollen, die "auf der Spitze (eines
existierenden Protokolls) reiten" um
die Daten an alle interessierten Parteien zu verteilen. Mit IP Multicast
müssen
die Empfänger
nicht wissen wer oder wo die Absender sind, um den Datenfluss von
ihnen zu empfangen. Die Absender müssen niemals wissen, wer die
Empfänger
sind. Weder die Absender noch die Empfänger müssen sich um die Netztopologie
kümmern,
weil das Netz die Auslieferung optimiert.
-
Multicast
ist ein empfänger-basiertes
Konzept; die Empfänger
schließen
sich einer besonderen Multicastsitzungsgruppe ein, indem sie ein
Protokoll wie das Internet-Gruppen-Management-Protokoll
(IGMP) benutzen, um einen Multicast-Router in ihrem Unternetz über ihre
Absicht zu informieren. Datenfluss wird dann allen Mitgliedern dieser
Gruppe mittels der Netzinfrastruktur zugestellt. Um gegenwärtige Mitgliedschaft
zu überprüfen, schickt
der lokale Multicast-Router periodisch eine IGMP-Hostmitgliedschaftsanfrage an die „alle Hosts" Gruppe. Um Stauung
zu vermeiden, die sonst auftreten würde, wenn jeder Mitgliederhost
auf die Anfrage reagieren würde,
verzögert
jeder Host die Übermittlung
seines Berichts mittels eines Zufallszeitintervalls. Am Ende des
Zeitintervalls schickt der Host seinen Bericht, nur wenn er keinen
Bericht von einem anderen Host aus der gleichen Gruppe gesehen hat.
Dadurch wird nur ein Mitgliedschaftsbericht als Antwort für jede aktive
Gruppenadresse geschickt, obwohl viele Hosts Mitglieder sein können. IGMP
kann auch benutzt werden, um die Gruppenmitgliedschaftsinformationen
von dem lokalen Router an die anderen Multicast-Router weiterzuleiten.
-
Zwecks
der Auslieferung eines Multicast-Datenpakets von der Quelle zu den
Zielknoten in anderen Netzen, müssen
Multicast-Router die Informationen, die sie über die Grupenmitgliedschaft
der Hosts, die direkt an die Multicast-Router verbunden sind, gesammelt
haben, austauschen. Es gibt viele unterschiedliche Algorithmen und
Protokolle zum Austausch dieser Routing-Informationen, wie Entfernungs-Vektor-Multicast-Routingsprotokoll
(Distance Vector Multicast Routing Protocol) (DVMRP), Multicast
Erweiterung für
den Offenen Zuerst-Kürzester
Weg (Multicast extension to Open Shortest Path First) (MOSPF), und
Protokoll-Unabhängiges
Multicast (Protocol Independent Multicast) (PIM). Basierend auf
der Routing-Information erhalten von einem der Protokolle, entscheiden
die Multicast-Router – wann
auch immer ein Multicast-Datenpaket zu einer Multicastgruppe geschickt
wird-, ob dieses Datenpaket zu ihrem(n) Netzwerk(en) weiterzuleiten
ist oder nicht. Anschließend
bestimmt der „Blatt"-Router, ob es ein
Mitglied der besonderen Gruppe in an ihm physikalisch angeschlossenen
Netzen basierend auf der IGMP Information gibt, und entscheidet
das Datenpaket weiterzuleiten oder nicht.
-
Wenn
der Sender seine Information schichtet (z. B. Video oder Audio Stream),
können
verschiedene Empfänger
unterschiedliche Mengen an Daten empfangen und daher unterschiedliche
Qualitäten
wählen.
Um dies zu erreichen, muss der Absender die Informationen als eine
Basisschicht (die geringste Qualität, die annehmbar sein könnte) und
als eine Anzahl von Erweiterungsschichten kodieren, wobei jede der
Schichten mehr Qualität
auf die Kosten von mehr Bandbreite hinzufügt. Wenn die Information zum
Beispiel Videoinformationen ist, könnten diese zusätzlichen
Schichten die Rahmenrate oder die räumliche Auflösung der
Bilder oder beides vergrößern. Jede
Schicht wird an eine unterschiedliche Multicastgruppe geschickt
und die Empfänger
können
individuell über
die Anzahl der Schichten zu denen sie sich anmelden, entscheiden.
-
1 zeigt
ein Beispiel eines IP-Multicast-Szenarios, in dem ein Informationsstream
(beispielsweise ein Videostream) zu jedem von den vier Empfängern geschickt
wird: ein erster Client 101, ein zweiter Client 103,
ein dritter Client 105, und ein vierter Client 107.
Ein erster Multicast-Router (MR1) 109 ist fähig, Routing von
Informationen zwischen einer Quelle 111 und einem zweiten
(MR2) und einem dritten (MR3) Multicast-Router 113, 115 durchzuführen.
-
Der
erste und zweite Client 101, 103 haben sich der
Gruppe durch das Informieren des zweiten Multicast Routers 113 angeschlossen;
und der dritte und vierte Client 105, 107 haben
das Gleiche mit dem dritten Multicast-Router 115 gemacht.
Der erste Client 101 empfängt eine Basisschicht (Datenpakete
vermerkt mit "A1"), die für ein Codec,
optimiert beispielsweise für
drahtlose Umgebungen, geeignet ist, während der zweite Client 103 diese
Basisschicht und eine zusätzliche
Schicht (Datenpakete vermerkt mit "A2")
für eine
bessere Dienstgüte,
beispielsweise eine bessere Videoqualität, empfängt. Der dritte und vierte
Client 105, 107 empfangen jeweils eine unterschiedliche
Basisschicht von Datenpaketen, beispielsweise eine Schicht, die
für einen verdrahten
Codec geeigneten ist, mit "B1" vermerkte Schicht.
-
Um
eine effiziente Übermittlung
zu erreichen, wird ein Spanning Baum errichtet, der alle Mitglieder
der Multicast-Gruppe verbindet. Nur eine Kopie einer Multicast-Nachricht
passiert eine Netzwerkverbindung (zwischen dem Quelleserver 111 und
dem ersten Multicast-Router, MR1, 109), und Kopien der
Nachricht werden nur wo Wege auseinander gehen in einem Router (z.
B., an den drei Multicast-Routern MR1 109, MR2 113 und MR3 115)
erstellt. Beachten Sie, dass das Zusammenfügen von Multicast-Streams an
den Punkten der Datenflussreplizierung (wie MR1 109, MR2 113 und
MR3 115) komplexe Algorithmen erfordert.
-
Mehr
Informationen über
IP-Multicasting können
in Andrew S. Tanenbaum, „Computer
Networks", Dritter
Ausgabe, Prentice-Hall, New Jersey, 1996, gefunden werden; und auf
der Internetseite für "IP-Multicast-Initiative
(IPMI)":
www.ipmulticast.com
-
In
dem Folgenden wird ein zuverlässiges
Multicasting behandelt. IP Multicast ist unzuverlässig (basiert auf
User Datagram Protocol, oder "UDP") und stellt die
beste Auslieferung bezüglich
des Aufwands (best effort delivery) bereit, die in gelegentlichen
Datenpaketverlusten resultiert. Für viele Multicast-Anwendungen,
die in Echtzeit, wie zum Beispiel Audio und Video, funktionieren,
kann dies annehmbar sein (solange der Datenpaketverlust innerhalb
einer sinnvollen Grenze liegt). Allerdings, für einige Anwendungen wie beispielsweise
die Synchronisierungsnachrichten zwischen Kopien, ist es notwendig
sicherzustellen, dass keine kritischen Informationen verloren gehen
werden.
-
Einige
der typischen Probleme, denen die zuverlässigen Multicast-Protokolle
gerecht werden müssen, sind
die folgenden:
- • Netzwerküberlastung, wenn ein Datenpaketempfang
bestätigt
wird (ACK) oder Datenpaketverlust angezeigt wird (NACK), auch als
die ACK/NACK-Implosionseffekt
bekannt. Dies wird üblicherweise
mittels Aggregation-Mechanismen
gelöst.
- • Gruppen-Management;
geschlossene, offen begrenzte und offen unbegrenzte Gruppen
- • Überlastung
Kontrolle
- • Skalierbarkeit
-
Eine
Vielfalt von zuverlässigen
Protokollen und Rahmenwerken (wie zum Beispiel das Zuverlässige Multicast
Rahmenwerk (Reliable Multicast Framework)) wurden für die Multicast-Datenauslieferung
vorgeschlagen. Im Gegensatz zu dem Unicast Fall, in dem die Anforderungen
an eine zuverlässige,
sequenzielle Datenzustellung ziemlich allgemein sind, haben Multicast-Anwendungen
weit unterschiedliche Anforderungen an die Zuverlässigkeit.
Zum Beispiel benötigen
einige Anwendungen, dass die Datenauslieferung einer totalen Ordnung
gehorcht, während
viele andere erfordern dies nicht. In einigen Anwendungen senden
viele oder alle Mitglieder die Daten, während in anderen nur eine Datenquelle
vorgesehen ist. Einige Anwendungen haben replizierte Daten, so sind
einige Mitglieder fähig,
einen Datenelement zu übertragen,
während
für alle
anderen die Daten von einer einzelnen Quelle stammen. Diese Unterschiede
beeinflussen das Design eines zuverlässigen Multicast-Protokolls.
Einige Beispiele von zuverlässigen
Multicast-Protokollen sind: Zuverlässiges Multicast Protokoll
(Reliable Multicast Protokol RMP), Skalierbares Zuverlässiges Multicast
(Scalable Reliable Multicast SRM), Zuverlässiges Multicast Transport-Protokoll
(Reliable Multicast Transport Protokol RMTP), Multicast Datei-Übertragungs-Protokoll (Multicast
File Transfer Protokol MFTP).
-
Die
RMT Arbeitsgemeinschaft in IETF erwartet unterschiedliche Protokoll-Instanzen zunächst für die eins-zu-mehreren
Multicast-Anwendungen zu standardisieren. Dies ist zu finden auf
der Internetseite der RMT Arbeitsgemeinschaft in IETF unter www.ietf.org/html.charters/rmt-charter.htm/.
-
Mehr
Informationen über
das zuverlässige
Multicast können
zum Beispiel auf der IP-Multicast-Initiative (IPMI) unter website:
www.ipmulticast.com gefunden werden.
-
In
dem Folgenden wird das Echtzeit-Transport-(Kontroll)Protokoll (Real-Time
Transport(Control)Protocol RT(C)P)behandelt. Das Echtzeit-Transport-Protokoll
(RTP) stellt Ende-zu-Ende Netzwerktransportfunktionen bereit, die
für Echtzeitdaten
sendende Anwendungen, wie Audio, Video oder Simulationsdaten über Multicast-
oder Unicast Dienste, geeignet sind. Die von RTP bereitgestellten
Funktionen beinhalten Identifikation des Nutzsignaltyps, Folgennummerierung,
Timestamping, und das Monitoren der Auslieferung.
-
Der
Datentransport wird mittels eines Kontrollprotokolls(RTCP)aufgebessert,
das benutzt wird, um die Dienstgüte
zu überwachen
(QoS) und Informationen über
die Teilnehmer in einer andauernden Sitzung zu übertragen. Jeder Medienstream
in einer Konferenz wird als eine getrennte RTP-Sitzung mit einem
getrennten RTCP-Stream übertragen.
RTCP-Berichte sorgen für
Statistik über
die von einer Quelle empfangenen Daten, wie beispielsweise die Anzahl
von Datenpaketsverlusten seit dem vorletzten Bericht, die kumulative
Anzahl von Datenpaketverlusten, das inter-arrival Jitter, und dergleichen.
-
In
dem Folgenden wird die Replizierung und Synchronisierung, wie beispielsweise
Quorums-Konsens-Synchronisierung behandelt. Ein Dienst oder Ressource
wird "reproduziert", wenn es über vielfache
logisch identische Instanzen erscheinend auf verschiedenen Knoten
im Netz verfügt.
Eine Anfrage bezüglich
des Zugangs zu der Ressource kann zu einer beliebigen Instanz gerichtet
werden. Einige Mechanismen sind vorhanden, um die unterschiedlichen
Kopien, auch Repliken genannt, zu synchronisieren und diese konsistent
zu halten. Im Falle einer Replizierung wird ein unterschiedlicher
Dienstszugangspunkt, beispielsweise IP-Adresse für jede Dienstinstanz benutzt.
-
Die
Hauptgründe
für die
Replizierung von Diensten sind die folgenden:
Lastverteilung
(Dienst kopiert zu mehreren Hosts)
Performanceverbesserung
(Dienst kopiert zu mehreren Hosts und
gegebenenfalls näher dem
aktuellen Client(s))
Verfügbarkeit
(Dienst kopiert zu mehreren Hosts)
Replizierung wird normalerweise
benutzt, wenn alle Clients einen Schreibzugriff zu dem ganzen Dienst
benötigen
(oder wenn der Dienst nicht in getrennte Einheiten aufgeteilt werden
kann).
-
In
dem Folgenden wird die Repliksynchronisierung behandelt. Im Falle
von gemeinsam genutzten Daten verteilt im Netz, können Teilnehmer
versuchen, ein gemeinsam genutztes Objekt (fast) gleichzeitig zu
manipulieren. Die gleichzeitigen Aktionen auf einem gemeinsam genutzten
Objekt können
in inkonsistenten Ansichten bei den Benutzern resultieren. Ohne
sorgfältige
Koordination würde
eine Folge von gleichzeitigen Aktionen unterschiedliche Ansichten
von den gemeinsam genutzten Daten verursachen.
-
Reproduzierte
Ressourcen müssen
synchronisiert/konsistent/zusammenhängend gehalten werden; das
heißt,
der Schreibzugriff muss allen Kopien mitgeteilt werden. Es gibt
hauptsächlich
zwei Methoden für
solche Synchronisierung:
-
In
dem Folgenden wird die Master/Slave-Strategie behandelt. In dieser
Methode gibt es einen primären
Server, der die Orginalkopie hält,
und mehrere sekundäre
Server (für
jede Replik). Die Orginalkopie bedient alle Updateanfragen, während die
Slave-Kopien durch
Empfangen von Änderungen
oder durch Aufnahme von Kopien von dem primären Server, aktualisiert (synchronisiert)
werden. Die Clients können
Daten sowohl von dem Server als auch von dem Slave-Vertreter lesen.
-
Der
primäre
Server kann flexibel oder fest sein. Im Falle eines flexiblen primären Servers
kann das Schreiben auf jedem Server durchgeführt werden. Der entsprechende
Server übernimmt
dann die Verantwortung für
das Aktualisieren aller Kopien. Dieses Verfahren wird auch Read-One-Write-All
genannt (ROWA). Im Falle eines festen Servers (auch "einfaches ROWA" genannt) ist das
Schreiben nur auf dem Server erlaubt. Obwohl dieser Mechanismus
einen zentralen Ausfallpunkt (der primäre Server) hat, erleichtert
die zentralisierte Kontrolle die Konflikte zwischen den Anfragen
zu lösen
und somit die Konsistenz aufrechtzuerhalten. Mehrere Verbesserungen
sind für
beide primäre
Servermodelle, das flexible und das feste, definiert worden.
-
In
dem Folgenden wird die verteilte Updatekontrolle (Abstimmung) behandelt.
Diese Methode ist robuster als die Master/Slave-Strategie, weil
kein zentraler Ausfallpunkt (Master) vorgesehen ist. Die Grundidee ist,
von den Kunden zu verlangen, dass diese eine Anfrage tätigen und
das Erlaubnis von mehreren Servern erwerben, bevor eine reproduzierte
Datei gelesen oder geschrieben wird. Die entsprechenden Strategien
sind als Quorums-Konsens (QC) Mechanismen bekannt.
-
Mehrere
Variationen sind definiert worden, wie beispielsweise:
Einheitliches
Mehrheits-QC: ein Erlaubnis von einer Mehrheit der
Servern
wird für
jeden Schreib- und Lesezugriff benötigt.
Gewichteter Mehrheit-QC: ähnlich wie
Uniform Mehrheit-QC, außer,
dass
ein Server mehr als eine Stimme haben kann (beispielsweise,
ein
zuverlässiger
oder ein Hochleistungsserver).
-
Abstimmung
mit Geistern: ein unechter (Geist) Server wird für jeden Server, der nicht aktiv
ist, benutzt. Das Geist kann sich nur dem Schreib-Quorum anschließen. Dieser
Mechanismus stellt sicher, dass ein Schreib-QC auch möglich ist,
falls ein paar Server nicht aktiv sind (da oft das Schreib-Quorum
aus mehreren Servern besteht).
-
Viele
weitere Mechanismen sind definiert worden. Die allgemeine Strategie
ist immer:
die Größe des Quorums
zu reduzieren (für
die Schreib- und Lesezugriffe) um den Synchronisierungsprozess zu
beschleunigen (und die Netzwerkübertragung
zu reduzieren); und,
die Wirkung von Serverausfällen zu
beschränken
(beispielsweise mittels der Abstimmung mit Hosts).
-
Ein
Kohärenzprotokoll
ist eine besondere Implementierung eines Kohärenz/Synchronisierungsmodells.
Es kann mehrere Protokolle für
ein einzelnes Modell geben. Welches Protokoll der beste ist, kann
von Problemen wie beispielsweise Lese/Schreib-Verhältnisse,
die Anzahl der Clients, die gleichzeitig auf ein Dienst zugreifen,
abhängen.
Der Standard, gegen den alle Modelle gemessen werden, ist eine sequenzielle
Konsistenz, das heißt,
dass alle Prozesse alle Speicherverweise in der gleichen Ordnung
sehen. Ursächliche
Konsistenz, Pipelined Random Access Memory (PRAHM) Konsistenz, und
Prozessorkonsistenz schwächen
an dem Konzept, bei dem die Prozesse alle die Speicherverweise in
der gleichen Ordnung sehen. Eine andere Vorgehensweise ist schwache
Konsistenz, Freigabekonsistenz, und Eintragkonsistenz, bei denen
der Speicher nicht die ganze Zeit konsistent bleibt, sondern der
Programmierer kann durch gewisse Aktionen, wie beispielsweise das
Betreten oder das Verlassen eines kritischen Regions, erzwingen,
dass es konsistent wird.
-
In
einem lokalen Netzwerk (Local Network Area LAN) ist es möglich, einen
zentralen Koordinator zu haben, der die Synchronisierung zwischen
den unterschiedlichen Kopien beaufsichtigt. Allerdings ist diese zentrale
Methode üblicherweise
in einem Grobraumnetzwerk (Wide Area Network WAN) aufgrund der hohen Latenzen
(es nimmt zu viel Zeit alle Kopien zu aktualisieren) und des zentralen
Ausfallpunktes nicht möglich. Deswegen
besteht in einem WAN Bedarf an eine verteilte Vorgehensweise. Mehr
Details über
Synchronisierungsstrategien können
in Andrew S. Tanenbaum, Distributed Operating Systems, Prentice-Hall,
New Jersey, 1995, gefunden werden; und in Coulouris bei al., Distributed
Systems: Concepts and Design, Addison-Wesley, Wokingham, 1991.
-
Mit
Multicasting wird die Information immer an alle Clients geschickt,
die sich für
die entsprechende Multicastgruppe angemeldet haben (und das Multicast-Port
abhören).
Im Fall einer geschlossenen Multicastgruppe, kann die Anzahl der
Clients bekannt sein.
-
Ein
Entwurf des Internet-Gruppen-Management-Protokolls, Version 3 (IGMPv3),
das im Internet unter http://search.ietf.org/internet-drafts/draft-ietf-idmr-igmp-v3-04.txt gefunden
werden kann, wird Möglichkeiten der
Quellenauswahl hinzufügen,
wie zum Beispiel das Abhören
nur einiger Quellen, oder aller Quellen aber mit einer Gruppe unerwünschter
Quellen. Allerdings gibt es ein Problem, dass noch kein Mechanismus
vorausgesehen ist, der Multicast nur zu einer Untergruppe der Mitgliedschaftshosts
ermöglicht.
-
Manchmal
(beispielsweise für
QC-Synchronisierung) gibt es eine Notwendigkeit, eine Art von Multicasting
zu haben, in dem die Größe der Untergruppe
aus der totalen Multicastgruppe definiert werden kann. Das heißt, dass
man die Anzahl von Empfängern
für eine
gewisse Multicast-Nachricht definiert. Im Fall der QC-Synchronisierung
kann man die Anzahl von Empfängern
definieren, die eine gewisse Synchronisierungsnachricht empfangen
sollten.
-
Eine
Methode zu Bilden einer Untergruppe aus einer vordefinierten Multicast-Gruppe ist in Shun
Yan Cheung et al: "Efficient
Quorumcast routing algorithms" Proceedings
of the conference on Computer Communications (Infocom). Toronto,
12 June 1994, pages 840–847
(ISBN: 0-8186-5572-0) offenbart. Hierin ist eine Methode zum Aufbau
eines minimallen Spanning-Baumes für eine Untergruppe einer Multicast-Gruppe
präsentiert,
um ein Lese/Schreib Quorum auf einem optimalen Weg. beispielsweise
betrachtend die kürzeste
Entfernung zwischen Knoten, zu leiten. Mittels der Verteilung von
Quoren wird die Synchronisation der Lese/Schreibe Operationen erzielt.
Das Dokument lehrt den Aufbau einer optimalen Untergruppe innerhalb
einer Multicast-Gruppe mit Hosts für den Zweck des Sendens einer
Nachricht zu einer Untergruppe einer Multicast-Gruppe. Eine allgemeine
Strategie ist vorgeschlagen, die den Synchronisationsprozess beschleunigt
und die benötigte
Netzwerkübertragung
innerhalb der Untergruppe mittels eines optimierten Routing-Multicastbaums
reduziert. Der Nachteil dieser Lösung
ist, dass eine zentrale Quelle alle Informationen über die
Netzwerktopologie und die Hosts der Verbindungen enthalten muss.
Darüber
hinaus wird mit dieser Lösung
nur eine Untergruppe für
den Zweck der Verteilung von Quoren aufgebaut. Deswegen ist diese
Lösung
für große Netzwerke
mit einer großen
Anzahl an Hosts nicht anwendbar und nicht skalierbar.
-
Wie
oben beschrieben, wird RTCP benutzt, um Informationen über die
Teilnehmer in einer andauernden Sitzung zu überbringen. Diese Information
wird Ende-zu-Ende
bereitgestellt, das heißt,
von den Bestimmungen zu der Quelle und dies nur in den Fällen funktioniert,
in denen das RTP-Protokoll üblicherweise
für Transport
von Echtzeitmultimediadaten benutzt wird.
-
Ein
jüngster
IETF-Entwurf (nämlich, "Ipv4-Option for Somecast", verfügbar im
Internet auf der Webseite: http://search.ietf.org/internet-drafts/draft-dhelder-somecast-00.txt) beschreibt "Somecast", der ein Mechanismus
ist, der bis zu neun Zieladressen in einem IP-Kopf enthält und kombiniertes
Unicast-Routing ausführt
solange die Bestimmungen die gleichen Zwischenleitungen benutzen
müssen.
Wenn ein Router feststellt, dass eine Bestimmung eine unterschiedliche
Zwischenleitung benutzt, wird das Datenpaket als Unicast geschickt.
Wie auch im IETF-Entwurf angegeben, ist diese Lösung nicht skalierbar. Außerdem hat
es solche Nachteile wie das Erfordernis, dass die Quelle alle Bestimmungen
im Voraus kennen muss.
-
Es
gibt deswegen einen Bedarf für
einen Mechanismus, der das Multicasting von Nachrichten nur an eine
Untergruppe einer definierten Gruppe von Mitgliedschaftshosts ermöglichen
wird.
-
Zusammenfassung
-
Es
sollte betont werden, dass die Begriffe "umfasst" und "umfassend", wie in dieser Beschreibung benutzt,
verwendet werden, um die Präsenz
von Merkmalen, Ganzzahlen, Schritten oder Bestandteilen zu spezifizieren;
aber die Verwendung dieser Begriffe schließt die Präsenz oder Ergänzung eines
oder mehrerer anderen Merkmale, Ganzzahlen, Schritten, Bestandteilen
oder Gruppen nicht aus.
-
Gemäß eines
Aspekts der vorliegenden Erfindung werden die vorhergehende und
andere Aufgaben mittels eines Verfahrens und einer Vorrichtung zur
Verteilung einer Nachricht von einer Quelle zu einem oder zu mehreren
Hosts in einem Kommunikationsnetz, das einen oder mehrere multicast-fähige Router-
umfasst, erfüllt.
Das ist erzielt mittels, in einem ersten multicast-fähigen Router,
Erzeugung einer ersten Tabelle, die mit dem ersten multicast-fähigen Route
verbundene Unterzweige identifiziert, und für jeden identifizierten Unterzweig,
mitgliedschaftsbezogene Information enthält, mit der entschieden werden
kann, wie viele Hosts Teil des Unterzweigs sind. Der erste multicast-fähige Router
empfängt
die zu verteilende Nachricht und einen ersten Wert, N1, der spezifiziert,
an wieviele Hosts die Nachricht zu verteilen ist. Er benutzt dann
die erste Tabelle um N1-Hosts und ihre jeweiligen Unterzweige zu
identifizieren, und um die Nachricht an jeden der identifizierten
Unterzweige zusammen mit einem zweiten Wert, N2, der spezifiziert,
an wieviele Hosts innerhalb des Unterzweigs die Nachricht zu verteilen
ist, zu verteilen.
-
In
einem anderen Aspekt der Erfindung mindestens einer der identifizierten
Unterzweige weist einen zweiten multicast-fähigen Router auf; und die Methode
ferner umfasst: in jedem der zweiten multicast-fähigen Routers, Erzeugung einer
zweiten Tabelle, die mit dem zweiten multicast-fähigen Router verbundene Unterzweige
identifiziert, und die für
jeden identifizierten Unterzweig mitgliedschaftsbezogene Information
enthält, mit
der entschieden werden kann, wieviele Hosts Teil des Unterzweiges
sind; in dem zweiten multicast-fähigen Router,
Benutzung der zweiten Tabelle um N2-Hosts und ihre jeweiligen Unterzweige
zu identifizieren; und in dem zweiten multicast-fähigen Router,
Verteilung der Nachricht an jeden der identifizierten Unterzweige
mit einem dritten Wert, N3, der spezifiziert, an wieviele Hosts
innerhalb des Unterzweiges die Nachricht zu verteilen ist. Auf diese
Weise wird eine rekursive Methode zur Verteilung der Nachricht zu
einer Untergruppe bewirkt.
-
In
einer alternativen Ausführungsform
kann der Unterzweig einfach die Nachricht an alle Hosts innerhalb
des Unterzweiges verteilen. In anderen Alternativen kann die Nachricht
zu bestimmten Hosts innerhalb des Unterzweiges unicasted werden.
-
In
anderer Ausführungsform
der Erfindung enthalten die erzeugten Tabellen außerdem eine
oder mehrere Metriken, die mit jedem der Unterzweighosts assoziiert
sind. Die verschiedenen Metriken können alternativ irgendeins
aus dem Folgenden anzeigen: eine Entfernung zwischen dem Unterzweighost
und dem zweiten multicastfähigen
Router; eine Verzögerung
zwischen dem Unterzweighost und dem zweiten multicast-fähigen Router;
Kosten assoziiert mit einer Übertragung
zwischen dem Unterzweighost und dem zweiten multicast-fähigen Router,
Bandbreite assoziiert mit einer Übertragung
zwischen dem Unterzweighost und dem zweiten multicast-fähigen Router, Übertragungsverzögerung zwischen
dem Unterzweighost und dem zweiten multicast-fähigen Router und/oder ein Zuverlässigkeitsmaßstab.
-
Die
Erfindung ferner umfasst, eine Methode zu Bestimmung wieviele Hosts
in den Unterzweigen eines Kommunikationsnetzwerkes enthalten sind.
-
KURZE BESCHREIBUNG DER
FIGUREN
-
Die
Gegenstände
und die Vorteile der Erfindung werden beim Lesen der folgenden detaillierten
Beschreibung im Zusammenhang mit den Figuren verstanden, in dem:
-
1 zeigt
ein Beispiel eines IP-Multicast-Szenarios, in dem ein Videostream
an vier Empfänger
in einem digitalen Kommunikationsnetz geschickt wird;
-
2 ist
ein Blockdiagramm eines Teiles eines Kommunikationsnetzes gemäß eines
Aspekts der Erfindung, in dem das Kommunikationsnetz eine Anzahl
von auf verschiedenen Wegen mittels Multicast-fähigen Routern (R1, R3, R6,
R7, R8) sowie Standart-Routern (nicht-multicast-fähigen Routers)
(R2, R4, R5) verbundenen Hosts (H1, H2, H3, H4, H5, H6, H7, H8)
enthält;
-
3 ist
ein Diagramm darstellend ein Verfahren zu Multicasting von Informationen
an eine Anzahl von Hosts gemäß einer
Ausführungsform
der Erfindung; und
-
4 ist
ein Diagramm darstellend ein Verfahren zu Bestimmung von Unterzweigmitgliedschaftsinformationen
gemäß eines
anderen Aspekt der Erfindung.
-
DETAILLIERTE BESCHREIBUNG
-
Die
verschiedenen Merkmale der Erfindung werden im Folgenden in Bezug
auf die Figuren beschrieben, in dem die gleichartige Elemente mit
den gleichen Bezugszeichen identifiziert werden.
-
Die
verschiedenen Aspekte der Erfindung werden jetzt detailliert in
Verbindung mit einer Anzahl beispielhafter Ausführungsformen beschrieben. Um
ein Verständnis
für die
Erfindung zu erleichtern, werden viele Aspekte der Erfindung als
eine Sequenz von Aktionen beschrieben, die durch Elemente eines
Rechnersystems und/oder Kommunikationsnetzes, ausgeführt werden.
-
Es
gilt, dass in jeder Ausführungsform,
die verschiedenen Aktionen mittels spezieller Schaltkreise (beispielsweise
diskrete logische Gattern, die miteinander geschaltet sind, um eine
spezielle Funktion zu realisieren), mittels Programmbefehlen ausführbar von
einem oder von mehreren Prozessoren, oder mittels einer Kombination
von beiden, ausgeführt
werden könnten.
Zudem kann es für
die Erfindung zusätzlich
gelten, dass diese ganz auf einem computerlesbaren Träger ausgeführt wird,
wie zum Beispiel Festkörperspeicher,
magnetische Platte, optische Platte oder Wellenträger (beispielsweise
Radiofrequenz, Audiofrequenz oder optischer Frequenzwellenträger) enthaltend
eine geeignete Gruppe von Computerbefehlen, die den Prozessor zur Ausführung der
da beschrieben Verfahren veranlassen würden. Damit können die
verschiedenen Aspekte der Erfindung mittels vieler unterschiedlicher
Formen ausgeführt
werden, und alle solche Formen werden als fallend unter den Schutzbereich
der Erfindung betrachtet. Für
jeden der verschiedenen Aspekte der Erfindung gilt, dass jede dieser
Formen der Ausführungsformen
als „eine
Logik konfiguriert zu" Ausführung der
beschriebenen Aktion oder alternativ als "Logik dass" eine beschriebene Aktion ausführt, bezeichnet
werden kann.
-
Die
Erfindung stellt ein Verfahren und eine Vorrichtung dar, die es
ermöglichen,
eine Nachricht nur an eine Untergruppe einer totalen Gruppe von
Multicast-Empfänger
zu multicasten. Die Untergruppe der Multicast-Empfängern kann
auf den verschiedenen Unterzweigen des Netzes verteilt werden, oder
die allen Multicast-Empfänger
können
sich innerhalb eines einzelnen Unterzweiges befinden. Um die verschiedenen
Aspekte der Erfindung zu veranschaulichen, wird Bezug auf 2 genommen,
welche ein Blockdiagramm eines Teiles eines Kommunikationsnetzes,
das eine Anzahl von auf verschiedenen Wegen mittels multicast-fähigen Routern
(R1, R3, R6, R7, R8) und mittels Standart-Routern (nicht-mulicast-Routers)
verbundene Hosts (H1, H2, H3, H4, H5, H6, H7, H8) enthält. Es ist
ersichtlich, dass in Bezug auf einen der Routers R1, ..., R8, eine Anzahl
von Unterzweigen definiert werden kann. Zum Beispiel, der Unterzweig 201 ist
einer der Unterzweigen von Router R1. Der Unterzweig 201 umfasst
Router R7 und R8 und Hosts H7 und H8. Die Router innerhalb eines
der Unterzweige können
selber Unterzweige haben. Zum Beispiel, in Bezug auf den Router
R7 (der im Unterzweig 201 enthalten ist), gibt es zwei
definierte Unterzweige: ein erster Unterzweig 203, der
den Router R8 und den Host H8 umfasst; und ein zweiter Unterzweig,
der nur den Host H7 umfasst.
-
Um
ein Untergruppen-Multicasting ausführen zu können, indem die Quelle die
Anzahl von Empfängern für die Nachricht
definiert, das Nachfolgende kann ausgeführt werden:
- 1.
Zähle die
Gesamtzahl von Empfängern
verfügbar
für eine
Einheit, die das Untergruppen-Multicasting auszuführen hat;
wenn diese Informationen nicht bereits mittels anderer Mitteln,
beispielsweise mittels Administration verfügbar sind.
- 2. Zähle
die Anzahl von Empfängern
pro Unterzweig.
- 3. Multicast die Information nur zu einer Untergruppe der totalen
Gruppe von Multicast-Empfängern..
-
Damit
das Untergruppen-Multicasting effizient ist, kann es auf einer Metrik
basieren, die für
die (Multicast-)Routingsprotokolle (wie Entfernung, Verzögerung,
Kosten, Bandbreite, Zuverlässigkeit
und dergleichen) benutzt wird. In einer alternativen Ausführungsform
der Erfindung kann das Untergruppen-Multicasting eher auf einer
Kombination von Metriken als auf einer einzelnen Metrik basieren.
Ausschließlich
um das Verständnis der
Erfindung zu erleichtern, werden nur einzelnen Metriken in den hierin
beispielhaft beschriebenen Ausführungsformen
veranschaulicht.
-
Es
sollte verstanden werden, dass es nicht unbedingt notwendig ist
für das
Funktionieren der Erfindung, dass die drei oben beschriebenen Schritte
getrennt auszuführen
sind. Zum Beispiel, Ausführungsformen können gebildet
werden, in denen das Zählen
der Zahl von Empfängern
pro Unterzweig auch in Wissen über die
Gesamtzahl von Empfängern
verfügbar
für die
Einheit, die das Untergruppen-Multicasting
ausführen
soll, resultiert, so dass die Schritte 1 und 2 zu einem Einzelschritt
verbunden werden.
-
Weiter
sollte es verstanden werden, dass das Untergruppen-Multicasting
ein rekursiver Prozess sein kann, wodurch jeder multicast-fähige Router
entweder die Nachricht zu einem keine multicast-fähige Router aufweisenden
Unterzweig weiterleitet, wodurch jeder Host in dem Unterzweig die
Nachricht empfangen wird, beispielsweise mittels unicasting, oder
der multicast-fähige
Router erzeugt und schickt seine eigene Untergruppe-Multicast-Befehle
an einen oder mehrere seine Unterzweige, dadurch lassend den oder
die mehrere multicast-fähige
Router innerhalb der Unterzweige über die Festlegung der Hosts,
die die Nachricht empfangen werden, entscheiden. Natürlich, ist
es nicht erforderlich, dass ein multicast-fähiger Router Multicasting benutzt,
wenn eine Nachrichten an seine Unterzweigen weiterzuleiten ist –– es kann
auch die Möglichkeit
des Senden von dedizierten Unicast Nachrichten zu der genauen Anzahl
von Mitgliedern, die gemäß der empfangenen
Multicast-Nachricht informiert werden müssen, geben.
-
Eine
zuverlässige
Funktionsweise kann durch die Anwendung eines der zuverlässigen Multicasting-Mechanismen
und durch Protokolle, beispielsweise wie jene beschrieben im Abschnitt
HINTERGRUND dieser Offenbarung, erreicht werden.
-
Eine
beispielhafte Ausführungsform
eines Verfahrens zu Multicasting einer Nachricht von einem multicast-fähigen Router
zu einem oder zu mehreren Hosts ist in dem Flussdiagramm der 3 dargestellt.
Der multicast-fähige
Router kann von einem anderen Router die Nachricht zusammen mit
einem Wert, der anzeigt, dass die Anzahl der gewünschten Empfänger der
Nachricht eine Zahl, N1 ist (Schritt 301), empfangen. Oder wenn,
der multicast-fähige
Router die Quelle der Nachricht ist, wird der Wert N1 lokal bestimmt.
-
Wenn
es bereits nicht gemacht wurde, erzeugt der multicast-fähige Router
eine Tabelle, die die an den ersten multicast-fähigen Router verbundene Unterzweige
identifiziert. Für
jeden identifizierten Unterzweig umfasst die Tabelle mitgliedschaftsbezogene
Information, mit der entschieden werden kann, wieviele Hosts Teil des
Unterzweigs sind. Optional, gemäß einiger
Ausführungsformen,
enthält
die erzeugte Tabelle ferner eine oder mehrere Metriken assoziiert
mit jedem der Unterzweighosts (Schritt 303).
-
Der
multicast-fähige
Router benutzt die Tabelle, um N1-Hosts und ihre jeweiligen Unterzweige
zu identifizieren (Schritt 305). In einer bevorzugten Ausführungsform
bedeutet das Identifizieren der Hosts das Auffinden jener Hosts,
die assoziiert mit einer oder mit mehreren Metriken einigen Kriterien
entsprechen, wie beispielsweise sich am nahsten zu einem multicast-fähigen Routers
befinden.
-
Die
Nachricht wird dann zu jedem der identifizierten Unterzweige mit
einem zweiten Wert, N2, der bestimmt, an wieviele Hosts innerhalb
des Unterzweiges die Nachricht zu verteilen ist, verteilt (Schritt 307).
Dies erlaubt einem multicast-fähigen
Router-Empfänger
den gleichen Multicast-Prozess zu seinen downstreamen Hosts auszuführen, diesmal
benutzend den Wert N2 für
die Anzahl von gewünschten
Nachrichtenempfängern.
-
Ein
Beispiel wird jetzt präsentiert,
um eine Anzahl von Aspekten der Erfindung zu veranschaulichen.
-
Clients
können
sich zum nahsten Multicast-Router mit IGMP anmelden. In den Protokollen
des Stands der Technik (beispielsweise MOSPF) wird ein Spanning-Baum
(oder eine andere Art von Graphenoptimierungsbaum) zwischen den
Multicast-Routern erzeugt. In der beispielhaften Konfiguration gezeigt
in 2, ist R1 die Wurzel mit drei Zweigen (R3, R6,
R7–R8).
-
Wie
oben beschrieben, die folgenden Grundschritte werden für ein Untergruppen-Multicasting
vorzugsweise ausgeführt:
- 1. Zähle
die Gesamtzahl von Empfängern
verfügbar
für eine
Einheit, die das Untergruppen-Multicasting auszuführen hat
(wenn diese Informationen nicht bereits mittels einiger anderer
Mitteln, beispielsweise mittels Administration verfügbar sind.).
-
Wie
oben beschrieben, empfangen lokale Router nur Informationen von
einem Mitglied einer bestimmten Multicast-Gruppe. Andere Mitglieder
unterlassen das Schicken ihre Mitgliedschaftsinformationen, sobald ein
anderes Mitglied schon über
diese Informationen berichtet hat. Zwei Lösungen diesbezüglich sind:
a) jedes Mitglied multicast seine Mitgliedschaft zum lokalen Router
und zu allen anderen Hosts verbundenen an den lokalen Netz; oder – effizienter – b) jedes
Mitglied unicast seine Mitgliedschaft zum lokalen Router Der lokale Router
kann die erwartete Mitgliedschaftsberichtsmethode in der IGMP-Mitgliedschaftsanfragenachricht
(siehe IGMP Memberschip Query Message IGMPv3) angeben.
-
Nachdem
ein einzelner oder mehrere Clients sich zu einem Multicast Router
angemeldet haben, informiert dieser Router den nahsten Multicast
Router auf dem Weg zu der Multicast-Router-Wurzel über die
Anzahl der verbundenen Hosts. Damit der Mechanismus die entsprechende
Metrik berücksichtigt,
wird nicht nur die Anzahl von Hosts, sondern auch die Metrik geschickt.
Jene der existierenden Multicasting-Routing-Nachrichten oder der IGMP-Nachrichten
zwischen den Multicast Routern kann um diese Information erweitert
werden.
-
Das
Verfahren zu Bestimmung von Unterzweigmitgliedschaftsinformationen
ist in dem Ablaufdiagramm dargestellt in der 4 veranschaulicht.
Ein Router initiiert das Verfahren, indem er eine Mitgliedschaftsanfragenachricht
an den Unterzweig schickt (Schritt 401). Als Antwort auf
die Anfrage empfängt
der Router eine Mitgliedschaftsinformationsantwort von dem Unterzweig
(Schritt 403). Die Mitgliedschaftsinformationsantwort identifiziert,
für den
Unterzweig, eine Identifikation von jedem multicast-fähigen Router
im Unterzweig. Für
jeden der identifizierten multicast-fähigen Router enthält ferner
die Mitgliedschaftsinformationsantwort einen Wert, der die Anzahl
von Hosts verbunden an den identifizierten multicast-fähigen Router
repräsentiert.
Optional, in einigen Ausführungsformen
der Erfindung, enthält
die Mitgliedschaftsinformationsantwort ferner eine oder mehrere
entsprechenden Metriken für
jeden der Hosts verbunden an jeden multicast-fähigen Router im Unterzweig.
-
In
dem Beispiel aus 2 wird die folgende zusätzliche
Information von den entsprechenden Multicast-Routern geschickt,
voraussetzend dass die beispielhafte Metrik die Entfernung vom Host
zum Router ist (Beachten Sie, dass der nicht-multicast Router die
Informationen transparent weiterleitet):
-
-
Anhand
der empfangenen Informationen und berücksichtigend die entsprechenden
Entfernungen zwischen den Multicast Routern, wird R1 eine Tabelle,
wie die folgende, erzeugen:
-
-
Jeder
Multicast Router kennt jetzt die Gesamtzahl von Empfängern in
seinem entsprechenden Unterzweig, einschließlich der entsprechenden Entfernungen.
Dies impliziert dass die Wurzel (d. h., R1 in dieser beispielhaften
Topologie) weiß die
Gesamtzahl von Empfängern.
-
Die
gesammelten Informationen über
die Anzahl von Multicast-Gruppenmitgliedern
können
für Bemessung,
Statistik, Abrechnung, und dergleichen benutzt werden. Wie unten
beschrieben, eine Anwendung ist, eine Multicast-Nachricht als einen
Quorumskonsens(QC)Synchronisierungsnachricht zu benutzen.
-
Das
Zählen
der Anzahl von Mitgliedern pro Unterzweig kann auf Wunsch eines
Host/Server oder des Wurzel des Multicast-Auslieferungsbaums ausgelöst werden.
Darüber
hinaus können
die existierenden, Multicast-Auslieferungsbaum bildenden Protokolle
mit dieser Information erweitert werden. Wenn ein Host/Server oder
die Wurzel es auslöst,
kann ein einfacher Anfrage/Antwortmechanismus benutzt werden, der
rekursiv an die Unterzweige des Multicast-Auslieferungsbaums geleitet
wird. Das Zählen
kann auch periodisch ausgeführt werden,
zum Beispiel alle 10 Minuten, da die Anzahl von Mitgliedern einer
Multicast-Gruppe sich dynamisch ändern
kann.
- 2. Zähle
die Anzahl von Empfängern
pro Unterzweig.
Siehe Punkt 1 oben: Die erzeugte Tabelle enthält Informationen,
von denen die Anzahl der Empfänger
pro Unterzweig zusammen mit ihren assoziierten Metriken bestimmt
werden kann. Zum Beispiel kann aus der erzeugten Tabelle entnommen
werden, dass zwei Hosts über
Router R7 erreichbar sind: ein Host über eine Entfernung von "2", und das andere über eine Entfernung von "3" (die relevante Metrik in diesem Fall
ist die "Entfernung").
- 3. Multicast die Informationen nur zu einer Untergruppe der
totalen Gruppe von Multicast-Empfänger.
-
Die
Quelle schickt die Multicast-Nachricht (z. B. eine QC-Synchronisierungsnachricht)
an die Multicast-Gruppe mit der Information über die Anzahl von Empfängern in
diesem Unterzweig, die die Nachricht empfangen müssen. Ein rekursiver Prozess
wird dann ausgeführt
wodurch die Multicast-Router innerhalb jedes Unterzweiges die gleichen
oben beschrieben Multicast Schritte ausführen, um die Nachricht nur
an eine bestimmte Anzahl von Hosts in den ausgewählten Unterzweigen zu leiten,
um wenn notwendig sicherzustellen, dass die richtige Anzahl von
Hosts die Nachricht empfängt.
-
Zum
Beispiel angenommen, dass die Nachricht an vier Empfänger geschickt
werden soll, wird das Folgende geschehen:
-
R1
wird die Nachricht empfangen und in seine Tabelle nach den „nahesten" vier Empfängern der
Multicast-Gruppe nachsehen (Die Annahme hier ist, dass die Metrik
die Entfernung repräsentiert,
und die Auswahl basiert auf Hosts, die am nahsten dem Sender sind;
keine dieser Bedingungen ist wesentlich für die Ausführung der Erfindung). Die vier
Nahsten (bestimmt anhand der Entfernung in der Tabelle) sind, derjenige,
der direkt verbunden ist (Host H1 mit Entfernung 1), derjenige verbunden
mit R7 (Host H7 mit Entfernung 2) oder entweder die zwei verbunden
mit R3 (Hosts H3 und H4 mit Entfernung 3) oder einer von ihnen (jeder
der Hosts H3 und H4) und derjenige verbunden mit R8 (Host H8 mit
Entfernung 3). Angenommen zwecks der Darstellung, dass die zwei
verbunden mit R3 ausgewählt
sind, wird R1 die folgenden Informationen zu den Multicast-Routern
schicken:
| Zu | Anzahl
von zu informierenden Hosts |
| R2 | 2 |
| R7 | 1. |
-
Beachten
Sie, dass die Identität
der Hosts nicht zu diesem Zeitpunkt bestimmt ist. Stattdessen ist
diese Bestimmung ein Ergebnis der rekursiven Ausführung dieses
Verfahrens in jedem der "flussabwärts" multicast-fähigen Router.
Folglich, fortsetzend das Beispiel, wird R2 (der Reihe nach) eine
Nachricht R3 schicken, anzeigend dass zwei Hosts zu informieren
sind.
-
Beachten
Sie, dass keine Nachricht an R4 geschickt wird (da keine seiner
Hosts genug nah an der Quelle der Information ist).
-
Ein
Multicast-Router, der eine Nachricht empfängt, die eine Anzahl von zu
informierenden Mitgliedern in seinem lokalen Netz anzeigt, hat einige
Optionen für
die Bereitstellung der Informationen:
- – Er kann
immer die Nachricht an den lokalen Netz multicasten, da viele Anwendungen
sich nicht darum sorgen, ob zu viel Mitglieder eine Nachricht empfangen.
Dies hält
den Mechanismus einfach. In einigen Ausführungsformen kann es vorteilhaft
sein, dies zu einer Option zu machen, in dem durch Hinzufügung eines
Indikators zu der Multicast-Nachricht
(z. B. in einer optionalen Erweiterung des Kopfs, wie beispielhaft eine
standardmäßige IP
optionale Kopferweiterung) die Empfänger informiert werden, ob
es erlaubt ist, die Nachricht an zu viele Mitglieder (d. h., mehr
als die Anzahl der tatsächlich
in der Untergruppe-Multicast Nachricht spezifizierten) zu multicasten.
- – Alternativmöglichkeit,
da der Multicast-Router die Mitglieder aufgrund der in Schritt 1 beschrieben
Lösungen
kennt, kann er alternativ eine dedizierte Unicast-Nachricht nur
an die Zahl der Mitglieder schicken, die gemäß der empfangenen Untergruppe-Multicast
Nachricht informiert werden müssen.
Falls die Anzahl der Mitglieder kleiner oder gleich der in der Nachricht
angezeigten Zahl ist, werden alle Mitglieder mittels eines Multicasting
im lokalen Netz informiert.
- – In
anderen Alternativen benutzt der Multicast Router selbst das oben
beschriebene Untergruppe-Multicast Verfahren, um dadurch zu erreichen,
dass ein "flussabwärts" multicast-fähiger Router
die Entscheidung trifft, welches der Hosts Empfänger sein sollten.
-
Beachten
Sie: Zuverlässigkeit
wird mittels der Bestätigungen
(von den Empfängern
wie in den zuverlässigen
Multicastingprotokolle definiert, erreicht. Dies ist auf den Schritt 3 in
der obigen Liste anzuwenden.
-
Multicasting
ist "Best-Effort" Prinzip, das bedeutet,
dass der Sender einer Nachricht nicht weiß ob und wieviele Mitglieder
die Nachricht empfangen haben. Wie oben beschrieben, können zuverlässige Multicast-Protokolle
positive (ACK) oder negative (NACK) Bestätigungen bereitstellen.
-
Zusätzlich zu
den existierenden zuverlässigen
Multicastingmechanismen, kann das Untergruppenmulticasting die Bestätigungen
folgendermaßen
ansammeln: Ein lokaler Multicast-Router empfängt die Bestätigungen
von den direkt verbundenen Mitgliedern und verfasst dies in eine
Bestätigungsnachricht
geschickt Richtung den nächsten
Multicast-Router liegend auf dem Weg zu der Wurzel. Die Nachricht
zeigt die Anzahl der Mitglieder in dem Unterzweig an, die (positiv)
den Empfang der Nachricht bestätigten.
Jeder Multicast-Router führt
dies durch und die Wurzel empfängt
die Gesamtzahl von Bestätigungen
für das
ganze Netz (Multicast-Auslieferungsbaum).
-
Beachten
Sie, dass die oben beschriebenen Mechanismen auch auf die gemeinsam
genutzten Multicast-Auslieferungsbäume, in denen ein Multicast-Auslieferungsbaum
von vielen Absendern benutzt wird, anzuwenden sind. In solchem gemeinsam
genutzten Baum gibt es mehrere Wurzeln.
-
Eine
Anzahl von Vorteilen werden aus der Erfindung abgeleitet. Erstens
ermöglicht
die Erfindung die Nachrichten nur an eine Untergruppe einer definierten
Gruppe von Mitgliedschaftshosts zu multicasten.
-
Zusätzlich,
verglichen mit der Verwendung von RTCP für die Übermittlung von Informationen über die Teilnehmer
einer Sitzung, kann der Mechanismus für die Bereitstellung dieser
Informationen vor dem Start der Sitzung sorgen. Er stellt ebenfalls
Information zu den unterschiedlichen Multicast Routern über die
Anzahl von Hosts verbunden in den unterschiedlichen Unterzweigen
bereit. Diese Informationen kann dann auch für andere Zwecke benutzt werden.
-
Die
oben beschriebene Lösung
stellt ebenfalls Mechanismen bereit, um die Anzahl von Multicast-Gruppenmitgliedern
pro Unterzweig in einem Netz zu zählen. Diese Information wird
den anderen Multicast Routern auf dem Weg zur Wurzel (oder Bezugspunkt)
eines Multicast-Auslieferungsbaums gemeldet, wo sie für mehrere
Zwecke benutzt werden kann (z. B. Dimensionierung, Statistik, Abrechnung,
Entscheidungen über
Dienstverteilung und dergleichen). Sobald die Gesamtzahl von Multicast-Gruppenmitgliedern
bekannt ist, werden diese Informationen benutzt, um für ein effizientes
Untergruppenmulticasting zu sorgen. Quellen können die Anzahl von Mitgliedern,
die eine bestimmte Multicast Nachricht empfangen sollten, spezifizieren,
und der Routing Mechanismus stellt sicher, dass die nahesten Hosts
(Hosts erfüllend
einige Metrik-basierte Kriterien) die Nachricht empfangen. Das Naheste
kann mittels einer Metrik wie schon heute für IP spezifiziert, definiert
werden.
-
Eine
beispielhafte Anwendung für
diesen effektiven Mechanismus ist Quorums-Konsens-Synchronisierung für replizierte
Server. Um der Gesamtkapazität
und der auferlegten Verzögerungsanforderungen
zu entsprechen, wird ein Server im Netz repliziert. Clients werden
an eine der verschiedenen Kopien angeschlossen. Die Auswahl der
Kopie für
einen bestimmten Client kann auf einem solchen Faktor wie Entfernung,
Verfügbarkeit,
und dergleichen basieren. Der Dienst, der von den Servern zu den
Clients bereitgestellt wird, ist ein interaktiver Echtzeitdienst,
wie beispielsweise ein Multibenutzerspiel oder eine virtuelle Welt.
Clients interagieren mit dem Dienst (Umgebung) und empfangen aktualisierte
Informationen von der Dienstumgebung in Realzeit. Wegen des Multibenutzers
und des interaktiven Echtzeitcharakters des Diensts gibt es Notwendigkeit, dass
die Server miteinander synchronisiert sind.
-
Diese
Synchronisierung kann vorteilhaft die oben beschriebenen Metrikbasierten
Untergruppenmulticastingverfahren einsetzen. Zum Beispiel, wann
immer ein Server ein lokales Update ausführt, synchronisiert er die
anderen Server/Repliken, indem er sie über das Update informiert.
Traditionell wird solch ein Update allen Kopien geschickt. Allerdings
mit Quorumskonsenssynchronisierung muss nur eine Untermenge der
Repliken synchronisiert werden (d. h., das System braucht nur einen
aktualisierten Konsens zu bilden). Wenn die Gesamtzahl von Repliken
bekannt ist, wird die Größe der Untermenge
für die
Quorumskonsenssynchronisierung mittels des angewendeten entsprechenden
Mechanismus ermittelt. Benutzend ein Zahlenbeispiel, angenommen,
dass die Gesamtzahl von Kopien 10 ist und dass die Untermenge, die
synchronisiert werden soll, 6 ist. Das Metrik-basierte Untergruppenmulticasting
kann angewendet werden um die 5 nahesten Repliken mit derjenigen,
wo das Update initiieret wurde zu synchronisieren (z. B. die "naheste" wird mittels einer
Verzögerung
definiert). Die gleiche Methode kann auf einen Lesezugriff angewendet
werden. In diesem Fall, benutzend das gleiche Zahlenbeispiel, muss
ein Lesen in einer Untermenge von 5 Kopien gemacht werden, um sicherzustellen,
dass mindestens eine Kopie den letzten (d. h., korrigierten) Status
hat.
-
Folglich,
mit einer Gesamtzahl von 10 Repliken, Schreibzugriffe müssen in
mindestens 6 Repliken ausgeführt
werden und die Lesezugriffe müssen
nur von mindestens 5 Kopien ausgeführt werden. Die Multicast-Untergruppe
basierend auf einer Verzögerung-,
Entfernungs-Metrik stellt sicher, dass für die Schreibzugriffe die nahesten
6 Repliken und für
die Lesezugriffe die nahsten 5 Repliken kontaktiert werden. Der
durch diese Methode erzielte Vorteil ist eine effiziente Übermittlung
mittels Multicasts, aber nur eine minimale Anzahl von Repliken wird
kontaktiert, und somit eine effiziente Verwendung der Ressourcen
der Kommunikationsnetzwerks wird erzielt.
-
Die
Erfindung ist im Bezug auf eine besondere Ausführungsform beschrieben worden.
Allerdings ist es für
einen Fachmann offensichtlich, dass es möglich ist, die Erfindung mit
spezifischen Formen anders als jene in der oben beschriebenen Ausführungsform
auszuführen.
-
Zum
Beispiel ist es beschrieben worden, wie ein Multicast Router eine
Information bezüglich
der Zahl der Mitglieder in einem Unterzweig anfordern kann. Allerdings
kann diese Anfrage in alternativen Ausführungsformen auch von einem
Host oder Server gemacht werden. Dies kann leicht mit einem Frage/Antwortmechanismus
realisiert werden.
-
Auch
ist die Erfindung in Bezug auf Ausführungsformen beschrieben worden,
in denen eine Nachricht eine Anzahl von Hosts anzeigt, die die Nachricht
empfangen sollen. Allerdings kann die Nachricht stattdessen in alternativen
Ausführungsformen
einen Prozentsatz der Mitglieder, die die Nachricht empfangen sollen,
anzeigen (z. B. es kann angezeigt werden, dass 30% der Mitglieder
die Nachricht empfangen sollen). In solchen Ausführungsformen, kann die Multicast-Router-Wurzel
Informationen aus der erzeugten Tabelle (d. h. Informationen anzeigend
die Gesamtzahl von Mitgliedern) benutzen, um den in Prozentsätzen ausgedrückten Wert
in eine eigentliche Anzahl von Mitgliedern abzubilden.
-
Damit
ist die bevorzugte Ausführungsform
ausschließlich
beispielhaft und sollte keinesfalls einschränkend betrachtet werden. Der
Schutzbereich der Erfindung wird eher durch die angehangene Ansprüche als durch
die vorangehende Beschreibung angegeben, und alle Schwankungen und Äquivalente,
die in den Bereich der Ansprüche
fallen, sind beabsichtigt, dass diese darin umfasst sind.
