Echtzeitdienste sind keine Fiktion

Erfahrungen und Ausblick

Die vorliegenden Praxiserfahrungen belegen, dass der in Diff-Serv realisierte Ansatz tatsächlich funktioniert: Geschäftskritische Anwendungen lassen sich von anderen unterscheiden; gleichzeitig können Echtzeitapplikationen, wie Sprache über IP, in ein Netz integriert werden, ohne Abstriche an der Qualität zu machen. Als aufwendig hat sich das Management der Serviceklassen beziehungsweise ihrer Ressourcen auf den Verbindungswegen erwiesen. Solange keine adäquaten Management- und Planungslösungen vorliegen, ist davon abzuraten, mit zu vielen Klassen zu arbeiten. Als sinnvoll haben sich zwei oder drei Datenklassen und eine Sprachklasse erwiesen.

In vielen Unternehmen tritt zudem das Problem auf, dass die Anforderungen der Anwendungen an das Netzwerk nicht genau bekannt sind oder sich die Anwendungen, bedingt durch dynamische Port-Wahl, nicht direkt klassifizieren lassen. In diesem Fall empfiehlt es sich, "Service Level Agreements" (SLAs) zu erarbeiten oder Verfahren einzusetzen, die Layer-7-Daten erkennen und verarbeiten, wie etwa "Network Based Application Recognition" von Cisco.

Die Mitglieder der IETF arbeiten mittlerweile daran, Int-Serv und Diff-Serv zusammenzuführen. Dies könnte so aussehen: Eine Applikation signalisiert dem Netz mit Hilfe von RSVP ihre Anforderungen; der erste Router befragt einen Cops-Policy-Server, der ein zu nutzendes Diff-Serv-Per-Hop-Behaviour zurückmeldet. Der RSVP-Request wird dann über den Diff-Serv-Backbone zum Ziel getunnelt. Microsoft, SAP und Cisco demonstrierten das Verfahren im September 1999 auf der Fachmesse Networld + Interop in Atlanta

Unter dem Strich ist festzuhalten, dass IP-Servicequalität heute keine Fiktion mehr ist, auch wenn noch einige Bausteine fehlen: Die Standards liegen vor, und der Anwender kann entsprechende Lösungen in sein Netz integrieren. Die größte Herausforderung für die Zukunft besteht darin, QoS in das Netzwerkmanagement einzubetten. (re)