Multicast-Proxy-Server für Audio-Live-Streams

Transkript

1 Multicast-Proxy-Server für Audio-Live-Streams Projektarbeit PA2 / Sna Mai bis 6. Juli 2001 Reto Glanzmann, José Fontanil Dozent: Dr. Andreas Steffen

2 Inhaltsverzeichnis 1. Zusammenfassung und Ausblick Zusammenfassung Ausblick Zeitplanung Grundlagen Multicasting IP Multicasting Übersicht Adressen IP-Multicast-Adressen Umsetzung der IP-Multicast Adresse in Multicast-MAC- Adressen im Ethernet Internet Group Management Protocol (IGMP) IGMP Version IGMP Version Distance Vector Multicast Routing Protocol (DVMRP) Protocol Independent Multicast (PIM) PIM Dense Mode PIM Sparse Mode Inter-Domain Multicast Multicast Border Gateway Protocol (MBGP) Multicast Source Discovery Protocol (MSDP) Border Gateway Multicast Protocol (BGMP) Administrative Konzepte Multicast Scope Control Bandbreitenlimitierung / Flusskontrolle Aufsetzen eines IP-Multicast-Tunnels Router MBone Zukünftige Entwicklungen Multicast in IPv QoS-Unterstützung für IP-Multicast Streaming Streaming Übersicht Unicast Streaming Multicast Streaming SDP, SAP und SIP RTP, RTCP und RTSP Multicast Streams per Web publizieren (Bsp. Apache) SDR MP3 Audio Plug-In Aufgabenstellung Analyse Vergleich von Streaming / Proxy Server-Produkten...29 Übersicht der verfügbaren Audio-Streaming Produkte...30 Doku PA2_Sna06.sdw Seite R. Glanzmann & J. Fontanil

3 4.2 ZHW MBone Anbindung Realisierung Beschreibung unserer Multicast-Streaming Lösung Versuchsaufbau Einführung Darstellung des Testaufbaus Erläuterungen zum Testaufbau Performance Aspekte Beurteilung der Lösung Beschreibung der Komponenten LiveCaster SHOUTcast DNAS-Server oddcast DSP Winamp Plug-In Kosten / Lizenzierung Benutzeranleitung Administrator LiveCaster (Multicast-Server) SHOUTcast DNAS-Server (Unicast Server) Winamp Plug-In oddcast DSP Winamp Line-In Plug-In Webpage mit 'tune-in' Angebot (Beispiel Apache) Empfänger Literaturverzeichnis Buch Internet RFCs und Internet Drafts Software Versionen Auf dem Server / Proxy eingesetzte Software Auf dem Client eingesetzte Software...51 Doku PA2_Sna06.sdw Seite R. Glanzmann & J. Fontanil

4 1. Zusammenfassung und Ausblick 1.1 Zusammenfassung Im Rahmen unserer zweiten Projektarbeit im dritten Studienjahr evaluierten wir Multicast-Streaming-Lösungen für den Campus-Einsatz. Nach Versuchen mit den einzelnen Komponenten haben wir das geforderte Ziel erreicht. Ein flexibles, leistungsfähiges und in der Anschaffung erstaunlich preisgünstiges Gesamtsystem. Die Kosten der eingesetzten Software belaufen sich auf magere US$ 100, wobei die Anzahl der Zuhörer nicht begrenzt ist. Die Lösung enthält alle geforderten Features: Proxy-Funktionalität, Live- Streaming ab einer beliebigen analogen Quelle und Multiple-Simultaneous- Streaming. Die Streams können bequem per Webinterface bezogen werden. Der vorliegende Projektbericht soll dem Leser die Grundlagen des Multicastings und Streamings vermitteln. Weiter ist eine Analyse und komplette Anleitung zum Aufbau der von uns erarbeiteten Gesamtlösung enthalten. Mit diesen Unterlagen soll es Firmen und Institutionen ermöglicht werden, innert kurzer Zeit eine lauffähige Multicast-Proxy-Lösung in Betrieb zu nehmen. Die Multicasting-Technologie ist heute noch sehr unausgereift. Router müssen neueste Betriebssystem-Updates haben, neue Routingprotokolle werden noch nicht von allen Routern unterstützt und gewisse Protokolle haben es noch nicht einmal auf den Stand eines RFCs geschafft. Gleichwohl glauben wir, dass diese Technologie eine grosse Zukunft haben wird, nicht nur im Campus-Bereich. Mit dem MBone existiert jetzt schon ein stetig wachsendes, weltumspannendes Multicast-Netz mit interessanten Inhalten. Auf unsere Initiative hin, sollte auch die ZHW in den nächsten Wochen den Anschluss an das MBone erhalten. Winterthur im Juli 2001 Reto Glanzmann José Fontanil Doku PA2_Sna06.sdw Seite R. Glanzmann & J. Fontanil

5 1.2 Ausblick Mit dieser Projektarbeit wurde der Grundstein gelegt, um sich genauer mit dem Thema Multicasting zu befassen. Mögliche Erweiterungen unserer Arbeit wären:? Langzeittest des Gesamtsystems? Da es trotz Multicasting nicht möglich ist, eine beliebige Anzahl Streams gleichzeitig anzubieten, benötigt man ein Auswahl- und Bewertungsverfahren. Wir haben uns vorgestellt, dass dies am einfachsten mit einem evote-system per Webinterface zu realisieren ist.? Viele Webradio-Stationen senden ihr Angebot in den proprietären RealMediaund Quicktime-Formaten, es wäre deshalb wünschenswert einen Konverter zu haben, sodass der LiveCaster auch diese Streams empfangen kann. 1.3 Zeitplanung Da es sich bei dieser Projektarbeit nicht um ein eigentliches Entwicklungsprojekt handelt, konnten wir keine Planung im klassischen Stil betreiben, da wir nicht wussten, was überhaupt auf uns zukommen wird. Zurückblickend kann gesagt werden, dass eine detaillierte Aktivitätenplanung im voraus für länger als eine Woche kaum möglich ist, da Produkte und Verfahren, die bei einer ersten Betrachtung vielversprechend ausgesehen haben, sich bei genauerem Studium als völlig untauglich entpuppen und umgekehrt. Militär Inbetriebnahme Infrastruktur Projektbesprechung Aufsetzen LiveCast-Server Aufsetzen Shoutcast-Server Aufsetzen Shoutcast-Source Installation Obsequieum Suche nach Proxy-Lösungen Einlesen Multicasting Krankheit Multiple Streams per LiveCaster Audio Live Stream Ressourcenanalyse Web-Oberfläche Daten kommerzielle Produkte Firmen kontaktieren für Details Daten nichtkommerz. Produkte SDR-Plugin ZHW-MBone-Anbindung Dokumentation José Fontanil & Reto Glanzmann José Fontanil Schulfreie Zeit Reto Glanzmann KW 21 KW 22 KW 23 KW 24 KW 25 KW 26 KW M D M D F M D M D F M D M D F M D M D F M D M D F M D M D F M D M D F Die relativ lange, krankheitsbedingte Abwesenheit von Reto Glanzmann brachte unsere am Anfang erstellte Grobplanung auch noch durcheinander. Wir verzichten hier deshalb, auf die Illustration aller Planungsversionen, da aus unserer Sicht das Schlussergebnis am aussagekräftigsten ist. Doku PA2_Sna06.sdw Seite R. Glanzmann & J. Fontanil

6 2. Grundlagen 2.1 Multicasting IP Multicasting Übersicht Schon Mitte 1993, noch bevor die Inflation von multimedialen Präsentationen im World Wide Web richtig angefangen hatte, war es für einige wenige schon möglich, die Übertragung eines Space-Shuttle-Flugs auf einer SUN-Workstation live miterleben zu können. Dies waren erste Anwendungen des IP-Multicasting im Rahmen des 1992 erschaffenen Multicast-Backbones, auch MBone genannt. Da der MBone nur ein virtuelles Overlay-Netzwerk auf der eigentlichen Internet- Struktur darstellt, ist es relativ einfach neue Verbindungen zu etablieren, da physisch keine neuen Leitungen geschaltet werden müssen. Multicasting bietet im Wesentlichen eine günstige und intelligente Möglichkeit, one-to-many und many-to-many Verbindungen zu ermöglichen, beziehungsweise zu routen. In den nächsten Kapiteln sollen der Aufbau des Multicast-Adressraums und die gebräuchlichsten Routing-Protokolle erläutert werden. Es werden auch zwei verschiedene Router vorgestellt. Weiter wird noch auf das Session Description Protokoll eingegangen. Mit ihm ist es möglich, seine Multicast Beiträge lokal oder weltweit anzukündigen. Es ist für das Verständnis des Resultats dieses Praktikums nicht nötig, Multicasting in dieser Tiefe verstehen zu müssen, jedoch ist es vorteilhaft Adressen Nun folgend wird der Aufbau der Layer 3 Multicast Adressen und deren Zuordnung zur Ethernet-Layer 2 Schicht näher betrachtet IP-Multicast-Adressen In der Version 4 des IP-Protokolls werden die verfügbaren 32Bit-Adressen zunächst einmal in grobe Adressräume unterteilt: A, B, C, D, E. Aus der Grafik kann man entnehmen, dass für die genauere Betrachtung nur die Gruppe D interessant ist. Der IP-Multicast-Adressraum umfasst alle IP-Adressen von bis (Siehe auch noch Kapitel ). Doku PA2_Sna06.sdw Seite R. Glanzmann & J. Fontanil

7 Multicast-Adressen werden keinem einzelnen Host, Router oder Netzwerkkarte zugeordnet. Multicast-Adressen werden einer sogenannten Multicast-Gruppe erteilt. Die Gruppenteilnehmer hören alle auf dieselbe, bekannte Multicast-Adresse und empfangen so die für sie bestimmten Daten. Die IANA (Internet Assigned Numbers Authority) hat den Multicast-Adressraum feiner unterteilt und je nachdem einzelnen Multicast-Anwendungen oder Routing-Protokollen zugeordnet. Die meisten dieser 'reservierten' Adressen dienen administrativen Zwecken oder enthalten Managementinformationen. Der Adressbereich zwischen und ist generell nur für die Managementkommunikation innerhalb eines Subnetzes vorgesehen und wird von Routern nicht über das lokale Netzwerk hinaus weitergeleitet. Die vollständige Liste aller reservierten Adressen findet man in der RFC Umsetzung der IP-Multicast Adresse in Multicast-MAC-Adressen im Ethernet Wie werden die Daten nun im Ethernet MAC-Layer (OSI-Layer 2) weiter verteilt? Im uns bekannten Unicast Fall geschieht das, indem dem IP-Paket der MAC-Header mit der entsprechenden MAC-Adresse (48 Bit) des Empfängers vorangestellt als Ethernet-Frame aufs Netz gesendet wird. Die Umsetzung beim Unicast übernimmt das ARP-Protokoll (Address Resolution Protocol). Da es sich beim Ethernet um ein Broadcast-Netz handelt, muss man ein IP-Multicast-Paket also nur aufs Netz legen und schon können alle im gleichen Netzwerksegment angeschlossenen Benutzer die Multicast-Pakete erhalten. Ethernet bietet weiter sogenannte Multicast-Adressen auf der MAC-Ebene, auch Hardware-Multicast genannt. Wenn ein User also einer Multicast-Gruppe beitritt, instruiert er seine Netzwerkkarte einfach dazu, diese Pakete an die IP-Schicht weiterzuleiten. MAC-Multicast-Adressen bestehen von links nach rechts gelesen aus der Herstellerkennung der IANA, welche im ersten Byte um ein Bit erhöht wurde ( E hex ). Die restlichen 24 Bit bilden das Kennzeichnungsfeld für die Multicast- Gruppe, wobei das erste Bit reserviert ist und immer 0 sein muss. Bei der Umsetzung einer 32 Bit langen IPv4-Adresse in eine MAC-Adresse, werden also NUR die 23 unteren Bits der IP-Adresse in die MAC-Adresse gemappt. Es wird in Kauf genommen, dass es zu Kollisionen und Mehrfachvergabe der gleichen Multicast-Gruppe auf einem Netzsegment kommen kann. Doku PA2_Sna06.sdw Seite R. Glanzmann & J. Fontanil

8 2.1.3 Internet Group Management Protocol (IGMP) IGMP dient dazu, die Multicast-Pakete zwischen den Routern und Gruppenmitgliedern in einem Netzwerksegment zu vermitteln. In den RFCs 1112 und 2236 wurden Version eins und zwei spezifiziert. Die Version drei ist in Abstimmung IGMP Version 1 Im IGMP-Protokoll gibt es zwei verschiedene Nachrichtentypen:? HOST-MEMBERSHIP-QUERY? HOST-MEMBERSHIP-REPORT Die Query-Nachrichten werden vom Router mit TTL=1 in periodischen Abständen auf die Multicast-Adresse gesendet, wobei die Abstände je nach Implementierung individuell eingestellt werden können. Üblich sind Werte zwischen ein bis zwei Minuten. Auf die Query-Anforderung antworten die Hosts im Netzsegment mit einem Report, aber jeder erst nach einer zufälligen Zeitspanne. Darin enthalten ist ihre Multicast-Gruppe, so sie denn einer angehören. Sind mehrere Rechner in der gleichen Multicast-Gruppe, greift das Prinzip mit dem zufälligen Zähler: Wenn ein Client schon einen Report zurück gesendet hat, sehen das die anderen Gruppenteilnehmer und senden daraufhin keine eigenen Reports. Ein Report kann auch unaufgefordert gesendet werden (join group). Ein 'leave group' gibt es in IGMP Version 1 noch nicht IGMP Version 2 Neu gibt es hier eine 'leave group' Anweisung, dadurch wurde die Latenzzeit für das Verlassen einer Gruppe und dadurch die unnötige Belastung des Netzwerks durch unerwünschte Pakete signifikant verringert. Damit das 'leave group' funktioniert, wird noch eine gruppenspezifische Query-Anfrage eingeführt, damit der Router anfragen kann, ob nach einem 'leave group' überhaupt noch jemand dieser Gruppe angehört, ohne zuviel Traffic zu erzeugen. Zum Schluss wurde noch das Verhalten bei mehreren Multicast-Routern in einem Netzwerksegment definiert. Der Router mit der tiefsten IP wird als Querier festgelegt. Doku PA2_Sna06.sdw Seite R. Glanzmann & J. Fontanil

9 2.1.4 Distance Vector Multicast Routing Protocol (DVMRP) Das bis heute am meisten verbreitetste Multicast Routing Protokoll DVMRP, wurde ursprünglich von Steeve Deering entwickelt und ist ein Routing Protokoll, das auf Basis von Distanzvektoren, also Hop-Counts, basiert. Eine frühe Version des Protokolls, eine Art Multicast-RIP, wurde in der RFC 1075 spezifiziert. Moderne Implementierungen beinhalten die starken Verbesserungen, die 1999 im Internet Draft draft-ietf-idmr-dvmrp-v3-09.txt festgehalten wurden. Der Aufbau des MBones und seine schnelle, weltweite Ausdehnung, geschah mit Hilfe dieses Protokolls und ist dem Umstand zu verdanken, dass es immer schon den frei verfügbaren Software-Multicast-Routing-Dämon mrouted für UNIX Betriebssysteme gab. DVMRP ist bekannt als ein 'prune and flood protocol' was heisst, dass DVMRP ähnlich wie IGMP arbeitet, aber über Netzwerksegmente hinweg. Schliesslich ist es ein Routing-Protokoll. Seit der Version drei routet mrouted auf der Basis vom Reverse Path Multicasting: Pruning: Der Sender S am Router R1 beginnt Daten an die Multicast-Gruppe G1 zu schicken, wofür die Kurzform (S,G1) üblich ist. RPB sorgt nun dafür, dass alle Router R1 bis R7 ein Paket der Übertragung erhalten (flooding). Truncated Reverse Path Broadcasting sorgt nun dafür, dass die Pakete nur an diejenigen LANs weitergeleitet werden, wo es auch zugehörige Gruppenmitglieder von G1 gibt (R3, R5). R7 und R6 stellen per IGMP fest, dass es in ihrem LAN keine zugehörigen Gruppenteilnehmer gibt und senden nun eine Prune-Nachricht an den jeweils vorderen Router im 'Multicast-Baum' zurück (pruning = beschneiden, entspricht abmelden). Damit ein Benutzer sich jederzeit in einer Multicast-Gruppe anmelden kann, wurde der grafting-mechanismus eingeführt. In unserem Beispiel meldet sich ein User über IGMP am Router R7 an. Dieser sendet nun eine Graft-Nachricht zum vorderen und dieser weiter bis zum Router R1. Danach wird R1 den G1 Multicast-Baum erweitern. DVMRP ist relativ einfach zu implementieren, hat aber den Nachteil, dass es einiges mehr an Ressourcen benötigt als z.b. PIM, da es die schon vorhandenen Unicast Routing-Tabellen nicht mitbenutzt. Weiter skaliert DVMRP schlecht und ist für grössere Netze deshalb weniger geeignet. Doku PA2_Sna06.sdw Seite R. Glanzmann & J. Fontanil

10 2.1.5 Protocol Independent Multicast (PIM) PIM bietet mit seinen beiden Modi dense und sparse im Gegensatz zu DVMRP auch Unterstützung von spärlich besetzten Regionen und die Verteilung mit möglichst geringen Verzögerungszeiten. Ein weiterer wichtiger Vorteil ist, dass PIM die schon vorhandenen Unicast Routingtabellen unabhängig vom eingesetzten Unicast-Routingprotokoll nutzt und dadurch Ressourcen spart. PIM ist zu schon existierenden Multicast-Routing-Protokollen wie z.b. DVMRP kompatibel und bietet eine erhöhte Skalierbarkeit (Steuermechanismen, Bandbreitenbedarf,...). Die Definition des PIM-Protokolls wurde in der RFC 2362 festgehalten PIM Dense Mode Der PIM Dense Mode (PIM-DM) arbeitet analog zum DVMRP Protokoll. Es handelt sich dabei auch um ein 'flood and prune' Protokoll. Der Unterschied zwischen DVMRP und PIM-DM liegt in der Ermittlung des kürzesten Pfades zum Sender. PIM-DM greift auf die im Router schon vorhandenen eigenen Unicast- Routing-Tabellen zu, während DVMRP eigene erstellen und verwalten muss. Insofern ist PIM-DM auch einfacher zu implementieren. Es müssen nur die Prune- Zustände bezogen auf die Gruppen gespeichert werden. Es ist nicht nötig, Routen zu berechnen. Dies hat den kleinen Nachteil, dass man etwas Flexibilität in Sachen Wegwahl einbüsst, da man den Multicast-Verkehr, den schon vorhandenen Routen entlang senden muss (Stichwort 'unsymmetrische Hin- und Rückwege') PIM Sparse Mode Die wichtigste Neuerung im PIM-Protokoll kommt eigentlich erst mit dem PIM Sparse Mode (PIM-SM). PIM-SM geht grundsätzlich davon aus, dass es keine Teilnehmer einer bestimmten Multicast Gruppe gibt und kann somit auf das 'flood and prune' Prinzip verzichten. In PIM-SM existieren ausgewählte Router als sogenannte Rendezvous Points (RP), bei denen sich die Teilnehmer zuerst anmelden müssen, bevor sie Multicast-Pakete einer bestimmten Gruppe erhalten. Sender müssen sich ebenfalls als RP registrieren. Ein PIM-SM Netz kann aus einem oder mehreren RPs bestehen, welche dann auch für verschiedene Multicast Gruppen zuständig sind. PIM-SM kann sowohl Shared Trees als auch Source-Based Trees aufbauen. Bei einem Shared Tree bildet der RP den initialen Kernverteilungsbaum. Es wird also ein gruppenspezifischer Shared Tree bestehend aus den Sendern und den Empfängern zusammengesetzt, die alle wiederum über einen RP miteinander verbunden sind. Beim Shared Tree senden die Sender ihre Pakete an den RP. Dieser weiss, wer die Multicast-Pakete empfangen will und leitet diese weiter. Ab einem gewissen Schwellenwert kann der RP den Shared Tree in einen Source- Based Tree umwandeln. Das heisst, dass der Verkehr nicht mehr über den RP läuft, sondern vom Sender direkt zu gewissen Teilnehmern. Doku PA2_Sna06.sdw Seite R. Glanzmann & J. Fontanil

11 1. Registrierung des Senders beim RP 2. Neuer Teilnehmer für Empfang 3 RP erweitert den Verteilungsbaum 4. Aufbau eines Source-based-Trees 5. Multicastverkehr auf dem kürzesten Pfad Zusammenfassend kann man also sagen, dass PIM wesentliche Verbesserungen gegenüber dem bisher bekannten DVMRP bietet. Es basiert nicht auf dem Fluten von Multicast-Paketen, sondern basiert auf einem expliziten Anmeldeverfahren an so genannten RPs. Es kombiniert die Möglichkeiten des Source-Based Tree (kürzester Pfad von Sender zu Empfänger) und des Shared Tree (nur Router im Pfad, die Teilnehmer haben) und geht effizienter mit Netzwerkressourcen um. Doku PA2_Sna06.sdw Seite R. Glanzmann & J. Fontanil

12 2.1.6 Inter-Domain Multicast Bisher haben wir nur Routingverfahren angeschaut, die primär auf einen Einsatz innerhalb einer Routingdomäne (Autonomous System, AS) zielen. Inter- Domain-Routing verlangt aber Unabhängigkeit von den in den AS eingesetzten Routingprotokollen, sollte möglichst nicht fluten und prunen (!) und wäre zuständig für den Aufbau der Multicastbäume über Domänen hinweg. Da dringender Handlungsbedarf bestand, hat sich die IETF dazu entschlossen, eine schnelle Lösung für internationales Multicast-Routing zu erstellen. Als eine Art Zwischenlösung entstanden dann die Protokolle Multicast Border Gateway Protocol (MBGP, Erweiterung der RFC 2283) und Multicast Source Discovery Protocol (MSDP). Eine ganzheitliche Problemlösung für internationales Multicast Routing sieht die IETF in Form des Border Gateway Multicast Protocols (BGMP, draft-ietf-bgmp-spec-02.txt) Multicast Border Gateway Protocol (MBGP) MBGP ist eigentlich kein 'eigenes' Protokoll. Der Name hat sich mittlerweile etabliert verweist aber lediglich auf die Multicast-Erweiterung des Border Gateway Protocol in der Version 4 (BGP-4, RFC 2283). Durch den Kennzeichner der Adressfamilie (SAFI), werden zwei neue BGP-4 Attribute hinzugefügt, welche den Austausch Multicast-relevanter Informationen erlaubt:? MP_REACH_NLRI Multiprotocol Reachable NLRI, die Menge der erreichbaren Ziele und deren Next-Hop-Information? MP_UNREACH_NLRI Multiprotocol Unreachable, die Menge der nicht erreichbaren Ziele Damit ist es nun möglich, Multicast-Routen separat von Unicast-Routen zu übermitteln, was zusätzlich den Vorteil hat, dass man für Unicast und Multicast getrennte Routing-Topologien konfigurieren kann. Der Einsatz von MBGP verhindert, dass der Grenzrouter eines Autonomen Systems (AS) die ganze Topologie des Multicast-Netzes kennen muss. Es genügt das Verständnis über die Topologie des eigenen AS und das Wissen um die Routen zu anderen AS Multicast Source Discovery Protocol (MSDP) MBGP regelt zwar den Austausch von Routinginformationen zwischen einzelnen AS, gibt aber keinerlei Auskünfte darüber, welche Domäne wann Teilnehmer in welcher Gruppe besitzt. Da PIM-SM ein explizites Anmelden der Gruppen-Teilnehmer beim entsprechenden Rendezvouz-Point Router erfordert, diese Router aber nur Multicast-Gruppen in der eigenen Domäne kennen, gibt es für einen Benutzer in der Domäne A keine Möglichkeit einer Multicast-Gruppe in der Domäne B beizutreten. Der Anmeldeversuch würde an den RP der Domäne A gesendet werden welcher die Multicast-Gruppe der Domäne B nicht kennt. Doku PA2_Sna06.sdw Seite R. Glanzmann & J. Fontanil

13 Das Multicast Source Discovery Protocol (MSDP, draft-ieft-msdp-spec-06.txt) erlaubt es also PIM-SM-Domänen mit eigenen RPs miteinander zu verbinden. MSDP basiert auf TCP-Verbindungen, um die Zuverlässigkeit der Übertragung zu gewährleisten. Dem für die Domäne verantwortlichen RP wird je eine MSDP Instanz zur Seite gestellt. Diese ist üblicherweise im gleichen Rechner installiert. MSDP funktioniert auch mit mehreren RPs pro Domäne, es wird dann einer ausgewählt, der die MSDP-Funktionalität für die Domäne übernimmt. Funktionsweise:? Jeder neue Teilnehmer der Multicast Daten sendet, ein Sender also, muss sich beim PIM-SM zuerst am für die Domäne verantwortlichen RP anmelden.? MSDP erkennt die neue Quelle und sendet einesource-active Nachricht an alle direkt verbundenen Nachbarn.? Ein MSDP Nachbar überprüft nun zuerst, ob die Nachricht von der richtigen Stelle her kommt (Endlosschleifenvermeidung). Ist dies der Fall, wird die Nachricht an alle Nachbarn weitergeleitet, ausser an den, von welchem die Nachricht erhalten wurde.? Will nun jemand einer entfernten Multicast-Gruppe beitreten, werden PIM-Join-Nachrichten an die Multicast-Senderadresse gesendet und der Multicast-Verteilbaum erweitert Border Gateway Multicast Protocol (BGMP) Dieses Protokoll stellt eine vollständige Interdomain Multicast Routing Architektur dar, hatte dafür aber etwas länger in der Entwicklung. Aktuell ist die Spezifikation vom November 2000 im IETF-Draft: draft-ietf-bgmp-spec-02.txt. BMGP etabliert wie PIM-SM gemeinsam genutzte Verteilungsbäume (Shared Tree), die jedoch im Gegensatz zu PIM bidirektional sind. Dies ermöglicht ein frühzeitiges erreichen der Teilnehmer einer Session auf der gleichen Hierarchieebene. Die Wurzel eines solchen Baumes ist immer eine ganze Domäne und nicht etwa ein einzelner Rechner. BGMP benutzt wie auch MSDP TCP, um zuverlässige Übertragungen der Routing-Informationen garantieren zu können. Das An- und Abmelden wird über Join- und Prune-Nachrichten vollzogen. Per KeepAlive-Nachrichten werden die Zustände periodisch aufgefrischt. BGMP arbeitet stark mit dem Unicast Border Gateway Protocol BGP zusammen und benutzt dessen Routing-Informationen, um die Verteilbäume zu generieren. BGMP unterstützt Classless Inter-Domain Routing (CIDR), welches schon seit einigen Jahren in Unicast-Netzen eingesetzt wird. Mit dieser wichtigen Funktionalität kann die Menge der zu übertragenden Routing-Informationen vermindert werden. Damit CIDR effizient mit Multicast eingesetzt werden kann, bedarf es einer strukturierten und hierarchischen Vergabe der Multicast-Adressen. Doku PA2_Sna06.sdw Seite R. Glanzmann & J. Fontanil

14 Dieser Problematik hat sich die Multicast Address Allocation Architecture (MAAA) angenommen. Darauf sei hier aber nicht weiter eingegangen. Wer mehr Informationen über MAAA benötigt, findet diese unter der Adresse der IETF Multicast Address Allocation Group Administrative Konzepte In den nächsten drei Kapiteln geht es um drei Kernprobleme, vor allem aus Administratoren-Sicht:? Reichweite der Multicast-Gruppen festlegen? Bandbreitenbegrenzung / Flusskontrolle des Multicast-Verkehrs? Da nicht alle Router über Multicastfähigkeiten verfügen müssen Tunnel eingerichtet werden können Multicast Scope Control Je nachdem, was der Inhalt des über Multicast gesendeten Materials ist, will man die Verbreitung eingrenzen können. Es gibt zwei Konzepte um die Reichweite von IP-Multicast-Paketen zu beschränken. Die Begrenzung des erreichbaren Bereichs über den Time To Live Wert (TTL) im IP-Header oder das administrative Scoping. TTL Beschränkung: Man setzt gezielt den TTL-Wert der Multicast-Pakete. Multicast-Router besitzen einen Konfigurationsparamter, der sogenannte treshold. Dieser ist eine Art Schwellwert einer Übertragungsleitung. Trifft ein Multicast Paket mit einem grösseren TTL als im treshold angegeben, bei einem Router ein, so wird das TTL dekrementiert und das Paket weitergeleitet. Ist der TTL Wert kleiner als der treshold, so wird das Paket verworfen. MBone De-Facto TTL-Standards Reichweite treshold lokales Subnetz 1 Innerhalb der Organisation / Institution 16 Innerhalb eines Landes 32 Innerhalb Europas 48 Ausserhalb Europas (z.b. USA) 64 Grösstmögliche Verbreitung (world) 255 Administrative Multicast-Bereiche: Da die Bereiche per TTL nur sehr grob 'beschrieben' werden können, hat man noch ein weiteres Konzept erarbeitet. Administratively Scoped IP Multicast (RFC 2365). Der administrative Multicast- Bereich ist ein definierter Bereich im Multicast-Adressraum. Er hat folgende Doku PA2_Sna06.sdw Seite R. Glanzmann & J. Fontanil

15 Eigenschaften:? Multicast-Pakete, die an administrative Multicast-Bereiche adressiert sind, überschreiben keine konfigurierten Administrationsgrenzen.? Adressen aus dem administrativen Bereich, werden lokal zugewiesen und besitzen deshalb nicht die Notwendigkeit, ausserhalb des Administrationsbereichs eindeutig zu sein. Der administrative Multicast-Bereich liegt zwischen und Es existiert noch eine weitere Unterteilung dieses Adressbereichs: Einsatzgebiet Adressbereich Nicht zugewiesen /10 Nicht zugewiesen /10 Nicht zugewiesen /10 Organisation / Institution /14 Reserviert für Erweiterung im lokalen Bereich /16 bis /16 Lokaler Bereich /16 Damit die administrativen Bereiche nutzbringend eingesetzt werden können, muss ein Multicast-Router die Konfiguration von IP-Multicast Bereichsgrenzen (Boundries) zulassen. Ein sogenannter Boundry-Router steht an der Grenze eines zu administrierenden Bereichs zu anderen Netzen. Der Router sperrt bidirektional alle Paket-Weiterleitungen an den Grenzen des administrativen Bereichs Bandbreitenlimitierung / Flusskontrolle Da der Multicast-Verkehr auf UDP basiert und somit keine Flusskontrolle hat wie z.b. der Sliding-Windows-Algorithmus vom TCP ihn bieten würde, muss man sein Netz vor Überbelastung schützen. Auch wenn der Verkehr das LAN verlässt und über das WAN geht, wo Bandbreite teuer ist, wäre man um eine Bandbreitenlimitierung froh. Da UDP keinen Rückkanal besitzt, wurde als 'Allerheilmittel' die Bandbreitenbeschränkung gewählt. Alle derzeit verfügbaren Implementierungen von Multicast-Router stellen eine Möglichkeit der Bandbreitenlimitierung zur Verfügung. Insbesondere bei Tunneln ist diese Limitierung wünschenswert. Beim bekannten Unix-Multicast-Routermrouted, konfiguriert man die Bandbreitenlimitierung mittelsrate_limit x, wobeix = Anzahl KBit/s ist. Bei den CISCO-Pendants kann man noch richtungsabhängig konfigurieren: rate-limit in und rate-limit out. Doku PA2_Sna06.sdw Seite R. Glanzmann & J. Fontanil

16 Aufsetzen eines IP-Multicast-Tunnels Das Internet besteht noch aus vielen nicht multicast-fähigen Routern. Trotzdem möchte man Multicast Inseln über viele Unicast-Strecken miteinander verbinden. Dies geschieht über Multicast-Tunnels. Hierbei wird eine virtuelle Unicast- Verbindung zwischen zwei Multicast Routern konfiguriert, die zwei oder mehrere direkt angeschlossene multicast-fähige lokale Netze miteinander verbindet. Multicast-Pakete aus dem LAN werden dann komplett in Unicast-IP-Datagramme mit der Adresse des Tunnelendpunkts verpackt und über normale Unicast-Routen ans Ziel befördert. Es wird dabei das IP over IP Protokoll benutzt (RFC 1700). Als Beispiel eine einfache Tunnelkonfiguration mit mrouted: tunnel IP1 IP2 metric 1 treshold 32 rate_limit 1000 Hier wird also ein Tunnel zwischen dem Router mit IP1 und einem anderen Router mit IP2 angelget. Der Tunnel bietet eine maximale Transferleistung von 1MBit/s für Multicastverkehr. Die Reichweite der Multicast-Pakete muss mindestens TTL=32 sein Router Hier soll nur erwähnt werden, wie es mit der IP-Multicast-Fähigkeit der heutigen Routern aussieht. mrouted ist der im MBone zur Zeit am meisten verbreitete Router, seine Handhabung ist sehr einfach. Leider unterstützt er nur das DVMRP Protokoll. Der mrouted wurde 1989 von Steve Deering an der Stanford University entwickelt. Die Weiterentwicklung lag danach beim Paolo Alto Centers, zur Zeit (Juni 2001) ist die Version 3.9 aktuell. Man sollte keine alten Versionen mehr benutzen, da es etliche Änderungen gegeben hat. Für den mrouted gibt es sogar ein SNMP- Interface und er ist für fast alle bekannten UNIXe erhältlich und gratis. CISCO Router unterstützen IP-Multicast seit der Betriebssystem Version IOS Die Version 10.2 ist jedoch ungenügend implementiert. Einsetzen sollte man kein IOS unter Version 11.1(9). CISCO Router bieten im Gegensatz zum mrouted das modernere Protokoll PIM an. Sie unterstützen sowohl PIM-SM als auch PIM-DM. Natürlich gibt es auch andere Router-Hersteller, die Multicast-Unterstützung bieten. Die beiden Alternativen mrouted und CISCO-Router sind aber die am meisten verbreiteten IP-Multicast-Router MBone Der erste Multicast-Tunnel wurde im Sommer 1988 zwischen der BBN und der Stanford University aufgeschaltet. Seit den ersten Live-Übertragungen von NASA-Missionen und Rock-Konzerten 1993, wuchs der MBone (Multicast-Backbone) enorm. Dank dem kostenlos verfügbaren UNIX Multicast Routingdämon mrouted, verbreiteten sich schnell überall auf der Welt Multicast-Inseln. Der Doku PA2_Sna06.sdw Seite R. Glanzmann & J. Fontanil

17 heutige MBone wird vor allem von den kontinentalen Forschungsnetzen gebildet (Europa: TEN-155, USA: vbns, CAIDA...). Die Kern-Router implementieren das Multicast-Netz direkt auf ATM-Verbindungen. Alle daran angeschlossenen Gegenstellen sind über MBGP und MSDP angeschlossen. Innerhalb der einzelnen MBone-Netzwerke läuft heute noch mehrheitlich das DVMRP Protokoll, beziehungsweise PIM-DM. Es gibt aber schon vereinzelte PIM-SM Inseln wurde noch angenommen, dass das Tunneling nur als Hack gebraucht werde, bis die Kern-Router Multicasting kennen. Diese Annahme erwies sich als falsch. Multicasting hat sich bis heute noch nicht breit genug durchgesetzt, so dass die meisten Neuanschlüsse immer noch per Multicast-Tunnel an den MBone angeschlossen werden. Bevor der MBone auch das Interesse der kommerziellen Provider weckte, war das Multicast-Netz eine reine 'Spielwiese' von Universitäten und Forschungseinrichtungen, welche auf diese Weise bereits erste Konferenzen ausserhalb der eigenen Netze realisieren konnten Zukünftige Entwicklungen In den folgenden Kapiteln wird jeweils kurz beschrieben, wie sich die zukünftigen Entwicklungen des Internets auf das Multicasting auswirken Multicast in IPv6 Mit IPv6 (RFCs 2373, 2526), haben wir sage und schreibe 1500 nutzbare IPv6- Adressen pro Quadratmeter Erdoberfläche. Klar ist, dass bei einer neuen Adresse auch die Adressauflösung anders vonstatten geht. Dies ist eine Auswirkung auf Doku PA2_Sna06.sdw Seite R. Glanzmann & J. Fontanil

18 das Multicasting. Eine IPv6-Multicast-Adresse beginnt mit acht auf eins gesetzten Bits, gefolgt von drei Nullen (future use) und dann, je nachdem ob es eine well-known IP-Adresse ist, ein 0 oder eine 1, wenn es sich um eine normale Adresse handelt. Dann folgen vier Bits, welche die Scope des Pakets definieren (von Node-local bis Global). Am Ende bleiben dann noch 112 Bits um die Multicast-Gruppe zu identifizieren. Weiter gibt es als grosse Neuerung die Anycast Adressierung: Anycast beschreibt die Adressierung eines beliebigen Knotens aus einer Gruppe von Rechnern. Über diese Technik wird das Adressieren von Multicast-Gruppen einfacher. Ein weiterer Vorteil von IPv6 ist, dass die Funktionalität vom IGMP Protokoll ins ICMPv6 (Internet Control Message Protocol) eingeflossen sind (QUERY, RE- PORT). IGMPv2 wird durch MLD (Multicast Listener Discovery, RFC 2710) ersetzt, das auf Basis von ICMPv6 arbeitet QoS-Unterstützung für IP-Multicast Die IETF bietet hier auch ohne IPv6 bereits QoS-Lösungen in einem IP-Netzwerk an: IntServ (Integrated-Services-Modell): Bietet zwar noch keine garantierte Übertragung an, unterstützt dafür aber bevorzugte IP-Pakete. Weitere Informationen findet man in den RFCs 2212 und RSVP (Resource-Reservation-Protocol): Dieses Signalisierungsprotokoll für Int- Serv ist in der RFC 2205 definiert. Über dieses Protokoll werden die Dienstklassen realisiert. RSVP bietet schon vom Konzept her eine gute Unterstützung für IP-Multicast. RSVP reserviert für einzelne Datenströme (definiert durch Quell-, Zieladresse und Portnummern) Netzressourcen. Diese Informationen werden in periodischen Abständen wiederholt gesendet um die Reservierungszustände in den Routern aufzufrischen. Da sich die Topologie des Multicast-Baums permanent ändern kann, werden so veraltete Reservierungen gleich implizit gelöscht. Bei Multicast-Gruppen mit mehreren aktiven Sendern (Konferenzen), werden in RSVP sogar verschiedene Reservierungstypen unterstützt. Ein weiterer Ansatz bietet noch die Differentiated-Service-Group der IETF, welche das Type-of-Service-Feld der IPv4 Headers benutzen will. Hier soll aber nicht näher auf den noch stark auf IP-Unicast ausgerichteten Ansatz eingegangen werden. Weitere Informationen findet man unter: draft-ietf-diffserv-framework- 02.txt und in draft-bless-diffserv-multicast-00.txt. Doku PA2_Sna06.sdw Seite R. Glanzmann & J. Fontanil

19 2.2 Streaming Streaming Übersicht Die Online-Radiostationen stossen auf grosses Interresse bei den Surfern. Das Radio ist als klassisches Tagesmedium besonders geeignet für das Internet. Berufsleute am Arbeitsplatz, Studenten und immer mehr Privathaushalte haben permanenten, breitbandigen Zugriff auf das globale Netzwerk. Gemäss einer Studie der amerikanischen Markforschungsfirma NPD hat bereits mehr als die Hälfte aller Internetsurfer schon einmal im Netz nach Audio- oder Videoangeboten Ausschau gehalten. Der Schwerpunkt des Nutzerinteresses liegt bei Musikprogrammen und Konzerten. Gemäss Schätzungen (Stand März 2000), sind 58 Prozent der Surfer, die Audiound Videoangebote via Internet nutzen männlich. Die meisten Nutzer sind zwischen 25 und 44 Jahre alt. Webcasting-Fans, auch Streamers genannt, haben darüber hinaus eine überdurchschnittlich gute Bildung. Diese soziodemographische Erkenntnis ist damit zu erklären, dass es momentan noch vorwiegend erfahrene Internetbenutzer sind, die mit Online-Audio und Videoangeboten vertraut sind. Dies wird sich aber in naher Zukunft sicher ändern, was Firmen und Schulen zwingen wird, sich Gedanken über die Verteilung und Unterbindung von Audio- bzw. Video-Livestreams zu machen Unicast Streaming Leider ist es heute noch so, dass der grösste Teil der Audio-Video Streams per Unicast übertragen wird. Dass heisst, dass jeder Zuhörer seine eigene Verbindung zum Streamingserver unterhält. Wollen z.b acht Leute an der ZHW DRS3 hören, so wird der gleiche Stream vom DRS3-Server acht mal an unsere Schule gesendet. Man kann sich leicht vorstellen, dass die benötigte Bandbreite für jeden weiteren Zuhörer linear ansteigt. Diesem Missstand kann durch Installation lokaler Proxy-/Relayingserver ein wenig entgegengewirkt werden (siehe Bild unten), da dann eigentlich der Proxy-/Relayingserver der einzige Empfänger des Streams ist und ihn dann im LAN an die Zuhörer verteilt. Dadurch wird die "teure" Leitung zum Internet wesentlich entlastet. Der Netzverkehr auf dem "billigen" LAN bleibt jedoch hoch. Die Übermittlung von Multimedia-Streams mittels Unicast hat jedoch auch nicht zu unterschätzende Vorteile. So kann die Übertragungsqualität individuell für jeden Zuhörer je nach Verbindungsqualität realtime verändert werden. Sollte die Verbindung zum Server für eine kurze Zeit ganz abreissen, kann der Mediaplayer aus dem Buffer die Empfangslücke für eine gewisse Zeit ausfüllen. Besteht die Verbindung dann zum Server wieder, so wird im Hintergrund der Buffer des Empfängers erneut gefüllt. So kann mit grosser Wahrscheinlichkeit ein Stream über lange Zeit unterbrechungsfrei empfangen werden. Ausserdem ist das Billing für kostenpflichtige Dienste sehr einfach zu realisieren. Doku PA2_Sna06.sdw Seite R. Glanzmann & J. Fontanil

20 CO L- H S1 HS2 OK1 OK2 PS ACT- H S1 HS2 OK1 OK2 PS STA CO L- ACT- STA - CO NSOLE CO NSOLE 6. Juli 2001 Benötigte Bandbreite für Unicast ohne einen Proxy- / Relaying-Server Streaming-Server 8 * 128 kbit/s = 1 Mbit/s Internet 8 * 128 kbit/s = 1 Mbit/s Hub/Switch Zuhörer Benötigte Bandbreite für Unicast mit einen Proxy- / Relaying-Server Streaming-Server Internet 1 * 128 kbit/s = 128 kbit/s Lokaler Proxy/ Relaying-Server 8 * 128 kbit/s = 1 Mbit/s Hub/Switch Zuhörer Doku PA2_Sna06.sdw Seite R. Glanzmann & J. Fontanil

21 2.2.3 Multicast Streaming Multicast Streaming erfreut sich langsam aber sicher immer grösserer Beliebtheit. Vor allem für den Streamer (Sender des Streams) bedeutet es eine enorme Kostenersparnis, da von seinem Server aus nur noch ein Stream gesendet wird. Will ein Zuhörer einen Media-Stream empfangen, so muss er seine Absicht dem Sender mitteilen. Dieser schaut dann dafür, dass der Zuhörer die Multicastpakete zugestellt bekommt. Wie wir bereits einige Kapitel früher erfahren haben, ist mit dem MBone (Multicast-Backbone) auch die nötige Technik im Backbonebereich vorhanden. Firmen und Schulen (die am MBone angeschlossen sind) können mittels Multicasting-Empfang unter Umständen enorm Bandbreite einsparen. Sofern man Campus-intern über eine multicastfähige Infrastruktur verfügt, aber nicht am MBone angeschlossen ist, kann man auch einen Proxy- / Relayingserver in Betrieb nehmen, der zwar die Streams per Unicast empfängt, dann aber per Multicast in das lokale Netz sendet. Somit entsteht vom Internet zum Campus auch nur eine einfache Bandbreitenbelastung, egal wie viele Hörer diesen Sender hören. Die Vorteile des Unicasting sind die Nachteile des Multicasting. Empfängt ein Hörer auf einmal keine Multicast-Pakete mehr, kann der Empfangsbuffer (welcher bei Empfangsbeginn gefüllt wird) zwar für eine gewisse Zeit den Player mit Daten versorgen, wenn der Hörer dann aber wieder Multicast-Pakete empfängt, kann der Buffer nicht wieder ohne Unterbruch gefüllt werden. Weil es halt eben Multicast ist und nicht individuell vom Sender auf die Probleme des Einzelnen eingegangen werden kann. Der unterbrechungsfreie Empfang über eine längere Zeit, ist also nicht gewährleistet. Ein nicht unwesentlicher Aspekt ist auch der Anschaffungskostenfaktor. Die wenigsten Firmen verfügen bereits über multicastfähige Netzwerktechnik, was dazu führt, dass aus Multicast ziemlich schnell Broadcast werden kann. Auch wenn die zur Verfügung stehende Bandbreite ständig wächst, die Zukunft liegt im Backbonebereich eindeutig beim Multicasting, weil dadurch enorme Bandbreitenersparnisse erwirkt werden können. In mikrosegmentierten LAN's ist der Einsatz von Multicasting unter Umständen zuerst abzuklären. Bandbreite in MBit/s Erforderliche Bandbreite Unicast vs. Multicast Multicast Unicast Anzahl Empfänger (gleicher Sender) Doku PA2_Sna06.sdw Seite R. Glanzmann & J. Fontanil

22 CONSOLE CONSOLE CONSOLE CONSOLE COL- HS1 HS2 OK1 OK2 PS ACT- STA COL- HS1 HS2 OK1 OK2 PS ACT- STA COL- HS1 HS2 OK1 OK2 PS ACT- STA COL- HS1 HS2 OK1 OK2 PS ACT- STA COL- HS1 HS2 OK1 OK2 PS ACT- STA COL- HS1 HS2 OK1 OK2 PS ACT- STA- CONSOLE CONSOLE 6. Juli 2001 Verkehrsaufkommen bei acht 128kbit/s Livestream-Empfängern (gleicher Sender) Unicast Streaming-Server 8 * 128 kbit/s = 1 Mbit/s Router 5 * 128 kbit/s = 0.5 Mbit/s 1 * 128 kbit/s = 128 kbit/s 3 * 128 kbit/s = 384 kbit/s Hub / Switch Hub / Switch Hub / Switch Multicast Streaming-Server 1 * 128 kbit/s = 128 kbit/s Multicastfähiger Router 1 * 128 kbit/s = 128 kbit/s 1 * 128 kbit/s = 128 kbit/s 1 * 128 kbit/s = 128 kbit/s Hub / Switch Hub / Switch Hub / Switch Doku PA2_Sna06.sdw Seite R. Glanzmann & J. Fontanil

23 SDP, SAP und SIP Das Session Description Protocol (SDP, RFC 2327) dient dazu Sitzungen zu beschreiben. Diese Beschreibungen werden mit Hilfe der Protokolle SAP, SIP, SMTP ( ) oder HTTP an potentielle Teilnehmer verteilt. Eine SDP-Beschreibung einer Session besteht aus reinem ASCII-Text, der die eigentliche Beschreibung der Session, den geplanten Zeitraum und die verwendeten Medien enthält. SDP SAP SIP HTTP SMTP UDP IP TCP In der oben abgebildeten Grafik wurde der im Multicasting meistens verwendete Fall, SDP in SAP über UDP über IP markiert. Man kann eine Session natürlich auch über HTTP und SMTP ankündigen, hierbei besteht aber das Problem, dass der potentielle Gruppenteilnehmer nicht zwingend auch Zugang zur angekündigten Session haben wird. Das Session Initiation Protocol (SIP, RFC 2543) erlaubt es Nutzer oder auch bestimmte Dienste explizit zu einer Sitzung einzuladen. Als Beschreibungsformat kommt wiederum SDP zum Zuge. Das Session Announcement Protocol (SAP, draft-ietf-mmusic-sap-v2-06.txt) dient zur Ankündigung von Sitzungen. Die Sitzungs-Ankündigungen werden periodisch an die festgelegte Multicast Adresse sap.mcast.net ( :9875) gesendet. Bei administrativem Scoping wird statt dieser well-known Adresse jeweils die höchste Multicast-Adresse des Adressbereichs genutzt. Wenn man mit Multicast-Streaming arbeitet, wird man früher oder später einmal über ein SDP-Announcement stolpern, sei dies im Cache vom Programm SDR oder wenn man die Announcements eines LiveCaster-Streaming Servers anschaut. Deshalb schauen wir nun noch an, wie eine SDR Nachricht aufgebaut ist. SDP Nachrichten werden also meistens via UDP und SAP verbreitet. Hierbei ist zu beachten, dass wenn man SAP verwendet, nur ein Announcement pro Paket gesendet werden darf und dass die SDP-Beschreibung nicht länger als 1kByte sein darf. UDP SAP Header SDP 1kByte max. Doku PA2_Sna06.sdw Seite R. Glanzmann & J. Fontanil

24 Der Aufbau einer SDP Nachricht ist zeilenweise in <type> = <value> Paare aufgeteilt. <type> ist dabei immer ein case-sensitives Zeichen, <value> ist ein zum <type> entsprechender String. Nun folgt eine Übersicht, welche Typen es in SDP gibt und was sie bedeuten: v Session Beschreibung Typ Wert Weitere Erklärungen Protokollversion o Ersteller der Session und Identifier <username> <session_id> <version> <network_type> <address_type> <address> s Name der Session i Optionale weitere Informationen Session bezogene Information u e p URI der Beschreibung Adresse des Erstellers Tel. Nr. des Erstellers c Connection Information Optional, wenn weiter unten schon angegeben b z k Bandbreiten Informationen Zeitzonenanpassungen Verschlüsselungs-Schlüssel a Null oder mehrere Attribute Genauere Beschreibung der Session Zeit bezogene Beschreibungen Typ Wert Weitere Erklärungen t Zeitblock in der die Session aktiv ist <starttime> <stoptime> Format: Dezimale Darstellung des Network Time Values r Null oder mehrere Repetitionen z.b. täglich, wöchentlich um 10Uhr morgens,... m i Medium Beschreibung Typ Wert Weitere Erklärungen Name des Mediums und Transport Adressen Titel des Mediums <media> <port/anzahl> <transport_protocol> <format_list> c Connection Information Optional wenn es oben schon angegeben wurde b k a Bandbreiten Informationen Verschlüsselungs-Schlüssel Null oder mehrere Medium- Attribute Doku PA2_Sna06.sdw Seite R. Glanzmann & J. Fontanil

25 Hier noch ein Beispiel einer SDP-Nachricht. Sie wurde aus dem Cache des SDR v.3.0 kopiert. Der Sender ist der LiveCaster Streaming Server: v=0 o= IN IP s=phpserver - WOLF FM - the hottest mix of the 70s, 80s and today! i=mp3 audio u= / e=fontajos@zhwin.ch t= a=type:broadcast a=tool:lc v1.0a83 m=audio RTP/AVP 14 c=in IP / RTP, RTCP und RTSP Was Streaming auszeichnet ist, dass man die gewünschten Daten schon während der Übertragung anschauen kann. Bei solchen Übertragungen ist es wichtig, eine niedrige Verzögerungszeit für den Empfang der Pakete zu gewährleisten. Probleme bei der Rekonstruktion des gesendeten Signals beim Empfänger treten insbesonderer dann auf, wenn Pakete unterschiedliche Verzögerungszeiten haben, auch Jitter genannt. TCP eignet sich nicht, da es jedes verloren gegangene Paket nochmals beim Sender anfordert. Der Empfänger müsste zu lange Wartezeiten hinnehmen. Verwendet man hingegen nur UDP, können Fehler in der Übertragung, übermässige Paketverluste und Änderung der Paketreihenfolge die Qualität negativ beeinflussen. Auch gibt es beim UDP kein Feedback über die Qualität der 'Verbindung'. Aus all diesen Gründen wurde 1991 das Real-Time Transport Protocol (RTP, RFC 1889) entwickelt. Es wurde primär für die Übertragung von kontinuierlichen Datenströmen, wie Audio- und Video, konzipiert. RTP stellt im Vergleich zu UDP zusätzliche Funktionalitäten bereit, bietet aber im Gegensatz zu TCP keine garantierte Übertragung aller gesendeten Pakete. RTP versieht die Audio- und Videopakete mit Zeitstempeln, um sie beim Empfänger wieder in die richtige Reihenfolge zu bringen. Sequenznummern werden verwendet, damit Paketverluste zuverlässig diagnostiziert werden können. Weiter können via RTP auch verschiedene Datenströme synchronisiert werden. RTP wird eigentlich immer über UDP versendet, es muss aber nicht. Denkbar wäre RTP auch direkt in einem ATM-Netzwerk auf dem Adaptation Layer 5 (AAL-5). RTP wird ausschliesslich für die Übertragung der Datenpakete verwendet. Damit man eine Kontrolle über die Qualität der Datenübertragung hat, verwendet Doku PA2_Sna06.sdw Seite R. Glanzmann & J. Fontanil

26 man das Real-Time Transport Control Protocol (RTCP, siehe auch RFC 1889, Kapitel 6). Über Sender- und Empfänger-Reports werden Informationen über die Qualität der Übertragung zwischen den Teilnehmern ausgetauscht (Paketverlustrate, u.s.w.). Das Real-Time Streaming Protocol (RTSP, RFC 2326) dient der Kontrolle von Multimedia-Echtzeit-Datenübertragungen. Es wurde 1996 von Real Networks, Netscape und der Columbia University entwickelt. RTSP bietet eine Art Fernbedienung für Multimedia Server (play, stop, u.s.w.). Für die Datenübertragung selbst, wird dann meistens RTP benutzt. Weiter überwacht es die Datenverbindung im Sinne einer Qualitätssicherung und bietet auch noch Urheberrechtsschutz-Funktionen. Eine Anmerkung am Rande: Für Shared Whiteboards (wb-dienst) und Text Applikationen muss eine gesicherte Datenübertragung existieren, deshalb wird hier nicht auf der Basis von UDP operiert, vielmehr wird der Reliable Multicast (RMC) Ansatz benutzt. Wer mehr über diesen neuen Ansatz wissen will, verweisen wir an die RMRG (Reliable Multicast Research Group der IETF) weiter. Interessantes zu diesem Thema findet man auch in 'NACK-Oriented Reliable Multicast (NORM) Protocol Building Blocks', festgehalten in dem draft-ietf-rmtnorm-bb-00.txt. Audio/Videoanwendungen RTCP RTP RTSP Whiteboard, Text- Tools Reliable MC UDP IP 2.3 Multicast Streams per Web publizieren (Bsp. Apache) Um einen Multicast Stream im RTP/AVP Format 14 per Weblink verfügbar zu machen, muss man wie folgt vorgehen: 1. Apache httpd.conf editieren und folgende Zeile hinzufügen: AddType audio/mpegurl.pls Tipp: Browsercache leeren und dann erst erneut versuchen auf die Datei zuzugreifen 2. Eine Homepage erstellen, die einen Link mit einer Datei z.b. song_1.pls enthält. (Genauerer Beschrieb, siehe auch Kapitel 6.1.5) Die Datei song1.pls enthält folgenden ASCII-Text und ist für alle lesbar: [playlist] numberofentries=1 File1=rtp:// :59106 Doku PA2_Sna06.sdw Seite R. Glanzmann & J. Fontanil

27 Der RTP-Protokoll-Link hinter File1 enthält die Multicast Adresse und Port. Wenn der Client nun einen Multicast fähigen Player hat (z.b. Winamp 2.7x inkl. in_rtp.dll), kann er diesen Stream per Mausklick aktivieren, einmal angenommen er ist in einem per Multicast erreichbaren Subnetz. 2.4 SDR MP3 Audio Plug-In SDR ist ein SAP und SDP Parser, mit welchem man bequem alle Sessions des MBones visualisiert und verwaltet. Man kann mit SDR auch via SIP andere zu Sessions einladen und eigene Sessions erzeugen. Damit man mit dem Programm SDR, die per SDP angekündigten MP3-Streams per Mausklick auf JOIN hören kann, muss ein Plug-In geschrieben werden, denn SDR muss wissen, mit welcher Anwendung es den MIME- Type mpegurl assoziieren soll. Dies ist allerdings nicht schwer. Folgender Text muss in eine Datei namens: sdr2.plugin.s07.audio.rtp.14.winamp im Verzeichnis Pfad\sdr\plugins gespeichert werden. (Unix: ~/.sdr/plugins/) media:audio proto:rtp/avp protoname:rtp tool:winamp fmt:14 { fmtname:mp3 audio flags: } flags:rtp://$(address):$(port) Dieses Plug-In ist für Winamp gedacht. Will man aber Freeamp starten, so muss man nur den Namen des Plug-Ins anpassen und in der Datei unter dem Punkt tool: Winamp durch Freeamp ersetzen. Wenn jemand Plug-Ins für andere Zwecke schreiben will, findet er eine ausführliche Anleitung in der Hilfe-Funktion des SDR-Programms. Doku PA2_Sna06.sdw Seite R. Glanzmann & J. Fontanil