Von: Axel Clauberg
In seinem Buch "Quality of Service", das er zusammen mit Geoff Huston geschrieben hat, bezeichnet Paul Ferguson QoS als "Elusive Elephant" (nicht fassbaren Elefanten). Er umschreibt damit, dass je nach Sichtweise unter QoS unterschiedliche Dinge verstanden werden. Zwar möchte jeder Servicequalität haben, doch für einen Teil der Fachwelt stellt QoS im Zusammenhang mit IP einen Widerspruch an sich dar, für andere Experten ist eine bestimmte Dienstgüte in IP-Netzen nur in Zukunft oder bestenfalls mit IPv6 zu erreichen. Eine dritte Fraktion wiederum vertritt die Meinung, dass Servicequalität in IP-Netzen bereits Realität ist.
Eine bestimmte Dienstqualität im Netz lässt sich provozierend auch als "gemanagte Unfairness" bezeichnen, denn einige Anwendungen werden zu Ungunsten anderer bevorzugt, etwa dann, wenn Engpässe bei bestimmten Ressourcen auftreten. Servicequalität ist ein Paradebeispiel für einen Netzdienst, der durchgehend ("Ende zu Ende") in LANs und Weitverkehrsnetzen angeboten werden muss. Viele Anwender konzentrieren sich zunächst darauf, das Weitverkehrsnetz QoS-tauglich zu machen, indem sie dort Bandbreitenengpässe beseitigen. Dazu rüsten sie die entsprechenden Systeme hoch oder setzen Leitungen mit höherer Bandbreite ein. Anschließend wird das lokale Netz angepasst.
Im Rahmen der "Internet Engineering Task Force" (IETF) diskutierten bereits Anfang der neunziger Jahre Fachleute darüber, wie das damals fast 20 Jahre alte "Best-Effort-Verfahren" zur Weiterleitung von IP-Paketen für Anwendungen mit besonderen Serviceanforderungen erweitert werden könnte. Diese Frage stellte sich erstmals im Zusammenhang mit Multimediadiensten, konkret der Übertragung der IETF-Meetings mit Hilfe der IP-Multicast-Technik. Der Versuch, das Problem durch eine stets ausreichende (also unendliche) Bandbreite zu lösen, scheiterte. Das exponentielle Wachstum des IP-Verkehrsvolumens führte bislang alle derartigen Bemühungen ad absurdum.
Die IETF hat mittlerweile zwei Ansätze entwickelt, mit deren Hilfe sich eine Quality of Service in IP-Netzen sicherstellen lässt:
- "Integrated Services" (Int-Serv): Bei diesem Verfahren werden im Netz Ressourcen pro Verbindung reserviert. Ein Endsystem verwendet in den meisten Fällen das "Resource Reservation Protocol" (RSVP), um die gewünschten Verkehrsparameter mitzuteilen. Einen bestimmten Zustand pro Verbindung im ge-samten Netz herzustellen und aufrechtzuerhalten, schränkt allerdings die Skalierbarkeit ein. Das Protokoll eignet sich daher hauptsächlich für Anwendungen mit einer überschaubaren Zahl von Verbindungen. Zu dieser Kategorie zählen Multimedia-Applikationen oder Multicast-Gruppen. Eine Internet-weite Nutzung war nicht angedacht.
- "Differentiated Services" (Diff-Serv): Bei differenzierten Services sind die Verbindungen in Klassen aufgeteilt. Ressourcen im Netzwerk werden nicht pro Verbindung, sondern für eine bestimmte Klasse reserviert. Dadurch lässt sich die Servicequalität nicht so fein abstufen wie bei Int-Serv oder in einem ATM-Netzwerk. Andererseits hat sich dieser eher "hemdsärmelige" Ansatz als deutlich besser skalierbar erwiesen.
Integrated Services: Grundlage RSVP
Int-Serv stellt ein Ende-zu-Ende-Servicemodell bereit. Es unterstützt neben Best-Effort-Verkehr auch den Transfer von Multimedia-Daten mit Echtzeitanforderungen sowie die kontrollierte Lastverteilung auf einer Verbindung. Eine Serviceanforderung geht von den Endsystemen aus. ATM verwendet hier das "User Network Interface" (UNI) zur Signalisierung. Ein vergleichbares Protokoll steht in der IP-Welt mit RSVP zur Verfügung. Es dient zur Signalisierung der Verkehrsparameter für Int-Serv, hat inzwischen aber auch in anderen Bereichen Einzug gehalten. Eine Reservierung, die mittels RSVP vorgenommen wird, ist stets unidirektional und kann für Unicast- oder Multicast-Verkehrsflüsse vorgenommen werden. Für eine Sprachverbindung über IP sind also zwei Reservierungen erforderlich, je eine für beide Kommunikationsrichtungen.
Der Sender signalisiert seine Verkehrsanforderungen in einer "PATH"-Nachricht. Das Paket ist mit der Router-Alert-Option gekennzeichnet, so dass jeder RSVP-fähige Router, der auf dem Weg zwischen Sender und Empfänger liegt, das Paket analysiert. Der Router prüft die Ressourcenwünsche, eventuell über einen externen Policy-Server, protokolliert die IP-Adresse des eingehenden Interfaces im RSVP-Paket und schickt das Paket dann weiter in Richtung Empfänger.
Der Adressat teilt die von ihm akzeptierten Verkehrsparameter in einer "RESV"-Nachricht mit, die gemäß der protokollierten IP-Adressen von Router zu Router ("Hop by Hop") in Richtung Sender übermittelt wird. Auf diese Weise ist sichergestellt, dass die unidirektionale Reservierung selbst bei asymmetrischen Routen korrekt erfolgt. Da sich eine Route im IP-Netz ändern kann, muss die PATH/RESV-Nachricht regelmäßig wiederholt werden. Bleibt sie aus, kann der Router die Reservierung löschen.
Reservierung mit Cops prüfen
Ein Router erkennt einen Datenstrom (Flow) anhand der IP-Adresse und des IP-Protokolls sowie der TCP/UDP-Portnummern, bei IPv6 auch anhand des Flow-Labels. RSVP überprüft jedoch nicht, ob eine Reservierung zulässig ist. Für diese Aufgabe ist das "Common-Open-Policy-Server"-Protokoll (Cops) zuständig, ein spezielles Policy-Protokoll.
Kommt Int-Serv zum Zuge, sollte das Netzwerk unterscheiden können, ob eine rechtmäßige Reservierungsanfrage vorliegt, etwa für eine geschäftskritische Anwendung, oder ob sich ein Mitarbeiter in der Mittagspause bei einem Multi-User-Spiel entspannt. Solche Policy-Entscheidungen werden nicht nur bei Int-Serv benötigt; deshalb hat die Arbeitsgruppe "Resource Admission Policy" (RAP) der IETF ein Policy-Modell entwickelt: den "Common Open Policy Server".
Ein Netzwerkgerät übernimmt dabei die Rolle eines "Policy Enforcement Point" (PEP). Über eine TCP-Verbindung wird bei einem "Policy Decision Point" (PDP) geprüft, ob die gewünschte Aktion überhaupt durchführbar ist. Mit Hilfe von Cops können PDPs und PEPs beliebige Policy- und Konfigurationsinformationen austauschen. Ein PDP bezieht seine Informationen beispielsweise aus einem LDAP-Verzeichnisdienst.
Obwohl die Int-Serv-Struktur seit 1994 dokumentiert ist und auch RSVP bereits seit 1997 vorliegt, wird Int-Serv kaum eingesetzt. Das liegt zum einen an der lange Zeit mangelhaften Unterstützung in den Endsystemen. So sind nur die aktuellen Windows-Versionen 98 und 2000 für RSVP ausgelegt; ähnlich sieht es im Unix-Bereich aus. Hinzu kommt, dass die Netzbetreiber die mangelnde Skalierbarkeit fürchteten. Außerdem fehlte lange Zeit ein Policy-Server. Die Router dagegen sind in der Lage, mehrere tausend RSVP-Datenströme zu unterstützen.
Differentiated Services: Ressourcen nach Klassen
Das Diff-Serv-Modell umschifft die Hürde der Skalierbarkeit von integrierten Services, indem es Ressourcen anhand der Verkehrsklasse reserviert. Ein IP-Paket wird bei Eintritt in das Netz einer Klasse zugeordnet und dann anhand vorgegebener Regeln gemäß den Anforderungen seiner Serviceklasse weitertransportiert.
Zur Klassifizierung wurde bereits 1981 im RFC 791 ein Teil des "Type-of-Service"-Oktetts (Tos) im IP-Header vorgesehen: die drei "IP Precedence"-Bits. Im Rahmen der Standardisierung von Diff-Serv stellte sich jedoch heraus, dass die damit möglichen acht Verkehrsklassen nicht ausreichten. Deshalb wurden die bislang kaum verwendeten anderen Teile des Tos-Felds komplett umgewidmet. Das nun als "Diffserv Field" bezeichnete Tos-Oktett bietet nun im "Diffserv Code Point" aufwärtskompatibel zur "IP Precedence" sechs Bit zur Klassifizierung. Die übrigen zwei Bit sind reser-viert, werden aber gegenwärtig nicht genutzt.
Auf Grundlage der 64 Serviceklassen, die IPv4 und IPv6 bereitstellen, wurden einige der pro Hop gültigen Verhaltensregeln ("Per Hop Behaviour" = PHB) standardisiert. Den Herstellern bleibt überlassen, wie sie die Norm in ihre Produkte einbauen. Jede Implementierung unterstützt zumindest das Best-Effort-PHB.
Das "Expedited Forwarding"-Verfahren wurde für Echtzeitverkehr wie Sprache über IP entworfen. Es räumt einem Sprachpaket Vorrang vor anderen Daten in einer Warteschlange ein. Der Haken dabei ist, dass Voice over IP zum Datentransfer das User Datagram Protocol (UDP) nutzt. TCP-Anwendungen müssen deshalb vor dem "Aushungern" geschützt werden, indem die Bandbreite, die UDP-Daten zur Verfügung steht, auf einen Maximalwert beschränkt wird. Ein weiteres Übertragungsverfahren im Rahmen von Diff-Serv ist das "Assured Forwarding". Es optimiert das Best-Effort-Verhalten für TCP-Anwendungen. Auf diese Weise lassen sich "Olympische Dienste" (Gold, Silber, Bronze) einrichten. Der Standard sieht insgesamt vier Verkehrsklassen mit jeweils drei Unterklassen vor.
Um Differentiated Services einzurichten und zu überwachen, sind spezielle Werkzeuge erforderlich, etwa für die Klassifizierung, das Metering oder das Einrichten von Policies. Hinzu kommen Tools, mit denen sich Warteschlangen und Überlastsituationen im Kern des Netzes steuern lassen. Auf diese Werkzeuge gehen wir in einem eigenen Beitrag ein. Skalierbare Diff-Serv-Implementierungen sind seit Ende 1997 auf Basis von "IP Precedence" beziehungsweise seit 1999 auf Grundlage von "Diffserv Code Points" verfügbar. Das Verfahren wird sowohl in den Netzen von Serviceprovidern als auch Enterprise Networks eingesetzt.
Erfahrungen und Ausblick
Die vorliegenden Praxiserfahrungen belegen, dass der in Diff-Serv realisierte Ansatz tatsächlich funktioniert: Geschäftskritische Anwendungen lassen sich von anderen unterscheiden; gleichzeitig können Echtzeitapplikationen, wie Sprache über IP, in ein Netz integriert werden, ohne Abstriche an der Qualität zu machen. Als aufwendig hat sich das Management der Serviceklassen beziehungsweise ihrer Ressourcen auf den Verbindungswegen erwiesen. Solange keine adäquaten Management- und Planungslösungen vorliegen, ist davon abzuraten, mit zu vielen Klassen zu arbeiten. Als sinnvoll haben sich zwei oder drei Datenklassen und eine Sprachklasse erwiesen.
In vielen Unternehmen tritt zudem das Problem auf, dass die Anforderungen der Anwendungen an das Netzwerk nicht genau bekannt sind oder sich die Anwendungen, bedingt durch dynamische Port-Wahl, nicht direkt klassifizieren lassen. In diesem Fall empfiehlt es sich, "Service Level Agreements" (SLAs) zu erarbeiten oder Verfahren einzusetzen, die Layer-7-Daten erkennen und verarbeiten, wie etwa "Network Based Application Recognition" von Cisco.
Die Mitglieder der IETF arbeiten mittlerweile daran, Int-Serv und Diff-Serv zusammenzuführen. Dies könnte so aussehen: Eine Applikation signalisiert dem Netz mit Hilfe von RSVP ihre Anforderungen; der erste Router befragt einen Cops-Policy-Server, der ein zu nutzendes Diff-Serv-Per-Hop-Behaviour zurückmeldet. Der RSVP-Request wird dann über den Diff-Serv-Backbone zum Ziel getunnelt. Microsoft, SAP und Cisco demonstrierten das Verfahren im September 1999 auf der Fachmesse Networld + Interop in Atlanta
Unter dem Strich ist festzuhalten, dass IP-Servicequalität heute keine Fiktion mehr ist, auch wenn noch einige Bausteine fehlen: Die Standards liegen vor, und der Anwender kann entsprechende Lösungen in sein Netz integrieren. Die größte Herausforderung für die Zukunft besteht darin, QoS in das Netzwerkmanagement einzubetten. (re)