Von: Petra Carle
Seit langem arbeitet die Internet Engineering Task Force an Mechanismen, mit denen sich Daten übertragen lassen, die spezielle Forderungen an die Dienstgüte (Quality of Service) stellen. Diese Anforderungen beziehen sich auf die Datenübermittlung in Echtzeit, Bandbreitengarantien sowie Paketverlustraten. Einzelne Aspekte wurden auf dem 48. Treffen der IETF in den Arbeitsgruppen "Differentiated Services" (Diffserv) und "Performance Implications of Link Characteristics" (PILC) behandelt. Weitere Diskussionen finden über die Mailing-Listen der Gruppen "Integrated Services" (Intserv), "Integrated Services over Specific Link Layers" (ISSLL) und "Resource Reservation Setup Protocol" (RSVP) statt, die dieses Mal in Pittsburgh nicht vertreten waren. Metriken zur Überprüfung der IP-Dienstgüte definiert die Arbeitsgruppe "IP Performance Metrics" (IPPM).
Ein Weg, um eine bestimmte Dienstqualität sicherzustellen, besteht darin, jede Netzkomponente mit genügend Ressourcen auszustatten. Gleichzeitig muss sich in das Verkehrsprofil jedes Nutzers eine "Bremse" einbauen lassen (Policing). Sie verhindert, dass ein Anwender einen zu großen Teil der Ressourcen für sich alleine beansprucht. Dann können Netzdienste mit vorhersagbarer und fest definierter Qualität zur Verfügung gestellt werden.
QoS-Unterstützung durch Intserv
Das "Integrated Services"-Modell (Intserv), beschrieben in RFC 1633 (Integrated Services in the Internet Architecture), erlaubt es, Dienstgüte für Anwendungen mit besonderen Anforderungen an Bandbreite, Verzögerungszeiten (Delay) und Jitter bereitzustellen. Im Mittelpunkt steht dabei das Signalisierungsprotokoll "Resource Reservation Protocol" (RSVP). Es erlaubt eine empfängerbasierte Reservierung, indem in bestimmten Zeitabständen RSVP-Nachrichten ausgesandt werden. Jeder Netzwerkknoten muss Informationen zu den IP-Datenströmen (IP-Flows), die ihn durchlaufen, verarbeiten und speichern.
Dieses explizite Reservieren von Ressourcen wird bereits erfolgreich in Firmen- und Zugangsnetzen eingesetzt, um QoS bereitzustellen. Im Backbone-Bereich ergeben sich allerdings Probleme mit der Skalierbarkeit, weil dort Netzknoten unter Umständen von sehr vielen Flows durchlaufen werden. Daher befassen sich die aktuellen Arbeiten zu Intserv mit Techniken, die RSVP besser skalierbar machen sollen. Außerdem wurde eine Methode vorgestellt, die das Datenvolumen verringert. Das Verfahren nutzt dazu die Ähnlichkeit der periodisch verschickten RSVP-Nachrichten. Ein weiterer Ansatz reduziert den Overhead bei der Verarbeitung von RSVP-Refresh-Nachrichten.
Parallel dazu sind Techniken in der Diskussion, mit denen sich eine hierarchische RSVP-Struktur aufbauen lässt. Ein Vorteil dieses Ansatzes: die bessere Skalierbarkeit von Routern mit vielen Intserv-Flows. Um RSVP auch dann einsetzen zu können, wenn Intserv nur auf einem Teil des Übertragungsweges zur Verfügung steht, wurde die Idee von RSVP-Proxies geboren. Sie sind in der Lage, vom Sender stammende RSVP-Nachrichten anstelle des Empfängers zu beantworten.
Bisher wurden bei Intserv und RSVP folgende Dienstklassen unterstützt:
- beim "Guaranteed Service" werden Garantien für Bandbreite, Verlust, Maximalverzögerung und Jitter gegeben,
- beim "Controlled Load Service" Zusagen bezüglich Bandbreite und Verlust.
In beiden Fällen muss die Anwendung exakte Obergrenzen für das Verkehrsprofil des IP-Flows angeben, damit in den Routern die erforderlichen Ressourcen reserviert werden können. Für Fälle, in denen das nicht möglich ist, wurde jetzt eine dritte Dienstklasse spezifiziert - der "Null Service". Hier äußert eine Anwendung lediglich den Wunsch, dass der von ihr erzeugte IP-Flow bevorzugt behandelt werden sollte, ohne ein Verkehrsprofil anzugeben. Das Netz stellt anschließend für die betreffenden Flows Ressourcen bereit, wobei es die Policies berücksichtigt. Normalerweise können die Anforderungen der Anwendungen dann auch erfüllt werden.
Diffserv: Differenzierte Dienstqualität
Die Arbeitsgruppe Differentiated Services (Diffserv) beschäftigt sich mit einer Architektur (RFC 2475), die Dienstqualität unterstützt, aber die bei RSVP möglichen Skalierungsprobleme vermeidet. Im Unterschied zu Intserv werden nicht die einzelnen IP-Flows berücksichtigt, sondern Verkehrsflüsse mit ähnlichen QoS-Anforderungen zu einem "Behavior Aggregate" (BA) zusammengefasst. Das "Diffserv-Code-Point"-Oktett im IP-Header (RFC 2474) zeigt an, wie mit einem bestimmten IP-Paket verfahren werden soll.
Gegenwärtig existieren zwei Lösungen in Bezug auf "Per Hop Behaviours (PHBs): das "Expedited Forwarding PHB" (EF) gemäß RFC 2598 und das Assured Forwarding (AF), das in RFC 2597 beschrieben ist. Die qualitativ beste Behandlungsart ist das "Expedited Forwarding". Mit EF lässt sich ein bevorzugter Dienst realisieren, bei dem - wie bei einer Standleitung - Garantien hinsichtlich Bandbreite, Paketverlustraten, maximaler Verzögerung und Jitter möglich sind. Auf dem IETF-Meeting wurde gefordert, diesen RFC zu überarbeiten. Der Grund: In der vorliegenden Form ist EF weder direkt implementierbar, noch lassen sich Konformitätstests durchführen.
Das Assured Forwarding (AF) laut RFC 2597 ist ein Verfahren, das eine bevorzugte Behandlung ohne "harte" Garantien wie bei EF sicherstellt. Bisher wurden vier AF-Klassen spezifiziert, die sich in Bezug auf die Verzögerungscharakteristik unterscheiden. Außerdem stellt jede Klasse zusätzlich drei Verlustkategorien zur Verfügung. So ist es möglich, den Anwendungen eine differenzierte Qualität anzubieten.
Beide Behandlungsarten setzen voraus, dass die Obergrenzen für das Verkehrsprofil derjenigen Flows bekannt sind, die Priorität genießen sollen. Zusätzlich müssen diese Limits am Netzeingang durch Policing fixiert werden. Im Gegensatz zu Intserv setzt Diffserv aber nicht voraus, dass eine Anwendung mit Hilfe eines Signalisierungsprotokolls den Netzknoten Angaben über ihr Verkehrsprofil und die Qualitätsanforderungen macht. Stattdessen stellt Diffserv über das Netzmanagement Ressourcen bereit. Wie einzelne Verkehrsflüsse zu behandeln sind, ist in den Policies geregelt.
Signalisierung für Diffserv
Der Einsatz von Diffserv-Konzepten in der Praxis ist regelmäßig Gegenstand von Diskussionen. Daher sind Beiträge, die konkrete Umsetzungen beschreiben, für die IETF-Arbeitsgruppe von besonderer Bedeutung. Im Beitrag "Policy Based Differentiated Services on AIX" wurde eine Implementierung von Diffserv für das Betriebssystem AIX von IBM beschrieben. Damit lassen sich sowohl fortgeschrittene "QoS-aware"- als auch konventionelle "QoS-unaware"-Anwendungen unterstützen. Es handelt sich um eine auf Policies basierende Implementierung, die das QoS-Schema der Policy-Arbeitsgruppe zur Diffserv-Konfiguration verwendet.
Eine wichtige Frage beim Diffserv-Modell ist, wie dynamische QoS-Anforderungen unterstützt werden können. Ein Lösungsansatz sind "Bandbreiten-Broker" (Bandwidth Broker). Sie sammeln die Anforderungen und vergeben dann die entsprechenden Ressourcen je nach Verfügbarkeit ("Capacity Admission Control") und Berechtigung ("Policy Admission Control").
MPLS: Traffic-Engineering für das Backbone-Netz
Einige Hersteller, an der Spitze Cisco Systems, führten die auf "Label Swapping" basierende Technik "Multiprotocol Label Switching" (MPLS) ein. Sie beschleunigt den Transport von Paketen durch Router (Packet Forwarding). Das Verfahren hat sich inzwischen etabliert. Aktuelle Themen beim IETF-Meeting waren die Unterstützung von Diffserv über MPLS, Erweiterungen des Signalisierungsprotokolls (Label Distribution Protocol) sowie der Einsatz redundanter Links zur Erhöhung der Zuverlässigkeit und der MPLS-Signalisierung zur Steuerung optischer Switches. Im Mittelpunkt der Diskussion aber standen Techniken für das "Traffic Engineering", um eine flexible Nutzung der Ressourcen zu unterstützen.
Techniken und Mechanismen für das Traffic-Engineering zu entwickeln, ist Aufgabe der "Internet Traffic Engineering"-Arbeitsgruppe (TEWG). Zusätzlich dient diese Arbeitsgruppe als Forum für Diskussionen, die sich um die Integration von Traffic-Engineering-Funktionen in andere von der IETF erarbeitete Protokolle drehen. Der Schwerpunkt liegt dabei auf dem Intra-Domain-Bereich.
Die TEWG trat erstmals auf dem 46. IETF-Meeting Anfang November 1999 in Washington zusammen. In Pittsburgh fand also erst das dritte Treffen der Gruppe statt. So ist es nicht verwunderlich, dass die TEWG bislang noch keinen RFC vorlegte. Allerdings befinden sich momentan neun Drafts in Vorbereitung. Die Diskussionen drehen sich gegenwärtig vor allem um das Rahmenwerk für "Internet Traffic Engineering" (TE). Es enthält Prinzipien und Anforderungen an TE sowie eine Beschreibung des Prozessmodells. Die Schlüsselkomponenten sind dabei Messungen für das Traffic-Engineering, Modellierung, Analyse und Simulation sowie Optimierung.
Diffserv und MPLS in Kombination
Auch andere Arbeitsgruppen der IETF beschäftigen sich mit Themen, die für das Traffic-Engineering relevant sind. Dies sind insbesondere Integrated Services (Intserv), RSVP, Differentiated Services (Diffserv), MPLS, "IP Performance Metrics" (IPPM), "Real Time Flow Measurement" (RTFM) und "Endpoint Congestion Management" (ECM). Die TE-Working-Group versucht, alle wesentlichen Anforderungen dieser Gruppen in ihrem Rahmenwerk zu berücksichtigen.
Diffserv und MPLS sind zwei unterschiedliche Ansätze, die einerseits QoS-Unterstützung bieten und andererseits ein Traffic Engineering erfordern. Beide werden nebeneinander existieren. Die aktuellen Debatten lassen erwarten, dass MPLS eher bei Providern beziehungsweise in Backbone-Netzen zum Einsatz kommen wird, während Diffserv in Firmennetzen oder im Zugangsbereich Verwendung findet. Bei der Entwicklung von Traffic-Engineering-Methoden ist es wichtig, den möglichen kombinierten Einsatz von Diffserv und MPLS zu berücksichtigen. (re)
Zur Person
Petra Carle studierte an der Universität Stuttgart Elektrotechnik. Sie ist gegenwärtig als Projektleiterin im Bereich Softwareentwicklung bei der Richard Hirschmann GmbH & Co im Geschäftsbereich Automatisierungs- und Netzwerksysteme tätig.