Resource Reservation Protocol

 Das RSVP-Protokoll [#!rfc2205!#] ist ein Signalisierungsprotokoll der OSI-Schicht 4 mit dem Anwendungen Ressourcen eines Netzes anfordern können. Das Netz gewährt diese Anforderungen oder lehnt sie ab. Durch Angabe der gewünschten IntServ-Dienstgüte kann eine Anwendung die für diese Dienstgüte benötigten Ressourcen spezifizieren. Für den Datentransport werden gängige Schicht 4 Protokolle, wie zum Beispiel TCP und UDP, eingesetzt (siehe Abbildung ).

 

Abbildung:   Dienstgüte-Signalisierung mit RSVP

RSVP trennt klar zwischen den Aufgaben, Bereitstellung von Ressourcen und Anforderung von Ressourcen. Für die Anforderung ist RSVP zuständig für die Bereitstellung das Traffic Control.

Mit RSVP-PDUs werden die Anforderungen zu den RSVP-Protokoll-Instanzen (RSVP-Prozesse), die für die einzelnen Subnetze verantwortlich sind, transportiert. Dort versucht der RSVP-Prozeß die Ressourcen im Subnetz anzufordern. Eine Anforderung kann aus zwei Gründen abgelehnt werden. Der erste Grund ist, daß eine Person nicht berechtigt ist die Dienstgüte anzufordern. Dies stellt RSVP durch Anfrage beim Policy Control fest (siehe Abbildung ).

 

Abbildung:   RSVP im Host und Router

Der zweite Grund ist, daß nicht genügend Ressourcen vorhanden sind. Dies erfährt RSVP vom Traffic Control, daß die Anforderung der Ressourcen ablehnt. Das Traffic Control besteht aus den Teilen: Classifier, Scheduler und Admission Control. Das Admission Control hat die Ressourcen zu verwalten. Es überprüft, ob einem Fluß eine Dienstgüte gewährt werden kann, ohne die Dienstgüten bestehender Flüsse zu gefährden. Kann die Dienstgüte gewährt werden, sorgen der Classifier und der Scheduler für die richtige Behandlung der PDUs eines Flusses.

Um die Anforderungen zu den RSVP-Prozessen zu bringen, sind zwei Phasen nötig:

• Es wird ein Pfad zwischen einem Sender und den Empfängern im Netz festgelegt.
• Auf diesem Pfad werden die Anforderungen gestellt.

RSVP besitzt die PDUs Path und Resv für diese zwei Phasen. Mit Path-PDUs wird der Pfad für einen Fluß im Netz festgelegt. Sie werden von einem RSVP-Prozeß des Senders erzeugt und dann von einem RSVP-Prozeß über den nächsten zum Empfänger gesendet. Ein Empfänger legt die Reservierung fest und sendet eine Resv-Nachricht auf dem Pfad zurück zum Sender (siehe Abbildung ).

 

Abbildung:   Reservierung

Eine Path-PDU hat folgenden Aufbau:

<Path Message> ::= <Common Header> [ <INTEGRITY> ]
                   <SESSION> <RSVP_HOP>
                   <TIME_VALUES>
                   [ <POLICY_DATA> ... ]
                   [ <sender descriptor> ]
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
                        [ <ADSPEC> ]

Im Header einer RSVP-Nachricht ist das Feld Time To Live (TTL). Dieses Feld ermöglicht es nicht RSVP-fähige Geräte auf dem Pfad zu erkennen. Jeder Router verringert das Feld TTL im IP-Header, aber nur ein RSVP-Router verringert das TTL-Feld im RSVP-Header. Unterscheiden sich beide, dann wurde eine RSVP-PDU von einem nicht RSVP-fähigen Router weitergeleitet.

Das Objekte POLICY_DATA überträgt die Daten die ein RSVP-Prozeß dem Policy Control übergibt. Mit dem Objekt INTEGRITY wird die Authentizität eine RSVP-Nachricht sichergestellt. Die Bedeutung von TIME_VALUES wird später erklärt.

Es soll nun genauer beleuchtet werden, welche Aufgaben die Path-PDU erfüllt.

1.

Sie identifiziert den Datenfluß.
Um die Flüsse einzeln behandeln zu können, müssen die Daten und die RSVP-PDUs den Flüssen zugeordnet werden können. Durch einen Identifikator wird die Zugehörigkeit der Path-PDUs zu einem Fluß festgelegt. Der Identifikator eines Flusses besteht aus den Objekten SESSION und SENDER_TEMPLATE. In SESSION wird die IP-Adresse des Empfängers, das verwendete Transportprotokoll und weitere Demultiplex-Information, z.B. Portnummer bei TCP und UDP, angegeben. SENDER_TEMPLATE enthält die IP-Adresse des Senders und die Demultiplex-Information des Transportprotokolls.

2.

Sie legt den Weg für den Datenfluß im Netz fest.
Es muß ein Pfad für den Datenfluß festgelegt werden, damit die PDUs eines Flusses alle den Weg entlang des Pfad folgen. Denn nur hier erfolgen die Reservierungen und die PDUs erhalten ihre Dienstgüte. Zur Aufzeichnung des Pfads dient das Objekt RSVP_HOP. Hier wird die IP-Adresse des letzten Geräts mit einem RSVP-Prozeß, das von der Path-Nachricht durchlaufen wurde, festgehalten. Diese IP-Adresse speichert ein RSVP-Prozeß und ersetzt es durch die eigene. Mit diesem Verfahren wird der Weg der Nachricht festgehalten.

3.

Sie beschreibt den Datenfluß, der vom Sender erzeugt wird.
Zur Erzeugung der Information über die Dienstgüte des Flusses, benötigt der Empfänger eine Beschreibung des Datenflusses, den der Sender erzeugt. Der Verkehr, der vom Sender erzeugt wird, wird mit SENDER_TSPEC beschrieben. Ein Bestandteil den alle SENDER_TSPEC, enthalten ist der TOKEN_BUCKET_TSPEC [#!rfc2215!#] mit folgender Information:

• Peak Data Rate
  Die Peak Data Rate ist die maximale Bitrate mit der die Anwendung Daten aufs Netz schicken darf.
• Token Bucket Rate (TBR)
  Die Token Bucket Rate und die Token Bucket Size sind Bezeichnungen, die dem Leaky-Bucket Algorithmus entspringen (siehe Abbildung ).
  
   

  Abbildung:   Leaky Bucket Algorithmus

  
  Bestandteile des Leaky Bucket Algorithmus sind ein Bucket und ein Generator. Der Generator erzeugt Token mit der Rate TBR. Diese Token werden in einem Eimer (Bucket) aufgefangen. Die Größe des Eimer ist die Token Bucket Size (TBS). Für jede Einheit (z.B. Octet), die gesendet werden will, muß ein Token aus dem Eimer entnommen werden. Sind keine Token mehr vorhanden, muß die Einheit weggeworfen werden. Werden weniger Token aus dem Eimer genommen, wie reinfallen, so läuft der Eimer über und Token gehen verloren. Die Token Bucket Rate und die Token Bucket Size begrenzen somit die maximale Datenmenge, die in einem Zeitraum der Länge erzeugt werden darf. Außerdem kann mit dem Leaky Bucket Algorithmus die Burstiness des Verkehrs beschrieben werden. Ist ein Verkehrsprofil durch relativ niedrige Bitraten über einen langen Zeitraum geprägt, daß durch relativ kurzfristige Übertragung mit hohen Bitraten unterbrochen ist, so werden diese kurzen Phasen als Bursts bezeichnet (siehe Abbildung ). Bei gleicher durchnittlicher Bitrate braucht ein Verkehr mit Bursts eine größere TBS als einer ohne.
  
   

  Abbildung:   Token Bucket Rate

  
  
• Token Bucket Size (TBS)
• Minimum Policed Unit
  Die Minimum Policed Unit ist die minimale Paketgröße, die eine Anwendung verwendet. Sie enthält die Header aller Protokolle überhalb von IP.
• Maximum Packet Size
  Die Maximum Packet Size ist die maximale Paketgröße.

4.

Sie liefert die Information über die gewünschte Dienstgüte und das Netz.
Im Objekt ADSPEC kann der Sender Vorschläge für die gewünschte Dienstgüte machen [#!rfc2210!#]. Dieses Objekt enthält auch die Information, die auf dem Weg durch das Netz für die gewünschten Dienstgüte gesammelt wurde (z.B. ob die gewünschten Dienstgüten verfügbar sind).

Die Resv-PDU hat folgenden Aufbau:

<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
                   <SESSION> <RSVP_HOP>
                   <TIME_VALUES>
                   [ <RESV_CONFIRM> ] [ <SCOPE> ]
                   [ <POLICY_DATA> ]
                   <STYLE> <flow descriptor list>
<flow descriptor list> ::= <empty> |
                           <flow descriptor list> | <flow descriptor>

Die Resv-Nachricht enthält die Objekte SCOPE und RESV_CONFIRM. Das Objekt SCOPE wird verwendet, um einen Effekt, der durch den Wildcard-Filter entstehen kann, vorzubeugen (siehe [#!rfc2205!#]). Mit RESV_CONFIRM kann der Empfänger die Bestätigung einer Reservierung veranlassen. Die Bedeutung der anderen Objekte wird anhand der beiden Aufgaben der Resv-Nachricht erklärt.

Die Aufgaben der Resv-PDU sind:

1.

Legt den Identifikator fest.
Der Identifikator ist abhängig von der verwendeten Reservierungsart. RSVP kennt drei Reservierungsarten (siehe Tabelle ).

 

Sender 2|c|Reservation

Selection Distinct Shared

Fixed-Filter Shared-Explicit

[-1.5ex]Explicit (FF) Style (SE) Style

(None defined) Wildcard-Filter

[-1.5ex]Wildcard (WF) Style

Ein RSVP-Fuß wird durch SESSION und FILTER_SPEC identifiziert und durch FLOWSPEC charakterisiert. FILTER_SPEC trägt den selben Inhalt (identifiziert Sender), wie SENDER_TEMPLATE in der Path-Nachricht. Der Fixed-Filter (FF) nutzt SESSION und FILTER_SPEC, um einen Fluß zu identifizieren.

<flow descriptor list> ::= <FLOWSPEC> <FILTER_SPEC> |
                           <flow descriptor list> <FF flow descriptor>
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC>

Mit einer Resv-Nachricht kann ein Empfänger mehrere RSVP-Flüsse reservieren lassen. Ein RSVP-Fluß nach dem FF kann einen Sender und einen Empfänger (siehe Abbildung ) haben, wird in SESSION eine Multicast-Adresse verwendet, aber auch mehrere Empfänger (siehe Abbildung ). Auf jeden Falls gibt es nur einen Sender.

 

Abbildung:   Unicast

 

Abbildung:   Multicast

Der Wilcard-Filter (WF) läßt FILTER_SPEC und damit den Sender offen. Ein RSVP-Fluß kann also von mehreren Sendern genutzt werden, damit lassen sich die Ressourcen besser ausnutzen.

<flow descriptor list> ::= <WF flow descriptor>
<WF flow descriptor> ::= <FLOWSPEC>

Ein RSVP-Fluß kann somit Many-to-One (siehe Abbildung ) oder Many-to-Many (siehe Abbildung ) sein.

 

Abbildung:   Many-to-One

 

Abbildung:   Many-to-Many

Der Filter Shared-Explicit (SE) erlaubt es ebenfalls, wie der Wildcard-Filter, daß sich mehrere Sender einen RSVP-Fluß teilen. Der Unterschied zum WF-Filter ist, daß die Sender explizit benannt werden müssen. Dies erfolgt durch eine Liste von FILTER_SPEC.

<flow descriptor list> ::= <SE flow descriptor>
<SE flow descriptor> ::= <FLOWSPEC> <filter spec list>
<filter spec list> ::= <FILTER_SPEC>
                       | <filter spec list> <FILTER_SPEC>

Ein Beispiel für eine sinnvolle Anwendung für eine Shared-Reservierung wäre eine Audio-Konferenz, denn es gibt hier immer nur einen Sprecher und damit einen Sender gleichzeitig.

2.

Legt die Reservierung fest.
Die zu reservierende Dienstgüte und die dafür benötigten Parameter werden in FLOWSPEC übergeben. Der Aufbau des FLOWSPEC ist durch den IntServ-Dienst [#!rfc2210!#] gegeben. Für Controlled-Load ist er wie der TOKEN_BUCKET_TSPEC aufgebaut. Garanteed Service besitzt neben TOKEN_BUCKET_TSPEC noch weitere Parameter [#!rfc2212!#], auf einige wird später noch eingegangen.
Ein RSVP-Fluß kann mehrere Empfänger haben, daher können in einem RSVP-Prozeß mehrere Resv-Nachrichten für den selben Fluß, aber mit unterschiedlichem FLOWSPEC, eingehen (siehe graue Knoten in Abbildung ).

 

Abbildung:   Verschmelzen von Datenflüssen

Trifft bei einem RSVP-Prozeß eine Resv-Nachricht für einen bereits bestehenden Fluß ein, dann erzeugt er einen neuen FLOWSPEC, ändert die Reservierung entsprechend, und sendet ihn mit einer Resv-Nachricht Richtung Sender oder er verwirft die Resv-Nachricht. Ersteres tritt ein, wenn ein Empfänger dieses Flusses mit der bereits bestehenden Reservierung nicht befriedigt werden kann. Es wird dann ein FLOWSPEC generiert, der die Bedürfnisse aller Empfänger erfüllt. Falls der eingehende FLOWSPEC geringere Anforderungen an den Fluß stellt, wird die Resv-Nachricht verworfen, um den Overhead des RSVP-Protokolls so klein wie möglich zu halten.

RSVP verwendet sogenannte Soft States, d.h. die Zustände [#!rfc2209!#], die durch Path- und Resv-Nachrichten in den RSVP-Prozessen erzeugt werden, werden nach Ablauf eines Intervalls gelöscht. Das Löschen eines Zustand führt zur Freigabe der Ressourcen. Jeder RSVP-Prozeß sendet periodisch Path- und Resv-Nachrichten für die vorhandenen Zustände. Die Dauer einer Periode wird mit dem Wert des Objekt TIME_VALUES festgelegt. Erhält ein RSVP-Prozeß ein Path- oder Resv-PDU, dann wird das Timeout-Intervall des entsprechenden Zustands hochgesetzt. Das Timeout-Intervall ist so gewählt, das es eine Anzahl an RSVP-Path- und RSVP-Resv-Verlusten verkraftet. Die RSVP-PDUs werden mit der Best Effort (BE) Dienstgüte transportiert. Die Best Effort-Dienstgüte gibt keine Garantien für Dienstgüteparameter.

Neben der Path- und Resv-PDU kennt RSVP noch fünf weitere PDUs auf die hier noch kurz eingegangen werden soll:

• PathErr
  Die PathErr (Path Error) Nachricht berichtet Fehler in der Bearbeitung von Path-Nachrichten.
• ResvErr
  Die ResvErr (Reservation Error) Nachricht berichtet Fehler bei der Bearbeitung von Resv-Nachrichten.
• PathTear
  Die PathTear (Path Teardown) Nachricht löscht den Zustand, der durch Path- und Resv-Nachrichten in den RSVP-Prozessen erzeugt wurde.
• ResvTear
  Die ResvTear (Reservation Teardown) löscht den Zustand, der durch die Resv-Nachrichten entstand.
• ResvConf
  ResvConf (Reservation Confirmation) Nachrichten können gesendet werden, um eine Reservierung zu bestätigen. Der Erhalt einer ResvConf-Nachricht muß keine Bestätigung einer End-zu-End-Reservierung bedeuten.

In diesem Kapitel wurden einige Dienstgüten auf OSI-Schicht 3 (z.B. Premium Service) und 4 (z.B. Guaranteed Service) erwähnt. Für die Erzeugung dieser Dienstgüten werden die Kommunikationsdienste von Netztechnologien verwendet. Im nächsten Kapitel werden einige Netztechnologien auf ihre Dienste und Dienstgüten untersucht.