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
Funktionsprinzip

Funktionsprinzip Zur Vorbereitung einer Echtzeit-Übertragung fordert der Empfänger für eine bestimmte Verbindung die erforderliche Dienstqualität (Quality of Service, QoS) an. Router leiten diese Anforderung an alle Netzknoten auf dem Pfad zum Sender weiter, die daraufhin entsprechende Ressourcen reservieren. RSVP ist empfänger-orientiert und kennt nur Simplex-Datenströme (d.h. Ströme in eine Richtung). Durch den gerade beschriebenen Vorgang werden daher nur Ressourcen für den Datenstrom vom Sender zum Empfänger reserviert. Sollen auch Ressourcen für den Rückkanal reserviert werden, muss der Sender diese selbst anfordern.

In einer Multicast-Umgebung werden die Anforderungen nur bis zum ersten Knoten weitergeleitet, in dem auch die Anforderungen anderer Empfänger eintreffen. Dort werden die Anforderungen kombiniert und eine entsprechende neue Anforderung weitergeschickt. Dadurch wird erreicht, dass der von Reservierungen erzeugte Overhead logarithmisch und nicht linear mit der Zahl der Empfänger steigt.

Da die Zahl der Teilnehmer in einer großen Multicast-Umgebung sehr wahrscheinlich variabel ist und sich Routing-Pfade verändern können, wird der Reservierungszustand in den einzelnen Knoten dynamisch gespeichert (soft state): RSVP sendet periodische Refresh-Nachrichten an die einzelnen Knoten. Bleiben diese an einem bestimmten Knoten aus, so wird die Reservierung dort automatisch gelöscht.

RSVP-Nachrichten

RSVP-Nachrichten Als Kontrollprotokoll funktioniert RSVP durch den Austausch von Nachrichten zwischen beteiligten Netzknoten. Die beiden wichtigsten Nachrichten sind Path und Resv (Reservation Request).

Jeder Sender überträgt zunächst Path-Nachrichten an den oder die Empfänger, die den kommenden Datenstrom beschreiben. Diese Nachrichten sind genauso adressiert wie die Datenpakete (als Absender- und Empfängeradresse sind die Endpunkte der Übertragung gesetzt) und werden daher genauso geroutet. In jedem Knoten, den sie passieren, wird ein Pfadzustand gesetzt, der unter anderem die IP-Adresse des vorhergehenden Knotens enthält.

Erreicht die Path-Nachricht einen Empfänger, so sendet dieser eine Resv-Nachricht zurück, in der die gewünschte Ressourcen-Reservierung definiert ist. Um sicherzustellen, dass Resv-Nachrichten auf dem gleichen Weg zurücklaufen, den später die Datenpakete nehmen, werden Resv-Nachrichten Knoten für Knoten auf dem Weg versandt, den auch die Path-Nachrichten genommen haben (mit Hilfe der im Pfadzustand gespeicherten Adresse des jeweils vorhergehenden Knotens). In jedem Knoten, den die Resv-Nachricht passiert, wird ein Reservierungszustand gesetzt, der die für diesen Datenstrom reservierten Ressourcen beschreibt.

Nach Empfang der Resv-Nachricht beginnt der Sender schließlich, seine Daten an den oder die Empfänger zu übertragen.

Soft-State-Prinzip

Soft-State-Prinzip Je nach Netzbedingungen kann sich das Routing der Datenpakete mit der Zeit verändern, weil z.B. ein Knoten ausfällt. In diesem Fall würden zum einen die Datenpakete über neue Knoten ohne Ressourcenreservierung geleitet und somit die Empfangsqualität leiden; zum anderen blieben in den nicht mehr genutzten Knoten dennoch Reservierungen bestehen, die andere Übertragungen unnötig einschränken.

Um dies zu vermeiden, verwendet RSVP für die Pfad- und Reservierungszustände ein Soft State-Prinzip: Pfad- und Reservierungszustand müssen periodisch aufgefrischt werden, um nicht zu verfallen. Der Sender überträgt daher auch nach dem Aufbau der Verbindung periodisch Path-Nachrichten. Zum einen wird so der Path-Zustand in den zugehörigen Knoten aufgefrischt, zum anderen wird bei Routing-Änderungen auch in den Knoten des neuen Pfads umgehend für eine Reservierung gesorgt - denn auch der Empfänger überträgt periodisch weiter Resv-Nachrichten, die über die gesamte Kette weitergeleitet werden und in allen besuchten Knoten die Reservierungen auffrischen bzw. neu anlegen.

Verfällt in einem Knoten der Pfad- oder Reservierungszustand, weil keine rechtzeitige Auffrischung erfolgte, so sendet er PathTear- bzw. ResvTear-Nachrichten an seine Nachfolger- bzw. Vorgängerknoten, um die reservierten Ressourcen auch dort unmittelbar freizugeben.

Natürlich können in jedem Knoten mehrere Pfad- und Reservierungszustände für verschiedene Datenströme, die über diesen Knoten laufen, gespeichert sein.

RSVP | Reservierungsmechanismus >

© 2000 Matthias Book