Dienste mit Qualität

QoS-Unterstützung durch Intserv

Das "Integrated Services"-Modell (Intserv), beschrieben in RFC 1633 (Integrated Services in the Internet Architecture), erlaubt es, Dienstgüte für Anwendungen mit besonderen Anforderungen an Bandbreite, Verzögerungszeiten (Delay) und Jitter bereitzustellen. Im Mittelpunkt steht dabei das Signalisierungsprotokoll "Resource Reservation Protocol" (RSVP). Es erlaubt eine empfängerbasierte Reservierung, indem in bestimmten Zeitabständen RSVP-Nachrichten ausgesandt werden. Jeder Netzwerkknoten muss Informationen zu den IP-Datenströmen (IP-Flows), die ihn durchlaufen, verarbeiten und speichern.

Dieses explizite Reservieren von Ressourcen wird bereits erfolgreich in Firmen- und Zugangsnetzen eingesetzt, um QoS bereitzustellen. Im Backbone-Bereich ergeben sich allerdings Probleme mit der Skalierbarkeit, weil dort Netzknoten unter Umständen von sehr vielen Flows durchlaufen werden. Daher befassen sich die aktuellen Arbeiten zu Intserv mit Techniken, die RSVP besser skalierbar machen sollen. Außerdem wurde eine Methode vorgestellt, die das Datenvolumen verringert. Das Verfahren nutzt dazu die Ähnlichkeit der periodisch verschickten RSVP-Nachrichten. Ein weiterer Ansatz reduziert den Overhead bei der Verarbeitung von RSVP-Refresh-Nachrichten.

Parallel dazu sind Techniken in der Diskussion, mit denen sich eine hierarchische RSVP-Struktur aufbauen lässt. Ein Vorteil dieses Ansatzes: die bessere Skalierbarkeit von Routern mit vielen Intserv-Flows. Um RSVP auch dann einsetzen zu können, wenn Intserv nur auf einem Teil des Übertragungsweges zur Verfügung steht, wurde die Idee von RSVP-Proxies geboren. Sie sind in der Lage, vom Sender stammende RSVP-Nachrichten anstelle des Empfängers zu beantworten.

Bisher wurden bei Intserv und RSVP folgende Dienstklassen unterstützt:

- beim "Guaranteed Service" werden Garantien für Bandbreite, Verlust, Maximalverzögerung und Jitter gegeben,

- beim "Controlled Load Service" Zusagen bezüglich Bandbreite und Verlust.

In beiden Fällen muss die Anwendung exakte Obergrenzen für das Verkehrsprofil des IP-Flows angeben, damit in den Routern die erforderlichen Ressourcen reserviert werden können. Für Fälle, in denen das nicht möglich ist, wurde jetzt eine dritte Dienstklasse spezifiziert - der "Null Service". Hier äußert eine Anwendung lediglich den Wunsch, dass der von ihr erzeugte IP-Flow bevorzugt behandelt werden sollte, ohne ein Verkehrsprofil anzugeben. Das Netz stellt anschließend für die betreffenden Flows Ressourcen bereit, wobei es die Policies berücksichtigt. Normalerweise können die Anforderungen der Anwendungen dann auch erfüllt werden.