Für das Multimedia-Zeitalter gerüstet

Im Zusammenhang mit Echtzeit-Multicast-Anwendungen spielen zwei Begriffe eine zentrale Rolle: das "Resource Reservation Protocol", das Anwendungen eine Dienstgüte sichert, und das Overlay-Netz "MBone".

Von: Joachim Zubke, Stefan Bohnert

Echtzeitdaten lassen sich nicht ohne weiteres mittels Multicast über IP-Netze transportieren. Die Voraussetzung dafür ist, dass Ressourcen wie Bandbreite, Bit-Rate oder Verarbeitungsleistung in einer garantierten Qualität zur Verfügung stehen. Das Internet arbeitet jedoch nach der "Best-Effort"-Methode, die eben keine garantierte Dienstgüte (Quality of Service = QoS) unterstützt.

Um dieses Problem in den Griff zu bekommen, wurden QoS-Mechanismen für Multimedia-Anwendungen entwickelt. Sie beruhen auf abgestuften Quality-of-Service-Niveaus. Ein solcher Ansatz ist Intserv (Integrated Services). Er stellt einzelnen Datenströmen gezielt Ressourcen bereit. Das bedeutet für die netzinternen Zwischensysteme, sprich Router oder Switches, dass sie Zustandsinformationen und Daten über die Ressourcenanforderungen jedes einzelnen Datenstromes speichern und auswerten müssen. Zu den Vorteilen einer gezielten Reservierung zählt, dass die Ressourcen explizit einer bestimmten Anwendung zur Verfügung gestellt werden.

Das Verfahren basiert darauf, dass sich die Datenströme in Klassen einteilen lassen. Intserv verwendet drei Dienstklassen:

- "Best Effort": Die Standard-Dienstklasse im Internet; sie bietet keine QoS-Garantien.

- "Controlled Load Service" (RFC 2210) stellt eine priorisierte Dienstklasse zur Verfügung, jedoch keine feste Zuteilung von Bandbreite.

- "Guaranteed Service" (RFC 2212): Sieht eine feste Reservierung von Bandbreiten vor, außerdem eine garantierte maximale Verzögerungszeit.

Intserv unterstützt somit Echtzeit- und "normale" Anwendungen. Ein Protokoll, das auf Intserv aufsetzt, ist das "Resource Reservation Protocol" (RSVP). Es implementiert ein empfängerorientiertes Reservierungskonzept. Ein Host "erfragt" dabei eine bestimmte Dienstgüte für einen Datenstrom. RSVP beschränkt sich dabei darauf, die Dienstgüte anzufordern. Um die Reservierung kümmert sich das Protokoll ebenso wenig wie um den Transfer der Nutzdaten. Dazu ist ein spezielles Protokoll erforderlich. Der Vorteil dieser Struktur ist, dass RSVP auf IP für den Nutzdatentransfer aufsetzen kann.

Das Resource Reservation Protocol eignet sich sowohl für Unicast- als auch für Multicast-Kommunikation. Allerdings ist dabei zu berück-sichtigen, dass RSVP ein Simplex-Protokoll ist, das heißt eine Reservierung gilt nur für eine Richtung, und zwar vom Sender zum Empfänger. Sie ist also unidirektional.