Papers
Papers
Home > Papers > RSVP/RTP
RSVP | Funktionsprinzip | Reservierungsmechanismus | Fazit: RSVP | RTP | Anwendungsfälle | RTCP | Fazit: RTP/RTCP | Literatur | Folien

Resource Reservation Protocol / Realtime Transport Protocol
Resource Reservation Protocol (RSVP)

Protokolle wie die Komponenten der H.323-Suite definieren die Codierung von Multimedia-Daten mit dem Ziel, sie in Netzwerken zu übertragen. Die Übertragung von Multimedia-Daten unterscheidet sich jedoch in einem wesentlichen Punkt von der Übertragung "konventioneller" Daten wie Mails oder Web-Seiten: Sie muss in Echtzeit erfolgen, d.h. der vom Sender ins Netz eingespeiste Datenstrom muss beim Empfänger ohne Unterbrechungen ankommen, um Aussetzer (z.B. im Videosignal) zu vermeiden. Unterbrechungen im Datenstrom werden durch Verzögerungen oder Paketverluste verursacht, die auftreten, wenn im Netz nicht genügend Bandbreite zum Transport von Paketen zur Verfügung steht. Um Echtzeitdaten störungsfrei transportieren zu können, ist daher die Reservierung entsprechender Bandbreite auf dem Übertragungspfad notwendig.

Zudem werden Multimediadaten im Gegensatz zu "konventionellen" Daten oft nicht Punkt-zu-Punkt übertragen, sondern (z.B. bei Konferenzen) zwischen mehreren Teilnehmern ausgetauscht, die unter Umständen über unterschiedlich leistungsfähige Netzanbindung und Hardware verfügen.

Die Protokolle RSVP und RTP werden eingesetzt, um diesen Problemen zu begegnen: Das Resource Reservation Protocol (RSVP) steuert die Reservierung der Bandbreite [RFC 2205], während der eigentliche Transport von Echtzeitdaten zwischen den Teilnehmern vom Realtime Transport Protocol (RTP) geleistet wird [RFC 1889].

Wir befassen uns zunächst mit dem Resource Reservation Protocol (RSVP) und gehen danach auf das Realtime Transport Protocol (RTP) ein.

Wir gehen dabei top-down vor, indem wir zunächst die grobe Funktionsweise von RSVP betrachten, dann die wichtigsten Nachrichten und Zustände kennenlernen und schließlich untersuchen, wie mit diesen Mitteln die Reservierung von Ressourcen erreicht wird.

Motivation: Wozu RSVP?

Auf den ersten Blick scheint die Einführung eines eigenen Protokolls zur Reservierung von Bandbreiten nicht notwendig zu sein - folgende Argumente werden immer wieder ins Feld geführt [RFC 1633]:

"Die künftig nutzbare Bandbreite wird fast unbegrenzt sein."
Die Bandbreite moderner Medien wie der Glasfaser ist zwar so groß, dass der Eindruck entstehen kann, sie reiche für alle Anwendungen aller Nutzer aus. Auch in Zukunft werden jedoch kaum alle beliebigen Endpunkte eines Netzes durchgängig über Hochleistungsmedien verbunden sein; an "Flaschenhälsen" sind Staus dann vorprogrammiert.

"Einfache Prioritätsvergabe reicht aus."
Die Einstufung von Echtzeitverkehr in eine Prioritätsstufe, die bevorzugt behandelt wird, kann nur funktionieren, wenn nicht zu viele Echtzeit-Datenströme die höhere Prioriät beanspruchen. Ab einem gewissen Punkt sinkt sonst die Bandbreite, die jedem Strom zur Verfügung steht.

"Anwendungen sollten flexibel mit wechselnder Bandbreite umgehen."
Hinreichend flexibel ausgelegte Anwendungen können kurzzeitige Aussetzer oder Bandbreitenschmälerungen zwar technisch überbrücken, ab einem gewissen Punkt ist sinnvolles Arbeiten für den Benutzers jedoch nicht mehr möglich (z.B. bei Videokonferenzen). Zudem gibt es Anwendungen, bei denen Aussetzer im Echtzeitdatenstrom schwerwiegende Konsequenzen haben können (z.B. Roboter-Telemetrie).

Funktionsprinzip >

© 2000 Matthias Book