für Internet-Telefonie in Differentiated-Services-Netzen

Transkript

1 Vom Fachbereich für Mathematik und Informatik der Technischen Universität Braunschweig genehmigte Dissertation zur Erlangung des Grades eines Doktor-Ingenieurs (Dr.-Ing.) von Dipl.-Inform. Urs Thürmann Dienstgüteunterstützung für Internet-Telefonie in Differentiated-Services-Netzen Referentin: Prof. Dr. M. Zitterbart Korreferent: Prof. Dr. L. Wolf eingereicht am: Tag der mündlichen Prüfung:

2

3 Vorwort Die vorliegende Arbeit entstand während meiner Tätigkeit als wissenschaftlicher Mitarbeiter am Institut für Betriebssysteme und Rechnerverbund der Technischen Universität Braunschweig. An erster Stelle möchte ich mich bei Frau Prof. Dr. Martina Zitterbart für die Möglichkeit zur Promotion an diesem Institut bedanken. Ihre Anregungen und Kritik sowie die gewährte Freiheit haben maßgeblich zur Entstehung der Arbeit beigetragen. Weiterhin gilt mein Dank Herrn Prof. Dr. Lars Wolf für die Übernahme des Korreferats. Ich danke meinen Kollegen des Instituts für Betriebssysteme und Rechnerverbund. In vielen Diskussionen, unter anderem während der regelmäßig stattfindenden Doktorandenseminare, haben sie wertvolle Hinweise und Anregungen geliefert. Auch durch die gute Arbeitsatmosphäre haben sie meine Arbeit unterstützt. Ebenfalls danke ich meiner Mutter Ursula Thürmann für die Durchsicht des Manuskriptes und die Suche nach orthographischen und grammatikalischen Fehlern. Mein größter Dank gilt jedoch meiner Freundin Bettina Kreipe, die während der letzten zwei Jahre große Geduld und viel Verständnis aufgebracht hat. Braunschweig, im Oktober 2002 Urs Thürmann iii

4 iv

5 Kurzfassung In der vorliegenden Arbeit wird ein Ansatz zur Dienstgüteunterstützung mit Differentiated Services für Internet-Telefonie vorgestellt und untersucht. Darüberhinaus wird eine Möglichkeit zur Integration der Mechanismen von Differentiated Services zur Dienstgüteunterstützung mit der H.323-Signalisierung zum Aufbau von Internet-Telefonieverbindungen entwickelt. Im heutigen Internet gibt es keine Unterstützung für Anwendungen, die besondere Anforderungen an die Dienstgüte ihrer Kommunikationsverbindungen stellen. Die Zwischensysteme im Internet, die sogenannten Router, leiten die Pakete aller Anwendungen ohne Unterscheidung zum nächsten Router weiter durch das Netz. Durch dieses Best-Effort-Prinzip erfährt jede Anwendung eine von der momentanen Lastsituation abhängige Dienstgüte für den Transport ihrer Daten. In der Internet Engineering Task Force (IETF) sind verschiedene Konzepte zur Unterstützung von Dienstgüte entwickelt worden. Eines dieser Konzepte heißt Differentiated Services (DiffServ) und verfolgt das Ziel, die Probleme anderer Ansätze mit der Skalierbarkeit zu beheben. Die Mechanismen für den Datenpfad eines Differentiated-Services-Netzes sind weitgehend diskutiert, die Ressourcensignalisierung ist jedoch noch weitgehend offen. In dieser Arbeit wurde ein Konzept zur Dienstgüteunterstützung für Internet-Telefonie auf der Basis von Differentiated Services entwickelt. Die Untersuchungen konzentrieren sich auf drei Schwerpunkte. Es wurden zunächst die Service-Klassen von Differentiated Services und verschiedene Parametrisierungen der DiffServ-Komponenten hinsichtlich ihrer Eignung zur Unterstützung von Internet-Telefonie untersucht. Für die Ressourcenreservierung sind Instanzen notwendig, die die vorhandenen Ressourcen verwalten und deren Reservierung mit den anfordernden Anwendungen und untereinander aushandeln. Dazu wurde ein Modell eines Bandwidth Brokers und ein geeignetes Signalisierungsprotokoll in dieser Arbeit entwickelt. Um die entwickelte Infrastruktur zur Ressourcenreservierung auch für Internet-Telefonie verwenden zu können, wurden Ansätze zur Integration von Differentiated Services und IP- Telefonie nach H.323 entwickelt und miteinander verglichen. Es werden unterschiedliche Signalisierungsvarianten zwischen H.323-Terminals und H.323-Gatekeepern sowie zwischen H.323-Gatekeepern und DiffServ-Bandwidth-Brokern diskutiert. v

6 vi

7 Inhaltsverzeichnis 1 Einleitung Überblick über diese Arbeit Grundlagen Dienstgüteunterstützung in Netzen Reservierungsprotokolle Zulassungskontrolle Scheduler Traffic Shaping Token Bucket Integrated Services und RSVP Guaranteed Service Controlled-Load Service Differentiated Services Border-Router Innere Router Services Per-Hop-Behavior Bandwidth Broker Warteschlangen-Mechanismen FIFO RED WFQ CBQ RIO und GRED Verkehrsmuster Existierende Ansätze IPTalk Bandwidth-Broker-Signalisierung Simulationen Internet2 und QBone Entwicklung des QBone Services Phase Phase Aggregierte Ressourcenreservierung mit QoS-Agenten vii

8 viii Inhaltsverzeichnis Ablauf einer Reservierung Aggregierte Reservierungen Aggregierung zu Zielen derselben Domäne Differentiated Services für Echtzeitverkehr Router für Differentiated Services Kontrollebene und Datenpfad Klassifizierung von Paketen und Test auf Einhaltung der Verkehrsverträge Per-Hop-Behaviors und Warteschlangen Konzept eines Bandwidth Brokers Ausdehnung der DiffServ-Domänen und Interaktion mit dem Bandwidth Broker Signalisierungsprotokoll Initialisierung und Bandwidth Broker Discovery Ressourcenreservierung Hard-States vs. Soft-States Ausfall eines Bandwidth Brokers Aggregierung von Reservierungen Aufbau des Bandwidth Brokers Datenstrukturen des Bandwidth Brokers Bidirektionale Reservierungen Routing-Änderungen IP-Telefonie Grundlagen Signalisierung für IP-Telefonie H SIP IP-Telefonie über Differentiated Services Integration von Bandwidth Brokern und H.323-Gatekeepern Unidirektionale Reservierungen beim Admission Request (ARQ) Bidirektionale Reservierung beim Admission Request (ARQ) Unidirektionale Reservierungen nach Call Proceeding Integrationsansätze mit Änderungen am H.323-Terminal Reservierungen durch die Terminals nach der Admission Confirmation (ACF) Reservierungen durch die Gatekeeper nach modifiziertem Admission Request (ARQ) Vergleich der Ansätze zur Integration von H.323 und DiffServ Auswertung Auswirkung von Differentiated Services auf TCP vs. UDP Simulation von Sprachverkehr Simulationsszenario Topologie Hintergrundverkehr Sprachverkehr

9 Inhaltsverzeichnis ix Klassifizierung des Verkehrs und Parametrisierung der PHBs Durchführung der Simulationen und Ergebnisse IP-Telefonie mit Best Effort Service IP-Telefonie mit Assured Service IP-Telefonie mit Premium Service IP-Telefonie mit Premium Service und WFQ Erreichbarer Durchsatz für Sprachverkehr Zusammenfassung Integration von H.323 und Differentiated Services Topologie Signalisierung Sprach- und Hintergrundverkehr Netzlast durch Signalisierung Zusammenfassung Zusammenfassung und Ausblick Verteilte Bandwidth Broker Abkürzungen 129 Literaturverzeichnis 133

10 x Inhaltsverzeichnis

11 Abbildungsverzeichnis 2.1 Token Bucket Filter t(b, r) Ressourcenreservierung mit RSVP Die Differentiated-Services-Architektur Aufbau eines DS-Routers Aufbau einer Reservierung durch die Bandwidth Broker Stausituation in einem Router Verzögerung von Paketen im Netz FIFO-Warteschlangenverfahren RED kontrolliert den Eintritt von Paketen in eine FIFO-Warteschlange Verlustwahrscheinlichkeit bei RED WFQ mit mehreren Warteschlangen Aufteilung der Bandbreite mit CBQ Verlustwahrscheinlichkeiten bei RIO Das Dumbbell-Netz Das Slalom-Netz Vorreservierung mit Core-Tunneln Ablauf einer Reservierung Aggregierung bei gleichen Zielen Aggregierung bei Zielen derselben Domäne Modell eines Routers für Differentiated Services Hierarchie von Warteschlangenverfahren Nachrichtenformat zwischen Bandwidth Brokern Initialisierung und Bandwidth Broker Discovery Format von Reservierungsnachrichten Reservierungsparameter Format von Reservierungsantworten Konfigurationsnachrichten an die Ingress-Router Reservierung mit End-to-end-Signalisierung Reservierung mit Immediate-Response-Signalisierung Ablauf einer Reservierung im Bandwidth Broker Ausfall eines Bandwidth Brokers Architektur des Bandwidth Brokers Struktur der Reservierungsdaten im Request Manager Struktur der Reservierungsdaten im Flow Manager Kommunikationsweg bei IP-Telefonie xi

12 xii Abbildungsverzeichnis 5.2 H.323-Architektur H.323 Gatekeeper Discovery und Registration H.323 Call Setup: Direct Endpoint Call Signalling H.323 Call Setup: Gatekeeper Routed Call Signalling H.323 Initial Communication and Capability Exchange H.323 Establishment of Audiovisual Communication H.323 Call Services H.323 Call Termination H.323 Fast Connect Procedure Integration von H.323 und Differentiated Services Unidirektionale Reservierungen beim Admission Request (ARQ) Schnellerer Verbindungsaufbau durch bidirektionale Reservierung Unidirektionale Reservierungen nach Call Proceeding Reservierungen durch die H.323-Terminals Simulation mit TCP über Differentiated Services Simulationsergebnisse für TCP über Differentiated Services Topologie des Simulationsmodells Struktur der Provider-Domänen Struktur der LANs Simulationen mit WFQ-Verfahren Simulationen mit CBQ-Verfahren Dienstgüte mit Best Effort Dienstgüte mit Best Effort und RED Dienstgüte mit Assured Service Dienstgüte mit Premium Service Dienstgüte mit Premium Service Dienstgüte mit Assured Service Backbone für Simulationen mit H.323 und DiffServ Verbindungsaufbauzeiten bei H.323 mit Differentiated Services Bandbreite des Signalisierungsverkehrs Reservierungsrate durch Sprachverbindungen

13 Kapitel 1 Einleitung Das Internet ist zur Zeit einem starken Wandel unterworfen. Ausgelöst durch den Internetdienst World Wide Web (WWW), haben Entwicklungen stattgefunden, die das Internet in wenigen Jahren von einem fast ausschließlichen Forschungsnetz zu einer Kommunikationsplattform verändert haben, deren heutige Bedeutung mit der des Telefonnetzes vergleichbar ist. Die Grundlagen des Internet gehen bis 1961 zurück, als Leonard Kleinrock am M.I.T. das erste Paper zum Packet Switching veröffentlichte. Als Folge des Sputnik-Schocks im Jahre 1957 versuchten die USA, Entwicklungsrückstände aufzuholen bzw. einen Vorsprung zu erreichen. In diesem Rahmen wurde bei der ARPA (Advanced Research Projects Agency) unter Leitung von J. C. R. Licklider die Entwicklung eines weltweiten Netzes begonnen, das auf der Packet Switching Technologie basierte. Nach der Absegnung des Anfang Juni 1968 eingereichten Plans für das ARPANET wurde die Entwicklung der notwendigen Maschinen begonnen. Als IMPs (Interface Message Processor) wurden umgebaute Honeywell DDP-516 eingesetzt. Am 30. August 1969 wurde der erste Host an der University of California at Los Angeles (UCLA) an das ARPANET angeschlossen. Der zweite Host wurde am 1. Oktober 1969 am Stanford Research Institute angeschlossen, und die erste Nachricht wurde von der UCLA an SRI gesendet. In den beiden folgenden Monaten wurde das geplante Ziel des ARPANET durch den Anschluß des dritten und vierten Hosts an der University of California at Santa Barbara (UCSB) und der University of Utah erreicht. Auch das Militär (DARPA) war an diesen Arbeiten interessiert und baute ein ähnliches Netz, später unter dem Namen MILNET bekannt, auf. Anfangs wurde noch das Network Control Protocol (NCP) im ARPANET verwendet. Mitte der 70er Jahre wurden Arbeiten zu neuen Protokollen, TCP/IP, veröffentlicht. Am 1. Januar 1983 erfolgte der Übergang von NCP zu TCP/IP. An der University of California at Berkeley (UCB) wurde 4.2 BSD, das erste Unix mit Unterstützung für TCP/IP fertiggestellt. Danach setzte eine rasante Entwicklung der Anzahl an dieses Netz angeschlossener Systeme ein, die Mitte 1970 noch bei sieben lag. Gerade von den Forschungseinrichtungen wurde der Nutzen eines solchen Netzes sehr schnell erkannt. Austausch von Informationen und Zugriff auf entfernte Ressourcen waren in einer bis dahin nicht gekannten Weise möglich. Der Transport von und News (SMTP und NNTP), Dateitransfer (FTP) und das Anmelden und Arbeiten auf entfernten Rechnern (TELNET) wurden die wichtigsten und am häufigsten genutzten Dienste. Die Netzwerkprotokolle, die für dieses Netz entwickelt worden sind, sind bis heute im Internet in Gebrauch. Die Protokollfamilie TCP/IP wurde für die Erfordernisse im damaligen 1

14 2 Kapitel 1. Einleitung Netz konzipiert. Die Anforderungen bestanden in erster Linie aus Zuverlässigkeit auch in Fehlersituationen und effizienter Ausnutzung der vorhanden Ressourcen. Diese beiden Ziele führten zu einem paketvermittelten Dienst in der Netzwerkschicht (IP) und einem Transportprotokoll (TCP), das Sequenznummern und Übertragungswiederholung benutzt. Ein weiteres Transportprotokoll (UDP) spielte für die anfangs benutzten, oben erwähnten Dienste nur ein untergeordnete Rolle. Außerhalb von Forschungseinrichtungen wurden Datennetze kaum benutzt. Dies hatte hauptsächlich den Grund, daß Computer außerhalb von großen Institutionen kaum finanzierbar und damit nicht verbreitet waren. In einigen großen Industriebetrieben wurden zwar schon Computer zur Verwaltung eingesetzt, aber es bestand noch nicht die Notwendigkeit, Daten in größerem Maße mit entfernten Stellen auszutauschen, die ein damals noch sehr teures Datennetz gerechtfertigt hätte. Auch mit dem Aufkommen von Computern in privaten Haushalten wurden Datennetze noch wenig genutzt. Diese Nutzung beschränkte sich dann meist auf Mailboxen und UUCP [75], die aber auch nur von wenigen Anwendern genutzt wurden. Die überwiegende Anzahl privater Computer war nicht vernetzt und wurde lediglich für Textverarbeitung und Spiele genutzt. Der Grund für die geringe Nutzung waren neben den hohen Kosten auch das Fehlen einfach zu bedienender Dienste mit attraktiven Anwendungen. Dieser Umstand änderte sich, als 1993 mit dem WWW ein neuer Dienst in dem auf TCP/IP basierenden Internet verfügbar wurde. Zusammen mit den inzwischen deutlich gestiegenen Rechenleistungen und grafischen Fähigkeiten von Computern zu einem erschwinglichen Preis war eine Anwendung des Netzes entstanden, die leicht zu bedienen war und interessante Informationsangebote im Netz zu realisieren erlaubte. Es entstand eine Wechselwirkung, die zu einem rasanten Anstieg der Nutzer im Internet führte: Steigende Nutzerzahlen weckten das Interesse verschiedenster (Informations-)anbieter, sogenannte WWW-Seiten im Netz verfügbar zu machen, was wiederum neue Nutzer des Netzes nach sich zog. Insbesondere die kommerzielle Nutzung des Internets hat in den letzten Jahren stark zugenommen. In den 5 Jahren von 1993 bis 1998 hat sich die Anzahl der an das Internet angeschlossenen Systeme mehr als ver-300-facht. Ein solcher Anstieg konnte von der bestehenden Infrastruktur natürlich nicht ohne erheblichen Ausbau verkraftet werden. Viele Internet-Service-Provider (ISP) bauten eigene Datennetze auf und stockten regelmäßig deren Kapazitäten auf. Trotzdem kam und kommt es durch das ständig wachsende Verkehrsaufkommen immer wieder zu Engpässen. Die Überlastung der vorhanden Ressourcen führt zu Stausituationen und Paketverlusten im Internet, insbesondere in den viele Teilnetze verbindenden Backbones, welche sich als Qualitätseinbußen bei den Netzdiensten auf Seiten jedes einzelnen Anwenders bemerkbar machen. Im Zuge der täglich wachsenden Anzahl an das Internet angeschlossener Rechner tritt ein weiteres Problem auf: Ohne die heutige Entwicklung vorhersehen zu können, wurde bei der Entwicklung der TCP/IP-Protokolle ein Adreßformat für IP festgelegt, das 32 Bits umfaßt, die in Netzwerk- und Rechneradresse aufgeteilt ist. Dieses Adreßformat bietet allerdings nicht genügend Adreßraum, um heute noch jedem Rechner eine eigene Adresse zuzuteilen. Neben anderen Problemen, z.b. der Forderung nach Verschlüsselung der Daten, besonders bei kommerzieller Nutzung, hat das Problem des Adreßraums zur Entwicklung eines neuen Netzwerkprotokolls mit dem Namen IPv6 geführt [21, 96, 22]. Obwohl das Internet und die im Internet verwendeten Protokolle für klassische Datendienste wie FTP und entworfen wurden, begannen schon Anfang der 90er Jahre Versuche, Anwendungen mit anderen Anforderungen über das Internet zu nutzen. Da in den USA schon 1960 große Teile des Telefonnetzes digitalisiert waren, gab es die Idee, digitalisierte

15 3 Sprache auch über Internet-Protokolle zu übertragen. Die israelische Firma Vocaltec bot 1995 erstmals ihr Programm InternetPhone an, das Sprachübertragung zwischen zwei PCs erlaubte, die über das Internet verbunden waren. Innerhalb weniger Monate sind mehr als Kopien dieses Programms verkauft worden [69]. Aufgrund der gegenwärtigen großen Verbreitung von PCs mit Internetanschluß, sowohl bei privaten als auch kommerziellen Nutzern, ist das Interesse, Telefonverkehr und weitere neue Anwendungen wie z.b. Videokonferenzen über das Internet zu realisieren, stark gewachsen. Heute sind viele Internet-Service-Provider gleichzeitig Anbieter von Telefondiensten, und fast alle Betreiber von klassischen Telefonnetzen bieten heute auch Internetdienste an. Die Telefonnetze und das Internet wachsen immer stärker zusammen mit dem Ziel, letzten Endes nur noch ein dienstintegrierendes Netz zu betreiben. Die treibende Kraft hinter dieser Entwicklung sind die effizientere Ausnutzung von Ressourcen und eingesparte Kosten beim Betrieb und bei der Wartung nur eines Netzes statt mehrerer paralleler Netze. Die Erfahrungen beim Einsatz solcher Programme wie InternetPhone zeigten schnell, daß das paketvermittelte Netzwerkprotokoll IP im Internet in der bestehenden Form nicht für diese neue Anwendung geeignet ist. In paketvermittelten Netzen senden Endsysteme ihre für den Empfänger bestimmten Daten mit der Geschwindigkeit, mit der sie die Daten erzeugen und ihr Netzanschluß die Daten aufnehmen kann, zum nächsten Zwischensystem im Netz. In den Zwischensystemen, die normalerweise viele Anschlußleitungen zu anderen Endsystemen und weiteren Zwischensystemen besitzen, konzentriert sich der Verkehr von vielen Datenströmen, die das Zwischensystem jeweils auf einer Leitung erreichen, um auf einer anderen Leitung zum nächsten Zwischensystem in Richtung des Zielsystems weitergeleitet zu werden. Jedes einzelne Paket des Datenstroms enthält dabei die Information, die das Zwischensystem braucht, um über den weiteren Weg des Paketes zu entscheiden. Wenn viele Endsysteme gleichzeitig Datenverkehr erzeugen, kann es zu der Situation kommen, daß ein Zwischensystem auf seinen Eingangsleitungen innerhalb eines Zeitintervalls mehr Daten für eine bestimmte Ausgangsleitung empfängt, als es auf der Ausgangsleitung in dieser Zeit weitersenden kann. Es muß daher die empfangenen Pakete in eine Warteschlange einfügen, in der die Pakete warten müssen, bis die Leitung, auf der sie das Zwischensystem verlassen sollen, wieder frei ist. Durch die Warteschlange kommt es bei der Weiterleitung der Pakete zu Verzögerungen. Da die Warteschlange in der Länge begrenzt ist, muß das Zwischensystem ankommende Pakete verwerfen, wenn die Warteschlange voll ist. Um Fehler bei solchen Paketverlusten zu vermeiden, können höhere Protokollebenen, z.b. TCP, Sendewiederholungen vornehmen. Neue Anwendungen wie Internet-Telefonie oder Videokonferenzen über das Internet haben jedoch sehr hohe zeitliche Anforderungen. Um den Dienst in gewohnter, akzeptabler Qualität anbieten zu können, müssen Daten, die ein Endsystem sendet, nach einer bestimmten, maximalen Verzögerung das andere Endsystem erreichen. Größere Verzögerungen durch Warteschlangen in den Zwischensystemen und Sendewiederholungen aufgrund von Paketverlusten sind nicht akzeptabel. Dieses Problem tritt im Telefonnetz nicht auf, da es grundlegend anders arbeitet. Das klassische Telefonnetz ist nicht paketvermittelt, sondern benutzt (virtuelle) Leitungsvermittlung. Das bedeutet, daß für jede Verbindung eine eigene Leitung im Netz reserviert wird, die nur dieser einen Verbindung zur Verfügung steht. Der Nachteil dieser Technik ist jedoch, daß die Ressourcen des Netzes nicht sehr effizient genutzt werden. Die Ressourcen, die eine bestehende Verbindung belegt, können von keiner anderen Verbindung genutzt werden. Das

16 4 Kapitel 1. Einleitung gilt auch, wenn die Verbindung, für die die Leitung reserviert wurde, diese gar nicht nutzt, weil der eine Gesprächspartner gerade nicht spricht. Um das Ziel zu erreichen, Dienste wie Internet-Telefonie mit hohen Anforderungen an das zugrundeliegende Netz im Internet zur Verfügung stellen zu können, sind neue, im traditionellen Internet nicht vorhandene Mechanismen notwendig. Durch diese Mechanismen muß das Netz in der Lage sein, Anwendungen eine bestimmte Dienstgüte (Quality of Service, QoS), die von ihnen gefordert wird, garantieren zu können. Die Anwendung stellt an das Netz eine Anfrage, um für einen Datenstrom eine bestimmte Dienstgüte zu erreichen. In der Anfrage der Anwendung muß der zu sendende Datenstrom charakterisiert und die geforderte Dienstgüte spezifiziert werden. Das Netz wird daraufhin eine Überprüfung vornehmen, ob genügend freie Ressourcen auf dem Weg zwischen Sender und Empfänger vorhanden sind, um die geforderte Dienstgüte zu erreichen. Wenn dies der Fall ist und wenn die Anwendung die Rechte hat, diese Ressourcen zu belegen, werden die Ressourcen für den Datenstrom der Anwendung reserviert und eine positive Bestätigung der Anfrage an die Anwendung gesendet. Anderenfalls muß die Anfrage abgelehnt werden. Im neu entwickelten Protokoll IPv6 sind Erweiterungen vorgesehen, die die Implementierung solcher Mechanismen unterstützen sollen. Trotzdem sind Mechanismen zur Dienstgüteunterstützung nicht nur im neuen IPv6, sondern auch mit dem traditionellen, zur Zeit noch überwiegend im Einsatz befindlichen IP-Protokoll möglich. Neben verschiedenen anderen Ansätzen [83] wurde 1994 der RFC 1633 [18] veröffentlicht. Dieser RFC beschreibt Integrated Services, eine Architektur zur Reservierung von Ressourcen im Internet, und ein Protokoll zum Austausch von Reservierungsinformationen, das Resource Reservation Protocol (RSVP). Im September 1997 sind eine Reihe weiterer RFCs zu Integrated Services und RSVP entstanden [19, 5, 8, 66, 20, 110, 109, 87, 4, 3, 88, 89]. Integrated Services und RSVP haben eine nicht unbedeutende Verbreitung in vielen Systemen gefunden. Eine Reihe verschiedener Anwendungsprogramme nutzt RSVP, um Ressourcen im Netz zu reservieren. Entsprechende Application Programmer Interfaces (API) werden auf verschiedenen Betriebssytemen zur Verfügung gestellt. Auch viele Router verschiedener Hersteller wie Cisco, Hewlett Packard oder 3com beherrschen heute RSVP. Dennoch ist RSVP im Netz eher selten im Einsatz. Oft ist RSVP auf den Routern nicht einmal konfiguriert. Ein Problem, das sich beim Einsatz von RSVP und Integrated Services in großen Backbone-Netzen ergibt, die viele Datenströme transportieren müssen, ist seine schlechte Skalierbarkeit. Da ein RSVP-fähiger Router für jede einzelne Verbindung mit reservierten Ressourcen entsprechende Informationen speichern muß, wird der Aufwand der Zustandsverwaltung und Signalisierung in den großen Backbone-Netzen immens. In den letzten Jahren hat sich daher ein alternativer Ansatz zur Dienstgüteunterstützung und Ressourcenreservierung bei der Internet Engineering Task Force (IETF) entwickelt [71, 12, 73]. Dieses neue Konzept heißt Differentiated Services, und es versucht, die Probleme der Skalierbarkeit von RSVP zu vermeiden. Die zentrale Idee von Differentiated Services zur Verbesserung der Skalierbarkeit ist die Aggregierung von Datenströmen und von Ressourcenreservierung. Statt für jeden einzelnen Datenstrom Reservierungen in jedem Router entlang des Kommunikationspfades vorzunehmen, brauchen die meisten Router in einem Differentiated-Services-Netz nur wenige aggregierte Datenströme zu unterscheiden und je nach den reservierten Ressourcen unterschiedlich zu behandeln. Im Gegensatz zu RSVP brauchen die meisten Router in einem Differentiated-Services-Netz keinen Zustand zu speichern, um die Pakete einer bestimmten Verbindung und den damit verbundenen Ressourcenreservierungen zuzuordnen. Stattdessen wird in einem Feld des Paketkopfes eingetragen,

17 1.1. Überblick über diese Arbeit 5 zu welchem aggregierten Datenstrom das Paket gehört. Die Behandlung des Paketes durch den Router hängt ausschließlich von diesem Feld in seinem Paketkopf ab. Im Differentiated-Services-Konzept wird das Internet in Domänen eingeteilt. Die Domänen, deren Router die Differentiated-Services-Mechanismen beherrschen, heißen Differentiated- Services-Domänen (DS-Domänen). Den Routern am Rande der Domänen (Border-Router), die die Verbindung zu den benachbarten Domänen herstellen, fällt ein Teil der Aufgabe der Zugangskontrolle zu. Vor dem Senden eines Datenstroms müssen Reservierungen ausgehandelt werden, die in einem Verkehrsvertrag festgehalten werden. Die Router am Rande einer DS-Domäne prüfen den eingehenden Verkehr und stellen fest, ob er mit dem ausgehandelten Verkehrsvertrag konform ist. Sowohl der Sender als auch die Border-Router einer Domäne können das Feld im Paketkopf zur Kennzeichnung der Zugehörigkeit zu einem aggregierten Datenstrom setzen. Das Differentiated-Services-Konzept sieht eine weitere Komponente für die Reservierung von Ressourcen vor. Die Border-Router und inneren Router einer Domäne bilden den Datenpfad, den alle Pakete durchlaufen müssen. Die Router und Ressourcen müssen aber aber auch verwaltet und Reservierungen entsprechend konfiguriert werden. Dies ist die Aufgabe der sogenannten Kontrollebene. Dazu kann jede DS-Domäne einen oder mehrere Bandwidth Broker betreiben, die die Ressourcen innerhalb der Domäne verwalten. Behandlung von Reservierungsanfragen und Zugangskontrolle in Abhängigkeit von den verfügbaren Ressourcen gehören zu den Aufgaben des Bandwidth Brokers. Der Bandwidth Broker kennt die Verkehrsverträge mit den Nachbardomänen und die aktuelle Auslastung der eigenen Domäne und kann aufgrund dieser Information die Zugangskontrolle für Reservierungsanfragen aus der Nachbardomäne vornehmen. Der Bandwidth Broker kennt jedoch nur die Auslastung der eigenen Domäne. Um eine Ende-zu-Ende-Reservierung für einen Datenfluß vorzunehmen, muß er Reservierungen in den benachbarten Domänen vornehmen, indem er mit deren Bandwidth Brokern kommuniziert. Differentiated Services ist ein relativ neuer Ansatz, der noch nicht in größerem Maßstab im Internet eingesetzt wird. Es gibt bisher nur einige wenige Versuche, Differentiated Services in einem Netz zu betreiben [112, 113]. Die Ausprägung des Bandwidth Brokers ist heute noch weitgehend offen. Bisherige Arbeiten haben sich weitgehend auf den Datenpfad konzentriert. Im Rahmen dieser Arbeit wurde Differentiated Services zur Dienstgüteunterstützung daher ausführlich untersucht. Verschiedene Mechanismen in den Routern wurden implementiert und werden in dieser Arbeit miteinander verglichen. Eine wesentliche Komponente eines Differentiated-Services-Netzes, der Bandwidth Broker, dessen Funktionalität bisher nur umrissen ist [73], wurde konzipiert und implementiert. Ein Simulationsmodell für eine Reihe von Differentiated-Services-Komponenten wurde implementiert, und simulative Untersuchungen wurden durchgeführt. Das Ziel dieser Untersuchungen besteht darin, eine Aussage über die Qualität der Dienstgüteunterstützung mit Differentiated Services und die Eignung der implementierten Komponenten treffen zu können. Außerdem wird ein Konzept zur Integration heute eingesetzter Protokolle für Internet-Telefonie mit Differentiated Services vorgestellt. 1.1 Überblick über diese Arbeit Aus der Vielfalt verschiedener Echtzeitanwendungen und deren Verkehrsmuster wurden IP- Telefonie und Videoübertragungen ausgewählt, um die erreichbare Dienstgüte für diese Anwendungen mit Differentiated-Services-Mechanismen zu untersuchen. Kapitel 2 beschreibt

18 6 Kapitel 1. Einleitung die Techniken, welche die Grundlage für diese Arbeit bilden. Es stellt grundlegende Mechanismen und mehrere Ansätze für QoS-Unterstützung vor. Weiterhin werden spezielle Anforderungen von IP-Telefonie und Videoübertragungen sowie deren typische Verkehrsmuster behandelt. In Kapitel 3 werden andere Arbeiten auf dem Gebiet von Differentiated Services besprochen und Abgrenzungen zur vorliegenden Arbeit vorgenommen. Der eigene Ansatz, Dienstgüte mit Differentiated Services zu unterstützen, wird in Kapitel 4 diskutiert. Neben der Untersuchung verschiedener Warteschlangenverfahren und deren Parametrisierung wird das Konzept eines Bandwidth Brokers zur Aushandlung von Ressourcenreservierung vorgestellt. Die in Kapitel 4 beschriebenen und implementierten Mechanismen wurden simulativ untersucht. Kapitel 6 behandelt die verwendeten Simulationsszenarien und die Ergebnisse der durchgeführten Simulationen. Ein Vergleich verschiedener Verfahren bezüglich ihrer Eignung, Dienstgüte für Echtzeitverkehr zu unterstützen, schließt diese Kapitel. Kapitel 7 gibt eine Zusammenfassung der Arbeit sowie einen Ausblick und schließt damit die vorliegende Arbeit ab.

19 Kapitel 2 Grundlagen In diesem Kapitel werden die Grundlagen der Dienstgüteunterstützung in paketvermittelten Netzen behandelt. Sie bilden die Basis, auf der die Untersuchungen von Differentiated Services für Echtzeitverkehr durchgeführt wurden. 2.1 Dienstgüteunterstützung in Netzen Das Internet entwickelt sich zur Zeit zur globalen Kommunikationsinfrastruktur für verschiedenste Anwendungen. Einer der prominentesten Vertreter aus Sicht der Anwendungen ist sicherlich heute noch das WWW. Neben den klassischen reinen Datenanwendungen wie und FTP geht der Trend aber heute immer mehr hin zu multimedialen Anwendungen wie Telefonie und Videokonferenzen. Das Internet muß daher in Zukunft auch Anwendungen mit Audio- und Videokomponenten und deren Realzeitanforderungen unterstützen. Diese sollen mit den reinen Datenanwendungen im paketvermittelten Internet integriert werden. Hieraus resultieren Anforderungen hinsichtlich einer geeigneten Dienstgüteunterstützung für solche Anwendungen, die im Internet heute kaum bereitgestellt wird. Die Anforderungen von multimedialen Anwendungen an die vom Netz erbrachte Dienstgüte unterscheiden sich erheblich von denen, die keine Realzeitdienste realisieren. Während Anwendungen, die vor allem Daten zwischen den beteiligten Rechnern kopieren, einen zuverlässigen Dienst ohne Übertragungsfehler benötigen, spielt bei multimedialen Anwendungen die zeitliche Komponente der Übertragung eine entscheidende Rolle. Für die multimediale Echtzeitkommunikation müssen in der Regel eine bestimmte Mindestbandbreite und eine maximale Verzögerung sowie geringe Verzögerungsschwankungen garantiert sein. Wegen der maximalen Verzögerung, die aus der festen zeitlichen Differenz zwischen dem Senden der Daten und dem Abspielen beim Empfänger resultiert, kommt eine Übertragungswiederholung bei Paketverlusten und Übertragungsfehlern in vielen Fällen nicht in Frage. Als Konsequenz macht sich die Paketverlustrate deutlich als Qualitätsverlust beim Abspielen des multimedialen Datenstroms beim Empfänger bemerkbar. Im Gegensatz zu reinen Datenanwendungen sind aber Übertragungsfehler und fehlende Daten bis zu einem gewissen Maß tolerabel. Zu den Parametern der Dienstgüte gehört daher neben der Bandbreite, Verzögerung und Verzögerungsschwankung auch die Paketverlustrate. Um Realzeitanforderungen unterstützen zu können, sind jedoch neue Konzepte und Mechanismen im Internet notwendig, die heute noch weitgehend fehlen. Im derzeitigen Internet werden Daten im wesentlichen nach dem Best-Effort-Prinzip von den Routern weitergeleitet, d.h. je nach den momentan verfügbaren Ressourcen und dem Verkehrsaufkommen, das 7

20 8 Kapitel 2. Grundlagen um diese Ressourcen konkurriert, werden Pakete sofort, nach einem längeren Aufenthalt in einer Warteschlange oder evtl. gar nicht bedient, sondern verworfen. Die Unterstützung von Dienstgüteanforderungen durch Anwendungen erfordert die Reservierung der Ressourcen in allen Routern, die zur Erbringung der Dienstgüte notwendig sind, so daß diese, unabhängig von der aktuellen Last im Netz, zur Verfügung stehen. Für die Signalisierung der zu reservierenden Ressourcen muß ein Reservierungsprotokoll in den Routern implementiert werden. Um die Ressourcenreservierung zu ermöglichen, muß natürlich die Anwendung dem Netz mitteilen, wie die zu sendenden Daten aussehen und welche Ressourcen benötigt werden. Das Netz wird vor der Reservierung jedoch eine Zulassungskontrolle durchführen, um festzustellen, ob es genügend nicht-reservierte Ressourcen besitzt und in der Lage ist, die Anforderung der Anwendung zu erfüllen. Wird die Anforderung angenommen, sollte die geforderte Dienstgüte vom Netz auch garantiert oder wenigstens mit hoher Wahrscheinlichkeit erbracht werden. Anderenfalls muß die Dienstgüteanforderung vom Netz abgelehnt werden Reservierungsprotokolle Vor dem Datenaustausch, der eine bestimmte Dienstgüte verlangt, müssen die Ressourcen in allen Routern entlang des Pfades zwischen der Quelle und dem Ziel reserviert werden. Bei den zu reservierenden Ressourcen handelt es sich u.a. um Speicherplatz in den Warteschlangen sowie Prozessorzeit in den Routern und Bandbreite auf den Übertragungsleitungen. Ein Reservierungsprotokoll dient zum Austausch der Reservierungsinformationen zwischen den Endsystemen und beteiligten Routern. Mit Hilfe des Reservierungsprotokolls können Reservierungsaufbau beim Aufbau der Verbindung, Reservierungsabbau beim Ende der Verbindung und Reservierungsänderungen für bestehende Verbindungen signalisiert werden. Als Reservierungsprotokolle werden z.b. das Stream Protocol Version 2 (ST-2) [83, 111] und das ResourceReservation Protocol (RSVP) [108, 83, 111] im Internet verwendet Zulassungskontrolle Vor der Annahme einer Reservierungsanforderung ist eine Zulassungskontrolle notwendig. Sie entscheidet, ob für den Zeitraum der gewünschten Reservierung genügend Ressourcen vorhanden sind, um die Anforderung dieser neuen Verbindung zu erfüllen. Die Zulassungskontrolle liefert eine positive oder eine negative Antwort an die anfragende Anwendung, nimmt also die Reservierung an oder lehnt sie ab. Bei der Überprüfung müssen die vorhandenen Ressourcen auf jedem Router entlang des Pfades der aufzubauenden Verbindung berücksichtigt werden. Das schließt aber nicht nur die Bandbreite und Pufferkapazitäten in den einzelnen Routern ein, sondern auch die darunterliegende Vermittlungsschicht. Im Falle einer Vermittlungsschicht, die selbst Dienstgüteunterstützung anbietet, sind die Router dafür verantwortlich, die für die laufende Reservierung notwendigen Ressourcen von der darunterliegenden Vermittlungsschicht anzufordern. Nur wenn die Vermittlungsschicht in der Lage ist, diese Reservierungen vorzunehmen, wird der Router seinerseits die von ihm verwalteten Ressourcen reservieren und die Reservierungsanfrage bestätigen. Außer der Zulassungskontrolle beim Aufbau einer Verbindung ist jedoch auch eine Zulassungskontrolle während der gesamten Lebensdauer der Verbindung auf Basis einzelner Pakete erforderlich. Es muß für die Pakete, welche die reservierten Ressourcen in Anspruch nehmen wollen, überprüft werden, ob sie die Berechtigung dazu haben, also wirklich vom Nutzer der Reservierung stammen, und ob sie mit dem für die Reservierung ausgehandel-

21 2.1. Dienstgüteunterstützung in Netzen 9 ten Verkehrsvertrag konform sind. Dazu muß der Ressourcenverbrauch für die Verbindung protokolliert werden. Nicht-konforme Pakete können verworfen, mit einer entsprechenden Markierung versehen oder verzögert werden Scheduler Alle Pakete, die einen Router erreichen, werden nach der Routing-Entscheidung zunächst in eine von evtl. mehreren Warteschlangen eingefügt, wo sie auf die weitere Bearbeitung warten. Ein Scheduler wählt diejenige Warteschlange, aus der das nächste Paket gelesen werden soll, bzw. das nächste Paket innerhalb einer Warteschlange, um es auf die entsprechende Ausgangsübertragungsleitung zu schicken. Ein traditioneller Router, der nur den Best-Effort-Dienst unterstützt, kann mit einer einfachen FIFO-Warteschlange implementiert werden. Für Router, die Dienstgüteanforderungen unterstützen sollen, sind diese einfachen Verfahren nicht geeignet. Es sind stattdessen Scheduler zu implementieren, die die Dienstgütegarantien gegenüber der Anwendung und die dafür reservierten Ressourcen berücksichtigen. Dazu müssen Pakete verschiedener Verbindungen erkannt oder getrennte Warteschlangen verwaltet werden Traffic Shaping Wie in Abschnitt erläutert, müssen Pakete einer Zulassungskontrolle unterzogen werden und im Falle einer Verletzung des Verkehrsvertrages besonders behandelt werden. Neben dem Markieren und Verwerfen von Paketen können Pakete auch verzögert werden, um den gesamten Datenstrom in Einklang mit dem Verkehrsvertrag zu bringen. Diese Aufgabe wird von einem sogenannten Traffic Shaper wahrgenommen. Im Traffic Shaper werden Pakete in einer kurzen Warteschlange gehalten, falls das Versenden der letzten Pakete erst kurz zurückliegt und ein sofortiges Weiterleiten die vereinbarte Senderate überschreiten würde. Die Warteschlange in einem Traffic Shaper wird üblicherweise sehr klein dimensioniert, um keine langen Wartezeiten für die nachfolgenden Pakete zu verursachen. Ist die Warteschlange voll, weil mehrere Pakete in zu kurzer Folge ankommen, müssen Pakete verworfen werden. Traffic Shaper lassen sich beispielsweise mit Token Bucket Filtern implementieren, die im nächsten Abschnitt beschrieben werden Token Bucket Ein Token Bucket oder auch Token Bucket Filter ist ein Netzwerkelement, mit dessen Hilfe sowohl Admission Control als auch Traffic Shaping realisiert werden kann. Ein Token Bucket läßt sich nämlich zum Messen der Bandbreite eines Datenstroms sowie zum Begrenzen der Bandbreite einsetzen. In beiden Fällen arbeitet der Token Bucket Filter sehr ähnlich. In einen Behälter (Bucket) einer festgelegten Größe werden sogenannte Tokens gesammelt, die mit einer fest eingestellten Rate erzeugt werden. Die Parameter eines Token Bucket Filters sind also die Token-Rate und die Größe des Buckets (siehe auch Abbildung 2.1). Kommt ein Paket am Token Bucket Filter an, wird festgestellt, ob ein Token im Bucket vorhanden ist. Ist das der Fall, darf das Paket den Token Bucket Filter ohne Verzögerung passieren. Das Token, das von diesem Paket verbraucht wurde, wird dabei aus dem Bucket entfernt. Anderenfalls hängt das Verhalten des Token Bucket Filters davon ab, ob er zum Messen oder zum Traffic Shaping benutzt werden soll:

22 10 Kapitel 2. Grundlagen r b Abbildung 2.1: Token Bucket Filter t(b, r) Soll der Datenstrom gemessen werden, wird das Paket sofort weitergeleitet, aber vorher mit einer Markierung versehen. Diese Markierung zeigt an, daß für dieses Paket nicht genügend Tokens im Bucket vorhanden waren, also das Paket die eingestellte Rate überschritten hat. Diese Markierung kann an anderer Stelle zur Entscheidung über zu verwerfende Pakete herangezogen werden. Ein zum Traffic Shaping eingesetzter Token Bucket Filter verzögert das Paket bis zum Eintreffen des nächsten Token oder verwirft es. Die Paketrate ist über einen längeren Zeitraum also durch die Token-Rate begrenzt. Für jedes weitergeleitete Paket bzw. für jedes unmarkiert weitergeleitete Paket muß ein Token vorhanden sein. Dadurch kann die Paketrate die Token-Rate nicht dauerhaft überschreiten. Kurzfristige Überschreitungen der Token-Rate sind möglich, wenn der Token Bucket nach einer Zeit mit geringer Paketrate mehr als ein Token enthält. Durch die begrenzte Größe des Bucket ist aber auch die Größe solcher Bursts von Paketen beschränkt. Statt ein Token für die Weiterleitung eines Paketes zu verlangen und bei Weiterleitung zu löschen, kann der Token Bucket Filter auch so implementiert werden, daß pro Byte des Paketes ein Token vorhanden sein muß bzw. gelöscht wird. Es wird dann nicht die Paketrate, sondern die Datenrate, und zwar in Bytes pro Sekunde, gemessen bzw. begrenzt. 2.2 Integrated Services und RSVP In der IETF wurden schon Anfang der 90er Jahre Arbeiten zur Ressourcen-Reservierung im Internet durchgeführt. Im Juni 1994 wurde der RFC 1633 [18] mit dem Titel Integrated Services in the Internet Architecture: an Overview veröffentlicht. Dieser RFC beschreibt ein Konzept zur Integration von Diensten mit verschiedenen Anforderungen im Internet durch Reservierung von Ressourcen. Er beschreibt außerdem das Resource Reservation Protocol (RSVP) zum Austausch von Reservierungsnachrichten. RSVP ist für die Kommunikation mit Dienstgüteunterstützung einer Multicast-Gruppe entwickelt worden, d.h. ein Datenstrom eines Senders an alle Empfänger der Multicast-Gruppe erhält durch Reservierungen in allen Zwischensystemen die geforderte Dienstgüte.

23 RESV 2.2. Integrated Services und RSVP 11 RSVP ist empfängerorientiert, weil die Empfänger der Multicast-Gruppe Reservierungsnachrichten an die Router senden, um Reservierungen für den empfangenen Datenstrom anzufordern. Der Ablauf der Signalisierung ist in Abbildung 2.2 dargestellt. Vor der Reser- Receiver PATH Sender PATH RESV Router Receiver PATH RESV PATH RESV Router Receiver Receiver Abbildung 2.2: Ressourcenreservierung mit RSVP vierung durch die Empfänger schickt der Sender PATH-Nachrichten an die Multicast-Gruppe. In der PATH-Nachricht beschreibt der Sender die Eigenschaften seines Datenstroms. Die Beschreibung des Datenstroms umfaßt die Rate und die Burst-Eigenschaften des Verkehrs, die in der Traffic Specification Tspec festgehalten werden. Diese Parameter sind geeignet, die Token Bucket Filter in den Routern für diesen Datenstrom zu parametrisieren. Nachdem die Empfänger die PATH-Nachricht vom Sender erhalten haben, können sie entscheiden, ob sie den darin beschriebenen Datenstrom empfangen wollen und welche Ressourcen sie dafür in den Routern anfordern wollen. Sie schicken eine RESV-Nachricht zum nächsten Router auf dem Weg zum Sender. Diese Nachricht enthält auch eine Verkehrsbeschreibung FlowSpec, die den gleichen Aufbau wie der TSpec des Senders besitzt. Der FlowSpec gibt die Ressourcen an, die der Empfänger für den Datenstrom auf dem Weg innerhalb des Multicast-Baums, der zu ihm führt, reservieren möchte. Der Router entscheidet, ob die geforderten Ressourcen zur Verfügung stehen und für diesen Datenstrom reserviert werden können. Der Router kann auch weitere RESV-Nachrichten von anderen Empfängern in anderen Teilbäumen des gesamten Multicast-Baums erhalten. Die Reservierungsnachrichten verschiedener Empfänger können unterschiedlich hohe Ressourcenanforderungen besitzen. Der Router führt für die Nachrichten aller Empfänger die gleichen Überprüfungen durch. Können eine oder mehrere dieser Reservierungen vorgenommen werden, berechnet der Router das Maximum aller geforderten und akzeptierten Reservierungen und leitet eine entsprechende RESV-Nachricht an den nächsten Router in Richtung Sender. Gleichzeitig reserviert er die Ressourcen für die Daten der Multicast-Kommunikation. Erreicht schließlich eine RESV-Nachricht vom letzten Router den Sender, enthält sie das Maximum aller geforderten und verfügbaren Ressourcen, die in den Routern reserviert werden können. Der Sender kann nun optional eine Bestätigung an die Multicast-Gruppe geben. Daten, die der Sender nun an die Multicast-Gruppe sendet, erfahren in den Routern auf dem Weg zu den Empfängern eine besondere Behandlung. Die Pakete des Datenstroms werden anhand von

24 12 Kapitel 2. Grundlagen Quell- und Zieladressen sowie von Portnummern als zu dem Datenstrom gehörig erkannt, für den die Reservierungen vorgenommen wurden. Zu diesem Zweck müssen alle vorgenommenen Reservierungen durchsucht werden. RSVP ist ein Soft-State-Protokoll. In den Routern werden für jede Verbindung, für die Ressourcen reserviert wurden, Informationen über die Verbindung gespeichert. Diese Informationen müssen aber regelmäßig durch neue Reservierungsnachrichten aufgefrischt werden. Bleiben die Reservierungsnachrichten zu lange aus, werden die Reservierungsinformationen im Router gelöscht und die Ressourcen freigegeben. Zu diesen Informationen gehören die reservierten Ressourcen und der Zustand eines Token Bucket Filters, mit dem die Nutzung von Ressourcen auf Konformität mit der Reservierung geprüft wird. Der Token Bucket Filter wird mit den Parametern aus dem FlowSpec-Feld der RESV-Nachricht konfiguriert. In der IETF wurden verschiedene Dienstgüteklassen für Integrated Services diskutiert, von denen zwei in RFCs spezifiziert wurden. Diese werden in den beiden nächsten Abschnitten kurz behandelt Guaranteed Service Für Anwendungen mit sehr harten Anforderungen an die Dienstgüte des Netzes wurde der Guaranteed Service entwickelt. Dieser Dienst bietet eine Mindestbandbreite und enge Grenzen für die Ende-zu-Ende-Verzögerung. Die Anwendung muß dazu in der Reservierungsnachricht nicht nur die Parameter (r, b) für den Token Bucket, also mittlere Datenrate und Größe des Token Bucket angeben, sondern auch die maximale Bandbreite p (peak rate) und die maximale Paketgröße des Datenstroms. Damit kann der Router die notwendigen Ressourcen ermitteln und reservieren. Um die zugesicherte Dienstgüte garantieren zu können, muß der Router eine Bandbreite auf der Ausgangsleitung reservieren, die mindestens so groß wie die maximale Bandbreite des Datenstroms ist. Reserviert er eine Bandbreite, die zwischen der mittleren und der maximalen Bandbreite des Datenstroms liegt, kann eine höhere, aber immer noch feste Grenze für die Ende-zu-Ende-Verzögerung eingehalten werden. Der Guaranteed Service ist in RFC 2212 [87] beschrieben Controlled-Load Service In RFC 2211 [109] ist der Controlled-Load Service spezifiziert, der wesentlich schwächere Garantien bezüglich der Dienstgüte gibt als der Guaranteed Service. Ein Datenstrom, für den der Controlled-Load Service vereinbart wurde, ist Paketverlusten und Verzögerungen unterworfen, die denen von Best-Effort, allerdings bei niedriger Netzlast, entsprechen. Im Gegensatz zu Best-Effort bleibt aber die Dienstgüte beim Controlled-Load Service weitgehend erhalten, d.h. Verzögerung und Paketverluste steigen nur unwesentlich, wenn die Last im Netz steigt. Damit ist dieser Dienst geeignet für Anwendungen, die zwar Echtzeitbedingungen unterliegen, sich aber in einem gewissen Rahmen der aktuellen Netzlast anpassen können. 2.3 Differentiated Services In der IETF wurde das Integrated-Services-Konzept entwickelt, das in 2.2 beschrieben wurde. Das Ziel von Integrated Services besteht darin, unterschiedliche Dienste mit unterschiedlichen Dienstgüteanforderungen im paketvermittelten Internet zu integrieren. Dazu ist eine Ressourcenverwaltung in den Routern sowie ein Signalisierungsprotokoll zum Austausch der