Strukturprotokolle der Datenkommunikation – Quality of Service

RSVP, Resource ReSerVation Protocol

RSVP ist die Abkürzung für Resource ReSerVation Protocol und ist im Zusammenhang mit Realisierungsfragen für Multimedia-Anwendungen aufgekommen. Es steuert eine Voraus-Reservierung von Betriebsmitteln für Unicast oder Multicast-Anwendungen, wobei auch die Gruppen-zu-Gruppen-Kommunikation unterstützt werden kann.

Die Reservierungen erfolgen immer unidirektional, RSVP ist ein Simplex-Protokoll. Das ist durchaus sinnvoll, denn gerade bei Multimedia hat man oftmals Informationsquellen wie einen Video-Server und Informationssenken wie Endgeräte. Vom Video-Server zum Endgerät kann die Reservierung einer Qualitätsklasse sinnvoll sein, in der Rückrichtung ist dies nicht erforderlich.

Dennoch hat man sich entschlossen, die Reservierung vom Empfänger ausgehen zu lassen. Wenn also eine Workstation eine Videoübertragung durch eine bestimmte Dienstklasse unterstützen soll, teilt sie dies dem Netz mittels RSVP mit. RSVP sorgt dann dafür, dass vom Video-Server bis zur empfangenden Station die gewünschte Dienstqualität durchgeschaltet wird, wenn dies möglich ist. Der Grund für diese Vorgehensweise ist darin zu sehen, dass RSVP überhaupt nicht für den Einsatz in LANs, sondern für Stadtnetze und WANs entwickelt wurde.

RSVP – ein Zusatz für Routing-Protokolle

Das RSVP-Protokoll ist ein Zusatz für die Routing-Protokolle. Es kann selbst nicht routen. Geräte, die RSVP unterstützen, werden aufgrund von RSVP-Reservierungen die Zuordnung ihrer Betriebsmittel (Speicher, Prozessor, Leitungskapazität) zu den Verkehrsflüssen ändern bzw. anpassen. Geräte, die RSVP nicht unterstützen, werden einfach transparent durchlaufen und denken sich nichts weiter dabei. Kommt es allerdings in diesen Geräten zu Engpässen, nützt es auch nichts mehr, dass die anderen Geräte sich den Qualitätswünschen angepasst haben. Eine Kette ist eben immer nur so stark wie ihr schwächstes Glied.

Wenn eine Anwendung einen Qualitätswunsch an das Netz äußert, wird zunächst mit der Policy Control nachgeprüft, ob ihr das überhaupt zusteht. Als nächstes wird mit der Admission Control geprüft, ob die Reservierung möglich ist. Die Reservierung kann nur dann durchgeführt werden, wenn ein spezieller Datenfluss auch eine Klassifizierung als Flow hat, sonst verstößt man schon gegen die Policy Control. Die Klassifizierung als Flow kann auf unterschiedliche Arten geschehen, z.B. per Default, durch das MPLS-Verfahren (Multiprotocol Layer Switching) oder im Rahmen von Prioritäten nach IEEE 802.1D/p.

Es gibt vier grundsätzliche Komponentengruppen bei RSVP, die die Rolle der jeweiligen Komponenten im Verfahren festlegen: Sender, Empfänger, Hosts und Router.

Damit RSVP überhaupt weiß, was zu tun ist, müssen alle in Frage kommenden Anwendungen als Sender registriert werden. Dabei werden ihre Verkehrscharakteristika, wie z.B. eine gewünschte minimale Bandbreite, die Paketgröße, der Durchsatz oder eine maximal erträgliche Verzögerungszeit festgehalten. Eine Station mit sendenden Anwendungen schickt dann so genannte Path Messages an alle potentiellen Empfänger der Nachrichten der betreffenden Anwendungen. In dieser Path Message stehen insbesondere die Verkehrscharakteristika.

Bei den Empfängern müssen diese Informationen in der Schnittstelle abgelegt werden, die eine Anwendung in den Empfängern später benutzt, um unter Zuhilfenahme einer RSVP-Reservierung mit einer sendenden Anwendung zu kommunizieren. Will ein Empfänger nun mit dem Sender kommunizieren und von ihm einen Datenfluss bekommen, schickt er über die genannte Schnittstelle die entsprechenden Parameter an die nächste lokale RSVP-Instanz. Dies ist meist ein Prozess in einem Router. Es müssen nicht alle Parameter übergeben werden, der Empfänger kontrolliert die anzustrebende Qualitätsstufe. Die Menge der möglichen Parameter und die Menge der ausgewählten Parameter ergeben die Flussspezifikation.

RSVP beginnt dann mit der Reservierung der Betriebsmittel in den Routern und zwar in Form von Reservierungs-Anfragen, die als IP-Pakete im Punkt-zu-Punkt-Upstream bis zum Sender hin durchgeführt werden, also genau entgegen der Richtung, in der die Sendung nachher abläuft. Im Verlaufe des Netzes können gleichartige Reservierungen auftreten, die dann entsprechend gesammelt werden.

Über einen Host können Anfragen gesammelt werden. Er kann als Konzentrator für mehrere Server benutzt werden. Darunter ist allerdings nicht notwendigerweise ein IBM-Großrechner zu verstehen, sondern einfach ein Gerät, welches mithilfe eines Multicast-Protokolls eine Gruppe nachgelagerter Server versorgt.

Router nehmen, wenn sie RSVP-fähig sind, die Reservierungsanfragen entgegen und versuchen, ihre Betriebsmittelzuordnung entsprechend zu modifizieren. Ist dies möglich, so senden sie in die Richtung des Anfragenden eine Bestätigung und leiten die Reservierungs-Anforderung in Richtung des nächsten Routers auf dem Weg weiter.

Klare Defizite

Es ist an dieser Stelle nicht beabsichtigt, tiefer in die Details von RSVP einzusteigen, weil die klaren Defizitbereiche schon jetzt auf der Hand liegen. Zunächst einmal nützt es relativ wenig, RSVP in ein paar Routern einzusetzen, man muss schon die überwiegende Mehrzahl der Geräte damit ausrüsten. Da die Reservierung Hop-by-Hop durchgeführt wird, ist eine Bestätigung der Reservierung nur ein Indiz dafür, dass es insgesamt funktionieren könnte, aber keine Garantie.

Eine Bestätigung eines Reservierungswunsches entspricht nur einer gewissen Wahrscheinlichkeit, dass es reserviert sein könnte. Algorithmus-Spezialisten haben nachgewiesen, dass sich unter bestimmten Bedingungen Reservierungen gegenseitig abschießen d.h. behindern können. Diese Situationen sind bekannt und müssen im Rahmen der Policies, der Nutzungsvereinbarungen im Vorfeld abgefangen werden.

Ähnliches gilt auch für die Kanalisierung von Reservierungswünschen. Lässt man wirklich jede Endstation Reservierungen vornehmen, sind die RSVP-Knoten wahrscheinlich nur noch damit beschäftigt, diese abzuarbeiten, anstatt z.B. zu routen. Also muss man für Multicast Gruppen wieder eigene Policies aufstellen, die das verhindern und Reservierungen z.B. direkt für eine Gruppe von Systemen vorsehen. Außerdem muss man den Sendern und Empfängern mühsam beibringen, wie die Verkehrscharakteristik aussehen soll. Schließlich ergibt sich noch das Problem, dass ein feindseliger Eindringling durch so genanntes „Request Spoofing“ in die Reservierungskette eindringen und Qualität bzw. Leistung stehlen und gegebenenfalls einen Angriff auf den autorisierten Sender und Empfänger vorbereiten kann.

Außerdem kann der berechtigte Benutzer nicht mehr senden. Das Problem ist, dass sich ein Angreifer nicht an das Ende der Kommunikationskette positionieren muss, sondern irgendwo zwischendrin an einem Router ansetzen kann. Andererseits: wenn man es im eigenen LAN einsetzt und dieses nicht allzu viele Router hintereinander beschäftigt, was ja auch aus anderen Gründen nicht wünschenswert ist, kann man RSVP gut einsetzen, vor allem, wenn man z.B. kurzzeitig Videokommunikation bevorzugen möchte. Die Erfinder sehen RSVP auch nicht als Technik für ein verzweigtes Backbone, sondern eher als Zugangstechnik für andere Priorisierungsmechanismen des Backbones.

Schließt man dann außen z.B. Switched Ethernets an, können diese zwischen Quelle zum Ziel Ende-zu-Ende RSVP benutzen. Es ist dann Aufgabe des Übergabepunktes zum Backbone, die RSVP-Anforderungen zu sammeln und in eine QoS-Stufe des Backbones zu überführen und vice versa, genauso wie die Ethernet-Pakete in Zelleströme zu zerhacken und umgekehrt.

Wenn das Backbone eine sehr hohe Leistungsfähigkeit hat, sollte es ihm in der Praxis gleichgültig sein, welche QoS von ihm verlangt wird. So muss man sich genau ansehen, wo man RSVP anwenden möchte und welche Vorteile es bringt.

Zurzeit gibt es keine allgemeinen RSVP-Policies, das ist auch im Standard nicht vorgesehen, sondern man muss die Regeln selbst erarbeiten. IEEE entwickelt in verschiedenen Arbeitsgruppen allerdings allgemeine Policies, die man sozusagen als Eingabe für RSVP verwenden kann.

weiter mit: Integrierte Dienste über LANs nach 802.1D/p

(ID:2049529)