Kapitel 7 Multimedia Netzwerke

Transkript

1 Kapitel 7 Multimedia Netzwerke Ein Hinweis an die Benutzer dieses Foliensatzes: Wir stellen diese Folien allen Interessierten (Dozenten, Studenten, Lesern) frei zur Verfügung. Da sie im PowerPoint-Format vorliegen, können Sie sie beliebig an Ihre Bedürfnisse anpassen. Wir haben sehr viel Arbeit in diesen Foliensatz investiert. Als Gegenleistung für dessen Verwendung bitten wir Sie um Folgendes: Wenn Sie diese Folien (z.b. in einer Vorlesung) verwenden, dann nennen Sie bitte die Quelle (wir wollen ja, dass möglichst viele Menschen unser Buch lesen!). Wenn Sie diese Folien auf einer Webseite zum Herunterladen anbieten, dann geben Sie bitte die Quelle und unser Copyright an diesem Foliensatz an. Danke und viel Spaß beim Lehren und Lernen mit diesem Foliensatz! JFK/KWR Copyright der englischen Originalfassung J.F Kurose and K.W. Ross, alle Rechte vorbehalten. Deutsche Übersetzung 2008 M. Mauve und B. Scheuermann, alle Rechte vorbehalten. Computernetzwerke: Der Top-Down-Ansatz, 4. Ausgabe. Jim Kurose, Keith Ross Pearson, Juli Computernetzwerke Mark Felegyhazi, CrySyS Lab, Department of Networked Systems and Services (HIT), BME 7-1

2 Was ist Dienstgüte/Quality of Service (QoS)? Multimedia-Anwendungen: Audio- und Videoübertragung ( kontinuierliche Medien ) QoS Netzwerk liefert die Dienstgüte, welche für die jeweilige Anwendung notwendig ist. 7 2

3 Ziele dieses Kapitels Grundlagen Klassifikation von netzwerkbasierten Multimedianwendungen Bestimmen der Netzwerkdienste, die für die Anwendungen benötigt werden Best-Effort -Dienste optimal ausnutzen Protokolle und Architekturen Protokolle für Best-Effort-Netzwerke Mechanismen, um QoS bereit zu stellen Architekturen zur Bereitstellung von QoS 7 3

4 Multimedia-Netzwerke 7.1 Multimediale Netzwerkanwendungen 7.2 Streaming von gespeichertem Audio/Video 7.3 Best-Effort-Dienste optimal nutzen 7.4 Anbieten von mehreren Dienstklassen 7.5 Dienstgütegarantien anbieten 7.6 Protokolle für interaktive Echtzeit-Anwendungen: RTSP, RTP, RTCP, SIP Computernetzwerke Mark Felegyhazi, CrySyS Lab, Department of Networked Systems and Services (HIT), BME 7-4

5 Netzwerkbasierte Multimedianwendungen Verschiedene Klassen: Streaming von gespeichertem Audio/Video Streaming von Live- Audio/Video Interaktives Audio/Video Neues Kriterium: Jitter (Verzögerungsschwankung) Bezeichnet die Schwankung der Verzögerung zwischen Sender und Empfänger. Zentrale Eigenschaften: Die Übertragungsverzögerung spielt eine wichtige Rolle Ende-zu-Ende-Verzögerung Jitter Aber: tolerant gegenüber Paketverlusten! Seltene Verluste beeinträchtigen die Qualität der Anwendung nur geringfügig. Das ist ganz anders als in der gewöhnlichen Daten-kommunikation! 7-5

6 Streaming von gespeichertem Audio/Video Streaming: Audio/Video ist auf einem Server gespeichert...und wird zu einem Client übertragen Streaming: der Client beginnt mit dem Abspielen, bevor die vollständigen Daten übertragen wurden Anforderung: Daten müssen beim Client ankommen, bevor dieser sie zum Abspielen benötigt 7 6

7 Streaming: Wie funktioniert das? Kumulierte Daten 1. Video wird aufgezeichnet 2. Video wird übertragen Netzwerkverzögerung 3. Video wird empfangen und abgespielt Zeit Streaming: der Client spielt das Video bereits ab, während der Server immer noch weitere Teile des Videos an den Client überträgt. 7 7

8 Streaming: Interaktivität beim Abspielen Funktionalität eines Videorekorders: Pause, Zurückspulen, schneller Vorlauf, schneller Rücklauf Kontrolliert durch den Client 10 Sekunden initiale Verzögerung für das Abspielen 1-2 Sekunden, bis ein Befehl ausgeführt wird Häufig verwendet: RTSP (mehr dazu später) Schneller Vorlauf nicht möglich, Rücklauf und Pause sind möglich 7 8

9 Interaktive Echtzeit-Multimediaanwendungen Anwendungen: IP-Telefonie Videokonferenz Voicechat Verteilte VR-Anwendungen / Online-Spiele Anforderungen an die Ende-zu-Ende-Verzögerung: Audio: < 150 ms gut, < 400 msec OK Netzwerk- und Anwendungsverzögerung Höhere Verzögerungen stören! Fragen zum Aufbauen einer Sitzung Woher kennt der Anrufer IP-Adressen, Port Nummern, Mediencodierung? Computernetzwerke Mark Felegyhazi, CrySyS Lab, Department of Networked Systems and Services (HIT), BME 7 9

10 Multimedia über das Internet TCP/UDP/IP: Best-Effort-Dienste keine Garantien bezüglich Verzögerung oder Verlusten??????? Aber wir haben doch eben gesehen, dass Multimedia Dienstgüte benötigt???? Aktuelle Multimedia-Anwendungen verwenden Techniken auf der Anwendungsschicht, um die Auswirkungen von Verzögerungen und Verlusten zu minimieren Computernetzwerke Mark Felegyhazi, CrySyS Lab, Department of Networked Systems and Services (HIT), BME 7 10

11 Wie soll das Internet für Multimedia sich entwickeln? Overprovisioning Keine signifikanten Änderungen Bei Problemen: mehr Bandbreite Content Distribution schlaue Anwendungen Integrated Services: Grundlegende Änderungen, so dass Anwendungen Ende-zu-Ende Reservierungen durchführen können Erfordert neue und komplexe Software in Endsystemen und Routern Differentiated services: Wenige, leichtgewichtige(re) Änderungen Einführung von Dienstklassen: Pakete erster Klasse Pakete zweiter Klasse Was ist Ihre Meinung? 7-11

12 Multimedia-Netzwerke 7.1 Multimediale Netzwerkanwendungen 7.2 Streaming von gespeichertem Audio/Video 7.3 Best-Effort-Dienste optimal nutzen 7.4 Anbieten von mehreren Dienstklassen 7.5 Dienstgütegarantien anbieten 7.6 Protokolle für interaktive Echtzeit-Anwendungen: RTSP, RTP, RTCP, SIP Computernetzwerke Mark Felegyhazi, CrySyS Lab, Department of Networked Systems and Services (HIT), BME 7-12

13 Streaming von gespeichertem Audio/Video Streaming umfasst eine Reihe von Mechanismen auf der Anwendungsschicht, um den Best-Effort-Dienst des Internet optimal zu nutzen: Puffern im Client, um Jitter auszugleichen Verwenden von UDP statt TCP Verwenden geeigneter Kompressionsverfahren Error Concealment (Verstecken von Fehlern) Diese Mechanismen sind Bestandteil des Abspielprogramms und nicht des Netzwerkes! 7 13

14 Trivialer Ansatz Audio und Video werden in Dateien auf einem Web-Server abgelegt und als Objekte per HTTP übertragen Dies ist kein Streaming: Die Datei vollständig heruntergeladen bevor dem Abspielen Browser lädt eine Beschreibungsdatei per HTTP-GET Browser startet den Media Player und übergibt die Datei Player kontaktiert den Webserver Webserver streamt die Datei (z.b. per HTTP) zum Player 7 14

15 Streaming von einem dedizierten Server Durch diese Architektur kann ein dediziertes Protokoll zum Streaming der Multimediadaten verwendet werden Dies ist in der Regel effizienter Außerdem kann UDP statt TCP zum Einsatz kommen 7 15

16 Real streaming? Kumulierte Daten 1. Video wird aufgezeichnet 2. Video wird übertragen Netzwerkverzögerung 3. Video wird empfangen und abgespielt Zeit Streaming: der Client spielt das Video bereits ab, während der Server immer noch weitere Teile des Videos an den Client überträgt. 7 16

17 Pufferung im Client Kumulierte Daten Übertragung mit konstanter Rate variable Netzwerkverzögerung Empfang mit variabler Rate gepufferte Daten Abspielen der Daten mit konstanter Rate Verzögerung durch Pufferung Zeit Jitter verursacht eine variable Verzögerung von Pakete Die Pufferung im Client kompensiert den Jitter 7 17

18 Streaming Multimedia: Client-Puffer Die Pufferung im Client kompensiert den Jitter der Netzwerkverzögerung! Computernetzwerke Mark Felegyhazi, CrySyS Lab, Department of Networked Systems and Services (HIT), BME 7 18

19 Streaming: UDP oder TCP? UDP Server sendet mit einer angemessenen Rate (ohne auf Überlast im Netzwerk ( nehmen Rücksicht zu Häufig: Senderate = Rate des Encoders = konstant Dann gilt: variable Rate = Rate des Encoders - Verluste Kleiner Puffer, um den Jitter auszugleichen Übertragungswiederholungen: falls es zeitlich Sinn macht TCP Sende mit der maximalen TCP-Rate Diese schwankt stark aufgrund der Überlastkontrolle Zusätzlich: verzögerte Auslieferung durch Übertragungswiederholungen Daher: größerer Puffer notwendig Aber: HTTP/TCP hat mit Firewalls weniger Probleme als UDP 7 19

20 Multimedia-Netzwerke 7.1 Multimediale Netzwerkanwendungen 7.2 Streaming von gespeichertem Audio/Video 7.3 Best-Effort-Dienste optimal nutzen 7.4 Anbieten von mehreren Dienstklassen 7.5 Dienstgütegarantien anbieten 7.6 Protokolle für interaktive Echtzeit-Anwendungen: RTSP, RTP, RTCP, SIP Computernetzwerke Mark Felegyhazi, CrySyS Lab, Department of Networked Systems and Services (HIT), BME 7-20

21 Internaktive Echtzeitanwendungen Wir betrachten im Folgenden die Telefonie als Beispiel! Telefonie zwischen PCs Skype PC-Telefon Dialpad Net2phone Skype Videokonferenzen Skype Polycom Computernetzwerke Mark Felegyhazi, CrySyS Lab, Department of Networked Systems and Services (HIT), BME 7-21

22 Internettelefonie als Beispiel Eigenschaften der Daten: Abwechselnd sprechen und pausieren Während des Sprechens werden Daten erzeugt z.b. mit 64kBit/s, falls ISDN-Codierung verwendet wird (hier betrachtet)...oder deutlich weniger bei geringerer Qualität oder besserer Kompression Wenn Daten übertragen werden Stücke von 20 ms mit 8 kbyte/s = 160 Byte Header für die Anwendungsschicht, die zur Übertragung der Audiodaten verwendet wird Daten+Header werden in UDP eingepackt Während des Sprechens sendet die Anwendung ein UDP- Paket alle 20ms 7 22

23 Internettelefonie: Paketverluste und Verzögerung Verlust im Netzwerk: IP-Paket geht im Netzwerk verloren Häufigster Grund hierfür: Netzwerküberlast = Überlauf einer Warteschlange eines Routers Verlust durch Verzögerung: IP-Paket kommt zu spät beim Empfänger an...und kann nicht mehr abgespielt werden Verzögerungen durch: Codierung/Decodierung im Sender/Empfänger das Netzwerk Maximal tolerierbare Verzögerung: ca. 400ms Toleranz gegenüber Verlusten: In Abhängigkeit von der Kodierung können Verlustraten von 1% bis 10% toleriert werden. 7 23

24 Konstanten Abspielgeschwindigkeit erhalten Empfänger versucht, jedes Sample genau q ms (Abspielverzögerung) nachdem es generiert wurde abzuspielen Jedes Sample hat einen Zeitstempel t und wird zum Zeitpunkt t+q abgespielt Wenn ein Sample später als zum Zeitpunkt t+q eintrifft, dann wird es verworfen Wahl von q: Großes q: weniger Samples müssen verworfen werden Kleines q: höhere Interaktivität 7 24

25 Beispiel Sender erzeugt alle 20 ms ein Paket Das erste Paket wird zum Zeitpunkt r empfangen Erster Abspielplan: beginnt zum Zeitpunkt p Alternativer Abspielplan: beginnt zum Zeitpunkt p Computernetzwerke Mark Felegyhazi, CrySyS Lab, Department of Networked Systems and Services (HIT), BME 7-25

26 Adaptive Bestimmung der Wiedergabeverzögerung Ziel: Wiedergabeverzögerung und verworfene Informationen minimieren Idee: adaptive Bestimmung der Wiedergabeverzögerung: Schätze die Netzwerkverzögerung ab, wenn ein Teilnehmer beginnt zu sprechen Die Perioden, in denen ein Teilnehmer nichts sagt, werden verkürzt oder verlängert, um die Veränderung der Wiedergabeverzögerung zu kompensieren Abspielen der Samples erfolgt immer noch alle 20 ms Adaptive Bestimmung: t i =Zeitstempel des i-ten Paketes r i =Ankunftszeit des i-ten Paketes d i =geschätzte Netzwerkverzögerung nach dem i-ten Paket u ist eine feste Konstante (z.b. u=0.01) Fortschreiben der Schätzung durch exponentielle Glättung: d i =(1-u)d i-1 +u(r i -t i ) 7 26

27 Adaptive Bestimmung der Wiedergabeverzögerung Zusätzlich wird die durchschnittliche Abweichung von der geschätzten Verzögerung bestimmt: vi=(1-u)v i-1 +u r i -t i -d i Die Werte d i und v i werden für jedes Paket bestimmt, werden aber nur dann verwendet, wenn ein Teilnehmer beginnt zu sprechen. Für das erste Paket nach einer Pause gilt dann: p i = Abspielzeit, K = Konstante p i =t i +d i +Kv i Die restlichen Pakete bis zur nächsten Pause werden dann wieder periodisch abgespielt. 7 27

28 Adaptive Bestimmung der Wiedergabeverzögerung Wie bestimmt der Empfänger ob ein Paket das erste Paket nach einer Pause ist? Wenn keine Paketverluste auftreten können: Beobachten der Zeitstempel von aufeinander folgenden Paketen Wenn sich diese um mehr als 20 ms unterscheiden, dann gab es eine Pause Wenn Paketverluste möglich sind: Einführen einer Sequenznummer Wenn zwei aufeinanderfolgende Pakete laut Sequenznummer weiter als 20 ms auseinander liegen, dann gab es eine Pause 7 28

29 Behandlung von Paketverlusten 1. Möglichkeit: Verwenden von Vorwärtsfehlerkorrektur (Forward Error Correction (FEC)): Für jede Gruppe von n Paketen wird ein Redundanzpaket erzeugt: z.b. XOR der n Pakete Es werden n+1 Pakete übertragen n Pakete können wieder hergestellt werden, wenn maximal eins von diesen n+1 Paketen verloren geht Die Wiedergabeverzögerung muss so gewählt werden, dass die n+1 Pakete empfangen werden können, bevor das erste davon abgespielt wird n wird grösser: weniger Redundanz übertragen steigt die Wiedergabeverzögerung steigt die Wahrscheinlichkeit dafür, dass zwei Pakete verloren gehen, das kann dann nicht mehr (mit diesem Verfahren) behoben werden 7 29

30 Behandlung von Paketverlusten 2. Möglichkeit: Hinzufügen eines zweiten Stromes mit niedriger Qualität Zweiter Strom wird als Redundanz geschickt Beispiel: Datenstrom als PCM mit 64 kbit/s Redundanz als GSM mit 13 kbit/s Immer dann, wenn nicht zwei Pakete hintereinander verloren gehen, kann der Empfänger den Verlust verbergen Erweiterbar: Redundanz kann auch an die folgenden n Pakete angehängt werden 7-30

31 Behandlung von Paketverlusten Interleaving: Samples werden in kleinere Einheiten zerlegt z.b. 4-5 ms pro Einheit Ein Paket enthält Einheiten von mehreren Samples Wenn ein Paket verloren geht, dann kann man das Sample zum großen Teil wieder herstellen Keine Redundanz Aber höhere Abspielverzögerung 7-31

32 Content-Distribution-Netzwerke (CDNs) Verzögerung minimalisieren Redundanz Die Anbieter von Inhalten sind die Kunden der CDNs Vorhalten von mehreren Kopien (replicas) der Inhalte mehrere Hunderte von CDN- Server im Internet in der Nähe der Benutzer. Das CDN vervielfältigt die Inhalte des Kunden auf ihren Servern. Verändert der Kunde des CDN den Inhalt, werden alle Server des CDN mit diesem aktualisiert. ex: Akamai 7-32

33 CDN Beispiel Ursprungsserver Stellt HTML-Seiten bereit ersetzt: Durch: highlights.mpg CDN Betreiber cdn.com Verteilt Inhalte Verwendet seinen DNS Server, um die Anfragen umzuleiten 7-33

34 CDNs - Details Der CDN-Provider erstellt eine Karte mit den Distanzen aller IP-Adressen zu seinen eigenen CDN-Servern Vorgehen beim Eintreffen einer Anfrage an einem DNS- Server des CDN Providers: Betrachte die IP-Adresse des Absenders Ermittle den besten CDN-Server für diese Anfrage mittels der erstellten Karte Gib die IP-Adresse dieses Servers in der DNS-Antwort zurück 7-34

35 Internet und Multimedia Bisher: eine Sammlung von Tricks, um Multimedia-Ströme über das Internet zu übertragen UDP verwenden, um die Überlastkontrolle von TCP zu umgehen Pufferung auf Seite des Clients, um den Jitter und die Verzögerung auszugleichen Medienströme in mehreren Datenraten bereitstellen, um sich an die Netzwerkverbindung zum Client anpassen zu können Mehrere Kopien verschiedener Codierung vorhalten Dynamische Anpassung während des Abspielens Kompensation von Fehlern: FEC, Interleaving ( ist Übertragungswiederholungen (sofern es zeitlich sinnvoll Fehler verbergen: niedrigere Qualitätsstufe abspielen, Abspielen von vorangegangenen Samples 7 35

36 Multimedia-Netzwerke 7.1 Multimediale Netzwerkanwendungen 7.2 Streaming von gespeichertem Audio/Video 7.3 Best-Effort-Dienste optimal nutzen 7.4 Anbieten von mehreren Dienstklassen 7.5 Dienstgütegarantien anbieten 7.6 Protokolle für interaktive Echtzeit-Anwendungen: RTSP, RTP, RTCP, SIP Computernetzwerke Mark Felegyhazi, CrySyS Lab, Department of Networked Systems and Services (HIT), BME 7-36

37 Anbieten von mehreren Dienstklassen Bisher: Best-Effort-Dienste optimal nutzen Gleiche Dienste für alle Alternative: Verschiedene Dienstklassen Aufteilen des Datenverkehrs in Klassen Das Netzwerk behandelt die unterschiedlichen Klassen verschieden (Analogie: VIP-Teilnehmer und normaler Teilnehmer) Granularität: Unterschiedliche Dienste für verschiedene Klassen, nicht für jeden einzelnen Datenfluss Ursprung: ToS-Bits

38 Mehrere Dienstklassen: Szenario 7 38

39 Prinzipien von QoS Beispiel: 1-MBit/s- Telefonverbindung und ein FTP Upload teilen sich einen 1.5-Mbit/s- Link FTP kann im Router Überlast erzeugen Priorität sollte auf dem Audio liegen (wirklich?) 1. Prinzip Das Markieren von Paketen ist notwendig, damit ein Router zwischen verschiedenen Verkehrsklassen differenzieren kann. 7 39

40 Prinzipien von QoS Was passiert, wenn sich Anwendungen falsch verhalten (z.b. Audio-Rate ist höher als angekündigt)? Policing: Quellen dazu zwingen, sich an die Absprachen zu halten 2. Prinzip Isolation der einzelnen Netzwerkströme 7 40

41 Prinzipien von QoS Feste Zuordnung von Ressourcen zu Netzwerkströmen: ineffizient, wenn Ströme die Zuordnung nicht ausnutzen! 3. Prinzip Trotz Isolation müssen die Ressourcen so gut wie möglich ausgenutzt werden! 7 41

42 Was nun? Prinzipien sind nun bekannt! Als nächstes: Mit welchen Mechanismen können diese Prinzipien umgesetzt werden? 7 42

43 Scheduling - FIFO Scheduling: Wahl des nächsten zu übertragenden Paketes FIFO-Scheduling (First-In-First-Out) : Bearbeitung in der Reihenfolge der Ankunft Discard-Policy: Welches Paket wird verworfen, wenn die Warteschlange voll ist? Drop-Tail: ankommendes Paket Prioritätsbasiert: nach Priorität der Pakete Zufällig: Zufällige Auswahl Active Queue Management: random early discard (RED): statistisch zufällig 7 43

44 Arbeitsweise einer FIFO-Warteschlange 7 44

45 Scheduling Prioritätswarteschlange Prioritätswarteschlange: übertragen des Paketes mit der höchsten Priorität Verschiedene Prioritätsklassen: Klasse kann durch Markierung des Paketes oder anhand von Headerinformationen (Quell-/Ziel-IP) bestimmt werden 7 45

46 Arbeitsweise einer Prioritätswarteschlange 7 46

47 Scheduling Round Robin Round-Robin-Scheduling: Verschiedene Klassen von Paketen Eine Warteschlange pro Klasse Abwechselndes Bedienen des ersten Paketes jeder Warteschlange 7 47

48 Scheduling Weighted Fair Queuing Weighted Fair Queuing: Generalisierung von Round-Robin-Scheduling Jede Warteschlange hat ein Gewicht Jeden Zyklus wird jede Warteschlange nach ihrem Gewicht bedient 7 48

49 Überwachung (Policing) Ziel: Datenverkehr so einschränken, dass er die vereinbarten Parameter nicht überschreitet Drei häufig verwendete Kriterien: Durchschnittliche Rate (long term average rate): wieviele Pakete können über eine längere Zeit hinweg im Durchschnitt pro Zeiteinheit übertragen werden Zentrale Frage: Wie lange ist das Intervall, in dem gemessen wird? 100 Pakete pro Sekunde und 6000 Pakete pro Minute haben den selben Durchschnitt! Maximale Rate (peak rate): zusätzlich zur durchschnittlichen Rate, um zu bestimmen, wie sich die Datenrate über kürzere Zeiträume verhalten darf. z.b Pakete pro Minute durchschnittliche Rate mit einer maximalen Rate von 1500 Paketen pro Sekunde Burst-Größe: maximale Anzahl von Paketen, die in Folge (ohne jede Verzögerung) übertragen werden dürfen 7 49

50 Überwachung Leaky Bucket Leaky Bucket: begrenzt den Paketfluss auf eine vorgegebene Burst-Größe und gleichzeitig auf eine vorgegebene durchschnittliche Rate. Der Eimer (engl. Bucket) kann maximal b Tokens beinhalten Token werden mit der Rate r Token/Sekunde generiert, solange der Eimer nicht voll ist Übertragen eines Paketes kostet einen Token Über ein Intervall der Länge t gilt dann: Anzahl der übertragenen Pakete ist kleiner oder gleich (r t + b). 7 50

51 Weighted Fair Queueing + Leaky Bucket Die Kombination von WFQ und Leaky Bucket führt zu einer oberen Grenze für die Verzögerung eines Datenpakets: QoS! 7 51

52 IETF Differentiated Services Gewünscht sind Dienstklassen Klassen werden unterschiedlich behandelt (aber keine einzelne Flüsse!) Klassen können mit unterschiedlicher Priorität behandelt werden: Platin, Gold, Silber Skalierbarkeit: einfach Funktionen im Inneren des Netzwerkes, komplexe Funktionen am Rand des Netzwerkes (Hosts oder Zugangsrouter) Das Signalisieren und das Aufrechterhalten von Zustandsinformationen in Routern ist problematisch, wenn es auf Basis einzelner Datenflüsse durchgeführt wird Keine Definition von Dienstklassen, sondern Bereitstellen einzelner Komponenten, um Dienstklassen zu unterstützen 7 52

53 Diffserv-Architektur Router am Rand des Netzwerkes: Verkehrsüberwachung auf Ebene einzelner Datenflüsse Markiert Pakete danach, ob sie einem gegebenen Profil entsprechen oder nicht Router im Inneren des Netzwerke: Verkehrsüberwachung auf Ebene von Verkehrsklassen Puffern und Scheduling auf Basis der Markierung Bevorzugung von Paketen, die dem Profil entsprechen 7 53

54 Diffserv-Architektur Router am Rand des Netzwerkes: Verkehrsüberwachung auf Ebene einzelner Datenflüsse r markieren Markiert Pakete danach, ob sie einem gegebenen Profil entsprechen oder nicht b Router im Inneren des Netzwerke: Verkehrsüberwachung auf Ebene von Verkehrsklassen Puffern und Scheduling auf Basis der Markierung Bevorzugung von Paketen, die dem Profil entsprechen 7 54

55 Diffserv-Architektur Router am Rand des Netzwerkes: Verkehrsüberwachung auf Ebene einzelner Datenflüsse Markiert Pakete danach, ob sie einem gegebenen Profil entsprechen oder nicht Scheduling. Router im Inneren des Netzwerke: Verkehrsüberwachung auf Ebene von Verkehrsklassen Puffern und Scheduling auf Basis der Markierung Bevorzugung von Paketen, die dem Profil entsprechen 7 55

56 Markierung in den Routern am Netzwerkrand Profil: Ausgehandelte Rate A, Bucket-Größe B Pakete eines Flusses werden gemäß dieses Profils markiert Rate A B Pakete eines Flusses Möglicher Einsatz von Markierungen: Klassenbasierte Markierung: Pakete werden entsprechend der Klasse ihres Flusses markiert Markierung anhand von Profilen: Pakete, die dem Profil ihres Flusses entsprechen, werden anders markiert als diejenigen, die dem Profil nicht entsprechen Computernetzwerke Mark Felegyhazi, CrySyS Lab, Department of Networked Systems and Services (HIT), BME 7-56

57 Verkehrsklassifikation und Überwachung Es ist häufig wünschenswert den Eingangsverkehr zu begrenzen: Benutzer verwenden ein Profil (z.b. durchschnittliche Rate + Burst-Größe) Der Verkehr wird überwacht und angepasst, wenn er sich nicht an das Profil hält 7 57

58 Markierung in Diffserv Die Markierung erfolgt im Type-of-Service-Feld (TOS) bei IPv4 oder im Traffic-Class-Feld bei IPv6 6 Bits werden für den Differentiated Service Code Point (DSCP) verwendet; dieser bestimmt das sogenannte Per-Hop-Verhalten im Inneren des Netzwerkes 2 Bits sind derzeit ungenutzt 7 58

59 Per-Hop-Verhalten Das Per-Hop-Verhalten (Per Hop Behaviour, PHB) ist unterschiedlich für verschiedene Markierungen Es führt zu beobachtbaren und messbaren Unterschieden beim Weiterleiten von Paketen Sehr weiche Definition Es spezifiziert NICHT, welche Mechanismen verwendet werden, um dieses Verhalten zu erreichen Beispiele: Klasse A bekommt x% der ausgehenden Linkbandbreite über Zeitintervalle einer fest vorgegebenen Länge Pakete der Klasse A werden immer vor Paketen der Klasse B weitergeleitet 7 59

60 Per-Hop-Verhalten In der Entwicklung befindliche Per-Hop-Verhalten: Expedited Forwarding: die Abgangsrate einer Klasse entspricht oder übersteigt eine vorher definierte Rate Logischer Link mit einer garantierten minimalen Rate Assured Forwarding: 4 Verkehrsklassen Jede Klasse mit einer eigenen minimalen Bandbreite (pro Klasse) Jede mit drei verschiedenen Unterklassen bezüglich des Verwerfens von Paketen, wenn Warteschlangen voll sind 7 60

61 Multimedia-Netzwerke 7.1 Multimediale Netzwerkanwendungen 7.2 Streaming von gespeichertem Audio/Video 7.3 Best-Effort-Dienste optimal nutzen 7.4 Anbieten von mehreren Dienstklassen 7.5 Dienstgütegarantien anbieten 7.6 Protokolle für interaktive Echtzeit-Anwendungen: RTSP, RTP, RTCP, SIP Computernetzwerke Mark Felegyhazi, CrySyS Lab, Department of Networked Systems and Services (HIT), BME 7-61

62 Prinzipien von QoS (Fortsetzung) Triviale Erkenntnis: es können nicht mehr Ressourcen verwendet werden als vorhanden sind! 4. Prinzip Rufzulassung (call admission control): ein Netzwerkstrom meldet seinen Bedarf an. Er muss abgewiesen werden, wenn keine ausreichenden Ressourcen bereit stehen. 7 62

63 QoS-Zulassungsszenario Ressourcenreservierung Rufaufbau, Signalisierung (RSVP) Deklaration von Verkehr und QoS- Anforderungen Zulassung QoS-unterstützendes Scheduling (z.b. WFQ) Anfrage/ Antwort Computernetzwerke Mark Felegyhazi, CrySyS Lab, Department of Networked Systems and Services (HIT), BME 7-63

64 QoS Rufzulassung: Beispiel Reservierung von Ressourcen Verbindungsaufbau, Signalisierung (RSVP) Datenverkehr mit QoS- Garantien, Zulassung von Datenströmen - QoS-Scheduling (z.b. WFQ) 7 64

65 IETF Integrated Services: Intserv Architektur, um einzelnen Datenströmen QoS-Garantien anbieten zu können Reservierung von Ressourcen: Router pflegen Zustandsinformationen (Reservierungen) Zentrales Problem: Kann ein neuer Datenstrom zugelassen werden, ohne dass die Garantien für andere Datenströme verletzt werden? 7 65

66 Intserv: Rufzulassung Eine neue Verbindung muss: Ihre QoS-Anforderungen bekannt geben: reservation specification (R-spec): Definition der gewünschten Dienstgüte traffic specification (T-spec): Definition der Eigenschaften des Datenflusses (Leaky Bucket, mit Angabe von r und n) Ihre Anforderungen signalisieren: Transport von R-spec und T-spec zu den Routern Einsatz von RSVP 7 66

67 QoS-Arten (Dienstmodelle) für Intserv ankommender Verkehr Token-Rate, r Größe des Buckets, b WFQ D = b/r max Rate R pro Fluss Garantierter Dienst: Leaky Bucket + WFQ führen zu einer festen Garantie bezüglich der Netzwerkverzögerung Controlled load service: "a quality of service closely approximating the QoS that same flow would receive from an unloaded network element." 7-67

68 Signalisierung im Internet verbindungsloses (zustandsloses) Weiterleiten durch IP Routers Best-Effort- Dienst + = Keine Signalisierungsprotokolle auf Netzwerkebene im Internet Neue Anforderung: Ressourcen entlang eines Ende-zu-Ende Pfades (Endsysteme, Router) reservieren RSVP: Resource Reservation Protocol [RFC 2205] allow users to communicate requirements to network in robust and efficient way also Signalisierung! Früheres Signalisierungsprotokoll im Internet: ST-II [RFC 1819] Next Steps in Signaling (NSIS) current proposal as RFC

69 RSVP-Designziele 1. Berücksichtigung heterogener Empfänger (verschiedene Bandbreite über unterschiedliche Pfade) 2. Berücksichtigung unterschiedlicher Anwendungen mit heterogenen Anforderungen an die Ressourcen 3. Multicast-Unterstützung, insbesondere Anpassung der Gruppenmitgliedschaft 4. Verwenden von existierendem Multicast-/Unicast-Routing, mit Anpassungen 5. Aufwand zu Signalisierung darf schlimmstenfalls linear mit der Anzahl der Empfänger wachsen 6. Modulares Design, um heterogene Technologien auf den tieferen Schichten zu unterstützen 7 69

70 Was RSVP nicht macht... Festlegen, wie Ressourcen reserviert werden Sondern: ein Mechanismus, um die Anforderungen dem Netzwerk mitzuteilen Festlegen, welche Route Pakete nehmen sollen Dies ist die Aufgabe der Routingprotokolle Signalisierung!= Routing In das Weiterleiten (Forwarding) von Paketen eingreifen Trennung der Kontrollebene (Singalisierung) von der Datenebene (Forwarding) 7 70

71 RSVP: prinzipielles Vorgehen Empfänger treten einer Multicast-Gruppe bei Hat noch nichts mit RSVP zu tun Sender müssen einer Gruppe nicht beitreten, in die sie senden (Eigenschaft von IP-Multicast) Unicast wird als degenerierter Fall von Multicast betrachtet Signalisierung des Senders an das Netzwerk Path Message: Bekanntmachen der Anwesenheit des Senders Path Teardown: Zustand bezüglich dieses Senders aus dem Zustand der Router löschen Signalisierung der Empfänger an das Netzwerk Reservation Message: Ressourcen vom Sender zum Empfänger reservieren Reservation Teardown: Ressourcen freigeben Signalisierung des Netzwerkes an die Endsysteme Path Error Reservation Error 7 71

72 Multimedia-Netzwerke 7.1 Multimediale Netzwerkanwendungen 7.2 Streaming von gespeichertem Audio/Video 7.3 Best-Effort-Dienste optimal nutzen 7.4 Anbieten von mehreren Dienstklassen 7.5 Dienstgütegarantien anbieten 7.6 Protokolle für interaktive Echtzeit-Anwendungen: RTSP, RTP, RTCP, SIP Computernetzwerke Mark Felegyhazi, CrySyS Lab, Department of Networked Systems and Services (HIT), BME 7-72

73 Steuerung des Abspielens durch den Anwender HTTP Nicht für Medienströme entworfen Keine Unterstützung für Pause, schnellen Vor-/Rücklauf RTSP: RFC 2326 Real Time Streaming Protocol Anwendungsprotokoll zur Steuerung des Abspielens von Medienströmen durch den Client Kommandos: Rücklauf, schneller Vorlauf, Pause, Abspielen, usw. Was bietet RTSP nicht: RTSP ist nicht verantwortlich für die Übertragung der Mediendaten (RTP) RTSP ist nicht verantwortlich für das Puffern der Daten im Player RTSP ist ein Kontrollprotokoll Analogie zu FTP Kontrollkanal für die Befehle Datenkanal zur eigentlichen Datenübertragung Wird als Out-of-Band -Steuerung bezeichnet 7-73

74 RTSP: Out-of-Band-Steuerung FTP: Datei wird über eine TCP- Verbindung übertragen. Steuerung (wechseln von Verzeichnissen, Anforderung einer Übertragung) wird über eine eigene TCP-Verbindung durchgeführt Verwenden verschiedener Portnummern zum Unterscheiden der Verbindungen RTSP: Auch RTSP verwendet einen anderen Port als die eigentlichen Mediendaten Port 554 Daher: Out-of-Band-Steuerung Computernetzwerke Mark Felegyhazi, CrySyS Lab, Department of Networked Systems and Services (HIT), BME 7-74

75 Beispiel für RTSP Szenario: Eine Metadatei (Präsentationsbeschreibungsdatei) wird dem Webbrowser des Anwenders übermittelt Der Browser startet einen geeigneten Player Der Player baut eine RTSP-Verbindung und eine Datenverbindung zum Server auf Der Benutzer steuert die Datenverbindung mit Hilfe von RTSP über die Kontrollverbindung 7 75

76 Beispiel einer Metadatei <title>twister</title> <session> <group language=en lipsync> </group> </session> <switch> <track type=audio e="pcmu/8000/1" src = "rtsp://audio.example.com/twister/audio.en/lofi"> <track type=audio e="dvi4/16000/2" pt="90 DVI4/8000/1" src="rtsp://audio.example.com/twister/audio.en/hifi"> </switch> <track type="video/jpeg" src="rtsp://video.example.com/twister/video"> 7 76

77 RTSP-Ablauf 7 77

78 RTSP: Beispiel für den Ablauf C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=play S: RTSP/ OK Session 4231 C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=0- C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=37 C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 S: OK 7 78

79 Real-Time Protocol (RTP) RTP standardisiert ein Paketformat für die Übertragung von Audio und Video RFC 3550 Der RTP-Header beinhaltet folgende Informationen: Identifikation des Payloads Sequenznummern Zeitstempel RTP wird von Endsystemen verwendet RTP Pakete werden per UDP verschickt Interoperabilität: Unterschiedliche RTP- Implementierungen sollten interoperabel sein Dienste können für beliebige RTP-Anwendungen angeboten werden z.b. Aufzeichnung von Sitzungen 7-79

80 RTP verwendet UDP RTP-Bibliotheken erweitern die Schnittstelle von UDP: Portnummern, IP-Adressen Identifikation des Payloads Sequenznummern Zeitstempel 7 80

81 Ein Beispiel für RTP Es soll ein 64-kBit/s-PCM-codierter Telefondatenstrom mit RTP übertragen werden. Die Anwendung bildet 20-ms-Samples, die in 160 Bytes codiert werden. Diese 160 Bytes werden mit einem RTP-Header versehen und in ein UDP-Paket eingepackt. Der RTP-Header beschreibt die Art der Codierung: Während des Gespräches kann ein Sender die Codierung ändern Zeitstempel und Sequenznummern werden ebenfalls hinzugefügt. 7-81

82 RTP und QoS RTP stellt keinerlei Mechanismen zur Verfügung, um die rechtzeitige Auslieferung der Daten oder andere QoS Merkmale zu garantieren. RTP wird nur von den Endsystemen interpretiert, Router sehen RTP als Anwendungsdaten. Router unternehmen daher keinerlei Anstrengungen, um RTP Pakete bevorzugt zu behandeln. 7 82

83 RTP Header Payload-Typ: Beschreibt die Codierung des Payload Typs. Diese kann während der Übertragung gewechselt werden, z.b. um auf Veränderungen der verfügbaren Bandbreite zu reagieren. Payload-Typ 0: PCM mu-law, 64 kbps Payload-Typ 3, GSM, 13 kbps Payload-Typ 7, LPC, 2.4 kbps Payload-Typ 26, Motion JPEG Payload-Typ 31. H.261 Payload-Typ 33, MPEG2 video Sequenznummer: wird um 1 für jedes übertragene Paket erhöht. Erlaubt die Erkennung von Paketverlusten und das Wiederherstellen der richtigen Paketreihenfolge. 7 83

84 RTP Header (2) Zeitmarke (32 Bits). Beschreibt den Zeitpunkt zu dem das erste Sample im Paket erstellt wurde. Für Audio wird die Zeitmarke üblicherweise um 1 für jedes Sample erhöht. Beispiel: alle ms bei Sampling mit 8KHz. Wenn die Anwendung immer 160 Samples zu einem Paket zusammenfasst, dann wird die Zeitmarke jeweils um 160 erhöht. Synchronization Source (SSRC) (32 Bit lang). Identifiziert den Sender des Paketes. RTP wurde für Multicast entwickelt dort kann es pro Gruppe viele Sender geben! 7 84

85 Real-Time Control Protocol (RTCP) Wird zusammen mit RTP eingesetzt und wurde wie RTP so entwickelt, dass es für Multicast einsetzbar ist Ist ein leichtgewichtiges Sitzungsprotokoll Informationen über Teilnehmer Informationen über die Empfangsqualität der Teilnehmer Jeder Teilnehmer überträgt periodisch RTCP-Pakete an alle anderen Teilnehmer Ein Absender kann auf diese Informationen reagieren und seine Übertragung anpassen 7 85

86 RTCP Multicast Wenn RTCP über Multicast verwendet wird, dann: Gibt es eine Multicastadresse für die die Sitzung (RTP+RTCP) RTP und RTCP unterschieden sich durch die verwendete Port Nummer Wird die Gesamtbandbreite von RTCP begrenzt, in dem jeder einzelne Teilnehmer seine RTCP Pakete seltener sendet je mehr Teilnehmer die Sitzung hat RTP Computernetzwerke Mark Felegyhazi, CrySyS Lab, Department of Networked Systems and Services (HIT), BME 7-86

87 RTCP-Pakete Receiver Report Packets Verlustrate, letzte erhaltene Sequenznummer, durchschnittlicher Jitter Sender Report Packets SSRC des Senders, aktueller Zeitstempel, Anzahl der gesendeten Pakete, Anzahl der gesendeten Bytes Source Description Packets Name und Kontaktinformationen des Teilnehmers, SSRC des Teilnehmers 7 87

88 Synchronisation durch RTP/RTCP Mit Hilfe von RTCP können unterschiedliche Medienströme synchronisiert werden Jeder Medienstrom besitzt nur einen relativen Zeitstempel (z.b. Anzahl der Samples seit Beginn der Sitzung) RTCP stellt eine Verbindung zwischen der aktuellen Zeit beim Absenden eines Paketes und den relativen Zeitstempeln her So kann ein Empfänger die unterschiedlichen Medienströme synchronisieren 7 88

89 Skalierung der Bandbreite von RTCP RTCP versucht seine Bandbreite auf 5% der Sitzungsbandbreite zu begrenzen Beispiel Ein Sender überträgt ein Video mit 2MBit/s. Dann versucht RTCP seine Bandbreite auf 100kBit/s zu begrenzen. RTCP teilt 75% dieser Rate den Empängern zu; die restlichen 25% dem Sender 75 kbit/s wird unter allen Empfängern aufgeteilt: bei R Empfängern sind dies 75/R kbit/s pro Empfänger. Sender überträgt mit 25 kbit/s. Jeder Teilnehmer bestimmt den Abstand zwischen seinen Übertragungen, indem er seine durchschnittliche RTCP Paketgröße berechnet und die ihm zur Verfügung stehende Rate durch diese Größe teilt. Computernetzwerke Mark Felegyhazi, CrySyS Lab, Department of Networked Systems and Services (HIT), BME 7-89

90 Session Initiation Protocol (SIP) Vision: Alle Telefonanrufe und Videokonferenzen werden über das Internet geleitet Menschen werden über ihren Namen oder ihre -Adresse identifiziert und nicht über eine abstrakte Telefonnummer Man kann den Kommunikationspartner erreichen, egal wo er sich aufhält und welches IP-fähige Endgerät er benutzt Protokoll wurde von der IETF entwickelt (RFC 3261) Massiver Einfluss auf die Internettelefonie 7 90

91 Welche Dienste bietet SIP? Eine Verbindung aufbauen Mechanismen, um dem Kommunikationspartner darüber zu informieren, dass man eine Verbindung herstellen möchte Mechanismen, um die zu verwendenden Medientypen und Codierungen auszuhandeln Mechanismen für das Beenden einer Verbindung Bestimmen der aktuellen IP-Adresse des Kommunikationspartnerns Abbildung eines Namens auf die dazugehörige IP-Adresse Rufsteuerung Neue Medienströme zu einer Verbindung hinzufügen Codierung während einer Verbindung ändern Neue Teilnehmer hinzufügen 7 91

92 Verbindung zu einer bekannten IP-Adresse herstellen Die Invite-Nachricht von Alice beinhaltet: ihre IP-Adresse + Portnummer Codierung, die Alice empfangen möchte Die OK-Nachricht von Bob beinhaltet: Seine IP-Adresse + Portnummer Codierung, die er empfangen möchte SIP-Nachrichten können per UDP oder per TCP verschickt werden 7 92

93 Verbindung zu einer bekannten IP-Adresse herstellen Aushandeln der Codierung: Falls Bob die von Alice gewünscht Codierung PCM ulaw nicht bereitstellen kann... antwortet er mit 606 Not Acceptable Reply... und gibt eine Liste von Codierungen an, die er unterstützt. Alice kann dann eine neue Invite-Nachricht schicken und eines der von Bob unterstützten Formate wählen. Ablehnen eines Rufes Bob kann einen Ruf ablehen... und dafür einen Grund angeben: Busy Gone Payment required Forbidden Die eigentlichen Mediendaten können dann per RTP oder über ein anderes Protokoll gesendet werden. 7 93

94 Beispiel für eine SIP-Nachricht INVITE SIP/2.0 Via: SIP/2.0/UDP From: To: Call-ID: Content-Type: application/sdp Content-Length: 885 c=in IP m=audio RTP/AVP 0 Die aktuelle IP-Adresse von Bob ist unbekannt. Alice verwendet den Standard-Port für das Senden und Empfangen von SIP- Nachrichten Alice kündigt an, dass Ihr SIP-Client die Nachrichten via UDP empfangen wird Anmerkungen: HTTP-ähnliche Syntax SDP = Session Description Protocol Call-ID ist für jeden Anruf eindeutig 7-94

95 Abbildung des SIP-Namens auf eine IP-Adresse Anrufer kennt lediglich den SIP-Namen des Gesprächspartners Er muss die IP-Adresse herausfinden Benutzer sind mobil DHCP wird eingesetzt (... PDA, Benutzer haben mehrere Geräte mit IP-Adressen (PC, Das Ergebnis der Anfrage kann abhängen von: ( Hause Tageszeit (am Arbeitsplatz, zu Anrufer Status des angerufenen Teilnehmers (umleitung auf Voicebox, wenn man ( spricht gerade mit jemand anderem Von SIP angebotene Dienste: SIP-Registrar SIP-Proxy-Server Funktionalität ähnlich zu (Dyn)DNS! 7 95

96 SIP-Registrar l Wenn Bob seinen SIP-Client startet, dann schickt dieser eine SIP REGISTER Nachricht an Bobs Registrar-Server l Beispiel für eine solche Nachricht REGISTER sip:domain.com SIP/2.0 Via: SIP/2.0/UDP From: sip:bob@domain.com To: sip:bob@domain.com Expires:

97 SIP-Proxy Alice sendet ihre Invite-Nachricht an ihren Proxy-Server Invite beinhaltet die Information: Der Proxy Server ist dafür verantwortlich, die SIP Nachricht zum angerufenen Teilnehmer weiterzuleiten Möglicherweise über mehrere Proxies hinweg Der angerufene Teilnehmer sendet seine Antwort auf dem gleichen Weg zurück Der Proxy von Alice liefert die Antwort an Alice aus In der Antwort ist die IP-Adresse von Bob enthalten Sehr ähnlich zu (Dyn)DNS: Proxy = lokaler DNS.Server 7 97

98 Beispiel Anrufer: Ziel: (1) Jim sendet eine Invite-Nachricht an den umass-sip-proxy. (2) Proxy leitet dies an den upenn-registrar weiter. (3) upenn-registrar gibt eine Redirect-Antwort, die besagt, dass man das Ziel nun unter erreichen kann (4) umass-proxy schickt ein INVITE an den eurecom-registrar. (5) Der eurecom-registrar leitet das Invite an weiter, dort läuft der SIP-Client von Keith. (6-8) SIP-Antworten werden zum Anrufer geschickt (9) Medienströme werden dann direkt übertragen. 7 98

99 Vergleich mit H.323 H.323 ist ein weiteres Signalisierungsprotokoll H.323 ist eine komplett standardisierte Familie von Protkollen für Videokonferenzen: Signalisierung, Registrierung, Zugangskontrolle, Transportportokolle, Codecs SIP ist nur eine Komponente. Arbeitet mit RTP zusammen, RTP ist jedoch nicht zwingend notwendig. SIP kann mit anderen Protokollen und Diensten kombiniert werden. H.323 stammt von der ITU (Telefonie). SIP stammt von der IETF: Viele Konzepte von HTTP übernommen. H.323 entnimmt viele Konzepte aus der Telefonvermittlung (SS7). SIP enspringt der KISS Entwurfsstrategie: Keep it simple (and) stupid. 7-99

100 Kapitel 7: Zusammenfassung Grundlagen Klassifikation von Anwendungen Identifikation der Dienste, die von Multimedianwendungen benötigt werden Best-Effort-Dienste optimal nutzen Protokolle und Architekturen Mechanismen, um QoS zu unterstützen Architekturen, um QoS zu unterstützen Einführung von Dienstklassen QoS-Garantien, Rufzulassung Spezielle Protokolle für Best-Effort-Netzwerke 7 100