Resv-Nachricht: Flow Spec

Betrachten wir eine Resv-Nachricht genauer: Kern jeder Reservierungsanforderung ist der sog. Flow Descriptor. Er besteht aus einer Flow Spec, die eine bestimmte Dienstqualität (QoS) definiert, und einer Filter Spec, die die Datenpakete definiert, denen diese QoS zugute kommen soll.

In der Flow Spec werden die Dienstklasse (Controlled-Load oder Guaranteed Service), die gewünschte QoS und der Datenstrom beschrieben [RFC 2210].

In der Dienstklasse Controlled-Load Service bekommt der Datenstrom mit Hilfe von Zugangskontrollmechanismen auch in Überlastsituationen annähernd die QoS zugeteilt, die er auch von einem unbelasteten Netzknoten erhalten würde [RFC 2211]. Guaranteed Service stellt sicher, dass die Ende-zu-Ende-Verzögerung sich innerhalb definierter Grenzen bewegt und garantiert so ein festes Maß an Verzögerung und Bandbreite [RFC 2212].

Die gewünschte QoS wird in einer Reservation Spec (RSpec) definiert, die von RSVP jedoch nur blind übertragen wird. Für die Auswertung der RSpec-Parameter wie Rate (zu übertragende Bytes/Sekunde) und Slack Term (Differenz zwischen gewünschter und angebotener Verzögerung) ist der Netzknoten verantwortlich. Gleiches gilt für die Traffic Spec (TSpec), die den Datenstrom mit Hilfe von Parametern wie Peak Data Rate und Maximum Packet Size beschreibt.

Resv-Nachricht: Filter Spec

Die Filter Spec ist der Teil der Reservierungsanforderung, der definiert, welchen Datenpaketen die gewünschte QoS zugute kommen soll.

Datenpakete werden über die IP-Adresse und (optional) den Quellport ihres Senders gefiltert. Anstatt des Quellports kann bei IPv6 auch der Flow Label verwendet werden, der in jedem Paketheader enthalten ist und einen bestimmten Datenstrom vom Sender zum Empfänger eindeutig identifiziert.

Je nachdem, ob IPv4 oder IPv6 als zugrundeliegendes Protokoll verwendet wird, sind also folgende Filter Spec-Formate möglich:

• IPv4-Absenderadresse (4 Bytes) und Quellport (2 Bytes)
• IPv6-Absenderadresse (16 Bytes) und Quellport (2 Bytes)
• IPv6-Absenderadresse (16 Bytes) und Flow Label (3 Bytes)

Auch wenn in der aktuellen RSVP-Spezifikation nur diese Parameter als Filter vorgesehen werden, können prinzipiell beliebige Parameter des Übertragungs- bzw. übertragenen Protokolls verwendet werden.

Path-Nachrichten enthalten ähnliche Informationen zur Beschreibung des zu erwartenden Datenstroms: Auch sie verwenden eine Filter Spec, um die Pakete des Datenstroms zu identifizieren, sowie eine TSpec, um die Charakteristika des Datenstroms anzugeben.

Reservierungsmechanismus

Betrachten wir nun genauer, wie die Reservierung in jedem Knoten, der eine Resv-Nachricht erhält, abläuft.

Empfängt ein Knoten eine Reservierungsanforderung, so übergibt der dort laufende RSVP-Prozess die Nachricht zunächst an die Admission Control, die überprüft, ob der Knoten über genügend Ressourcen verfügt, um die gewünschte QoS bereitzustellen, und an die Policy Control, die überprüft, ob der Benutzer das Recht hat, diese Reservierung durchzuführen. Wie schon die QoS-Parameter werden auch die Policy-Parameter von RSVP nur blind übertragen, jedoch nicht interpretiert [RFC 2750].

Verlaufen beide Checks positiv, so werden Packet Classifier und Packet Scheduler konfiguriert: Der Packet Classifier ordnet jedes empfangene Datenpaket einer QoS-Klasse zu. Er wird entsprechend der Filter Spec eingestellt. Der Packet Scheduler hingegen bestimmt die Reihenfolge, in der die Datenpakete weitergeleitet werden und ist somit für die Realisierung der QoS verantwortlich. Er wird so eingestellt, dass er die in der Flow Spec definierte QoS liefert (Diese Einstellungen gelten jeweils für einen Datenstrom, von denen jeder Knoten natürlich mehrere handhaben kann).

Anschließend wird eine neue Resv-Nachricht an den nächsten Upstream-Knoten auf dem Pfad zum Sender weitergeleitet. Diese Reservierungsanforderung kann sich von der empfangenen unterscheiden, da in einem Knoten die Anforderungen mehrerer Empfänger zusammenlaufen können. In diesem Fall wird nur eine Anforderung weitergeleitet, die eine Kombination der Einzelanforderungen darstellt.

< Funktionsprinzip | Fazit: RSVP >