Von: Kai-Oliver Detken, Bernd Reder
Jahrelang wurden die Begriffe "Asynchroner Transfermodus" (ATM) und "Quality of Service" (QoS) quasi synonym verwendet. Es kam die These auf, eine "echte" Dienstgüte sei nur in ATM-Netzen möglich. Quality of Service à la ATM ist verbindungsorientiert und legt für einzelne Datenflüsse die Verkehrs- und QoS-Parameter fest. Ein Vorteil von ATM ist, dass mit dem "Private Network to Network Interface" (P-NNI) ein intelligentes Routing-Protokoll implementiert ist, das QoS mit einbezieht - im Gegensatz zur IP-Welt mit Verfahren wie "Open Shortest Path First" (OSPF). Allerdings ist das Routing bei ATM kompliziert, weil mehrere Parameter gleichzeitig zu berücksichtigen sind.
Ein relativ neuer ATM-Dienst ist die "Guaranteed Frame Rate" (GFR), die in der Spezifikation Traffic Management 4.1 enthalten ist. Sie lässt die Übertragung von Paketen zu, in die Zellen "eingepackt" sind. Allerdings wird GFR keine große Bedeutung beigemessen, weil viele Hersteller von Netzwerksystemen inzwischen Switching auf Grundlage von Frames und nicht von Zellen verwenden. Moderne ATM-Switches unterstützen heute bis auf GFR alle Dienstkategorien.
Dienstgüte bei ATM ist einekomplizierte Angelegenheit
In der Praxis hat sich ATM-QoS als kompliziert und unflexibel erwiesen. So ist es aufwändig, die Parameter zu bestimmen und deren Einhaltung zu überwachen. Hinzu kommen Probleme mit der Skalierung, vor allem dann, wenn Ressourcen für einzelne Sitzungen reserviert werden sollen. Außerdem arbeitet ATM mit Zellen, die aber meist mit Hilfe des "ATM Adaptation Layer 5" (AAL-5) transportiert werden, das heißt letztlich doch als Pakete.
Ein Vorteil ist dagegen, dass sich eine präzise Garantiezusage treffen lässt. Außerdem steht einheitliches und durchgängiges QoS-Konzept im LAN und im Weitverkehrsnetz bereit, und zwar mit Bandbreiten von 2 bis 2400 MBit/s. Allerdings sind nur wenige ATM-Endgeräte verfügbar, die QoS-Merkmale nutzen, beispielsweise Video-Codecs und Systeme für die Kopplung von Telekommunikations-Anlagen. Auch Anwendungen sind Mangelware, obwohl ATM-Erweiterungen für Programmierschnittstellen vorhanden sind, darunter Unix-XTI oder Microsofts Winsock 2, zudem eine Implementierung von Fore/Marconi.
Ein Grund für diese Entwicklung ist sicherlich der Siegeszug des Internet Protocol. Mittlerweile werden überwiegend IP-Daten über ATM-Netze übertragen. Die Internet Engineering Task Force (IETF) hat zudem mit Integrated Services (Intserv) und Differentiated Services (Diffserv) zwei Verfahren entwickelt, die Dienstgüte in IP-Netzen garantieren sollen. In den Integrated Services findet das "Resource Reservation Protocol" (RSVP) (Intserv) Verwendung, das auch in ATM-Netzen eingesetzt werden kann.
Problematisch dabei ist, dass vor allem in heterogenen Netzen ein Mapping von Protokollen auf verschiedenen Ebenen erforderlich ist. Zudem unterscheidet sich Diffserv stark von ATM-QoS. Das hat dazu beigetragen, dass in der Praxis ATM-Quality-of-Service kaum zum Zuge kommt. Es gibt einige proprietäre Lösungen, beispielsweise von Lucent Technologies, Siemens, Cisco Systems und Nortel Networks. Die Universallösung, als die sie von der Fachwelt gefeiert wurde, ist ATM-QoS jedoch mit Sicherheit nicht.
Keine QoS durch Bandbreite im Überfluss
Ursprünglich sollten auch in lokalen Netzen Echtzeitdienste mit Hilfe von ATM realisiert werden. Davon ist heute keine Rede mehr: Im LAN hat sich Ethernet durchgesetzt, mit Datenraten bis 1 GBit/s und in Verbindung mit Switching. Das führt häufig zu dem Trugschluss, dass keine QoS-Mechanismen mehr notwendig sind, weil ja genügend Bandbreite zur Verfügung steht. Dabei wird übersehen, dass Störfaktoren wie Verzögerungen, Jitter und Paketverluste auch dann auftreten, wenn Überkapazitäten im Netz vorhanden sind.
Aus diesem Grund wurden mehrere Verfahren entwickelt, die Quality of Service und damit Echtzeitdienste in IP-Netzen ermöglichen. (siehe "QoS-Ansätze in IP-Netzen"). So spezifizierte die IETF ein Protokoll zur "Admission Control" auf Grundlage von RSVP, damit sich in Layer-2-LANs Ressourcen zuteilen lassen. Es geht davon aus, dass LAN-Hosts oder Layer-3-Router der Anfangs- und Endpunkt von Datenströmen sind. Damit muss der Protokoll-Stack in den Layer-3-Systemen nur minimal angepasst werden. Spezielle Agenten, die "Subnet Bandwidth Manager" (SBM), übernehmen das Management der Layer-2-Geräte.
RSVP hat jedoch einen gravierenden Nachteil: die schlechte Skalierbarkeit. Denn je mehr Datenflüsse vorhanden sind, desto mehr Informationen müssen die Systeme im Netz untereinander austauschen, um eine bestimmte Bandbreite zu reservieren. Einen Ausweg bieten "aggregierte" Datenströme. Das heißt, Sitzungen mit vergleichbaren Anforderungen werden zusammengefasst, und diesem "Bündel" weist RSVP dann zentral die notwendigen Ressourcen zu.
Mit dem richtigen Etikett schneller durchs Netz
Vorteile in Bezug auf die Skalierbarkeit weist der Ansatz Diffserv auf. Er definiert unterschiedliche Servicelevels: Expedited Forwarding (EF), Default Forwarding (DF) und Assured Forwarding (AF). Die AF werden wiederum in vier Klassen unterteilt, wobei innerhalb der Klassen eine weitere Unterteilung stattfinden kann. Diffserv verwendet nicht das Type-of-Service-Feld eines IP-Paketes, das nur 3 Bit groß ist, sondern das "Differentiated-Service-Code-Point"-Feld mit 6 Bit. Statt 8 sind daher 64 Klassen möglich
Ein weiterer Ansatz, um QoS in IP-Netze einzuführen, ist Multi-Protocol Label Switching. MPLS ist ein Forwarding-Schema, das gut mit ATM zusammenarbeiten könnte, um IP eine garantierte Dienstgüte zu ermöglichen. Jedes MPLS-Paket enthält ein "Etikett" (Label) mit Informationen über dessen Priorität. Das Verfahren sucht für jedes "Datenhäppchen" den kürzesten Weg durch ein Router-Netz. Dazu untersucht jeder Router den Kopf eines Paketes und leitet es an seinen nächstgelegenen Kollegen weiter. Auf diese Weise lässt sich eine schnelle durchgängige Verbindung herstellen.
Subnet Bandwidth Management (SBM) ist ein Draft der IETF. Er definiert, wie künftig ein Mapping zwischen Layer 2, 3 und 4 in Bezug auf QoS durchgeführt werden kann. SBM enthält einen "Bandwidth Allocator" (BA) mit Bandbreitenmanagement, Admission Control und anderen Policy-Kriterien. Hinzu kommt ein "Requester Module" (RM), das in jedem Endgerät installiert ist und das Mapping zwischen den Schichten vornimmt.
Neben den diversen Priorisierungsverfahren und QoS-Ansätzen sind die Warteschlangen-Mechanismen ausschlaggebend für die faire Behandlung unterschiedlicher Datenströme. Auch hier gibt es mehrere Ansätze, die unterschiedliche Techniken verwenden.
- Priority Queuing (PQ),
- Custom Queuing (CQ),
- Weighted Fair Queuing (WFQ) und
- Weighted Random Early Detection (WRED).
PQ arbeitet zuerst die Warteschlange mit der höchsten Priorität ab, während CQ auf das Round-Robin-Verfahren zurückgreift. WFQ versucht dagegen, je nach Applikation die IP-Pakete möglichst "gerecht" zu behandeln, während WRED weniger wichtige Pakete bei Überlast einfach löscht.
Ohne Policies keine Multiservice-Netze
Quality of Service nutzt wenig, wenn keine Regeln vorhanden sind, die festlegen, welche Applikationen überhaupt eine bestimmte Dienstgüte benötigen. Die IETF hat deshalb ein Rahmenwerk für solche Policies entworfen. Als "Policy Repository" favorisiert das Gremium das "Lightweigth Directory Access Protocol". LDAP eignet sich aber nur bedingt dafür, weil es keine Benachrichtigung bei Änderungen vorsieht. Außerdem wurde LDAP dafür konzipiert, statische Daten zu verteilen, nicht aber dynamische.
Unklar ist zudem, wie mit unterschiedlichen Versionen derselben Datenbestände verfahren werden soll. Daher gibt es derzeit mehrere LDAP-Implementierungen, die nicht interoperabel sind. Und daran dürfte sich auch mittelfristig nichts ändern. Umstritten ist zudem, welche Kriterien eine "Policy Control" erfüllen muss. Die Fachleute diskutieren gegenwärtig drei "inkompatible" Ansätze:
- Die Anwendungen vergeben Prioritäten und Berechtigungen: Dabei legt eine Applikation gemäß IEEE 802.1d die Priorität fest. Solche Lösungen bietet beispielsweise 3Com an. Die Konfiguration wird in den Endgeräten gegen Manipulation gesichert, etwa mit Hilfe eines Schreibschutzes der Konfigurationsdateien. Im LAN selbst erfolgt keine Kontrolle der Policies. Dieses Modell scheint weder flexibel noch sicher gegen Missbrauch zu sein.
- Anhand von Policy-Kriterien werden IP-Adressen und Port-Nummern vergeben: Dieses Prinzip favorisiert Cisco. Dazu ist es notwendig, Listen zugelassener IP-Adressen und Port-Nummern mit entsprechenden Berechtigungen in Routern und Switches vorzuhalten. Die Policies lassen sich dann in jedem Netzknoten überprüfen. Außerdem sind die Netzknoten nur für Systemadministratoren zugänglich. Somit bietet dieser Ansatz einen höheren Grad an Flexibilität und vor allem mehr Sicherheit als das Policy-Control-Modell von 3Com. Probleme bereiten Teilnehmer, die dynamische IP-Adressen besitzen sowie Anwendungen, die transiente Ports benutzen. Vor allem Echtzeit-Video-Anwendungen nutzen oft transiente UDP-Ports. An dieser Stelle versagt auch dieses Modell.
- Policy-Server werden in jeder Domäne installiert: Die Policy-Server enthalten personenbezogene Informationen und authentifizieren die Teilnehmer einer Domäne. Die Lösung ist im Vergleich zu den beiden anderen Ansätzen sehr aufwändig, bietet aber die größte Flexibilität und einen höheren Sicherheitsgrad. Sie wird von Microsoft unterstützt.
Dienstgüte ist immer noch ein Mythos
Zusammenfassend lässt sich festhalten, dass es erhebliche Schwierigkeiten dabei gibt, Quality of Service in der Praxis umzusetzen. Schuld daran sind die Komplexität des Ansatzes, die schlechten Gesamtkonzepte und fehlende Standards. Hinzu kommt, dass die Hersteller unterschiedliche Konzepte vertreten. Alles zusammen hat dazu geführt, dass die Anwender verunsichert sind.
Es gibt keinen Königsweg, der aus diesem Dilemma führt. Die Situation lässt sich aber zumindest verbessern, wenn folgende Punkte berücksichtigt werden:
- Alle Verfahren liegen zumindest als Rahmenwerk vor. Keines wurde aber bislang in der Praxis erprobt oder in größerem Maßstab eingesetzt. Es ist deshalb notwendig, Testnetze aufzubauen und Messungen vorzunehmen. Nur auf diese Weise lässt sich ein Fein-Tuning durchführen, und zwar in Bezug auf die RSVP-Anforderungen als auch auf die Größe und Gewichtung der Warteschlangen in den Netzknoten. Außerdem fehlen Erfahrungswerte darüber, wie sich einzelne Parameter beim Mappen der QoS-Anforderungen auf die Link-Layer-Schicht auswirken.
- Die Schnittstelle zum RSVP-Prozess und zur Traffic-Control-Einheit in den Endgeräten sollte verbessert und vereinfacht werden. Nur dann haben Programmierer die Möglichkeit, Anwendungen mit einem vertretbaren Aufwand so "umzustricken", dass sie dem Netz ihre Anforderungen in puncto Dienstgüte mitteilen können.
- Die Authentifizierungsverfahren müssen weiterentwickelt und getestet werden.
Diese Aufgaben sollten Industrie und Normierungsgremien nicht auf die lange Bank schieben. Denn eines steht fest: Ohne QoS-Mechanismen bleiben Echtzeitapplikationen und die Konvergenz von Sprache und Daten in paketgestützten Netzen eine Utopie. (re)
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.