Strukturprotokolle der Datenkommunikation – Quality of Service

Integrierte Dienste über LANs nach 802.1D/p

Die Gruppe 802.1 ist bei IEEE 802 vor allem für Definitionen des unmittelbaren Umfeldes zuständig. Sie hat sich in der Vergangenheit nicht so oft durchsetzen können, so wurde z.B. ein schöner Ansatz zum Netzwerk-Management nie wirklich von den Herstellern so realisiert wie vorgesehen.

Es gibt eine Arbeitsgruppe für die Erarbeitung von Spezifikationen hinsichtlich der Einführung integrierter Dienste vermöge einer Erweiterung der LLC-Funktionalität: 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 einfach daran, dass diese Anforderung vor ca. 25 Jahren, als die heutigen LLCs 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 gibt es die Alternativen, 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.

Konstruktive Probleme

All das kann man durchaus implementieren, allerdings zeigt sich hier ein schweres konstruktives Problem. 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. Man geht davon aus, dass die Switching Fabrik ein Betriebsmittel ist, welches die Warteschlangen in etwa in dem Maße entleert, wie sie sich füllen. Manchmal ist die Switching Fabrik aber schneller und manchmal langsamer als die Menge der Anforderungen.

Die Annahme von IEEE führt den Anwender auf sehr dünnes Eis. Um es einfach zu formulieren: wenn die Auslastung eines Switches so hoch ist, dass die Priorisierungsverfahren wirklich funktionieren und für die Priorisierten einen Vorteil bringen, dann ist die Switching Fabrik am äußersten Ende ihrer Leistungsfähigkeit angelangt und jede weitere Steigerung des Gesamt-Verkehrsaufkommens führt in die Phase, wo der Switch Pakete verwerfen muss, anstatt sie weiterzuleiten.

Die zusätzliche Belastung der Switches mit der Verwaltung unterschiedlich priorisierter Warteschlangen muss ja 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 Switchen. 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 die zusätzliche Einfügung von 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.

IEEE 802.1D/p 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. IEEE 802.1 D/p orientiert sich hierbei letztlich an dem Modell, wie es für Breitband-ISDN mit der ATM-AAL entwickelt wurde.

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 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 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.

Mit IEEE 802.1D/p und RSVP werden dem Nutzer Elemente an die Hand gegeben, auch herstellerübergreifende Lösungen zu finden.

Nach wie vor bleibt jedoch das Argument bestehen, dass man besser einfach an der Leistungsschraube dreht anstatt mit komplizierten Mechanismen zu arbeiten. Das ist es auch, was die Betreiber letztlich wollen, denn jedes dieser Zusatzverfahren sorgt für zusätzliche Arbeit bei Einrichtung und laufendem Betrieb.