NETZAGENTUR NRW
Projektgruppe im Auftrag des MSWF und der Hochschulen des Landes NRW
an der Universität - Gesamthochschule Essen
Dr. B. Lix (Universität - GH Essen)
Prof. Dr. H. Obrecht (Universität Dortmund)
R. Bauer (Universität Dortmund)
H. Herker (Universität - GH Essen)
F. Klapper (Universität Bielefeld)
W. Moll (Universität Bonn)

Inhaltsverzeichnis *

1 Anliegen *

2 Einführung *

3 Status Quo *

4 Vorschläge für eine alternative Struktur *

5 Literatur *

1. Anliegen

An vielen Universitäten in Deutschland, speziell auch in Nordrhein-Westfalen, finden sich vielfältige Ansätze, innovative Anwendungen mit multimedialer Technik voranzutreiben. Trotz oft erheblicher finanzieller Investitionen in eine Multimedia-Infrastruktur (lokale Hochgeschwindigkeitsnetze, Multimedia-Hörsäle) bleiben die erzielten Ergebnisse bislang hinter den Erwartungen zurück. Als eine der Ursachen für diese unbefriedigende Situation kann die mangelnde Unterstützung solcher Anwendungen durch das Internet, speziell im BWiN, festgemacht werden. Ohne eine integrale Verankerung von Multicast-Diensten im Internet wird die Entwicklung und der Einsatz innovativer Anwendungen auch zukünftig massiv behindert. Dieser Bericht versucht, die derzeitigen Problempunkte zu identifizieren und grundlegende Anforderungen für eine adäquate Multimedia-Netzinfrastruktur aufzustellen.

2. Einführung

Das Internet wird bislang überwiegend für den zuverlässigen Transport von Datenströmen zwischen zwei Endpunkten genutzt, wobei die heute noch dominierenden Anwendungen wie Dateitransfer, Email und World Wide Web nur geringe Ansprüche an die Dienstgüte stellen und zudem zeitliche Schwankungen innerhalb des Datenstromes in hohem Maße toleriert werden. Viele der sich neu entwickelnden Anwendungen sind jedoch durch eine anders geartete Kommunikationsstruktur gekennzeichnet, bei der ein oder mehrere Sendepunkte Daten zu vielen Empfängern übertragen. In diese Rubrik gehören etwa klassische Multimedia-Anwendungen wie Video-Konferenzen, verteiltes kooperatives Arbeiten und Distance Learning. Aber auch paralleles Rechnen, verteilte Visualisierung und Finanzinformationsdienste fallen in diese Anwendungskategorie. Voraussetzung für eine effiziente Nutzung des Netzes ist in allen Fällen die Nutzung der Multicast-Technik, bei der ein einzelnes Datenpaket, das den Sender verläßt, automatisch auf dem Weg zu seinen Empfangsstationen bei Bedarf kopiert und nur zu solchen Empfängern geleitet wird, die diese Nachricht empfangen wollen. Somit ist gewährleistet, daß kein unnötiger Mehrfachverkehr den gleichen Netzabschnitt durchläuft. Multicast-Technik ermöglicht damit die breite Skalierung von netzintensiven Anwendungen.

Im Internet wird diese Technik seit 1992 experimentell im MBONE (Multicast Backbone) eingesetzt. Es handelt sich hierbei um ein Overlay-Netz, welches auf der existierenden Internet-Infrastruktur aufsetzt. Insbesondere im BWiN haben die bisherigen Erfahrungen die Grenzen der heute eingesetzten Technik deutlich aufgezeigt. Eine akzeptable Übertragungsqualität kann mit der bestehenden Infrastruktur selbst in kleinerem Rahmen nicht erzielt werden.

 

3. Status Quo

Im BWiN weist die MBONE Struktur prinzipielle Engpässe auf mehreren Ebenen auf: eine technisch unzureichende Netzstruktur, historisch bedingte Mängel im Multicast-Routing sowie gravierende Probleme im operativen Management.

1. Netztechnik

Die Entwicklung der Multicast-Technik ist lange Zeit durch proprietäre Ansätze geprägt worden. Erst seit relativ kurzer Zeit liegen IETF Standards vor, die es erlauben, den stabilen Betrieb eines Multicast-Netzes zu gewährleisten. Um dem experimentellen Charakter des MBONE Rechnung zu tragen und um negative Auswirkungen auf den normalen Verkehr zu vermeiden, wird im BWiN eine separate Routerinfrastruktur für den Multicast-Verkehr genutzt. Multicast-Pakete werden dazu in normale IP-Unicast Datenströme verpackt (Tunnels) und an speziell konfigurierte Router geleitet, wo diese Pakete dann vervielfältigt und wiederum eingepackt in IP-Unicast Datenströme weitergeleitet werden. Die Anbindung der Multicast-Router an die zentralen BWiN-Router erfolgt üblicherweise über Ethernet-Schnittstellen, vereinzelt auch über FDDI (z.B. im Kölner Knoten). Diese Konstruktion verkehrt die Intention der Multicast-Technik, Mehrfachverkehr auf einem Streckenabschnitt zu vermeiden, geradewegs ins Gegenteil, da nun jedes ankommende Multicast-Paket auf der gleichen Leitung n-fach wieder hinausgeschickt wird. Auch eine Erhöhung der Bandbreite zwischen BWiN- und Multicast-Router behebt diesen Engpaß nicht, wie auch die Erfahrungen im Kölner Knoten gezeigt haben. Die Umwandlung zwischen Multicast- und Unicast-Datenströmen stellt sich als das eigentliche Problem dar, da der damit einher gehende Overhead die Router schlichtweg überfordert. Ein Austausch der Router durch leistungsfähigere Modelle könnte ebenfalls nur kurzfristig Abhilfe verschaffen.

Um die beschriebene Überlast-Problematik zu entschärfen, wird im BWiN die für Multicast insgesamt zur Verfügung gestellte Bandbreite auf 2 Mbit/s begrenzt – effektiv nutzbar sind pro Einrichtung davon erfahrungsgemäß etwa 500 Kbit/s. Es ist evident, daß selbst eine Verdopplung dieser Kapazität, wie sie bei einem Hardware-Austausch des Routers zu erwarten wäre, für qualitativ hochwertige Multimedia-Anwendungen nicht ausreichend ist.

 

2. Multicast-Protokolle

Im Gegensatz zum normalen IP-Unicast Routing, bei dem die Empfangsadresse a priori bekannt ist, erfordert die Multicast-Technik vergleichsweise komplexe Verfahren, um die Pakete so im Netz zu verteilen, daß einerseits alle beteiligten Stationen erreicht werden, andererseits aber unnötiger Datenverkehr vermieden wird. Eine Multicast-Adresse identifiziert dabei eine bestimmte Gruppenanwendung, beispielsweise den Audio-Kanal in einer Videokonferenz. Zum Aufbau der Topologie des Multicast-Netzes jeder einzelnen Multicast-Anwendung wird prinzipiell ein Spanning-Tree Algorithmus eingesetzt, wobei diese Topologie einer hohen Dynamik unterworfen ist, da Stationen laufend der Gruppe beitreten oder diese verlassen können Die bisher eingesetzten Verfahren lassen sich grob in zwei Kategorien einteilen: dense-mode oder sparse-mode Verfahren.

Protokolle der ersten Gruppe (DVMRP, MOSPF, PIM-DM) gehen von der Annahme aus, daß die Mitglieder einer Multicast-Gruppe dicht beieinander liegen und genügend Bandbreite vorhanden ist, so daß periodisch das Netz mit Multicast-Nachrichten geflutet wird um den Spannbaum aufzubauen.

Demgegenüber gehen dense-mode Protokolle (CBT, PIM-SM) davon aus, daß die Gruppenmitglieder weit im Netz verstreut sind. Nur wenn eine Station explizit ihren Wunsch auf Teilnahme an einer Multicast-Anwendung mitteilt, wird die Multicast-Toplogie entsprechend modifiziert.

Trotz der offensichtlichen Nachteile von dense-mode Verfahren ist das historisch älteste Protokoll, DVMRP, im wissenschaftlichen Umfeld auch heute noch weit verbreitet, da dieses zunächst als public-domain Implementierung auf Unix Rechnern (gated) zur Verfügung stand. Mittlerweile gibt es aber auch entsprechende Implementierungen von sparse-mode Protokollen, namentlich von PIM-SM.

 

3. Operatives Management

Im BWiN gibt es kein einheitlich verwendetes Multicast-Protokoll. Statt dessen sind die einzelnen Einrichtungen per Unicast-Tunnel an den BWiN-Multicast-Routern angeschlossen. Innerhalb der Kundennetze kommen die verschiedensten Protokolle zum Einsatz. Die zentralen Multicast-Router im BWiN werden dabei vom DFN NOC in Stuttgart administriert. Durch fehlerhafte Konfigurationen in den Kundennetzen, insbesondere bei Verwendung von DVRMP, kommt es aber immer wieder zum Auftreten von "schwarzen Löchern", die den gesamten Multicast-Verkehr ansaugen und den Multicast-Backbone damit saturieren. Insgesamt gestaltet sich das Management des Multicast-Netzes im BWiN daher als ausgesprochen schwierig und zeitintensiv.

Erschwert wird diese Situation zudem durch das nahezu gänzliche Fehlen von Management-Tools für Multicast-Netze. Weder Anwender noch Netzadministratoren in den Einrichtungen haben einen Überblick über die aktuelle Auslastung im MBONE. So ist es unmöglich, Aussagen im Vorfeld über die erreichbare Qualität von Multimedia-Anwendungen im BWiN zu machen.

Weitere Probleme stellen die bislang noch nicht befriedigend gelösten Fragen, wie Multicast-Adressen vergeben werden können, wie die Reichweite einer Übertragung begrenzt werden kann, wie Sicherheitsaspekte behandelt werden und schließlich Fragen des Accountings.

 

4. Vorschläge für eine alternative Struktur

Multicast-fähige Netze sind in Zukunft unverzichtbar, wenn innvovative Anwendungen, speziell im Bereich Multimedia, eine Chance haben sollen. Sie dürfen nicht wie bisher als Experimentierfeld, abgeschottet vom normalen Netz, sondern müssen vielmehr als integraler Bestandteil des Dienstangebotes betrieben werden. Im einzelnen sind dazu folgende Schritte notwendig:

• Die Multicast-Funktionalität muß in die normalen BWiN-Router integriert werden. Das bislang vorgebrachte Argument, dadurch würde die Betriebssicherheit des normalen Netzes gefährdet, ist mit dem mittlerweile erreichten Stand der Standardisierung und Implementierung von Multicast-Protokollen nicht mehr zutreffend.
• Die Bandbreitenlimitierung von 2 Mbit/s darf nicht länger Bestand haben. Viele Anwendungen, die Multicast einsetzen, haben einen hohen Bandbreitenbedarf und können sich nicht entwickeln, wenn die nutzbare Bandbreite nicht einen signifikanten Anteil der Gesamtbandbreite ausmacht.
• Im BWiN ist ein einheitliches Routing Protokoll für Multicast einzusetzen. Mit PIM-SM als sparse-mode Protokoll ist ein effizientes, stabiles und standardisiertes Verfahren verfügbar.
• Das Netzmanagement im Multicast-Netz muß dezentralisiert werden können, insbesondere soll der Anwender Zugang zu Management-Informationen erhalten.

1. Literatur

[1] IP Multicast Initiative, http://www.ipmulticast.com

[2] Protocol independent multicast sparse-mode (PIM-SM): Protocol specification, RFC 2362, IETF Juni 1998

[3] Multiprotocol extensions for BGP-4, RFC 2283, IETF Februar 1998

[4] Multicast extensions to OSPF, RFC 1584, IETF März 1994