Im INTERNET besitzt jeder Rechner eine[ Ein Rechner kann auch mehrere Adressen besitzen ("multi-homed host"), jedoch ist dies für die weitere Betrachtung nicht von Bedeutung] 32-Bit Adresse[ Dies gilt für IPv4[rfc791]. Derzeit wird an der Einführung von IPv6 [rfc1883] gearbeitet, bei dem die Adressen länger sind.]. Mittels dieser Adresse kann jeder Rechner im INTERNET mit jeden anderen Rechner in direkten Kontakt treten und Daten austauschen. Dieses ist für die traditionellen Anwendungen, wie ftp (Filetransfer zwischen zwei Rechnern) oder telnet (login auf einen entfernten Rechner) optimal geeignet.
Durch die Einführung von Multimedia-Anwendungen, wie die Übertragung von Audiodaten, entstand jedoch der Wunsch, diese Daten an mehrere Rechner gleichzeitig übertragen zu können. Damit die benötigte Bandbreite hierbei nicht proportional mit der Anzahl der potentiellen Empfänger steigt, wurden sogenannte Gruppenadressen eingeführt. Diese Gruppenadressen sind somit nicht einem, sondern mehreren Rechnern gleichzeitig zugeordnet. Verwendet werden hierzu IP-Class-D-Adressen (auch Multicast-Adressen genannt). Die nötigen Erweiterungen und ein zusätzliches Kontrollprotokoll sind in [rfc1112] beschrieben.
Es ist somit möglich, daß ein von einem Rechner ausgesandtes Datenpaket gleichzeitig von hunderten oder tausenden anderen Rechnern gleichzeitig empfangen werden kann, ohne daß die benötigte Bandbreite hierdurch steigt! Ein wesentlicher innovativer Aspekt liegt dabei in der Tatsache, daß diese Gruppen nicht statisch sind. Es existiert keine Konfigurationsdatei oder ähnliches, in der definiert wurde, welche Rechner zu welcher Gruppe gehören. Diese Zuordnung wird dynamisch von jedem Rechner selbst verwaltet. Mit Hilfe von IGMP [rfc1112], dem "Internet Group Management Protocol" wird Multicast fähigen Routern mitgeteilt, welche Multicast Gruppen in einem Netzsegment verwendet wird. Mittels geeigneter Protokolle, die zwischen den Routern ausgetauscht werden ist es möglich, die IP-Datagramme in den jeweiligen Netzsegmenten zu duplizieren. Verwendet werden hierzu PIM [Deer9610:Protocol] (Protocol Independent Multicast) oder DVMRP [rfc1075] (Distance Vector Multicast Routing Protocol).
Dieses IP-Multicast Verfahren wird nun verwendet, um Konferenzen im INTERNET zu realisieren. Somit kann beispielsweise ein Vortrag an einer Universität in den USA gehalten, und auf der ganzen Welt verfolgt werden, wenn dieser mittels IP-Multicast im INTERNET übertragen wird.
Derzeit ist es noch ein wenig problematisch diese IP-Multicast-Pakete im INTERNET zu übertragen, da dies einige Änderungen in den Routing-Implementierungen erforderlich macht. Aus diesem Grunde wurde das sogenannte MBONE (Multicast Backbone), ein virtuelles IP-Multicast-Netz im INTERNET eingerichtet. Hierbei werden die IP-Multicast Pakete zwischen zwei Teilnetzen über einen sogenannten Tunnel ausgetauscht. Innerhalb dieser Netze werden die Daten wieder als gewöhnliche IP-Multicast-Pakete verschickt. Für einen Rechner, der diese IP-Multicast-Pakete versendet oder empfängt besteht somit keine Abhängigkeit zu dem verwendeten Routing-Verfahren. Sollten in Zukunft die Router in der Lage sein, das Routing selber ausführen zu können, wird nach und nach das MBONE als solches verschwinden, ohne daß die Rechner oder Benutzer irgend etwas davon merken.
Nachdem das Umfeld der Multimedia-Konferenzen im INTERNET beschrieben wurde, wollen wir nun die Probleme herausarbeiten, die bei der temporären Koppelung des Internets mit einem externen Rechner (wie etwa von zu Hause) bei der Übertragung von Multimedia Daten entstehen[ Es muß nicht unbedingt nur ein Rechner sein, der mit dem INTERNET gekoppelt wird, es kann sich auch um ein kleines Teilnetz handeln. Für die weitere Betrachtung spielt das jedoch nur eine untergeordnete Rolle.].
Die eigentliche Schwierigkeit liegt nicht in der Übertragung der Multicast-Pakete an sich, sondern in der Entscheidung, welche Pakete zu übertragen sind. Angenommen in dem einen Teilnetz der PPP-Verbindung finden gerade mehrere IP-Multicast Konferenzen statt. Würden nun alle diese Pakete über die PPP-Verbindung geschickt werden, wäre diese sofort zu hunderten Prozent überlastet, da diese Verbindung in der Regel eine weit aus geringere Übertragungsrate zur Verfügung stellt, als die, die für die Konferenzen nötig wäre.
Aus diesem Grunde ist es wichtig zu wissen, welche Multicast Gruppen auf der jeweiligen Seite aktiv sind. Nur solche Gruppen, die auf beiden Seiten aktiv sind dürften über die PPP-Verbindung geroutet werden. Hierzu ist wiederum eines der bereits erwähnten Routing-Protokolle nötig, die jedoch bis jetzt nicht in PPP-Implementierungen realisiert wurden.
Jedoch reicht dies nicht aus. Nehmen wir beispielsweise die Konfiguration in Abbildung [mcast-igmp1] an. Zu irgendeinen Zeitpunkt t sendet der PPP-Router P1 eine IGMP-REQUEST Nachricht ins Netz. Jeder Rechner, der in der Lage ist IP-Multicast zu empfangen, empfängt daraufhin diese Nachricht. Für jede Multicast-Gruppe, in denen ein Rechner Mitglied ist, generiert er eine IGMP-RESPONSE. Diese wird nicht sofort, sondern erst nach einem zufälligen Timeout ins Netz gesendet (vgl. auch [Stev94:TCP]).
Nehmen wir an, der Timer vom Rechner A läuft zuerst ab, so daß dieser als erste seine Nachricht ins Netz schickt. Der-PPP Router P1 empfängt ebenfalls diese, und sendet sie an den anderen Router P2 weiter, der diese wiederum in das lokale Teilnetz auf seiner Seite sendet. Der Rechner X, der ebenfalls in der gleichen Multicast-Gruppe ist, empfängt diese Nachricht, und stoppt somit seinen Timer für das Aussenden der IGMP Nachricht. Er geht davon aus, daß alle Router das Paket ebenfalls empfangen haben, so daß er seine Mitgliedschaft nicht bekannt geben muß. Dies ist der normale Ablauf, so wie er in [rfc1112] definiert wurde.
Durch dieses Verhalten können die beiden Router P1 und P2 nur feststellen, daß im Teilnetz A die Multicast-Adresse A verwendet wird. Keiner weiß jedoch, daß auch im Teilnetz B diese Gruppe benutzt wird. Aus diesem Grunde würden die Router auch keine IP-Multicast-Pakete über die PPP-Verbindung routen[ In der Tat, nach einiger Zeit könnte es sein, daß der Timer von X vorher abläuft, so daß die Benutzung der Gruppe im Teilnetz B bekannt wäre. Wenn das Teilnetz A jedoch sehr groß ist, und mehrere Rechner Mitglied der Gruppe sind, kann das sehr lange dauern. ].
Das Problem könnte dadurch gelöst werden, daß die Router ein von dem anderen Router empfangenes IGMP-REPORT Paket nicht das lokale Netz schicken. Aus diesem Grunde würde dann der Timer von Rechner X ablaufen, so daß dieser ebenfalls einer IGMP-REPORT Nachricht sendet. Beide Router würden dann wissen, daß diese Adresse in beiden Netzen benutzt wird, und würden dann die IP-Pakete für diese Gruppe übertragen. Somit wäre das Problem der Übertragung von IP-Multicast-Paketen über PPP-Verbindungen bereits gelöst.
Das Problem besteht jedoch weiterhin! Wenn im benachbarten Teilnetz, das über die PPP-Verbindung verbunden ist, kein Rechner Mitglied dieser Multicastgruppe ist, gibt es auf die IGMP-QUERY nie eine Antwort aus dem Teilnetz A (vgl. Abbildung [mcast-igmp2]). Der Grund liegt darin, daß IGMP normalerweise nicht geroutet werden darf. Aus diesem Grunde wird der Router R aus dem Teilnetz A die IGMP-Nachricht auch nicht ins INTERNET schicken. Die PPP-Router würden somit immer annehmen, daß die Gruppe im benachbarten Teilnetz nicht benutzt wird, und würden somit auch keine Multicast-Pakete routen.
In unserer Testumgebung haben wir diese Probleme nicht weiter betrachtet. Die zu routenden Multicast-Adressen werden fest eingestellt.