Motivation. Dienstgütearchitekturen im Internet. Frühere Ansätze: IP-Type of Service. "Traditionelle" Anwendungen. Problem. Themen

Transkript

1 Themen Dienstgütearchitekturen im Internet Erste Ansätze Precedence-Feld in IP, ST-II Integrated Services Ressourcen werden dediziert für individuelle Datenströme bereitgestellt Architektur, Signalisierungsprotokoll RSVP, Dienste Differentiated Services Es werden nur aggregierte Reservierungen von Ressourcen betrachtet Architektur, Dienste Problemfelder Management, Sicherheit, Abrechnung Problem Motivation Die grundlegenden Protokolle im Internet bieten keine Unterstützung für Dienstgüten an. Diese werden aber für Realzeit-Anwendungen benötigt (z.b. Multimedia-Konferenzen, IP-Telefonie...) bit IP und Dienstqualität Das Feld Type-of-Service (TOS) kann verwendet werden zur Beschreibung von Anforderungen an die Übertragung Vorrang: verschiedene Prioritäten Verzögerung: normale (0), niedrig (1) Durchsatz: normal (0), hoch (1) Zuverlässigkeit: normal (0), hoch (1) Es können mit IP keine Dienstgarantien gegeben werden. Vorrang Verzöge- Durchrunsatz Zuverlässigk. 0 0 Next Generation Internet SoSe03 72 Next Generation Internet SoSe03 73 Version Frühere Ansätze: IP-Type of Service Bit Nr Lebenszeit (Time-to-Live) Priorität (Precedence) Ver- Zuverzögerunsatkeit Durch-lässig- Reserviert Kopflänge Diensttyp (IHL) (Type of Service ToS) Identifikation (Identifikation) Schalter (Flags) Protokoll (Protocol) Quelladresse (Source Address) Zieladresse (Destination Address) Nutzdaten (Payload) 1981 RFC RFC 1349: + Kostenmininierung, nur 1-aus-4-Auswahl, Wegewahl entspr. Gesamtlänge (Total Length) Sprunggrenze (Hop Limit) Kopfprüfsumme (Header Checksum) Next Generation Internet SoSe03 74 Füllzeichen (Padding) 31 "Traditionelle" Anwendungen Elastische Anwendungen Hier sind keine Zeitgarantien für die Auslieferung der Daten erforderlich. Die Verzögerungsanforderungen unterschiedlicher elastischer Anwendungen können stark variieren. Elastische Anwendungen repräsentieren traditionelle Anwendungen, wobei die folgenden drei Kategorien unterschieden werden. Interaktiv (z.b. Telnet) Interaktiv stoßartig (bursty) (z.b. FTP) Asynchron (z.b. ) Charakterisierend ist die Tatsache, dass keine obere zeitliche Grenze für die Auslieferung der Daten vorhanden ist. Elastische Anwendungen lassen sich dadurch charakterisieren, dass die Daten durch längere Verzögerungszeiten nicht unbrauchbar werden. Sie können damit problemlos im heutigen Internet realisiert werden. Welche Probleme haben nicht elastische Anwendungen? Next Generation Internet SoSe03 75

2 Echtzeit-Anwendungen Problem Echtzeit-Anwendungen stellen zeitliche Anforderungen an die Auslieferung der Daten. Echtzeit-Anwendungen Hier im Wesentlichen Audio- und Videodatenströme betrachtet Echtzeit-Anwendungen in der Fabrikautomatisierung weitere Anwendungen Audio- und Videoanwendungen Redundanz Aus der redundanten Information resultiert eine gewisse Toleranz hinsichtlich Datenverlusten. Zu spät eintreffende Daten stellen in diesem Sinne auch Verluste dar. Adaptivität Verzögerungsadaptivität: Pufferschranke kann sich zum Beispiel an der mittleren Verzögerungszeit im Netz orientieren. Ratenadaptivität: Videoapplikationen können z.b. die Bitrate zugunsten der Qualität senken. Abtastung A/D- Wandler Verzögerungszeit Puffer D/A- Wandler Next Generation Internet SoSe03 76 Dienstgarantien? Von "Internet-Gurus" werden häufig folgende Argumente gegen die Notwendigkeit von Dienstgarantien aufgelistet "Unendliche" Bandbreite Man geht davon aus, dass die im Internet verfügbare Bandbreite immer so hoch sein kann, dass alle Benutzer bedienbar sind Aber: Kosten für Netzdienste hängen eng mit der Bandbreite zusammen und werden hier nicht erwähnt / Zugangsbereich? Einfache Prioritäten sind ausreichend Mit Prioritätsstufen können unterschiedliche Dienstanforderungen berücksichtigt werden. Aber: Flexiblere Regelungsmöglichkeiten sind erforderlich, beispielsweise für alle Jobs auf der höchsten Prioritätsebene. Adaptive Applikationen Adaptive Anwendungen können sich an die aktuellen Gegebenheiten im Netz anpassen. Aber: Verzögerung im Netz muss für interaktive Anwendungen begrenzt werden. Kostenfaktor muss hier ebenfalls berücksichtigt werden. Next Generation Internet SoSe03 77 Frühere Ansätze: Internet Stream Protocol 1979 J. Forgie ST A proposed Internet Stream Protocol zur Unterstützung von Sprache, Video, verteilten Simulationen 1990 Internet Stream Protocol, Version 2 (STII) 1995 ST2+ Separates Protokoll neben IP, verbindungsorientiert Schlechte Skalierungseigenschaften für große Gruppen (Sender bestätigt immer Beitritt) Zustandsverwaltung der virtuellen Verbindungen Konnte sich nicht etablieren Integrated Services Mitte der 90er Jahre: Architektur für Integrierte Dienste Unterstützung multimedialer Anwendungen Abkehr vom zustandslosen : Zustand je Datenstrom besondere Behandlung der Pakete wie in Profil abgelegt Erhalten der Robustheit durch Soft State -Reservierung Ergänzung der bestehenden Internet-Architektur Integration gruppenkommunikationsbasierter Anwendungen Next Generation Internet SoSe03 78 Next Generation Internet SoSe03 79

3 Dienstgütemodell der Integrated Services Integrated Services: Anwendungsklassen Die folgenden Dienste stehen zur Verfügung Nicht echtzeitfähige Dienste Best-Effort Echtzeitdienste Controlled Load Service Simulation eines unbelasteten Netzes. Guaranteed Service Math. nachweisbare Begrenzung der Verzögerung in n. Grundlegende Annahme Ressourcen müssen explizit verwaltet werden, um Dienstanforderungen einhalten zu können. Schlüssel-Bausteine für die Bereitstellung von Echtzeitdiensten sind Ressourcenreservierung in den involvierten Systemen und Zugangskontrolle zu den Ressourcen Verfahren zur Vergabe der Ressourcen erforderlich unter Beachtung von Authentifizierung von Benutzern Authentifizierung von Dateneinheiten Guaranteed Service Intolerant gering Echtzeit Nicht Adaptiv Tolerant Verzögerung Anwendungen Controlled Load Adaptiv Rate Interaktiv, stoßweise gering hoch Toleranz der Verzögerungschwankung Elastisch Interaktiv, Asynchron, Massendaten Massendaten hoch Toleranz der Verzögerung Next Generation Internet SoSe03 80 Next Generation Internet SoSe03 81 Controlled Load Services RFC 2211 Guaranteed Quality of Service I RFC 2212 Charakteristika Approximieren Dienst in unbelasteten Netzen. Ein hoher Prozentsatz von Dateneinheiten wird korrekt ausgeliefert. Die tatsächlich erfahrene Übertragungsverzögerung wird die minimale Verzögerung nur unwesentlich überschreiten. Tspec (Traffic Specification) Muss durch Zugangskontrolle gesichert werden. Spezifikation eines Token-Buckets Rate r (1 byte/sec Tbyte/sec) und Bucket-Tiefe b (1 byte Gbyte) Maximale Rate (peak rate) p Minimale policed Einheit m Maximale Größe der Dateneinheiten M Implementierungsbeispiele: data Zwei Prioritäten: hohe Priorität für Controlled-Load Verkehr, niedrige Priorität für Best-Effort Verkehr. Anwendungen: solche, die sensibel auf Netzüberlastung reagieren. Z.B. für Videoübertragung r b Charakteristika TSpec Garantierte Verzögerungs-Begrenzung (inkl. Warteschlangen) und Bandbreite. Keinerlei Garantien hinsichtlich Jitter. Unabhängig von der Etablierung (z.b. durch RSVP). Token bucket: Rate r und Bucket-Tiefe b Maximale Rate (peak rate) p Minimale policed Einheit m Maximale Größe der Dateneinheit M RSpec (Reservation Specification) Gewünschte Datenrate R Slack term S Definiert den Unterschied zwischen der gewünschten Verzögerung und der erfahrenen Verzögerung. Next Generation Internet SoSe03 82 Next Generation Internet SoSe03 83

4 Guaranteed Quality of Service II Ressourcenverwaltung Verkehrskontrolle Zugangskontrolle Policing An den Zugangsknoten der Netze. Shaping An allen heterogenen Verzweigungs- und Merge-Punkten im Verteilbaum. Beispiel Zugangskontrolltest beim Verbindungsaufbau ausreichend Kapazität für neue Verbindung? keine Verletzung bestehender Garantien! Reservierung der Ressourcen beim Verbindungsaufbau Zuteilung der Ressourcen beim Datentransfer (z.b. Zuteilung des Prozessors durch Scheduler) Anwendungen Audio- und Videoströme Freigabe der Ressourcen beim Verbindungsabbau Next Generation Internet SoSe03 84 Next Generation Internet SoSe03 85 Erforderliche Komponenten Dienstgüteaushandlung bei Multicast Scheduler Ist an der Warteschlange für zu sendende Daten (typischerweise Treiberebene des Betriebssystems) lokalisiert. Unterschiedliche Scheduling-Algorithmen sind möglich, z.b. FIFO, WFQ,... D min = 1 Mbit/s D max = 50 Mbit/s Sender 5, 10 1, 50 Empfänger 1 D min = 5 Mbit/s D max = 10 Mbit/s Klassifizierer Jede empfangene Dateneinheit muss einer Klasse zugeteilt werden. Eine Klasse ist eine lokale Abstraktion eines s. Eine Dateneinheit kann auf verschiedenen n in unterschiedliche Klassen eingeordnet werden. 20, 40 Empfänger 2 D min = 20 Mbit/s D max = 40 Mbit/s Zugangskontrolle Entscheidungsalgorithmus für die Zulassung neuer Daten mit Dienstanforderungen. Bestehende Dienstgarantien dürfen nicht beeinflusst werden. Signalisierungsprotokoll für Reservierungen Signalisiert Dienstanforderungen an involvierte Systeme (Zwischensysteme im Netz). Bei mehreren Empfängern kann es während der Dienstgüteaushandlung zu Konflikten kommen. Konfliktauflösung beim Sender gemäß der gewählten Gruppensemantik. Abweisung des Verbindungsaufbauwunsches. Ablehnung eines einzelnen Empfängers. Aufbau der Multicast-Verbindung mit unterschiedlicher Dienstgüte (erfordert entsprechende Unterstützung des Kommunikationssystems). Next Generation Internet SoSe03 86 Next Generation Internet SoSe03 87

5 Unterschiedliche Dienstgüten für Multicast-Verbindungen Gemeinsame Nutzung von Ressourcen Station A Farbe Empfänger 1 Sender Farbe Station C Monochrom Empfänger 2 Station B Datenfluss von Sender A Datenfluss von Sender B Filtern eines Datenstromes in Zwischensystemen ermöglicht die Bereitstellung unterschiedlicher Dienstgüten für eine Multicast-Verbindung. Das Filtern erfordert eine hierarchische Kodierung der Benutzerdaten, z.b. MPEG-kodierte Videoströme (MPEG-2) Trennung von Film- und zusätzlicher Farb-Information Filtern ermöglicht die effiziente Nutzung von Betriebsmitteln durch eine "maßgeschneiderte" Reservierung Filtern ermöglicht Konfliktauflösung bei Dienstgüteaushandlung Abhängig von der Kommunikationsbeziehung zwischen den Teilnehmern können reservierte Ressourcen gemeinsam genutzt werden. Beispiel: Audio-Konferenz: zu einem Zeitpunkt ist meist nur ein Sprecher aktiv Ressourcen werden nur einmal reserviert, können jedoch von allen Sprechern genutzt werden Next Generation Internet SoSe03 88 Next Generation Internet SoSe03 89 Das Signalisierungsprotokoll RSVP Grundlegende Konzepte Ziel Signalisierung von Reservierungsanforderungen in IP-basierten Netzen. Datentransfer findet weiterhin über IP statt. Konzept Empfängerbasierte Signalisierung von Reservierungsanforderungen für unidirektionalen Datenfluss. Unterstützung heterogener Dienstqualität, d.h. unterschiedliche Empfänger können verschiedene Dienstqualität erfahren. Unterstützt Multicast-Kommunikation Unterstützung verschiedener Reservierungsstile. Soft-States Empfänger erhält keine Quittung für die Reservierung. Kein expliziter Abbau der Reservierungen erforderlich. Jeder Reservierung ist ein Zeitgeber zugeordnet nach dessen Ablauf die Reservierung gelöscht wird. Session eine Menge von Datenströmen mit dem gleichen Ziel (Multipeer). Definiert durch: Ziel-IP-Adresse, Ziel-Protokoll-Kennung, Ziel-Port. Reservierungsanforderung Wird vom Zielsystem gesendet und als Flow Descriptor bezeichnet. Sie besteht aus FlowSpec Beschreibt die gewünschte Dienstqualität. Der Inhalt der FlowSpec ist nicht Gegenstand von RSVP. FilterSpec Beschreibt, welche Dateneinheiten einer Session die Reservierungen nutzen dürfen. Durch die Unterscheidung von FlowSpec und FilterSpec findet eine explizite Trennung von Reservierung und Nutzung der Ressourcen statt. Next Generation Internet SoSe03 90 Next Generation Internet SoSe03 91

6 RSVP: Nachrichtenaustausch Sender PATH RESV Daten Verschmelzung RESV Empfänger 1 PATH Empfänger 2 Sender schicken periodisch PATH-Dateneinheiten und bauen damit einen Verteilbaum auf. PATH-Dateneinheiten enthalten Information über den gesendeten Datenstrom (z.b. Dienstqualität). Empfänger schicken periodisch RESV-Dateneinheiten zur Reservierung der Ressourcen in Rückwärtsrichtung entlang des aufgebauten Verteilbaumes. Reservierungswünsche verschiedener Empfänger werden in n zu einem neuen Reservierungswunsch verschmolzen, der in Richtung zum Sender weitergeleitet wird. Heterogener Multicast mit RSVP Barny MPEG (25 Bilder/s) Dino- MPEG (5 Bilder/s) MPEG (25 Bilder/s) Umsetzung des MPEG-Stroms Pebbles Beispiel für heterogene Anforderungen Fred fordert MPEG-Video mit 5 Bildern/s Pebbles fordert MPEG-Video mit 25 Bildern/s Im Knoten Dino- erfolgt eine Umsetzung des Datenstroms. Die Umsetzung des Datenstroms ist nicht Bestandteil von RSVP. RSVP dient lediglich der Signalisierung. Fred Gruppe BarnyShow Next Generation Internet SoSe03 92 Next Generation Internet SoSe03 93 Integrated Services: -Modell Nachrichten Daten Routing Prozess Integrated Services RSVP Prozess Gute Isolation der Datenströme voneinander Vorhersagbare (berechenbare) Ende-zu-Ende-Garantie Aber: Skalierbarkeitsproblem aufgrund datenstromspezifischer Zustände politikbasierte Zugangskontrolle Klassifizierer Paketzuteiler ressourcenbasierte Zugangskontrolle Kontrollebene Datenpfad Nachrichten Reservierungen In der FilterSpec werden verschiedene Reservierungsstile unterschieden hinsichtlich der folgenden Aspekte: Speziell für jeden Sender oder gemeinsam für alle Sender explizite Kontrolle der Sendermenge oder alle Sender erlaubt Die Reservierungsstile in RSVP Fixed Filter: dedizierte Reservierungen für einen speziellen Sender Shared-Explicit Filter: gemeinsame Ressourcennutzung durch eine ausgewählte Sendermenge (Beispiel: Audioübertragung) Wildcard Filter: gemeinsame Ressourcennutzung durch alle Sender Unterschiedliche Filter können nicht verschmolzen werden. Reservierungen Kontrolle Explizit Wildcard Speziell Gemeinsam Fixed-Filter Shared-Explicit... Wildcard-Filter Next Generation Internet SoSe03 94 Next Generation Internet SoSe03 95

7 Fixed-Filter Beispiel Verschmelzen von Filtern Die maximale Anforderung pro Sender muss reserviert und in dessen Richtung weitergeleitet werden. Richtung, S 2 {4B} {3B}) Zwischensystem E 1 {4B} S 2 {3B} S 3 {5B} A 1 {2B} {3B}) {4B} {5B}) Verschmelzen von Filtern Shared-Filter Reservierungen können gemeinsam genutzt werden, müssen also nicht für jeden Datenstrom in Richtung eines Senders getrennt durchgeführt werden. Beispiel Zwischensystem SF(( ){2B}) {5B} SF(( ){5B}) SF(( ){5B}) Richtung, S 2 E 1 A 1 Richtung S 3 FF(S 3 {5B}) E 2 {3B} S 2 {2B} S 3 {4B} A 2 {3B} {2B} {4B}) Richtung S 3 SF(S 3 {5B}) {4B} E 2 A 2 SF(( ){4B}) FF: Fixed-Filter S i : Sender i SF: Shared-Filter S i : Sender i Next Generation Internet SoSe03 96 Next Generation Internet SoSe03 97 Verschmelzen von Filtern Wildcard-Filter Beispiel Reservierungen sind keiner Sendergruppe zugeordnet. Richtung, S 2 WF(*{5B}) Zwischensystem E 1 *{5B} A 1 WF(*{5B}) WF(*{3B}) Richtung S 3 WF(*{5B}) E 2 *{5B} A 2 WF(*{2B}) WF: Wildcard-Filter S i : Sender i Next Generation Internet SoSe03 98