Mit einer für die Branche der Internetworking-Hersteller sehr unüblichen Diskretion haben in den vergangenen zwei Jahren eine Reihe Verfahren für Quality of Service spezifiziert. Nun stehen die ersten Implementierungen an - der Beweis, daß sich diese auf breiter Ebene einsetzen lassen, muß noch erbracht werden. Ähnlich wie bei ATM handelt es sich um ein Zusammenspiel mehrerer Protokoll-Spezifikationen, die insgesamt eine Ende-zu-Ende-Dienstgüte ermöglichen sollen: MAC-übergreifend IEEE 802.1D-1998 und 802.1Q; auf IP-Ebene Differentiated Services (Diffserv, DS), Multi-Protocol Label Switching (MPLS) und Resource ReSerVation Setup Protocol (RSVP); auf TCP/UDP-Ebene Layer-4-Switching (siehe Tabelle "QoS-Ansätze für LANs"). Dazu gesellen sich Policy-Konzepte mit herstellereigener Software oder unter Nutzung rudimentärer Standards wie Directory Enabled Networks (DEN), Lightweight Directory Access Protocol Version 3 (LDAPv3) und Common Open Policy Services (COPS).
Um Datenpakete einer bestimmten Dienstgüte zuzuordnen, müssen sie entsprechend gekennzeichnet werden, zum Beispiel über Portnummer oder Tags. Die Klassifizierung führt im besten Fall zu einer Ende-zu-Ende durchgeschalteten Reservierung (bei Einsatz von RSVP), während eine Priorisierung als "Praktiker-Ansatz" eine solche Garantie allenfalls in grober Näherung erreicht. Das Zusammenspiel verschiedener Protokollebenen zeigt Bild 2. Allen Ansätzen liegt dabei eine einzige Annahme zugrunde: Die Netze enthalten zwischen Sender und Empfänger mindestens einen Switch, in dem die Bearbeitung von Dienstgüte-Anforderungen beziehungsweise Serviceklassen stattfinden kann. Aus diesem Grund sollten Anwender am besten alle Shared-LAN-Hubsysteme ausmustern.
Layer-2-Switches ermöglichen Priorisierungen für wichtige Unicast- oder Multicast-Frames. Aktuell ist mit drei Prioritäts-Bits eine statische Priorisierung mit den Werten 0 bis 7 definiert. Vorgeschlagen wird eine mindestens zweistufige Dienstklassen-Implementierung von 0 bis 3 für unkritische und 4 bis 7 für Realzeit-Applikationen. Eine Verfeinerung auf bis zu acht Stufen je Port ist denkbar. Darüber hinaus ist es möglich, Multi-casts generell anders zu behandeln als Unicasts, das heißt ihnen eine andere Priorität zuzuweisen.
Die Bedeutung von IP-Multicasts nimmt zu, zum Beispiel für Konferenzen und Application Sharing. Da sich IP-Multicasts immer auf MAC-Multicasts abbilden lassen, ist eine Behandlung in Layer-2/3 Mischkonfigurationen möglich. MAC- Multicasts können dynamisch an Switchports registriert werden, mit der Konsequenz, daß sie nicht mehr an alle Ports weitergeleitet werden, sondern nur an diejenigen, an die aktive Teilnehmer angebunden sind.
Für große Netzwerke ist eine rein endgerätebezogene Behandlung des Datenflusses zu aufwendig. Gleichartige Sessions werden daher zu sogenannten Dienstklassen (Class of Service) zusammengefaßt und nach demselben Service-Level bearbeitet. Weil dann nur noch ein Eintrag je Applikation und nicht mehr für jeden Benutzer einzeln nötig ist, verbessert das die Skalierbarkeit.
Mit dem Differentiated-Services-Konzept hat ein Netzbetreiber die Möglichkeit, den Kunden eine Reihe von Netzdiensten anzubieten, die sich nicht nur nach Preisgruppen, sondern auch - meß- und kontrollierbar - nach Performance unterscheiden. Der Kunde schließt einen Vertrag über einen bestimmten Performance Level ab, der auf IP-Ebene realisiert wird. Typischerweise gehört zum Service-Profil, das zwischen Provider und Kunde vertraglich vereinbart wird, die Festlegung der Zugangsrate und in wenigen Fällen des Delays. Überschreitet der Kunde die zugesicherten Raten, ist die vereinbarte Dienstgüte für den Mehranteil nicht mehr garantiert (Rückstufung auf einen Default-Level).
Zur Implementierung des Differentiated-Services-Konzepts wird das Type-of-Services-(TOS-) Byte im IPv4-Header benutzt. Es erhält eine neue Aufteilung und wird dann "DS Byte" genannt: Bit 0 bis 5 ist der Prioritäts-Wert, Bit 7 und 8 sind reserviert. Der Wert der Prioritäts-Bits aus IPv4 läßt sich aus Gründen der Kompatibilität auf die ersten 3 Bit des DS-Byte abbilden.
"Policy-Netze" sind ein noch weiter gehendes Konzept. Im überwiegenden Sprachgebrauch verbirgt sich dahinter eine zentrale Dienstgütesteuerung und Überwachung von vernetzten Ressourcen. Über eine Policy-Konsole mit grafischer oder Text-Oberfläche kann der Netzbetreiber die erforderlichen Vorrang-Regeln und Parameter eingeben. Damit diese auch wirksam werden, muß erstens irgendwo im Netz ein Policy-Server die Eingaben umsetzen. Zweitens müssen die Netzkomponenten "Policy-fähig", das heißt in der Lage sein, mit dem Policy-Server zu kommunizieren und sich nach dessen Vorschriften zu verhalten.
Eine Standard-Entwicklung zeigt sich in weiter Ferne: der IETF Draft (Version 7) vom August 1999, entwickelt von Firmen wie Level3, Intel, IPHighway und Cisco. Das COPS-Protokoll definiert ein einfaches Anfrage-Antwort-Modell, um Policy-Informationen zwischen einem Policy-Server und den ihm zugeordneten Clients auszutauschen. Ein solcher Client kann zum Beispiel ein Router oder ein Switch sein. Clients stellen Reservierungs-Anfragen an den Policy-Server, senden ihm aber auch Updates und Löschungswünsche. Der Server bearbeitet Updates und Löschungen und entscheidet über Reservierungswünsche. COPS benutzt als Basis-Protokoll TCP, für die Durchführung von Reservierungen wird RSVP als Signalisierungs-Protokoll verwendet.
Attraktiv für Netzbetreiber ist, daß Directory Enabled Networking (DEN) mittels integrierter Verzeichnisdienste für Benutzer und Netzkomponenten es vereinfachen könnte, Dienstgüte anzubieten und angemessen zu betreiben: Derzeit fließen zu viele Arbeitsstunden in Anpassung/Customizing von Kunden-Datenbanken und die benutzerbezogene Anpassung einzelner Dienste. Netzbetreiber könnten Service Level Agreements (SLAs) leichter implementieren, wenn Benutzer-Zertifizierung, SLA-Vereinbarungen, Benutzer-, Netzwerk- und Dienstgüte-Informationen in derselben logischen Directory-Infrastruktur zusammengefaßt wären. Statt dessen sind bei den Netzbetreibern immer noch Excel-Tabellen und Powerpoint/Visio-Dateien für die Ablage und Pflege von Kundendaten zu finden.
Wenn ein Benutzer sich im Netz einloggt, kennt eine DEN-basierende Netzarchitektur alle Netzelemente, die an dieser Verbindung beteiligt sind, und verwaltet diese gleichzeitig mittels Verzeichnisdienst. Beim Session-Aufbau erfolgt eine Anfrage an einen Policy-Server, ob der entsprechende Benutzer den angefragten Dienst aktivieren darf und wenn ja, mit welcher vereinbarten Dienstgüte. Die Policy-Information - "Wer, was, wann, wieviel, wie oft, wie gut" - stammt natürlich vom DEN Directory Server. Ein möglicher Verbindungsaufbau sieht dann so aus: Der beteiligte Client (Endgerät oder erster Layer-3-Switch) startet mit SNMP, HTTP oder RADIUS eine Policy-Anfrage an einen Policy-Server. Die notwendigen Informationen zur Beantwortung der Anfrage holt dieser sich mittels LDAPv3 aus dem DEN Directory. Nach Auswertung der Directory-Informationen erhält der Client die Beantwortung der Anfrage vom Policy-Server sowie gegebenenfalls ein Update seiner eigenen Policy-Parameter, wenn die Konfiguration einer Netzkomponente entsprechend der Netzsituation dynamisch angepaßt werden muß. Eine Übersicht über die beteiligten Netzkompo-nenten zeigt obiges Bild.
Alle Implementierungen sind proprietär
Die Vision vom zentral gesteuerten Konfigurations-Download in Netzwerkkomponenten, der dann gleich alle nötigen Policy-Parameter enthält - möglicherweise ist sie unrealistisch. "Heute ist der Standard für Gerätekonfiguration eine Telnet-Session zu jedem einzelnen Gerät - das ist ein großes Hindernis für die Implementierung", räumt J. Craig Easley, Produkt Marketing bei Nortel, ein. Im Extremfall sind existierende Produkte inkonsistent und völlig überfrachtet: "Wir unterstützen 80 oder 90 QoS-Mechanismen - keine Einzelperson in einem Unternehmen kann diese alle verstehen", so Paul McNab, Marketing Manager von Cisco. Die Produktsituation läßt sich wie folgt zusammenfassen: Alle Implementierungen, soweit sie tatsächlich verfügbar sind, sind proprietär. Auch solche, die mit "Standards" wie DS, COPS, MPLS werben, denn diese sind entweder noch nicht verabschiedet oder inkompatibel zum Rest der Welt implementiert. Die Preise bewegen sich je nach Produkt und Konfiguration zwischen 50000 und bis zu stolzen 300000 Euro.
Angeklickt
In der klassischen Internetworking-Welt ist mit der Etablierung von Switching bis zum Endgerät ein deutlicher Trend erkennbar, QoS-Funktionalität mit Frame-Technologie auf 802.x LANs möglich zu machen. Besonders intensiv wird an der Interaktion von Layer-3- und Layer-2-Geräten gearbeitet, die eine durchgehende Dienstgüte in Form von Priorisierung ermöglicht. Der Fokus liegt dabei auf Einfachheit und Beschränkung auf wesentliche Dienstklassen beziehungsweise elementare Paket-Klassifizierung. Die bislang erreichte Funktionalität ist zwar sicher nicht mit den hochkomplexen Möglichkeiten eines ATM-Netzes vergleichbar, kann jedoch eine praktikable Grundqualität herstellen. Damit hat ATM ein wichtiges Alleinstellungsmerkmal verloren.
Derzeit ist für QoS ein Zusammenspiel verschiedener Protokolle erforderlich (COPS, DS, RSVP, MPLS, 802.1D-1998). Dabei wird allerdings eines klar: Die Realisierung von Dienstgüte in LANs führt zu einer deutlichen Steigerung der Konfigurationskomplexität. Bei der noch weiterreichenden Implementierung von Policy-Konzepten muß als goldene Regel gelten: KISS (keep it simple and stupid)! Die Implementierung von 1001 Policy-Funktionen wird sich mangels Pflegbarkeit genauso wenig am Markt durchsetzen wie seinerzeit die ausgeklügeltsten VLAN-Konzepte.
Ratgeber
Bei der Betrachtung existierender Policy-Lösungen (zum Beispiel von Cabletron, Cisco, Extreme, Fore, IBM, Intel, Lucent, Nortel, 3Com, Xylan) sollten einige Aspekte bewertet werden:
- Umfaßt das Policy-Konzept LAN und WAN?
- Ist Policy-Software auf allen Endgeräten erforderlich?
- Wie werden Policy-Informationen im Netzwerk verbreitet, und wie wird die Policy-Einhaltung durchgesetzt und überwacht?
- Wie werden Verzeichnisdienste, Dynamic-Host-Configuration-Protocol-(DHCP-)Server, Sicherheitsfunktionen und Baselining Tools zur Parameter-Festlegung und Validierung der gesetzten Policy eingebunden?
- In welcher Richtung sind verfügbare Produkte getunt: Leistung? Sicherheit? Bestimmte Applikationen (zum Beispiel Web)?
- Handelt es sich um im Grunddesign alte Produkte, die nur mit ein bißchen Policy-Funktion "aufgepeppt" wurden?
*Petra Borowka ist Geschäftsführerin der UBN Unternehmensberatung Netzwerke in Aachen