Vergleichstest Core- und Edge-Switches:
Warum Quality-of-Service heute wichtig ist

von Werner Veith (werner.veith@networkcomputing.de), Prof. Dr. Bernhard G. Stütz

Share
03.04.2009

Mit Voice- und Video-over-IP kommen Echtzeitdienste in die Unternehmen, die auf Störrungen empfindlich reagieren. Mit Quality-of-Service oder besser Class-of-Service sollen Netzwerkomponenten deren Übertragung sichern.

Moderne Kommunikationsnetze stellen aktive Komponenten vor immer anspruchsvollere Aufgaben. Mit dem Siegeszug der IP-Telefonie kommen Echtzeitanforderungen auf die Ethernet- beziehungsweise IP-Unternehmensnetze zu. Und auch die Integration von Video-over-IP, beispielsweise für Konferenzsysteme, steht in vielen Bereichen schon im Pflichtenheft. Dann sind da noch die klassischen Datenapplikationen. Sie stellen ebenfalls immer größere Ansprüche an das Netzwerk.

Die verschiedenen Störfaktoren im LAN

Um diesen Herausforderungen zu begegnen, haben die Switch-Hersteller ihre Systeme weiter entwickelt. Mit der Einführung von 10-Gigabit-Ethernet ist das Ganze nochmals um den Faktor 10 schneller geworden. Mechanismen wie die Datenpriorisierung und das Bandbreitenmanagement sollen dafür sorgen, dass die im Netz zur Verfügung gestellten Ressourcen im gesamten Unternehmensnetz intelligent ausgenutzt werden.

Das LAN stellt sich auch mal quer

Die Übertragung von einem Endpunkt im Netzwerk zum anderen erfordert eine gewisse Laufzeit. Dabei gibt es zunächst einen festen Teil. Dieser lässt durch die Auswahl der Codecs, also der Sprach-Digitalisierungs-Algorithmen, und der Netzwerkkomponenten beeinflussen und ziemlich gut berechnen. Der feste Anteil ergibt sich durch die Zeit, die die Kodierungsalgorithmen an beiden Endpunkten benötigen. Hinzu kommt die Hardware-Durchlaufzeit auf den beteiligten End- und Knotenpunkten. Als drittes ist da noch die Zeit, die die Pakete bei der Übertragung über die verschiedenen Medien über die verschiedenen Strecken im Netz brauchen.

Zusätzlich entstehen Verzögerungen beispielsweise durch volle Warteschlangen bei Überlast oder durch die Wahl alternativer Routen zum Zielpunkt. Die beiden letzteren Punkte können auch die Ursache für zwei andere Übertragungsfehler sein: Sequence-Error und Jitter. Beim so genannten Jitter treffen Pakete, die in regelmäßigen Intervallen in das Netz geschickt werden, in unregelmäßigen Abständen beim Empfänger ein.

Analysen der Verteilung der Framegrößen haben beispielsweise für das MCI-Backbone oder Business-DSL-Links ergeben, dass rund 50 Prozent aller Datenrahmen in realen Netzwerken 64 Byte groß sind.

Ist bei isochromem Datenverkehr wie der IP-Sprachübertragung ein Paket zu schnell am Ziel, kann es für die Ausgabe noch nicht verwendet werden. Kommt es dagegen später an als erwartet, können Lücken in der Sprachwiedergabe entstehen. Diesem Jitter wirkt der Einsatz eines Buffers entgegen, der Pakete aus dem Netz entgegen nimmt. Diese gibt er dann gleichmäßig an die Dekodiereinheit weiter, was aber zu einer Verzögerung führt.

Treffen die Pakete beim Empfänger in einer anderen Reihenfolge ein, als vom Sender beabsichtigt, ist dies ein Sequence-Error. Die häufigste Ursache hierfür ist, dass einige zu einer Übertragung gehörende Pakete auf Grund einer Überlast über einen anderen Netzwerkpfad übertragen werden (Re-Routing). So erreichen sie ihr Ziel auf einem anderen, möglicherweise langsameren Weg.

Wie gut sich solche Fehler in der Paket-Reihenfolge ausgleichen lassen, hängt in erster Linie von der Länge des Jitter-Buffers ab. Es gehen bei der Übertragung auch Pakete ganz verloren (Packet-Loss). Die Auswirkungen sind dann umso größer, je höher die Anzahl der Sprachdaten-Bytes in dem verlorenen Paket war und je stärker der Codec komprimiert hat.

Gehen mehrere aufeinander folgende Pakete verloren (Consecutive-Packet-Loss), sind die Auswirkungen auf die Sprachqualität deutlich stärker, als wenn die Verluste gleichmäßig streuen. Dieses tritt überwiegend in Burst-Situationen auf. Die Ursache für Paketverlust liegt häufig darin, dass auf dem Übertragungsweg Bandbreitenengpässe auftreten.

Durch länger dauernde Bursts laufen dann Warteschlangen über. Deshalb werden Pakete verworfen. Oder die Pakete in den Warteschlangen erfahren eine so große Verzögerung, dass sie sich nicht mehr sinnvoll über den Jitter-Buffer versenden lassen. Ist der Jitter-Buffer sehr groß, führt dies selbst zu einer zu großen Verzögerung. Jitter-Buffer verringern also Probleme, die durch Jitter und Sequenz-Error entstehen können, erzeugen aber ihrerseits zusätzliche Delay-Zeiten. Gute Endgeräte verwalten den Jitter-Buffer daher dynamisch.

Bei entsprechender Überlast im Netz sind Datenverluste ganz normal. Diese sollten sich durch Priorisierungsmechanismen in der Regel auf nicht echtzeitfähige Applikationen verlagern. Arbeitet die Priorisierung nicht wie vorgesehen, kommt es auch bei den bevorzugten Sprachdaten zu Verlusten. Für eine realitätsnahe Auswertung der Messergebnisse ist es zudem entscheidend zu wissen, welche Framegrößen in welcher Verteilung in realen Netzwerken vorkommen.

Es gibt Analysen der Verteilung der Framegrößen beispielsweise für das NCI-Backbone oder Business-DSL-Links. Diese haben ergeben, dass rund 50 Prozent aller Datenrahmen in realen Netzwerken 64 Byte groß sind. Die übrigen rund 50 Prozent der zu transportierenden Datenrahmen streuen über alle Rahmengrößen von 128 bis 1518 Byte.

Für Echtzeit-Anwendungen wie die Voice- oder Video-Übertragung entscheidet zuerst der Datenverlust über die Qualität der Verbindung. Ab fünf Prozent Verlust ist je nach Codec mit deutlicher Verschlechterung der Übertragungsqualität zu rechnen. Zehn Prozent führen zu einer massiven Beeinträchtigung. Ab 20 Prozent ist beispielsweise die Telefonie definitiv nicht mehr möglich.

So verringert sich der R-Wert für die Sprachqualität gemäß E-Modell nach ITU G.107 schon bei zehn Prozent Datenverlust um je nach Codec 25 bis weit über 40 Punkte. Diese Werte machen massive Probleme im Telefoniebereich sehr wahrscheinlich. Auf Grund ihrer Bedeutung für die Übertragungsqualität hat Network Computing daher das Datenrahmenverlustverhalten als primäres K.O.-Kriterium für seine Tests definiert.

Die Parameter Verzögerung (Latency) und Jitter sind dann für die genauere Diagnose und weitere Analyse im Einzelfall wichtig. Sie misst Network Computing ebenfalls standardmäßig. Sind jedoch schon die Datenverlustraten zu hoch, retten gute Werte für Verzögerung und Jitter die Echtzeitübertragungsqualität auch nicht mehr. Damit es zu solchen massiven Datenverlusten im Ethernet-LAN erst gar nicht kommt, sollten entsprechende Priorisierungsmechanismen gut funktionieren. Sie tun dies aber durchaus nicht immer, wie die Erfahrung aus vorhergehenden Tests gezeigt hat.

Die Qual der Wahl bei der Qualitätssicherung

Das Ethernet-Protokoll erlaubt es nicht, Quality-of-Service (QoS), wie es etwa ATM kennt, zu definieren. Stattdessen gibt es hier Class-of-Service oder CoS. Allgemein lassen sich zwei Wege unterscheiden, Service-Qualität zu realisieren. Zum einen werden dazu Netzwerk-Ressourcen reserviert. Zum anderen leitet das Netzwerk bestimmte Pakete bevorzugt weiter (Priorisierung). Grundlage dafür ist die Priorität, die ein Netzwerkpaket besitzt. Basis dafür sind die Informationen aus den Headern der Ebenen 2, 3 oder 4.

So ist es möglich, den Verkehr beispielsweise hinsichtlich der Quell- und Zieladressen (MAC oder IP) oder der Protokoll- und Portnummern einzuteilen. Dies hängt natürlich davon ab, bis in welche Ebene das Netzwerkgerät die Protokoll-Header analysieren kann. Außerdem lassen sich in den Protokoll-Headern der verschiedenen Ebenen für eine Prioritätsstufe bestimmte Bits gezielt einstellen. Die Hierarchie der Prioritätsentscheidungen auf den verschiedenen Ebenen, die ja durchaus widersprüchlich sein kann, hat jeder Switch intern gelistet. Sie lassen sich entweder frei konfigurieren oder sind fest vorgegeben.

Zu beachten ist auch, dass Layer-2-Priorisierungen auf dem Weg durch ein LAN in der Regel verloren gehen, sobald auf Layer-3 ein Switching beziehungsweise Routing erfolgt. Die Konfiguration des aktiven Netzwerks, das intelligent die Priorisierungsmechanismen nutzen soll, ist daher gerade in heterogenen Bereichen nicht gerade trivial. Häufig empfiehlt es sich für ITK-Verantwortliche, dass er sich schon aus Gründen einer vollständigen Kompatibilität für ein Netzwerk aus einer Hand entscheidet. Bei größeren Netzen ist auch eine entsprechende CoS-Management-Software unerlässlich, um die zur Verfügung stehenden Priorisierungsmechanismen auch wirklich effizient nutzen zu können.

Netzwerk-Ebene 3 für QoS nutzen

Eine Möglichkeit der Zuordnung eines IP-Pakets ist die Nutzung des Type-of-Service-Bytes (ToS) im IPv4-Header. Dabei gibt es sind zwei Varianten. RFC 791 definiert mit den Bits 0 bis 2 acht Klassen, von »Routine« über »Immediate« bis zu »Network-Control«. Pakete mit einem höheren Octal-Wert in diesem 3-Bit-Feld werden vorrangig behandelt (IP-Precedence). Variante 2 verwendet die Bits 3 bis 6, um eine normale und vier besondere Service-Klassen zu kennzeichnen. Dies steht im RFC 1349.

Ungünstigerweise wird dieses vier Bit große Teilfeld des ToS-Byte ebenfalls als Type-of-Service bezeichnet. Es gibt also im IP-Header ein ToS-Byte und darin enthalten ist ein ToS-Feld. Pakete lassen sich anhand des ToS-Felds entsprechend der eingestellten Klasse Warteschlangen unterschiedlicher Priorität zuordnen. Im IPv6-Header ist ebenfalls ein Byte für eine Klasseneinteilung vorgesehen. Es wird treffend als »Class« bezeichnet und könnte ähnlich verwendet werden.

Eine Arbeitsgruppe der IETF stellte schon 1997 eine weitere Implementierung des ToS-Byte vor: Differentiated-Services (Diffserv). Es dient dazu, Pakete zu markieren. Ein Netzwerkknoten leitet dann das Paket entsprechend dem Eintrag an den nächsten weiter (Per-Hop-Behavior). Dazu erhält dieses Byte im IP-Header per Definition eine neue Bedeutung und wird in diesem Anwendungsfall dann als Differentiated-Service-Byte (DS-Byte) bezeichnet.

Die Diffserv-Spezifikation nach RFC 1349 legt sechs Bits fest, die dazu dienen, den Differentiated-Services-Code-Point festzulegen. Diese sechs Bits definieren verschiedene Service-Klassen zu. Jede Netzwerkkomponente entscheidet anhand dieser Bits, wie sie die entsprechenden Pakete behandelt, und steuert das Per-Hop-Behavior.

Die sechs Bits sind nochmals in zwei mal drei Bits unterteilt. Diese Struktur ist im RFC 1349 festgeschrieben. Letztlich ist es den Herstellern beziehungsweise den Netzwerkadministratoren freigestellt, wie sie diese Bits genau nutzen. Eine sinnvolle Diffserv-Anwendung ist daher nur möglich, wenn ein Managementsystem die notwendigen Service-Klassen-Zuordnungen durchgängig steuert.

Die vorhandenen Hardware-Queues beziehungsweise auf die zur Verfügung stehenden Links müssen die insgesamt 64 Codierungs-Möglichkeiten abbilden. Diese Mechanismen sollten in einer Domäne konsistent arbeiten und zwischen verschiedenen Domänen durch Mapping gesichert werden.

Die Gateways und Knotenpunkten ordnen anhand der CoS-Einstellungen in den Headern die Pakete den Warteschlangen (Queues) zu. Dort werden die Pakete entsprechend den Queuing-Mechanismen weitergeleitet. Hier gibt es verschiedene Ansätze. In vielen Fällen sollte eine Priorisierung aber nicht ohne eine Festlegung einer gewissen Bandbreite erfolgen.

Diese könnte so aussehen, dass die Queue mit der höchsten Priorität nur eine bestimmte maximale Bandbreite erhält. Sonst kann es passieren, dass bei einer Überlast ausschließlich hoch eingestufte Pakete transportiert werden. In den unteren Queues stauen sich dann die Pakete, bis sie verworfen werden. Das Festlegen einer minimalen Bandbreite für Pakete niedrigerer Priorität erfüllt denselben Zweck. Moderne Switches verschieben diese Grenzen dynamisch, abhängig vom momentanen Verkehr.

Allerdings können auch Pakete mit einer höheren Priorität verfallen. Das passiert, wenn die Bandbreite vollständig genutzt wird, und auch die Puffer die höheren Prioritäten überlaufen. Hierin liegt ein grundsätzlicher Nachteil der Ethernet-Technologie. Obwohl eigentlich alle aktuellen Netzwerkgeräte das ToS- beziehungsweise DS-Byte auswerten können, ist diese Funktion in den seltensten Fällen aktiviert. Sie wird höchstens im In-House-Bereich oder anderen abgegrenzten und kontrollierbaren Umgebungen genutzt.

Klassifizierung über Port-Nummern als Ausweg

Die meisten Applikationen sowie Windows-Betriebssysteme beherrschen die Klassifizierung mit ToS und Diffserv nicht. Deshalb ist eine erste Klassifizierung nach Diensten im Edge-Bereich über die benutzten TCP- oder UDP-Port-Nummern sinnvoller. Hierbei weist der Edge-Switch anhand der erfolgten Klassifizierung den Paketen die entsprechende Hardware-Queue zu.

Optional lassen sich die Klassifizierungen dann auch auf ToS- beziehungsweise Diffserv-Werte mappen. Dabei werden die schon vorhandenen Werte überschrieben. Diese ToS- und Diffserv-Werte können dann die Core-Switches weiter verwenden. Sie müssen dabei kein weiteres Mapping durchführen. Im aktuellen Vergleichstest erfolgte die Festlegung der Priorität nach den jeweiligen UDP-Portnummern. Die Klassifizierung der einzelnen Datenströme führte der jeweiligen Switch durch, der die Datenströme empfing.
Verwandte Artikel