Von: Kai-Oliver Detken, Bernd Reder
Das Internet ist kein homogenes Ganzes, sondern besteht aus vielen Teilnetzen. Das hat Konsequenzen für den Transport von Daten, die eine bestimmte Dienstgüte benötigen, wie etwa Sprachinformationen oder Videosequenzen. Es sind "Verträge" notwendig, die dafür sorgen, dass die Quality of Service (QoS) in allen Netzsegmenten bereitsteht.
Diese Anforderung betrifft in erster Linie die Router - die zentralen Vermittlungssysteme im Internet. Ein Router nimmt die Verkehrsströme von Host-Rechnern in Empfang und gibt sie an eine Warteschlange (Queue) weiter. Dann analysiert er den Paketkopf und entscheidet, an welchen Ausgang (Port) er das Paket weiterreicht. Am Eingang des Netzes werden meist mehrere solcher kleinen Datenströme zu einem großen "Stream" zusammengefasst. Die Hosts greifen normalerweise unabhängig voneinander auf das Internet zu. Das hat zur Folge, dass auch die Ressourcen des Netzes nach einem bestimmten statistischen Muster genutzt werden. Deshalb heißt dieses Verfahren statistisches Multiplexen.
Beim "Statistical Multiplexing" beeinflussen folgende Parameter die Verkehrscharakteristik:
- die Zahl der ankommenden Datenpakete,
- die Verarbeitungsgeschwindigkeit des Routers sowie
- die verfügbare Bandbreite zwischen den Routern im Backbone.
Auch das Internet-Protokoll selbst weist Eigenheiten auf, die sich auf die Übertragung von Echtzeitdaten auswirken. So ist IP ein Protokoll der Vermittlungsschicht, also der Ebene 3 des ISO/OSI-Modells. Daher arbeitet es unabhängig von der Übertragungstechnik und dem physikalischen Medium. Funktionen wie QoS oder das Reservieren von Ressourcen setzen allerdings Mechanismen voraus, die sowohl Layer-2-Protokolle als auch IP mit einbeziehen.
Gegenwärtig werden zwei Ansätze diskutiert, mit denen sich "Classes of Service" (CoS) beziehungsweise Quality of Service in IP-Netzen sicherstellen lassen: Integrated Services (Intserv) und Differentiated Services (Diffserv).
Komplexer Ansatz: die Integrated Services
Das Intserv-Modell wurde von der Arbeitsgruppe "Integrated Services" der Internet Engineering Task Force (IETF) erarbeitet. Details sind im Request for Comment (RFC) 1633 zu finden. Der Ansatz soll das "Best-Effort-Modell" ablösen, das den Anforderungen von Echtzeit-Applikationen nicht gerecht wird. Bei Intserv fragt der Host bei den Routern im Inter- oder Intranet an, ob die Ressourcen für einen Verkehrsfluss vom Sender zum Empfänger vorhanden sind. Ist das der Fall, stellen die Vermittlungssysteme die Verbindung in der gewünschten Qualität her und halten sie solange aufrecht, bis die Übertragung zu Ende ist.
Das Konzept sieht mehrere Klassen von Prioritäten vor. Je nachdem, wie empfindlich Anwendungen auf Schwankungen der Übertragungszeiten reagieren, ordnet Intserv ihnen unterschiedliche QoS-Klassen zu. Der Hintergrund ist, dass Echtzeitapplikationen wie Video- und Audiokonferenzen exakt definierte Verzögerungszeiten benötigen, während andere Anwendungen weniger anfällig sind. Die Integrated Service Group hat drei Kategorien von Applikationen festgelegt:
- "Hard Real-Time Applications"
- "Delay Adaptive Applications"
- "Elastic Applications"
Die erste Gruppe reagiert empfindlich auf Störungen, während die zweite Gruppe leichte Verzögerungen bei der Übermittlung der Daten toleriert. Die dritte Kategorie umfasst reine Datenanwendungen, wie etwa FTP oder E-Mail, die große Zeitverzögerungen verkraften und das Zwischenspeichern von Paketen zulassen.
Auf dieser Grundlage definierte die Intserv-Arbeitsgruppe fünf Dienstklassen, von denen jedoch gegenwärtig nur die beiden ersten eine Rolle spielen: "Controlled Load Service" und "Guaranteed Service". Der Guaranteed Service berücksichtigt alle Serviceparameter und deren Kombinationen. Das heißt, nicht nur der Durchsatz dient als Maßstab für die Dienstgüte, sondern auch die Verzögerungszeit. Außen vor bleiben dagegen Jitter und Latenzzeit.
Der Controlled Load Service (RFC 2211) erlaubt es, einzelnen Anwendungen eine bestimmte Bandbreite zuzuweisen. Alle anderen QoS-Parameter fallen unter den Tisch. Das heißt, dass sich Netzparameter nicht einbeziehen lassen. Eine Dienstgüte à la Controlled Load lässt sich auch oberhalb der Sicherungsschicht implementieren. Das hat den Vorteil, dass die unteren OSI-Ebenen ohne Änderung übernommen werden können.
Einfachere Lösung: die Differentiated Services
Intserv weist zwei grundlegende Schwächen auf: Das Modell ist kompliziert und nur in geringem Maße skalierbar - unter anderem deshalb, weil es eine Reservierung von Ressourcen für jeden einzelnen Datenfluss erfordert. Das wiederum strapaziert die Router in erheblichem Maße.
Deshalb entwickelte die IETF eine Alternative: die "Differentiated Services". Dieses Konzept sieht vor, dass Dienste in wenige QoS-Klassen unterteilt werden. Für jede Dienstklasse steht ein Satz von Regeln bereit, das "Per-Hop Behavior" (PHB). Wird ein Datenpaket ins Netz eingespeist, erhält es im DS-Feld des Headers eine Markierung. Diese entspricht der Dienstklasse, die für das Paket vorgesehen ist. Mehrere Datenströme mit ähnlichen QoS-Anforderungen werden dann zu einem Verkehrsbündel zusammengefasst. Dieser Vorgang heißt Aggregation.
iors) mit einem Datenpaket zu verfahren ist.
Das Verfahren ist erheblich einfacher als Intserv, weil es nicht notwendig ist, jeden Datenfluss separat zu verwalten. Nur einmal, nämlich am Eingang des Diffserv-Netzes, werden die Daten bearbeitet und die QoS-Klassen festgelegt oder die Policies kontrolliert.
Als DS-Feld bezeichnet man bei Diffserv das Type-of-Service-Feld des IPv4-Headers beziehungsweise das "Traffic Class Octett" des IPv6-Kopffeldes. Die ersten sechs Bit, die DS-Codepoints (DSCP), dienen dazu, die einzelnen Datenströme eines Verkehrsbündels auseinander zu halten. Anhand des DS-Codepoints entscheidet ein DS-Knoten, welchen Regeln, sprich Per-Hop Behaviors, ein Paket gehorchen muss. Jedem Codepoint entspricht exakt ein PHB.
Zentrale Elemente eines Netzes auf Grundlage von Diffserv sind "Diffserv Clouds" oder "DS-Domänen". Im Internet lassen sich mehrere Diffserv-Wolken aufbauen, in denen feste Regeln gelten, wie Datenströme zu behandeln sind. Darüber hinaus regeln Service Level Agreements (SLA), wie mit diesen "Flows" zu verfahren ist, wenn sie in solche "Wolken" eintreten oder sie verlassen. Dieser Ansatz entspricht der Art, wie das Internet in der Praxis verwaltet wird, für den QoS-Bereich ist er dagegen neu.
Ein Paket, das ein Diffserv-Netz erreicht, passiert einen Classifier, der es einem bestimmten "Aggregate" zuordnet. Vom Classifier läuft es zu einem Traffic Conditioner weiter, der es mit einem DS-Codepoint versieht. Jeder DS-Knoten auf dem Weg zum Empfänger prüft den DSCP und leitet das Paket entsprechend der zugehörigen PHB und Routing-Tabelle weiter. Welche DSCP zu welchem PHB passt, überprüft der Knoten mit Hilfe von Mapping-Tabellen.
"Quality of Service" oder "Class of Service"
Zum Abschluss noch eine Anmerkung zum Begriff "Quality of Service". QoS ist laut Definition die Dienstgüte, die für eine einzelne Sitzung erreicht wird. Dabei spielen Faktoren wie die garantierte Bandbreite, Verzögerung, Jitter, Bandbreitenschwankungen oder Prioritäten eine Rolle. Weitere Kriterien sind Verfügbarkeit, Fehlertoleranz, Redundanz, Effizienz und Sicherheit. Es liegt auf der Hand, dass sich alle diese Punkte nur mit erheblichem Aufwand in Techniken umsetzen lassen, die eine "richtige" Dienstgüte garantieren.
Wie oben erläutert, berücksichtigen Diffserv oder Intserv nur einige dieser Faktoren. Die "IP-QoS", die beide Verfahren und auch IEEE 802.1p bieten, sollte daher besser als "Class of Service" (CoS) bezeichnet werden. CoS bedeutet, dass gleichartige Datenströme in einer Klasse zusammengefasst werden, der das Netz dann eine bestimmte Dienstgüte zuordnet. Einzelne Sessions erhalten also keine individuelle Quality of Service.
Die Einteilung in CoS-Prioritäten ist dabei nicht mit einer garantierten Dienstgüte verbunden, wie das bei ATM der Fall ist. Es werden weder "Verkehrsverträge", sprich Traffic Contracts, aufgesetzt noch Garantien vergeben. Auch Jitter und Verzögerungszeiten finden nur bedingt oder gar keine Berücksichtigung. Man geht einfach davon aus, dass das Netz isochrone Datenströme optimal unterstützt, sodass es zu keinen Störungen kommt.
Zur Person
Kai-Oliver Detken
studierte an der Universität Bremen Informationstechnik. Gegenwärtig ist er als Berater und als freier Autor im IT-Umfeld tätig.