Suchen

Grundlagen moderner Netzwerktechnologien im Überblick – Teil 27 Moderne LAN-Technologien: Quality of Service, QoS

Autor / Redakteur: Dr. Franz-Joachim Kauffels / Dipl.-Ing. (FH) Andreas Donner

Durch die in der letzten Folge beschriebenen Anforderungen entsteht auf der Grundlage einer soliden Netz-Konstruktion der Bedarf nach Mechanismen zur Definition und Durchsetzung von Quality of Service, kurz QoS. Auch hierfür gibt es entsprechende Standards.

Moderne Switches erlauben eine Priorisierung des Datenverkehrs; Bild: Dr. Franz-Joachim Kauffels
Moderne Switches erlauben eine Priorisierung des Datenverkehrs; Bild: Dr. Franz-Joachim Kauffels
( Archiv: Vogel Business Media )

Im Zuge erhöhter Anforderungen an Lokale Netze hat der Begriff „Quality of Service“, kurz QoS, in der Diskussion breiten Raum eingenommen. Es geht hierbei schlicht um die Frage, ob man von dem bislang vorherrschenden Gleichheitsprinzip in LANs abweichen und Pakete bestimmter Anwendungsströme bevorzugt behandeln soll.

Dabei ist QoS durchaus vielfältig: Man kann z.B. verlangen, dass eine bestimmte, geringe Bandbreite immer zur Verfügung steht und die Verzögerung auf dieser Verbindung klein gehalten wird. Dies braucht man, um bspw. Sprache auf einem Datennetz sinnvoll zu übertragen.

Bildergalerie

Oder man kann verlangen, dass ein Netz eine bestimmte hohe Bandbreite zwar kurzzeitig, aber vollständig zur Verfügung stellt. Dies wäre bei Videoübertragung wünschenswert, wo die Updates in festen Zeitabständen anfallen. Ein weiteres Qualitätsmerkmal wäre die Zuverlässigkeit einer Verbindung. Das ist für die meisten Anwender extrem wichtig, steht aber bei den Normungsgremien und Herstellern eher unten auf der Skala.

Es gibt zwei grundsätzliche Vorgehensweisen, um mehr Qualität zu erzielen: die Realisierung relativ komplexer Reservierungs- und Spezifizierungsverfahren oder die Erhöhung der Bandbreite.

In dieser Folge geht es um die Technologien der ersten Gruppe. Hier sind die Verfahren RSVP, IEEE 802.1D/p und IEEE 802.1Q zu nennen, die auf unterschiedliche Weise dazu beitragen, dass man in einem LAN Qualitätsstufen durchsetzen und nutzen kann. Die Verfahren entbehren allerdings nicht einer gewissen Komplexität und führen auch nur unter bestimmten Voraussetzungen zum Erfolg.

Die andere Methode kommt einem Vorgehen mit der Brechstange gleich und bedeutet, einfach so viel Bandbreite üppige zu spendieren, dass das Netz gar nicht anders kann, als alle Pakete mit höchster Qualität und sehr geringer Verzögerung auszuliefern. Hierfür gibt es durchaus einen theoretischen Hintergrund aus der Warteschlangentheorie: Kleinrock hat schon früh berechnet, dass vor einer Ressource praktisch keine Warteschlangen entstehen, wenn diese nur zu höchstens 70% ausgelastet wird. Das bedeutet im Klartext, dass man sich all die komplizierten Verfahren praktisch schenken kann, wenn man genügend Bandbreite hat. Man muss dabei nur immer darauf achten, nicht über die 70% Auslastung zu kommen, die sich natürlich an der Real- und nicht an der Nominalleistung orientieren.

Grundsätzlich ist die Einführung von QoS in paketvermittelnden LANs wie folgt organisiert. Die IEEE Integrated Services Working Group definiert Dienstklassen und die dazugehörigen Zugangskontrollmechanismen. Dies erspart es Anwendern und Herstellern, selbst über diese Fragen nachzudenken, und hat eine übersichtliche Menge von Qualitätsstufen geschaffen. Die Pakete der Schichten 2 und/oder 3 werden als Ergebnis in Klassen eingeteilt, die zu den Qualitätsstufen passen. Dabei gibt es verschiedene Möglichkeiten, wie z.B. eine proprietäre Klassifizierung, eine Klassifizierung nach dem aus der Internet-Welt stammenden Reservierungsprotokoll RSVP oder eine Klassifizierung nach IEEE 802.1D/p, wozu wir gleich kommen.

weiter mit: RSVP, das Resource ReSerVation Protocol

RSVP, das Resource ReSerVation Protocol

Diese Klassifizierung dient sozusagen als Arbeitsanweisung für das Reservierungsprotokoll RSVP, welches eine dynamische Ende-zu-Ende-Reservierung vornehmen kann, aber noch mehr Fähigkeiten hat, wie z.B. die Unterstützung von Multicasts.

RSVP ist die Abkürzung für Resource ReSerVation Protocol und ist im Zusammenhang mit Realisierungsfragen für Multimedia-Anwendungen aufgekommen. Es steuert eine Voraus-Reservierung von Betriebsmitteln für Unicast oder Multicast-Anwendungen, wobei auch die Gruppen-zu-Gruppen-Kommunikation unterstützt werden kann.

Die Reservierungen erfolgen immer unidirektional; RSVP ist ein Simplex-Protokoll. Das ist durchaus sinnvoll, denn gerade bei Multimedia hat man oftmals Informationsquellen wie einen Video-Server und Informationssenken wie Endgeräte. Vom Video-Server zum Endgerät kann die Reservierung einer Qualitätsklasse sinnvoll sein, in der Rückrichtung ist dies nicht erforderlich.

Dennoch hat man sich entschlossen, die Reservierung vom Empfänger ausgehen zu lassen. Wenn also eine Workstation eine Videoübertragung durch eine bestimmte Dienstklasse unterstützen soll, teilt sie dies dem Netz mittels RSVP mit. RSVP sorgt dann dafür, dass vom Video-Server bis zur empfangenden Station die gewünschte Dienstqualität durchgeschaltet wird, wenn dies möglich ist. Der Grund für diese Vorgehensweise ist darin zu sehen, dass RSVP überhaupt nicht für den Einsatz in LANs, sondern für Stadtnetze und WANs entwickelt wurde.

Ein Empfänger muss in diesem Zusammenhang die Möglichkeit haben, die Qualität einer Verbindung und damit das, was er für diese Verbindung bezahlen muss, zu steuern. Ist er mit einer schlechteren Qualität zufrieden, muss er auch weniger bezahlen.

Dies haben sich die Schöpfer des Verfahrens zumindest so vorgestellt, eine Realisierung ist dem Autor allerdings nicht bekannt. Im LAN-Bereich wird man normalerweise keine Abrechnung vornehmen, aber auch hier ist die Wahlmöglichkeit von der Workstation aus ganz praktisch. Wenn man z.B. als Standard eine geringe Dienstgüte vereinbart, die für die üblichen Anwendungen ausreicht, kann man, sobald man in eine Anwendung wechselt, die eine höhere Dienstgüte verlangt, die Änderung der Dienstqualität veranlassen.

Das RSVP-Protokoll, ein Zusatz für das Routing

Das RSVP-Protokoll ist ein Zusatz für die Routing-Protokolle. Es kann selbst nicht routen. Geräte, die RSVP unterstützen, werden aufgrund von RSVP-Reservierungen die Zuordnung ihrer Betriebsmittel (Speicher, Prozessor, Leitungskapazität) zu den Verkehrsflüssen ändern bzw. anpassen. Geräte, die RSVP nicht unterstützen, werden einfach transparent durchlaufen und denken sich nichts weiter dabei. Kommt es allerdings in diesen Geräten zu Engpässen, nützt es auch nichts mehr, dass die anderen Geräte sich den Qualitätswünschen angepasst haben. Eine Kette ist eben immer nur so stark wie ihr schwächstes Glied.

Wenn eine Anwendung einen Qualitätswunsch an das Netz äußert, wird zunächst mit der Policy Control nachgeprüft, ob ihr das überhaupt zusteht. Als nächstes wird mit der Admission Control geprüft, ob die Reservierung möglich ist. Die Reservierung kann nur dann durchgeführt werden, wenn ein spezieller Datenfluss auch über eine Klassifizierung als Flow verfügt, sonst verstößt man schon gegen die Policy Control.

Die Klassifizierung als Flow kann auf unterschiedliche Arten geschehen, z.B. durch Default, das MPLS-Verfahren (Multiprotocol Label Switching Protocol) oder im Rahmen von Prioritäten nach IEEE 802.1D/p.

weiter mit: Die vier grundsätzlichen Komponentengruppen bei RSVP

Die vier grundsätzlichen Komponentengruppen bei RSVP

Es gibt vier grundsätzliche Komponentengruppen bei RSVP, die die Rolle der jeweiligen Komponenten im Verfahren festlegen: Sender, Empfänger, Hosts und Router. Damit RSVP überhaupt weiß, was zu tun ist, müssen alle in Frage kommenden Anwendungen als Sender registriert werden.

Dabei werden ihre Verkehrscharakteristika, wie z.B. eine gewünschte minimale Bandbreite, Paketgröße, Durchsatz oder eine maximal erträgliche Verzögerungszeit festgehalten. Eine Station mit sendenden Anwendungen schickt dann sog. Path Messages an alle potentiellen Empfänger der Nachrichten der betreffenden Anwendungen. In dieser Path Message stehen insbesondere die Verkehrscharakteristika.

Bei den Empfängern müssen diese Informationen in der Schnittstelle abgelegt werden, die eine Anwendung in den Empfängern später benutzt, um unter Zuhilfenahme einer RSVP-Reservierung mit einer sendenden Anwendung zu kommunizieren. Will ein Empfänger nun mit dem Sender kommunizieren und von ihm einen Datenfluss empfangen, schickt er über die genannte Schnittstelle die entsprechenden Parameter an die nächste lokale RSVP-Instanz.

Dies ist meist ein Prozess in einem Router. Es müssen nicht alle Parameter übergeben werden, der Empfänger kontrolliert die anzustrebende Qualitätsstufe. Die Menge der möglichen Parameter und die Menge der ausgewählten Parameter ergeben die Flussspezifikation.

RSVP beginnt dann mit der Reservierung der Betriebsmittel in den Routern und zwar in Form von Reservierungs-Anfragen, die als IP-Pakete Punkt-zu-Punkt bis zum Sender hin durchgeführt werden, also genau entgegen der Richtung, in der die Sendung später abläuft. Im Verlaufe des Netzes können gleichartige Reservierungen auftreten, die dann entsprechend gesammelt werden.

Router nehmen, wenn sie RSVP-fähig sind, die Reservierungsanfragen entgegen und versuchen, ihre Betriebsmittelzuordnung entsprechend zu modifizieren. Ist dies möglich, so senden sie in die Richtung des Anfragenden eine Bestätigung und leiten die Reservierungs-Anforderung in Richtung des nächsten Routers auf dem Weg weiter.

Integrierte Dienste über LANs nach 802.1 D/p

Die Gruppe 802.1 ist bei IEEE 802 vor allem für Definitionen des unmittelbaren Umfeldes zuständig. Es gibt eine Arbeitsgruppe für die Erarbeitung von Spezifikationen hinsichtlich der Einführung integrierter Dienste: ISSLL (Integrated Services over Specific Link Layer. Die heutigen LLC Typen können Reservierungswünsche, wie sie von RSVP kommen, überhaupt nicht richtig verarbeiten. Das liegt daran, dass diese Anforderung vor ca. 25 Jahren, als die LLCs, wie wir sie heute benutzen, definiert wurden, nicht existiert hat oder in irgendeiner Weise absehbar war.

Die ISSLL-Gruppe geht nunmehr davon aus, dass moderne LANs im wesentlichen aus Switches bestehen und nicht mehr aus Shared Segmenten. Für die Switches nimmt man ein Grundmodell an, in dem vor der eigentlichen Switching Fabrik bzw. Switching Matrix eine Menge von Warteschlangen existiert.

Funktionen für Priorisierung und bestimmte Qualitätsstufen möchte man nun so durchsetzen, dass man ausgehend von der Spezifikation unterschiedlicher Dienstklassen diese auf Funktionen der LLC abbildet, die wiederum hauptsächlich durch Manipulationsfunktionen an den Warteschlangen realisiert werden. So denkt man daran, pro Port zwei Queues mit statischer Priorisierung, oder 2-8 Queues mit statischer Priorisierung oder 8 Queues mit dynamischer Priorisierung oder mehrere Queues mit Flussklassifizierung durch die Layer-3-Header nach unterschiedlichen Policies vorzunehmen.

weiter mit: Warteschlangenhäufung

Warteschlangenhäufung

All das kann man durchaus implementieren, allerdings zeigt sich hier eine schwere konstruktive Schwäche. Bei größeren Switches können die Definitionen zu mehreren Hundert Warteschlangen führen. Diese Schlangen müssen alle verwaltet werden. Die Elemente der Schlangen sind IEEE 802.x-Nachrichten, die zwar eine feste Obergrenze haben, aber ansonsten dynamische Längen aufweisen.

Im Zweifelsfall muss man immer mit der Obergrenze kalkulieren. Die Arbeitsgruppe geht davon aus, dass die Switching Fabric ein Betriebsmittel ist, welches die Warteschlangen in etwa in dem Maße entleert, wie sie sich füllen. Manchmal ist die Switching Fabric jedoch schneller, manchmal langsamer als die Menge der Anforderungen.

Die zusätzliche Belastung der Switches mit der Verwaltung unterschiedlich priorisierter Warteschlangen muss irgendwo geleistet werden. Ein Software-basierter Switch wird dies mit seiner CPU machen müssen. Die Leistung, die die CPU mit dem Verwalten der Schlangen verbrät, fehlt dann beim Switching.

Hardware-basierte Switches mit einer Switching Matrix müssen diese Leistung von dem Prozessor abziehen, der die Sonderfälle verarbeitet, die nicht mit Cut-Trough erledigt werden können, wie fehlerhafte Pakete, zu konvertierende Pakete, Pakete mit unbekannten Adressen usw. Auch dieser wird davon nicht schneller.

Natürlich ist es kein großes Problem, immer mehr Rechenleistung in die Switches zu packen, aber das Einfügen einer Warteschlangenverwaltung macht einen Switch generell tendenziell langsamer, alleine wegen der notwendigen Vorsortieroperationen, die ja völlig unabhängig von der tatsächlichen Auslastung durchgeführt werden müssen.

Man hat sich in Anlehnung an Arbeiten von IETF bislang nur zu zwei Dienstklassen durchringen können: Controlled Load und Guaranteed Service. Controlled Load ist „so gut es geht“ und die untere der zwei Stufen, bei der gegenüber der normalen LLC-Abarbeitung lediglich eine grundsätzliche mittlere Verzögerungszeit angegeben wird.

Guaranteed Service definiert eine obere Grenze für die Verzögerungszeit des Paketes, was sinnvoll sein kann. Beschränkt man sich auf diese zwei Klassen, dann ist der Effekt einfach der, dass im Falle einer recht hohen Auslastung des Switches die Pakete der besseren Dienstklasse bevorzugt behandelt werden.

IEEE 802.1D/p ist allerdings damit nicht zufrieden und definiert acht Dienstklassen, und zwar benutzerorientiert, also von Ende zu Ende. Die Priorisierung ist statisch und kann pro Port gesetzt werden. Bezogen auf die logischen Verbindungen sollte die Priorisierung auf den Zugriff auf das Übertragungsmedium abgebildet werden können.

Die Priorität 1 (BK) ist die schlechteste Stufe und bedeutet Background. Hierhin kann man alle Verkehrswünsche abstufen, die in den höheren Stufen nicht berücksichtigt werden konnten. Die Priorität 2 ist nicht weiter definiert. Die Priorität 0 (BE) liegt logischerweise über 2, bedeutet „Best Effort“ und ist der Default. Nach 0 kommt dann die Stufe 3 EE, „Excellent Effort“, die wiederum etwas besser ist. Die Prioritätsklassen 0 bis 3 dienen dem „normalen“ Verkehr. Die Klasse 4 CL „Controlled Load“ läutet die zeitkritischeren Anforderungen ein, muss aber parametriert werden.

Die Klasse 5 VI ist für Video und lässt Latenz und Jitter von höchstens 100 Millisekunden zu. Die Klasse 6 VO, „Voice“, ist dann noch strenger und beschränkt Latenz und Jitter auf höchstens 10 Millisekunden. Damit kommt man schon auf eine sehr hohe Qualität, allerdings schaffen das nur wenige Switches.

Die Klasse 7 NC, „Network Control“ ist dann für Kontroll-Pakete definiert. Sieht man einmal von einer gewissen Orientierungslosigkeit auf den unteren Prioritätsstufen ab, so ist die Definition durchaus realistisch, wenn man an eine vollständige Integration von Sprache und Bewegtbildern denkt.

So kann man sich letztlich die Nutzung eines so genannten integrierten Dienstes wie folgt vorstellen: eine Endstation mit vollständigem Protokollstack stellt eine Anfrage an die so genannte Admission Control der ISSLL der Schicht 2: Kann ich für Datenverkehr einer bestimmten Charakteristik mit bestimmten Leistungsanforderungen von dieser Quelle zu jenem Ziel eine Reservierung vornehmen und mit welchem Label muss ich dann die Datenpakete versehen? Z.B. Data Link mit 25 Mbit/s und maximalem Delay 5 Sekunden von IP-Adresse zu IP-Adresse oder Video mit 10 Mbit/s und maximalem Delay 100 Millisekunden von IP-Adresse zu Multicast-Teilnehmern usw.

Danach bemüht sich das Netz in verschiedenen Komponenten, dem Wunsch stattzugeben und Betriebsmittel vorauszureservieren. Je nachdem, ob dies gelingt, fällt die Antwort aus.

Fazit

Wie wir gesehen haben, gibt es durchaus Möglichkeiten zur Priorisierung von Datenströmen in einem modernen LAN. Neben den Standards bieten die Hersteller dazu auch noch eigene Verfahren. All dies darf aber nicht darüber hinwegtäuschen, dass man mit einer Priorisierung die zur Verfügung stehende Gesamtleistung lediglich anders verwaltet, aber in keinem Fall erhöht.

Die Warteschlangentheorie zeigt, dass bei einem System zur Priorisierung (in weitem Bereich unabhängig von dessen spezieller Arbeitsweise) die höchste Prioritätsklasse einen Gewinn gegenüber einem ungeregelten Verkehr hat, die zweite und dritte ungefähr so bedient werden wie im ungeregelten Fall, alle anderen Klassen aber gegenüber einer ungeregelten Lösung fürchterlich untergebuttert werden.

Hersteller ziehen die Priorisierung immer dann aus dem Hut, wenn sie an einen Leistungsengpass geraten, den sie anders nicht abstellen können. Das ist dann aber meistens mehr ein Hilferuf und keine Lösung. Es gibt dafür immer wieder Beispiele.

Letztlich kann man sagen: auf die Dauer hilft nur Power!