clicken zum download

Seminararbeit
PG Verteile Multimedia
”
Serversysteme“
Thema: RSVP & DiffServ
Andreas Goebels
Paderborn, den 21. März 2001
Inhaltsverzeichnis
1 Einleitung
1.1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 RSVP
2.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Designziele und ihre Realisierung in RSVP . . . . . . .
2.2.1 Unterstützung heterogener Empfänger . . . . .
2.2.2 variable Teilnehmerzahlen . . . . . . . . . . . .
2.2.2.1 Geplantes Abmelden eines Empfängers
2.2.2.2 Ausfall eines Empfängers . . . . . . .
2.2.3 Kanal- / Quellwechsel . . . . . . . . . . . . . .
2.2.4 dynamische Routen . . . . . . . . . . . . . . . .
2.2.5 angepasster Protokolloverhead . . . . . . . . . .
2.3 Beispielhafter RSVP Ablauf . . . . . . . . . . . . . . .
2.4 Komponenten an einem RSVP-Knoten . . . . . . . . .
2.4.1 Policy Control . . . . . . . . . . . . . . . . . . .
2.4.2 Admission Control . . . . . . . . . . . . . . . .
2.4.3 Packet Classifier . . . . . . . . . . . . . . . . .
2.4.4 Packet Scheduler . . . . . . . . . . . . . . . . .
2.5 Paket-Aufbau . . . . . . . . . . . . . . . . . . . . . . .
2.5.1 RSVP-Paket . . . . . . . . . . . . . . . . . . . .
2.5.2 Header . . . . . . . . . . . . . . . . . . . . . . .
2.5.3 Object . . . . . . . . . . . . . . . . . . . . . . .
2.6 Schwächen von RSVP . . . . . . . . . . . . . . . . . .
3 DiffServ
3.1 Definition . . . . . . . . . . .
3.2 Beispiel . . . . . . . . . . . .
3.3 Vorgehen . . . . . . . . . . . .
3.3.1 Packet Classification .
3.3.2 Traffic Conditioning .
3.3.2.1 Token-Bucket
3.3.2.2 RED . . . . .
3.3.2.3 RIO . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
5
5
6
6
7
7
8
9
9
9
10
10
10
10
11
11
11
12
13
.
.
.
.
.
.
.
.
14
14
14
14
15
16
16
16
16
Inhaltsverzeichnis
3.4
3.5
3.3.2.4 CBQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
DiffServ als Internet-Standard . . . . . . . . . . . . . . . . . . . . . . 17
Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4 Fazit und Ausblick
19
3
1 Einleitung
1.1
Abstract
Diese Seminararbeit wurde in Verbindung mit der Projektgruppe Verteilte Multimedia Serversysteme im WS 2000/2001 erstellt. Die Projektgruppe beschäftigt sich
mit der Übertragung digitaler Videodaten über Netze.
In diesem Zusammenhang ist es wichtig, daß den Empfängern ein bestimmter Quality of Service (QoS) garantiert werden kann. Da eine garantierte Güte in IP Netzwerken mit den bekannten Protokollen (TCP/UDP) nicht gegeben ist, müssen andere
Techniken entwickelt werden, um diese Funktionalität zu gewährleisten.
In dieser Arbeit wird einmal das RSVP Protokoll angesprochen, welches dynamisch
Bandbreiten und Empfänger- & Sendergruppen verwalten kann und mit hoher Wahrscheinlichkeit einen einmal zugesagten QoS für die gesamte Dauer einer Sitzung
anbietet. Zum anderen wird das Differentiated Services Modell erläutert, welches
die Bandbreite schon bei der Konzeption eines Netzes fix in verschiedene Klassen
aufteilt.
4
2 RSVP
2.1
Definition
Das Resource ReSerVation Protocol (RSVP) ist ein Signalisierungsprotokoll, welches im ISO-OSI Modell in der Schicht 4 angeordnet werden kann. Es verwaltet
dynamisch die zur Verfügung stehende Bandbreite und verteilt diese auf - ebenfalls möglicherweise dynamische - Sender- und Empfängergruppen. Dabei werden
vom Sender ausgehend die Datenströme, die dieser zur Verfügung stellen kann, den
Empfängern bekanntgemacht und diese reservieren Bandbreite an den Knoten, über
die die Datenpakete verschickt werden sollen, und zwar mit dem QoS, der von ihm
gewünscht wird.
RSVP ist nicht, wie z.B. TCP/IP, als point-to-point Struktur aufgebaut, sondern
spart Bandbreite durch einen multipoint-to-multipoint Aufbau. Identische Datenströme, die zu unterschiedlichen Empfängern geschickt werden, werden so lange wie
möglich über identische Routen geschickt.
Zusätzlich baut RSVP auf vorhandene Infrastruktur (TCP/UDP) auf und durch diese Systemunabhängigkeit und das Nutzen externer Routingalgorithmen ist es sehr
flexibel und leicht auf unterschiedlichsten Systemen einzusetzen.
2.2
2.2.1
Designziele und ihre Realisierung in RSVP
Unterstützung heterogener Empfänger
Nicht jeder Empfänger möchte oder kann die volle Qualität empfangen, die ein
Sender ggfs. zur Verfügung stellt. Zum Beispiel kann ein Empfänger mit Softwaredecoder vielleicht nur ein viertel des gesamten Datenstroms verarbeiten. RSVP soll
dieses berücksichtigen können und für diesen Empfänger sofort nur weniger Daten
weiterleiten, um nicht unnötig Netzwerkresourcen zu verschwenden. Dieser Punkt
wird auch in Zukunft immer wichtiger werden, wenn Netzwerkgebühren nicht mehr
nach Dauer einer Verbindung sondern nach übertragenem Datenvolumen abgerechnet werden. In diesem Fall muß dem Client die Wahl gelassen werden, wieviel er
bekommen und somit bezahlen möchte.
Dieses Designziel wird von RSVP gelöst, indem eine Reservierung empfängerinitiiert vorgenommen wird. Das bedeutet, daß ein Sender alle Empfänger darüber informiert, welche maximale Qualität er senden kann, aber der Empfänger selbst be-
5
2 RSVP
stimmt, welche Qualität er bekommen möchte. Da alle Router, über den der Sender
die maximale Qualität sendet, diesen Wert ihrer eigenen zur Verfügung stehenden
Bandbreite anpassen können, enthält der Empfänger also eine Obergrenze, nach unten kann er diesen Wert aber beliebig seinen Möglichkeiten bzw. seinen Bedürfnissen
anpassen. Der vom Empfänger gewünschte Quality of Service wird auf jedem Router,
über den dann die Pakete geschickt werden, gespeichert (siehe auch 2.2.4). Hierdurch
können Datenströme, die von einem Sender zu mehreren Empfängern geschickt werden, genau dann in die unterschiedlichen QoS -Werte aufgesplittet werden, wenn die
Wege sich teilen.
Abbildung 2.1: Heterogene Empfänger
2.2.2
variable Teilnehmerzahlen
Bei großen Empfängergruppen kann es sehr häufig vorkommen, das sich Mitglieder
abmelden oder daß neue hinzukommen. RSVP soll dieses nicht nur ermöglichen, sondern auch keinerlei erkennbare Skalierungsschwächen zeigen, ebenso kann die Menge
der Sender sich verändern, auch diese Fälle soll RSVP effizient abdecken.
RSVP arbeitet mit refresh messages, welche einen einmal gewählten Weg aufrecht
erhalten und auf Routing-Änderungen unbemerkt von Sender und Empfänger reagieren. Jeder neue Empfänger fragt alle Router auf dem Weg bis zum Empfänger,
ob die von ihm gewünschte Bandbreite noch zur Verfügung steht. Erst, wenn alle einzelnen Knoten dieses bestätigt haben, sendet der Sender auch zu dem neuen
Empfänger auf dem vorher definierten Weg, ohne daß die restlichen beteiligten Sender bzw. Empfänger dieses bemerken oder hierdurch eingeschränkt werden.
Das Abmelden eines Empfängers geht ähnlich effizient vonstatten. Es können generell zwei Fälle unterschieden werden:
2.2.2.1
Geplantes Abmelden eines Empfängers
In diesem Fall informiert der Empfänger einfach auf der gespeicherten Route zum
Sender alle beteiligten Knoten über sein Ausscheiden, und somit können die Knoten direkt die für diese Verbindung reservierte Bandbreite freigeben und neuen
Empfängern zur Verfügung stellen.
6
2 RSVP
2.2.2.2
Ausfall eines Empfängers
Bei einem Ausfall eines Empfängers kann dieser die beteiligten Knoten nicht mehr
informieren, diese leiten weiterhin alle Pakete an den Empfänger weiter und lassen
die Bandbreite für diese Verbindung reserviert. Aber dieses dauert nur solange, bis
ein TimeOut durch Ausbleiben der refresh messages auftritt. Wenn dieses geschieht,
geben die Knoten automatisch den belegten Speicherplatz frei.
2.2.3
Kanal- / Quellwechsel
Zum Beispiel bei Videokonferenzen ist es wichtig, dem Empfänger innerhalb einer
Sitzung die Auswahl eines Senders dynamisch zu ermöglichen, in diesem Szenario
etwa sollten immer von dem Sender Daten empfangen werden, der gerade die sprechende Person repräsentiert. Dabei muß sichergestellt sein, daß bei einem Wechsel
des Senders diese neue Reservierung immer Erfolg hat.
Generell gibt es drei Möglichkeiten, Verbindungen zu mehreren Sendern zu reservieren, um eben diesen Senderwechsel zu ermöglichen:
Abbildung 2.2: Quellwechsel am Beispielnetzwerk
1. Seperate Reservierung zu allen Sendern
Dieses ist der einfachste Fall, aber auch der ineffizienteste. Wir reservieren einfach am Beginn einer Übertragung zu allen Sendern einzeln die Bandbreite, die
wir irgendwann bei einem Wechsel des Senders benötigen. In diesem Beispiel
also sowohl Bandbreite von S1 zu E als auch von S2 zu E. Auf der Strecke R3
zu E haben wir hierbei unnötig reserviert, da wir niemals von beiden Sendern
gleichzeitig Pakete empfangen, aber trotzdem für diesen Fall Bandbreite reservieren. Gerade bei langen Wegen mit vielen Wegüberschneidungen und vielen
Sendern wird durch solch ein Vorgehen sehr viel Bandbreite verschwendet.
2. Seperate Reservierung jeweils zum aktuellen Sender
Die nächste Möglichkeit wäre es, die Reservierungen erst dann vorzunehmen,
wenn auch wirklich die Bandbreite benötigt wird, also hier erst Bandbreite
auf der Strecke S1 zu E zu reservieren, und dann beim Wechsel auf Sender
S2 die Bandbreite für die Verbindung S2 zu E zu reservieren. Dieses Vorgehen nutzt nur ein absolutes Minimum an Bandbreite, allerdings ist hiermit
das Designziel von RSVP verletzt, jederzeit zwischen verschiedenen Sendern
7
2 RSVP
wechseln zu können, ohne die Gefahr einer Ablehnung der Reservierung. Es
kann nämlich in diesem Beispielszenario durchaus vorkommen, daß bei einem
Wechsel auf Sender S2 die für diese Verbindung benötigte Bandbreite nicht
mehr zur Verfügung steht, da die Bandbreite durch einen neuen Empfänger
verbraucht wurde und die Reservierung damit fehlschlägt.
3. Reservierung mit Filtern an den Routern (distinct & shared reservation)
Dieses Vorgehen wird von RSVP durchgeführt, und bietet quasi einen Kompromiss zwischen den beiden vorherigen Punkten. Es wird strikt zwischen reservation und filtering unterschieden. In unserem Beispiel würde R3 entscheiden,
welche Pakete weitergeleitet werden, ob jetzt vom Sender S1 oder vom Sender
S2. Dadurch benötigt E nur die Bandbreite für einen Sender auf der Strecke
R3 zu E, aber da auf den Strecken von Sx bis R3 jeweils die Bandbreite zum
Übertragen der Pakete reserviert wurde, kann ein Senderwechsel einfach durch
Ändern der Filterregel in R3 vorgenommen werden und funktioniert auf jeden
Fall. Zwar ist in diesem Fall auch Bandbreite reserviert, die nie gleichzeitig
benutzt wird (von S1 zu R3 und gleichzeitig von S2 zu R3 ), aber dieses muß
geschehen, um Reservierungen garantieren zu können.
2.2.4
dynamische Routen
RSVP selbst enthält keinen Routing-Algorithmus, um systemunabhängiger eingesetzt werden zu können, es ist also auf externe Algorithmen angewiesen, welche die
Routen unabhängig von RSVP dauernd dynamisch anpassen (können). RSVP muss
mit solchen Routen-Änderungen fertig werden und den Quality of Service beibehalten können, ohne daß die Empfänger oder Sender davon etwas bemerken.
Dieses Designziel erfüllt RSVP, indem es mit sogenannten Soft States arbeitet. Soft
States sind eine Art Verbindung zwischen Sender und Empfänger, die in beide
Richtungen über dieselben Knoten führt und eben auch bei routing Änderungen
noch funktioniert. Diese Eindeutigkeit des Weges zwischen Sender und Empfänger
ist besonders wichtig, wenn man das letzte Designziel betrachtet. Wenn dort ein
Empfänger seinen Sender wechseln möchte, muß er dieses allen Routern bekannt
geben, die die Pakete vom Sender an ihn weiterleiten, da in diesen ggfs. die Filterregeln angepasst werden müssen. Ohne Zusatzfunktionen würden aber messages vom
Empfänger zurück an den Sender nicht unbedingt die gleichen Router passieren und
damit würde das filtering fehlschlagen.
Aus diesem Grund speichert RSVP beim Anlegen einer Verbindung in jedem Knoten, der passiert wird, den vorherigen Knoten, von dem aus das Paket geschickt
wurde. Durch diese gespeicherten Werte können jetzt Pakete vom Empfänger zum
Sender genau über die Rückwärtskanten“ geschickt werden. Dieses Prinzip funk”
tioniert auch bei Änderung der Route durch einen Routing-Algorithmus, da durch
die refresh messages laufend die Werte in den einzelnen Knoten angepasst und aktualisiert werden.
8
2 RSVP
2.2.5
angepasster Protokolloverhead
Zu guter letzt sollte der notwendige Overhead auf das notwendigste beschränkt
werden, um weder die einzelnen Router noch die Netzwerkbandbreite zu stark zu
beanspruchen.
Die Protokollfrequenz kann bei RSVP vollkommen dynamisch festgelegt werden, sie
wird in der Praxis antiproportional an die Anzahl der Empfänger und Sender angepasst, das bedeutet, daß, je mehr Empfänger in einem System vorhanden sind, desto
weniger Protokollnachrichten verschickt werden. Dieses beeinträchtigt natürlich andere Bereiche von RSVP, z.B. können Routenänderungen nicht mehr so schnell durch
TimeOuts erkannt werden, da die Frequenz der RESV- und PATH-Nachrichten eben
abnimmt. Dieses bedeutet eine zusätzliche Belastung der Gesamtbandbreite des Netzes.
2.3
Beispielhafter RSVP Ablauf
Der Aufbau einer RSVP-Verbindung zwischen einem Sender S und einem Empfänger
E läuft nach folgendem Schema ab:
Als erstes schickt der Sender eine PATH-Nachricht an alle Empfänger mit der maximalen Quality of Service, die er zur Verfügung stellen kann. Diese Nachricht wird
durch einen externen Routing Algorithmus über bestimmte Router geschickt. Diese Router können die maximale Qualität reduzieren, wenn an ihren Knoten nicht
ausreichend Bandbreite zur Verfügung steht. Gleichzeitig speichern sie bei sich den
Knoten, von dem die PATH-Nachricht an sie geschickt wurde, um einen eindeutigen
Rückweg zu definieren. Nach diesem Verarbeiten und ggfs. Modifizieren der PATHNachricht wird diese an den nächsten Router weitergeleitet, bis sie die Empfänger
erreicht hat.
Der Empfänger hat jetzt Informationen über den Content des Senders, über die
Qualität, die er maximal erhalten kann und er kennt den Knoten, an den er eine
Reservierung schicken muß. Wenn er jetzt eine Reservierung durchführen möchte,
schickt er eine RESV-Nachricht zurück, worin er gleichzeitig spezifiziert, welchen
QoS er benötigt und ebenfalls, ob und welches filtering er an den einzelnen Knoten
wünscht. Diese wird auf dem durch die PATH-Nachrichten definierten Weg zurückgeschickt und an jedem Knoten überprüft (siehe 2.4). Kommt eine RESV-Nachricht
beim Sender an, steht die Verbindung mit dem gewünschten QoS bereit und der
Sender kann Pakete verschicken.
2.4
Komponenten an einem RSVP-Knoten
In diesem Abschnitt werden die einzelnen Komponenten erläutert, die an einem
RSVP-Knoten vorhanden sind. Die ersten beiden, die Policy Control und die Admission Control, kümmern sich beim Aufbau einer Verbindung darum, ob der
Empfänger überhaupt Bandbreite reservieren kann oder darf, der Packet Classifier
9
2 RSVP
und der Packet Scheduler kümmern sich um den Versand der Pakete vom Sender
über den jeweiligen Router.
2.4.1
Policy Control
Die Policy Control ist ein sehr wichtiger Teilbereich von RSVP. Sie kümmert sich
ganz allgemein um Berechtigungen. Eine Reservierungsanfrage eines Empfängers
wird nicht automatisch weitergeleitet, sondern erst wird hier überprüft, ob genau
dieser Empfänger überhaupt vom Sender den Datenstrom erhalten darf (Kanalfreischaltungsprinzip z.B. bei PremiereWorld, FSK Beschränkungen etc.). Daher ist hier
auch die beste Stelle, Zahlungsmodalitäten abzuwickeln. Ein Beispiel für ein Berechtigungsprotokoll, welches von der Policy Control genutzt werden kann, ist z.B. das
COPS Protokoll. Wie dieses eingebunden werden kann wird beim Paketaufbau eines
RSVP Paketes näher beschrieben (siehe 2.5.1).
2.4.2
Admission Control
Die Admission Control ist zuständig für die Verwaltung der zur Verfügung stehenden
Bandbreite, sie entscheidet, ob bei einer neuen Reservierung die gewünschte Bandbreite bereitgestellt werden kann, ohne den Quality of Service der restlichen Reservierungen zu gefährden. Die Admission Control kann auch dazu eingesetzt werden,
die maximale Bandbreite pro Reservierung einzuschränken, um eine gleichmäßigere
Verteilung unter der gesamten Empfängermenge zu erreichen, und nicht nur wenige Nutzer mit unrealistisch hohen Reservierungen zu bedienen; dieses ist zusätzlich
hilfreich gegen Attacken auf das eigene Netz, die durch extreme Bandbreitenanforderungen sonst anderen Empfängern den Zugang verwehren könnten.
Erst wenn die Policy- und die Admission Control einer gewünschten Reservierung
zugestimmt haben, wird diese an den nächsten Knoten weitergeleitet, ein Nein von
einer dieser beiden Komponenten führt zur Ablehnung eines Reservierungswunsches.
2.4.3
Packet Classifier
Der Packet Classifier ist, wie der Name schon vermuten läßt, für die Klassifizierung
der Pakete vom Server zu den unterschiedlichen Empfängern zuständig. An dieser
Stelle wird das filtering durchgeführt, d.h. der Classifier entscheidet anhand der
Werte im filterSpec, ob und wohin ein Paket weitergeleitet wird. Er hängt es an
eine Queue an und dort enscheidet dann der Scheduler über den Zeitpunkt der
Weiterleitung.
2.4.4
Packet Scheduler
Der Packet Scheduler regelt die Quality of Service der Pakete an den Empfänger
anhand der Werte im flowSpec. Durch den Zeitpunkt der Weiterleitung kann er die
10
2 RSVP
Menge der Pakete steuern, die den Empfänger endgültig erreichen werden. Wie bereits anfangs beschrieben kann dieser QoS individuell von jedem Empfänger vorher
bestimmt werden, es muß also auch vom Scheduler jeder Empfänger separat verwaltet und behandelt werden.
2.5
2.5.1
Paket-Aufbau
RSVP-Paket
Ein RSVP Paket hat einen sehr flexiblen Aufbau, es besteht aus einem Header
und dann einer (fast beliebigen) Anzahl von Objekten. Je nach Typ der RSVP
Nachricht sind einige Objekte notwendig, andere optional, z.B. ist in jedem Paket
das SESSION Objekt enthalten, welches den Zielpunkt der Nachricht beschreibt.
Durch diesen sehr variablen Aufbau einer Nachricht ist RSVP sehr flexibel, dadurch
können z.B. Berechtigungsprotokolle wie COPS einfach eingebaut werden, allerdings
entsteht hierdurch auch der große Aufwand für die Router, da alle Pakete an jedem
Routerc erst entschlüsselt und verarbeitet werden müssen.
Im folgenden wird der Header aufgeschlüsselt und eine Übersicht über alle Objectund Message-Typen gegeben.
2.5.2
Header
Der Header besteht aus folgeden Feldern:
• Vers (4 Bit): Versionsnummer von RSVP, momentan 1.0
• Flags (4 Bit): Im Moment werden diese Bits noch nicht benutzt
• Message Type (8 Bit): Der Typ der Nachricht
– PATH : Eine Nachricht eines Senders an Empfänger
– RESV : Eine Reservierungsanfrage eines Empfängers an einen Sender
– PATHERR: Eine Fehlermeldung vom Sender
– RESVERR: Eine Fehlermeldung vom Empfänger
– PATHTEAR: Ein Aufgeben einer Verbindung durch den Sender
– RESVTEAR: Ein Aufgeben einer Verbindung durch den Empfänger
– RESVCONF : Eine Bestätigung einer Reservierung durch den Sender
• Checksum (16 Bit): Einerkomplement der Einerkomplementsumme der Nachricht (0 = keine Checksumme)
• Send TTL (8 Bits): Der TimeToLive-Wert aus dem IP Paket
• RSVP Length (16 Bit): Die Gesamtlänge des RSVP Paketes, einschließlich
Header und Länge aller Objekte
11
2 RSVP
2.5.3
Object
Ein Objekt besteht aus folgenden Feldern:
• Length (16 Bit): Die totale Länge des Objektes in Byte
• Class-Num (8 Bit): Beschreibt die Objektklasse, folgende Klassen sind vorhanden:
– NULL: Ein Null-Objekt, dieses wird von allen Empfängern ignoriert
– SESSION : Dieses Objekt muß in jedem RSVP Paket enthalten sein. Es
enthält die IP Adresse des Empfängers des aktuellen Paketes und den
Port, über den kommuniziert wird. Durch diese Daten wird die Sitzung
definiert.
– RSVP HOP : Dieses Objekt enthält die IP Adresse des letzten sendenden
RSVP-fähigen Knotens. Dieser Wert wird von jedem Knoten geändert,
indem jeder seine eigene IP-Adresse hier einträgt, der Wert wird gespeichert, um später den Rückweg der RESV-Nachrichten korrekt abwickeln
zu können (siehe 2.2.4).
– TIME VALUES : Enthält den Wert der refresh Periode. Hierdurch wird
die Protokoll-Frequenz bestimmt und damit die timeOut values.
– STYLE : Definiert die Reservierungsart und spezielle Daten, die nicht in
den flowSpec oder filterSpec Objekten enthalten sind. Dieses Objekt muß
in jedem RSVP Paket enthalten sein.
– FLOW SPEC : Beschreibt die verlangte Quality of Service einer RESVNachricht.
– FILTER SPEC : Beschreibt die Menge an Sendern, zu denen reserviert
werden soll.
– SENDER TEMPLATE : Muss in jeder PATH Nachricht vorhanden sein
und beschreibt den Sender anhand seiner IP Adresse und weiterer Senderspezifischer Daten.
– SENDER TSPEC : Muss in jeder PATH Nachricht vorhanden sein und
beschreibt den Datenstrom, den der Sender liefert (maximale QoS etc.).
– ADSPEC : Enthält OPWA (One Pass With Advertising) Daten einer
PATH Nachricht, das ist die maximale Qualität, die über alle Router
hinweg einem Empfänger zur Verfügung gestellt werden kann.
– ERROR SPEC : Eine genaue Fehlerspezifikation und -beschreibung.
– POLICY DATA: Daten, die in der Policy Control benötigt werden, um
zu entscheiden, ob ein Empfänger Daten empfangen darf.
– INTEGRITY : Enthält Daten zur Verifizierung einer RSVP Nachricht.
– SCOPE : Enthält eine explizite Liste von Sendern, an die eine Nachricht
weitergeleitet werden soll.
12
2 RSVP
– RESV CONFIRM : Enthält die IP Adresse eines Empfängers, der eine
Bestätigung seiner Reservierung wünscht.
• Class Type (8 Bit): Dieser Wert wird nur in Verbindung mit Class Num gesetzt,
die Aufsplittung in zwei Felder erfolgt aus Kompabilitätsgründen
• Object Contents: Die eigentlichen Daten des Objektes, die Länge dieses Feldes wird durch die Gesamtlänge des Objektes bestimmt und muß immer ein
Vielfaches von 4 betragen
2.6
Schwächen von RSVP
Bei RSVP fallen drei deutliche Schwächen auf:
• Sehr großer Verwaltungsaufand an den einzelnen Routern: Die Knoten müssen
jedes Paket differenziert betrachten und weiterleiten, und dazu erst den gesamten Header interpretieren. Außerdem müssen zu jedem reservierten Datenfluß
zwischen Sender und Empfänger mehrere Flußspezifische Daten gespeichert
und verwaltet werden und die Routen durch regelmäßige refresh messages aufrechterhalten werden. Durch diese Punkte wird sowohl die Bandbreite als auch
die Effizienz der Router sehr stark beeinträchtigt und macht RSVP dadurch
für große Netze, z.B. das Internet, vollkommen ungeeignet.
• RSVP Verbreitung: Jeder Knoten, über den geroutet wird, muß RSVP unterstützen, ansonsten kann die reservierte Quality of Service nicht garantiert
werden. Auch dieser Punkt ist in großen Netzwerken nur schwer zu realisieren.
Allerdings können RSVP Verbindungen prinzipiell auch über nicht RSVP-fähige Router aufgebaut werden, dann ist der gewünschte QoS aber nur noch mit
gewisser Wahrscheinlichkeit aufrechtzuerhalten.
• Dynamische Routenänderungen: RSVP kommt zwar gut mit Routenänderungen durch externe Algorithmen zurecht, da diese durch die dauernden refresh
messages erkannt werden, allerdings kann bei dem neu gerouteten Weg die
vorherige reservierte Bandbreite und damit der gewünschte Quality of Service
nicht garantiert werden. Diesem Nachteil wird im Moment durch verschiedene Mechanismen versucht, entgegenzuwirken, z.B. soll durch route pinning an
einmal gewählten Routen festgehalten werden.
13
3 DiffServ
3.1
Definition
Differentiated Services ist ein Modell, welches nicht dynamisch Bandbreite verwaltet,
sondern schon bei der Konzeption eines Netzes die zur Verfügung stehende Bandbreite in verschiedene Klassen aufteilt. Dadurch ist die Last an den Routern nicht
mehr, wie bei RSVP, abhängig von der Anzahl der Pakete, sondern nur noch von
der Anzahl der erzeugten Klassen.
Die einzelnen Klassen können dann an unterschiedliche Kunden verkauft werden
und bilden somit eine garantierte Bandbreite für diese Kunden. Um eine sinnvolle
Netzauslastung zu allen Zeitpunkten zu garantieren, können sich die Klassen untereinander Bandbreite ausleihen. Ebenso wie bei anderen Protokollen bietet DiffServ
die Möglichkeit, Pakete abzuweisen, wenn die Bandbreite überbucht wird, hier werden allerdings einige intelligentere Verfahren angewandt als beispielsweise in Standard IP Netzen.
3.2
Beispiel
Dieses Modell kann man am besten an einem Beipiel erläutern. Ein Provider könnte seine Bandbreite in zwei Klassen aufteilen, eine Standard Klasse mit 34% der
Bandbreite und eine Premium Klasse mit den restlichen 66%. Diese beiden Klassen
können nun an verschiedene Kunden verkauft werden, denen jeweils die 34 bzw. 66%
der Bandbreite garantiert werden. Sobald einer von beiden Kunden seine Bandbreite
nicht vollständig ausnutzt, kann der freie Teil von der anderen Klasse ausgeliehen“
”
werden. Diese zusätzliche Bandbreite muß allerdings sofort wieder freigegeben werden, wenn sie von dem eigentlichen Besitzer benötigt wird. Aus kommerzieller Sicht
bietet sich für den Provider die Möglichkeit an, Bandbreite zu überbuchen, d.h. die
verkaufte Bandbreite wird nur noch mit einer gewissen Wahrscheinlichkeit garantiert.
3.3
Vorgehen
Bei DiffServ müssen an den beteiligten Routern prinzipiell zwei Techniken angewandt werden: Einmal müssen die Pakete klassifiziert werden (packet classification),
14
3 DiffServ
Abbildung 3.1: Beispielhafte Konzeption eines Netzes in zwei Klassen
d.h. ihrer jeweiligen Bandbreite zugeordnet werden, und es muß geregelt werden, was
passiert, wenn eine Bandbreite überbucht wurde (traffic conditioning). Diese beiden
Techniken werden im folgenden erläutert:
3.3.1
Packet Classification
Die Klassifizierung von Paketen kann auf drei Arten erfolgen, wobei sich diese Verfahren auch kombinieren lassen:
• Klassifizierung durch Felder im IPvX
– IPv4: type of service field (TOS)
– IPv6: traffic class field (TC)
Diese Felder werden bisher noch nicht benutzt, es können also durch die neuen
Werte keine Fehlinterpretationen der IP Pakete vorkommen. Das Einbinden
von DiffServ in die Standardprotokolle hat natürlich den Vorteil, daß durch
diese Technik die gesamte DiffServ-Erweiterung abwärtskompatibel ist. Da das
Feld allerdings nicht unbedingt für diese Funktionalität vorgesehen war, kommen Schwierigkeiten auf, da Applikationen selbständig dieses Feld modifizieren
dürfen, und somit durch Benutzereingriffe Veränderungen der Klassen erreicht
werden können, was im allgemeinen Fall natürlich nicht erwünscht ist.
• Klassifizierung durch Inhalt
Ähnlich wie bei einem packet filtering in Firewalls werden Quell- und Ziel-
15
3 DiffServ
IP zusammen mit dem Port dazu genutzt, die Pakete zu identifizieren und
darüber der korrekten Klasse zuzuordnen.
• Klassifizierung durch Header
Man kann natürlich auch wieder, ähnlich wie bei RSVP, eine zusätzlichen
Header um die Pakete basteln, hierbei bietet sich MPLS (multi protocol label
switching) an, allerdings treten hier wieder ähnliche Schwierigkeiten auf, da
jeder Knoten MPLS unterstützen muß, um verbindliche Aussagen über die zur
Verfügung stehende Bandbreite machen zu können.
3.3.2
Traffic Conditioning
Durch traffic conditioning sollen Heuristiken zur Verfügung gestellt werden, die den
Datenfluß direkt reduzieren oder Pakete intelligent“ löschen können. Im folgenden
”
werden vier Verfahren kurz angerissen:
3.3.2.1
Token-Bucket
Beim Token-Bucket-Verfahren verteilt der Router Tokens. Nur die Pakete, die ein
Token erhalten haben, dürfen weitergeleitet werden. Um Bursts im Netzwerk ausgleichen zu können, besteht bei diesem Verfahren noch die Möglichkeit, Tokens bis
zu einer bestimmten Obergrenze zu speichern (im sog. Bucket). Durch dieses Verfahren kann der Router direkt auf die Datenrate der Pakete Einfluß nehmen, indem
er den Tokenfluß anpasst.
3.3.2.2
RED
Beim random early detection Verfahren werden Pakete, die sich in der Queue befinden, zufällig gelöscht. Dabei ist die Anzahl der zu löschenden Pakete abhängig vom
Füllstand der Queue, je mehr Pakete sich darin befinden, desto mehr Pakete werden
gelöscht. Der Vorteil bei der zufälligen Auswahl der zu löschenden Pakete liegt darin,
daß nicht - wie in normalen IP Netzen - immer nur die zuletzt eintreffenden Pakete
gelöscht werden, sondern daß alle Pakete und damit alle Datenströme an diesem
Router gleichmäßig gebremst werden.
3.3.2.3
RIO
RIO (RED with In and Out) ist eine Erweiterung des RED Prinzipes, hier wird noch
unterschieden zwischen inprofile und out-of-profile Paketen, wobei inprofile Pakete
mit einer kleineren Wahrscheinlichkeit verworfen werden.
3.3.2.4
CBQ
Beim class bases queuing wird das Round-Robin-Prinzip durchgeführt. Durch Zeitscheiben wird die Klassengewichtung der Pakete beeinflußt. Wenn zusätzliche Band-
16
3 DiffServ
breite zur Verfügung steht, werden erst die Klassen mit der höheren Priorität berücksichtigt und ihnen die freie Bandbreite zusätzlich zur Verfügung gestellt.
3.4
DiffServ als Internet-Standard
Bei der Implementierung von DiffServ als Internet-Standard wurde einmal das TOSfield des IPv4 (entsprechend das TC-field beim IPv6) völlig neu interpretiert, es wird
zum DS-field. Wie vorher schon erwähnt wird dieses Feld bisher nicht genutzt, es
treten also keine Schwierigkeiten bei dieser Uminterpretation auf. Zusätzlich betrachtet die Implementierung noch Teilnetze auf dem gerouteten Weg. In diesen
Teilnetzen unterscheidet DiffServ zwischen border-nodes und interior-nodes. Die
border-nodes befinden sich am Rand des Teilnetzes und können noch in ingressund egress-Knoten unterteilt werden. An diesen Randknoten wird der Hauptteil der
Analysearbeit durchgeführt, sprich die Klassifizierung wird bestimmt und direkt in
den Paketen gespeichert. Die interior nodes können daher einfach auf die vorberechneten Werte zugreifen und können die Pakete so sehr effizient den einzelnen Klassen
zuordnen, da sie im allgemeinen deutlich mehr Pakete betrachten müssen als die
border nodes. Dadurch ist das gesamte Teilnetz merklich effizienter.
3.5
Traffic Engineering
Bisher wurde angenommen, daß eine garantierte Bandbreite auch immer garantiert
ausgenutzt werden kann, in der Praxis gibt es aber immense Probleme, in einem
Teilnetz, in dem prinzipiell ausreichend Bandbreite vorhanden ist, alle Pakete so zu
routen, daß die Bandbreite optimal aufgeteilt ist und es nirgendwo zu Engpässen
kommt. Dieser Teilbereich von DiffServ ist momentanes Forschungsgebiet und bisher
noch nicht zufriedenstellend gelöst worden.
In diesem Beispiel stellt zum Beispiel die egress Kante den Flaschenhals dar und
Routingalgorithmen müssen intelligent versuchen, alle Pakete, die von den unterschiedlichen ingress Knoten kommen, zu routen, sodaß der egress Knoten optimal
ausgelastetet ist.
17
3 DiffServ
Abbildung 3.2: Teilnetz mit border nodes (B): ingress (I) und outgress (O)
18
4 Fazit und Ausblick
Beide Verfahren beschäftigen sich mit einem garantierten Quality of Service. RSVP
hat den Vorteil, sehr dynamisch auf verschiedenste Teilnehmergruppen und Routings durch ein Netzwerk reagieren zu können, allerdings ist der immense Protokolloverhead gerade im Internet einfach zu komplex, wodurch es hierfür vollkommen
ungeeignet ist. Es gibt aber schon Weiterentwicklungen dieser Technik (advanced reservation), welche den Overhead einzudämmen versuchen, wodurch dieses Protokoll
vielleicht doch noch einen sinnvollen Einsatz zuläßt.
DiffServ kann genau die Nachteile von RSVP ausgleichen, hier ist der Aufwand an
den einzelnen Routern unabhängig von der Anzahl der über ihn verschickten Pakete, sondern lediglich abhängig von der Anzahl der Klassen, die im allgemeinen
relativ gering ist (< 10). Allerdings ist das Traffic Engineering hier noch aktuelles
Forschungsgebiet und konnte bis jetzt noch nicht sinnvoll gelöst werden, wodurch
auch dieses Prinzip in seiner Grundform nicht wirklich praktikabel einsetzbar ist,
jedenfalls nicht in komplexen und dynamischen Netzen wie z.B. dem Internet.
Erfolgreicher als die beiden Einzelvarianten könnte auch eine Kombination aus beiden sein, wobei durch RSVP-Knoten der Zugang zu einen DiffServ (Teil-)Netz geregelt wird. Auch hieran wird im Moment geforscht.
19
Literaturverzeichnis
[1] Roland Balmer. Integration von Integrated und Differentiated Services, November 1999.
[2] Andreas Goebels. RSVP & DiffServ Presentation, Februar 2001.
[3] Network Working Group. RFC 2205: Resource ReSerVation Protocol (RSVP)
– Version 1 Functional Specification, September 1997.
[4] Network Working Group. RFC 2475: Architecture for Differentiated Services,
December 1998.
[5] Martin Karsten. RSVP Signalling for Commercial QoS, May 2000.
[6] Sebastian Lederer. Differentiated Services, 1999.
[7] Michael Lenhart. Kostenmodelle für Abrechnungen, Least Cost Routing und
Quality of Service, Januar 1998.
[8] Achim Meinerhagen. Network Support for Quality-of-Service Guarantees, November 1997.
[9] Stefan Menne. Das Resource Reservation Protocol, 1999.
[10] S. Hoch, S. Kolen, G.Schlipköther. RSVP - Resource Reservation Protokoll,
1999.
20