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.
Multicast-Kommunikation mit RSVP
Der Sender einer Multicast-Kommunikation beginnt damit, in periodischen Abständen "Pfad-Dateneinheiten" (PATH) an eine Multicast-Gruppe zu senden. Basierend auf diesen Informationen wird in den Routern eine entsprechende Zustandsinformation etabliert. Die Daten geben beispielsweise Auskunft über den Weg zurück zum Sender. Ein Empfänger, der an einer Multicast-Kommunikation teilnehmen möchte, signalisiert dies dem Sender über die sogenannte Reservierungs-Dateneinheit (RESV). Der Empfänger kann eine RESV-Dateneinheit senden, sobald er eine PATH-Mitteilung erhalten hat. In der Reservierungs-Dateneinheit gibt der Empfänger die gewünschte Dienstgüte an. Die Router werten diese Informationen aus und leiten sie in Richtung Sender weiter. Dabei bündeln sie die Anforderungen mehrerer Empfänger gegebenenfalls zu einem einzigen Reservierungswunsch. In den Zwischensystemen erfolgt jeweils die Reservierung der erforderlichen Ressourcen.
Der Empfänger erhält normalerweise keine Reservierungsbestätigung. Er weiß also nicht, ob die Ressourcen auch tatsächlich bereitstehen. Dies ist im Zusammenhang mit dem Soft-State-Konzept zu sehen, das RSVP verfolgt. Es werden quasi "weiche" Garantien gegeben, das heißt den Einträgen wird jeweils ein Timer zugeordnet. Läuft er ab, wird der Eintrag - bei RSVP also die Reservierung - gelöscht. Erhält der Sender eine Reservierungs-Dateneinheit, weiß er, dass die erforderlichen Ressourcen bereitstehen. Allerdings beginnt die Sendestation meist bereits vor Eingang der Bestätigung damit, Daten zu übertragen. Es gibt also keine klare Trennung zwischen den Phasen "Reservierung" und "Datentransfer". Beide überlappen sich.
In der Praxis bedeutet das: Der Sender übermittelt Daten; falls interessierte Empfänger vorhanden sind, versuchen diese, die erforderlichen Ressourcen auf dem Pfad zu reservieren. Für diese Reservierungen werden wegen des Soft-State-Konzepts keine Garantien gegeben. Der Sender übernimmt somit bei RSVP keinerlei "Verantwortung".
IP-Netz für Echtzeitdaten: das Multicast-Backbone
Da bei der Einführung der Multicast-Dienste das Internet bereits beachtliche Ausmaße erreicht hatte, entschloss sich die Internet Engineering Task Force, ein Multimediataugliches IP-Overlay-Netz zu schaffen. Der Startschuss dafür fiel auf der IETF-Konferenz im März 1992, als Vorträge in Form von Bild- und Toninformationen mit Hilfe spezieller Programme über das Internet übertragen wurden. Dieses "Multicast Backbone" (MBone) ist seit 1992 von 40 Domänen in vier Ländern auf Tausende von Domänen weltweit angewachsen.
Innerhalb einer solchen Domäne können IP-Multicast-Pakete verschickt und empfangen werden. Eine Domäne ist über Zwischensysteme mit dem Internet verbunden, die nicht über die Multicast-Erweiterungen verfügen. Daher ist der Austausch von Multicast-Paketen zwischen den Domänen nicht ohne weiteres möglich. Um dieses Problem zu lösen, sind die Domänen im MBone über Tunnel verbunden. Ein Tunnel ist eine virtuelle Verbindung zwischen Multicast-fähigen Routern an den Tunnelendpunkten. Zwischen diesen kann sich eine Reihe nicht Multicast-fähiger Router befinden. Um nun die Multicast-Pakete über diese Router weiterzuleiten, wird im MBone hauptsächlich IP-IP-Einkapselung (Encapsulation) eingesetzt. Bei diesem Verfahren wird ein IP-Multicast-Paket von einem "Mrouter" (MBone-Router) in ein Unicast-IP-Paket verpackt ("encapsulated"), dessen Zieladresse die Unicast-Adresse des Mrouters am anderen Endpunkt des Tunnels ist. Auch Unicast-Router sind dann in der Lage, die Daten weiterzuleiten. Hat das Datenpaket den Ziel-Mrouter erreicht, wird es dort wieder ausgepackt (decapsulated) und innerhalb der Multicast-fähigen Domäne per Multicast weitertransportiert.
Die IP-IP-Encapsulation hat aber auch Nachteile. So werden die Pakete durch das Verpacken größer; außerdem lässt sich das Verfahren nur dann anwenden, wenn der Mrouter am Tunnelendpunkt die IP-Pakete auch auspacken kann. Insgesamt ist festzustellen, dass Tunnel nur als vorübergehendeLösung zu sehen sind, auch wenn das MBone als Overlay-Netzwerk in den vergangenen Jahren seine Funktionsfähigkeit bewiesen hat. (re)
Zur Person
Joachim Zubke
studierte an der Fachhochschule Hamburg Elektrotechnik, Fachrichtung Nachrichtentechnik. Seit Herbst 1999 ist er bei der Firma Netsprint Consulting in Hamburg als zertifizierter Netzwerk-Trainer für Cisco Systems tätig.
Stefan Bohnert
absolvierte ebenfalls in Hamburg ein Studium im Fach Elektrotechnik. Wie Zubke ist Stefan Bohnert bei Netsprint als Netzwerktrainer tätig.