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]: