Institut für Kommunikationsnetze und Rechnersysteme - Universität ...

– 66 –
Auswahl der jeweils als nächstes zu bedienenden Warteschlange auftretende Sortierproblem
schwer. Zwar gibt es, wie in [167] aufgezeigt wird, hierzu wie auch zum Problem der Paketklassifizierung
effiziente Algorithmen, mit denen auch noch Tausende gleichzeitig existierender
Reservierungen beherrscht werden können. Doch letztendlich konnten dadurch die grundsätzlichen
Bedenken im Hinblick auf die Skalierbarkeit nicht vollkommen ausgeräumt werden.
Daneben gibt es noch weitere Gründe dafür, dass sich IntServ bis heute nicht durchsetzen
konnte. Dabei sind zunächst Defizite des in Abschnitt 3.3.2.1 vorgestellten Dienstemodells zu
nennen. Dieses zielt in erster Linie auf Multimedia-Gruppenkommunikation ab, während
WWW-Dienste, die zum Zeitpunkt der Festlegung der IntServ-Architektur erst in ihrer
Anfangsphase waren, keine besondere Berücksichtigung finden. Der wesentliche Unterschied
ist hierbei die deutlich kürzere Dauer von Ende-zu-Ende-Verbindungen im Fall von WWW, die
dazu führt, dass sehr häufig Reservierungen vorgenommen werden müssen.
Aber auch bzgl. Echtzeitverkehr haben die in IntServ spezifizierten Dienstklassen Schwächen.
Der Guaranteed Service konzentriert sich auf die Bereitstellung deterministischer Verzögerungsgarantien,
was im Vergleich zu statistischen Garantien einen wenig effizienten Umgang
mit Bandbreiteressourcen bedeutet, zumal die meisten der heutigen Echtzeitanwendungen mit
geringer Wahrscheinlichkeit auftretende Überschreitungen der vorgegebenen maximalen Verzögerung
tolerieren können. Die Definition des Controlled-Load Service andererseits ist sehr
unscharf. Dies gilt sowohl aus Nutzersicht als auch aus dem Blickwinkel von Netzbetreibern,
denen konkrete Anhaltspunkte für die Verbindungsannahme fehlen.
Hinzu kommen schließlich die grundsätzlichen Probleme einer Dienstgütearchitektur mit
absoluten Garantien wie die Schwierigkeit, Verkehrsprofil und Ressourcenbedarf einer
Anwendung anzugeben, oder die Notwendigkeit einer durchgängigen Unterstützung in allen
(oder zumindest in den durch Überlast am meisten gefährdeten) Netzknoten.
3.3.3 Die Differentiated-Services-Architektur
Nachdem die genannten Schwächen des IntServ-Ansatzes, insbesondere im Hinblick auf die
Skalierbarkeit, innerhalb der IETF erkannt wurden, entstand immer mehr der Wunsch nach
einer einfacheren Architektur für ein Internet, das wenigstens die Möglichkeit einer grundlegenden
Dienstgütedifferenzierung und damit einer Verbesserung gegenüber Best-Effort-Verkehr
gibt. Daraus entstand 1997 die Arbeitsgruppe Differentiated Services (DiffServ), in der
eine gleichnamige Rahmenarchitektur definiert wurde [27, 126, 143, 204, 205].
3.3.3.1 Kerngedanken
Der wesentliche Unterschied zu IntServ ist, dass bei DiffServ im Kernnetz aggregierte Verkehrsströme
behandelt werden, d. h. innerhalb einer DiffServ-Region finden keine Reservie-