Review II: done

caption, source done.

Rendering tags done.

Acronyme, Absätze und Wordanführungszeichen done.

Review von Prof. Kosch eingearbeitet.

Unbekannte Character ausgebessert.

Referenzen aufgeteilt.

Echtzeit-Protokolle

1

Übersicht über Echtzeit-Protokolle

• Die wichtigsten Protokolle und ihr Anwendungsbereich...
  • Medien-Transport: RTP106
    • sendet Daten und Metadaten
  • Strom Kontrolle: RTSP146
    • Fernkontrolle der Sitzung
  • Resourcen Reservierung (falls benötigt): RSVP144
    • Sicherstellung, dass der Kommunikationspfad angemessene Garantien bieten kann...
    • ...anderenfalls Best-Effort Übertragungen!

Einführung TCP/UDP

• Protokolle der Transportschicht
• Adressierung mittels Portnummern
• TCP145
  • verlässlich
  • Bytestrom
  • verbindungsorientiert
• UDP141
  • verbindungslos
  • unzuverlässig

Traditionelle Protokolle

TCP Verhalten

Auto PC

Auto PDA_Phone

Auto

• Langsamer Start
• Sender merkt wenn Pakete verworfen werden
• Sender vermindert die Bit-Rate wenn Pakete verworfen werden

UDP Verhalten

Auto PC

Auto PDA_Phone

Auto

• UDP141 sendet blind an einen Empfänger
• Keine Rückmeldung vom Empfänger
• Sender weiss nicht, ob Pakete verloren/verworfen werden

Protokolle für Echtzeit-Audio und Video

Auto PC

Auto PDA_Phone

Auto

• Audio/Video Applikationen können nicht mit TCP145 übertragen
  • langsamer Start, Staukontrolle, ...
• Sie verwenden UDP141
  • Aber UDP141 hat keinen Zeitstempel, Rückmeldung ...
• Die meisten Applikationen verwenden RTP106 (Real-Time Transport Protokol)
  • Zeitstempel
  • Erkennung von Paketverlusten

Echtzeit Protokoll RTP

• RTP106: ein Internet IETF258 Standard
• IETF258 Audio/Video Transport WG
  • RTP106v1 RFC 1889 (Januar 1996)
  • RTP106v2 draft-ietf-avt-rtp-new-09.txt (März 2001)
• Unterstützung von Applikationen mit Echtzeit-Eigenschaften
  • Zeitsteuerungs-Rekonstruktion (Intra-Medien Synchronisierung)
  • Verlusterkennung
  • Inhalts- (medien) Identifikation
• Leichter als TCP145
  • kein erneutes Übertragen, keine Flusskontrolle
  • TCP145 Header: 20 Bytes; RTP106 Header: 12 Bytes

Echtzeit Protokoll Dienste

• Zwei Teile in RTP106
  • RTP106 an sich: für Datenübertragung
  • RTCP142: zur Identifizierung der Beteiligten,
    überwacht Quality of Service
• Datenübertragung ("RTP an sich")
  • RTP106 Header sind nummeriert (Seq. nummer: 2 Bytes)
    • um Paketverlust zu entdecken, Empfang in falscher Reihenfolge
  • RTP106 Header tragen Zeitstempel (4 Bytes) für
    • Intra-Media Synchronisation
    • Inter-Media Synchronisation (z.B. für Lippensync.)
• Sitzungskontrolle (RTCP142)
  • Empfänger sendet periodisch Multicast"berichte"
  • "Berichte" geben an wie gut der Empfang ist

RTCP Funktionen

• Grundsätzlich:
  • periodische spontane Übertragung von Kontrollpaketen an alle Beteiligten
• Funktionen
  • Rückmeldung über die Qualität der Datenverteilung
    • nützlich für Sender (z.B. Zur Adaptierung der Kodierung)
    • nützlich für Empfänger (z.B. um Probleme wahrzunehmen)
  • Evaluierung der Anzahl der Beteiligten, und Abgleich der Berichtrate

2

Übersicht über Echtzeit-Protokolle

Die wichtigsten Echtzeit-Protokolle sind RTP106 (Real-Time Protocol), RTSP146 (Real-Time Streaming Protocol) und RSVP144 (Resource Reservation Protocol).
RTP106 dient zur Übertragung von kontinuierlichen Daten und Metadaten.
RTSP146 hat die Aufgabe, entweder Unicast- oder Multicastübertragungen von teilweise mehreren Medienströmen zu kontrollieren.
RSVP144 kann Medienapplikationen ein bestimmtes Quality of Service garantieren indem es am gesamten Übertragungspfad Ressourcen reserviert. Ist das nicht möglich so werden die Daten mit Best-Effort Übertragungen transportiert.
RTP106 und RTSP146 setzen auf die Protokolle der Transportschicht auf, RSVP144 hingegen direkt auf IP.

Einführung TCP/UDP

TCP145 (Transmission Control Protocol) und UDP141 (User Datagram Protocol) stellen die beiden wichtigsten Protokolle der Transportschicht dar. Beide Protokolle arbeiten mit Ports. Mit den Portnummern werden auf der Transportschicht die verschiedenen Anwendungen adressiert um die empfangenen Daten an die korrekte Applikation weiterzuleiten. TCP145 und UDP141 können die gleichen Portnummern belegen, allerdings haben sie jeweils eigene Adressräume. Das bedeutet, dass die Portnummer 53 in TCP145 nicht identisch mit der Portnummer 53 in UDP141 ist.

• TCP145 ist ein zuverlässiges, verbindungsorientiertes, Bytestrom Protokoll (definiert in RFC 793). Die Hauptaufgabe von TCP145 besteht in der Bereitstellung eines sicheren Transports von Daten durch das Netzwerk. Die Zuverlässigkeit von TCP145 wird durch einen Mechanismus garantiert, bei dem vom Empfänger der Datenpakete für jedes Paket eine Bestätigung an den Sender zurückgeschickt wird. Erhält der Sender innerhalb eines bestimmten Zeitraumes keine Bestätigung, so überträgt er das Paket erneut. TCP145 baut die Verbindung zwischen Server und Benutzer mit einem 3-Wege-Handshake auf, über welches Steuerinformationen ausgetauscht werden, mit denen eine logische Ende-zu-Ende-Verbindung aufgebaut wird. Um die Verbindung zu beenden, tauschen die beiden Hosts wiederum einen 3-Wege-Handshake aus. Dieser Mechanismus wird als Verbindungsorientierung bezeichnet. TCP145 teilt die zu übertragenden Daten in höchstens 64 Kbyte große Pakete auf, welche dann als IP-Datengramme verschickt werden und auf der Transportschicht beim Empfänger wieder zu den ursprünglichen Byteströmen zusammengesetzt werden.
• UDP141 hingegen ist ein unzuverlässiges, verbindungsloses Protokoll (definiert in RFC 768). Unzuverlässig bedeutet, dass das Protokoll keinerlei Mechanismen zur Verfügung stellt, die sichern, dass die Daten auch tatsächlich beim Empfänger ankommen. Außerdem wird bei UDP141keine explizite Verbindung aufgebaut. Der Sender beginnt einfach Daten an den Empfänger zu übertragen. UDP141 wird vor allem von Anwendungen verwendet, bei denen nur eine geringe Anzahl von Daten übertragen wird. Das liegt daran, dass die Herstellung einer zuverlässigen Verbindung unter Umständen aufwändiger ist als das wiederholte Übertragen der Daten.

Traditionelle Protokolle

TCP Verhalten

Auto PC

Auto PDA_Phone

Auto

Nach Aufbau der Verbindung über das TCP145-Protokoll beginnt der Sender dem Empfänger Daten zu übermitteln. Zuerst beginnt er langsam zu senden, mit der Zeit erhöht TCP145 dann die übertragene Paket-Rate. Überschreitet die Anzahl der Datenpakete, die der Sender dem Netz übergibt, die Aufnahmekapazität des Empfängers, wird dieser überlastet und verwirft einen Teil der Pakete. Dies wird dem Sender gemeldet, wodurch dieser wiederum seine Paket-Rate reduziert. Dieser Mechanismus wird Flusskontrolle genannt.

UDP Verhalten

Auto PC

Auto PDA_Phone

Auto

Bei der Übertragung von Daten mithilfe des UDP141-Protokolls beginnt der Sender von Anfang an mit Höchstgeschwindigkeit Daten an den Empfänger zu übermitteln. Sollen weniger Daten übertragen werden, so reduziert UDP141 die Paket-Rate. Bei diesem Protokoll erhält der Sender keinerlei Rückmeldung vom Empfänger. Wird der Empfänger durch eine zu hohe übertragene Paket-Rate überlastet, so ist er gezwungen Pakete zu verwerfen. Da in diesem Fall allerdings dem Sender keine Rückmeldung übertragen wird, überträgt er weiterhin mit der hohen Paketrate.

Protokolle für Echtzeit-Audio und Video

Auto PC

Auto PDA_Phone

Auto

Um allerdings Echtzeit-Daten zu übertragen sind weder TCP145 noch UDP141 alleine wirklich geeignet. Mit TCP145 können Echtzeit-Audio und -Video Applikationen nicht übertragen, da dieses wie schon erwähnt, die Datenübertragung langsam startet.
Multimedia-Applikationen verwenden bei der Übertragung UDP141, da dieses Protokoll von Beginn an mit Höchstgeschwindigkeit zu übertragen beginnt. Der Nachteil von UDP141 ist allerdings, dass es keinen Zeitstempel besitzt und dass an den Sender keine Rückmeldung gegeben wird, ob die Daten im richtigen Zeitfenster angekommen sind.

Um auch diese Nachteile auszugleichen, wird von den meisten Applikationen RTP106 (Real-Time Transport Protokoll) dazwischengeschalten. RTP106 arbeitet unabhängig von der darunterliegenden Transport- und Netzwerkschicht. Es überträgt sowohl Uni- als auch Multicast über UDP141. Dieses Protokoll wird nicht als eigene Netzwerkschicht dargestellt, es ist in die Applikation integriert. RTP106 verwendet Zeitstempel und arbeitet mit Rückmeldungen, wodurch der Sender den Verlust von Paketen erkennen kann.

Echtzeit Protokoll RTP

Das Echtzeit-Protokoll RTP106 wurde als Internet IETF258 (The Internet Engineering Task Force) Standard definiert. Version 1 von RTP106 wurde im Januar 1996 als RFC 1889 definiert, Version 2 im März 2001.

Die zentralen, von RTP106 angebotenen Funktionen sind:

• Inhalts-Identifikation
• Verlusterkennung
• Zeitsteuerungs-Rekonstruktion

Die Inhalts-Identifikation wird mithilfe eines speziellen Bytes im Header des RTP106-Paketes definiert und gibt an, ob es sich bei den übertragenen Daten z.B. um ein Video-Frame oder eine Sequenz von Audio-Samples handelt. Durch die Formatangabe in jedem Paket wird eine dynamische Änderung des Kodierungsverfahrens im Verlauf einer Sitzung ermöglicht.

Um Verluste zu erkennen ist es notwendig die einzelnen Pakete zu nummerieren, was mittels der Sequenznummer geschieht. Durch diese Nummerierung ist es dem Empfänger möglich die ursprüngliche Reihenfolgebeziehung der Pakete wiederherzustellen und eventuelle Paketverluste zu erkennen.
Mithilfe des Zeitstempels, den RTP106 bietet, ist die Synchronisation sowohl innerhalb eines Datenstroms (Intra-Media Synchronisation) als auch zwischen unterschiedlichen Strömen (Inter-Media Synchronisation) möglich.

Ein Vorteil von RTP106 gegenüber TCP145 ist, dass es den Netzverkehr weniger belastet. Zum einen dadurch, dass der RTP106 Header nur 12 Byte ausmacht, wohingegen der TCP145 Header aus 20 Byte besteht. Zum anderen dadurch, dass RTP106 keine Flusskontrolle und kein erneutes Übertragen von Paketen anbietet.

Echtzeit Protokoll Dienste

RTP106 an sich ist nur für die Datenübertragung zuständig. Um eine dynamische Skalierung der Anwendung und auch flexible Anpassungen an die jeweiligen QoS72-Parameter zu ermöglichen ist ein weiteres Protokoll nötig und zwar RTCP142 (Real-Time Transport Protocol).

RTP106 Header besitzen, wie schon erwähnt, Sequenznummern, welche aus 2 Bytes bestehen, um Paketverlust zu entdecken und die ursprüngliche Reihenfolge der übertragenen Daten wiederherzustellen. Außerdem besitzen sie Zeitstempel (4 Bytes), welche zur Intra-Media als auch der Inter-Media Synchronisation dienen.

Das Protokoll RTCP142 ist hingegen zuständig für die Sitzungskontrolle. Es basiert auf dem periodischen Austausch von Kontrollpaketen unter den Sitzungsteilnehmern. RTCP142 setzt hierbei auf die gleichen Protokollschichten wie RTP106 beim eigentlichen Datentransport.

RTCP Funktionen

Das RTCP142 basiert auf den periodischen Austausch von Kontrollpaketen unter den Sitzungsteilnehmern. RTCP142 deckt insbesondere folgende Funktionsbereiche ab:

Rückmeldung der erzielten Dienstqualität:

Vergleichbar mit den Mechanismen zur Fluß- oder Staukontrolle traditioneller Protokolle enthalten die RTCP142-Pakete wichtige Rückmeldungen über die erzielte Dienstqualität. Diese sind sowohl für die Sender als auch für Parteien, die nicht direkt an der Sitzung teilnehmen, nützlich. Der Sender kann aufgrund dieser Informationen Übertragungsparameter wie z.B. das Kodierungsverfahren oder die Frame-Rate bei Videos in geeigneter Weise anpassen. Da alle Teilnehmer Berichte verschicken, kann weiter diagnostiziert werden, ob bestimmte Netzprobleme lokaler oder globaler Art sind.

Identifikation der Sitzungsteilnehmer:

RTCP142 überträgt an die RTP106-Quelle eine feste Transportschichtkennung, den sogenannten kanonischen Namen (Cname). Empfänger können anhand des Cnames verschiedene Datenströme einem Sender eindeutig zuordnen und entsprechend weiterverarbeiten (z.B. Lippensynchronität Audio-Video).

Sitzungskontrolle:

Eine optionale Funktion besteht in der Unterstützung einer minimalen Sitzungskontrolle, z.B. Anzeigen von Teilnehmer-Informationen wie Name oder E-Mail-Adresse der Teilnehmer einer Audio-Konferenz. Dies ist beispielsweise in Sitzungen nützlich, wo das Beitreten oder Verlassen ohne zusätzliche An- bzw. Abmeldung erfolgt. Weitergehende Funktionen sollten allerdings von einem, mit entsprechenden Funktionen ausgestatteten Sitzungsprotokoll angeboten werden.

3

Referenzen zu RTP

RTP04a

RTP04b

RTSP

1

Motivation für RTSP: Streaming über das Web

• Audio- und Videodateien werden auf Webservern gespeichert
• Browser fragt um eine Datei mit einer HTTP63 Anfragenachricht an
• Web Server sendet die Datei in einer HTTP63 Antwortnachtricht
• Inhalts-Typ im Header zeigt die verwendete A/V Kodierung an
• Browser startet den Medienplayer und übergibt ihm die Datei
• Medienplayer rendert die Datei

Auto PC

Auto PDA_Phone

Auto

Haupthindernis: Medienplayer interagiert mit dem Server über den dazwischenliegenden Web Browser

Alternative: Verbindungsaufbau zwischen Server und Player

• Der Web Browser stellt eine Anfrage und erhält eine Metadatei (eine Datei welche eine Beschreibung der zu übertragenden Datei enthält) anstatt die Datei selbst zu empfangen
• Inhalts-Typ Header welcher die spezifische Audio/Video Applikation angibt
• Browser startet den Medienplayer und übergibt ihm die Metadatei
• Player startet eine TCP145-Verbindung mit dem Server und sendet eine HTTP63 Anfrage

Auto PC

Auto PDA_Phone

Auto

Probleme:
Medienplayer kommuniziert über HTTP63, welches allerdings nicht für Operationen wie Pause, Fast Forward, Rewind konzipiert ist

Auto PC

Auto PC

RTSP Grundsätze

• IETF258 Standard
  • RFC 2326, April 1998
  • Standard: http://www.faqs.org/rfcs/rfc2326.html

• Real-Time Streaming Protocol
  • Arbeitet als « Netzwerkfernkontrolle »

• Unterstützt folgende Operationen:
  • Bereitstellung der Medien von einem Server
  • Hinzuziehen eines Medien Servers zu der Konferenz
  • Aufzeichnung der Konferenz
• Protokoll Design
  • text-basiertes Protokoll
  • unabhängiges Transport-Protokoll
  • RTSP146 kann über UDP141 oder TCP145 übertragen werden
  • ähnliches Design wie HTTP63 mit einigen Unterschieden!
    • Benutzer -> Server und Server -> Benutzeranfragen
    • Server behält einen « Sitzungsstatus »
    • Daten werden band-extern übertragen
  • arbeitet entweder mit Unicast oder mit Multicast

RTSP beginnt und kontrolliert Übertragung

Auto PC

Auto PDA_Phone

Auto

• Benutzer bezieht eine Beschreibung der Multimedia-Präsentation, welche aus verschiedenen Medienströmen besteht
• Der Browser ruft einen Medienplayer (Hilfsapplikation) basierend auf dem Datentyp der Präsentationsbeschreibung auf
• Präsentationsbeschreibung beinhaltet Referenzen zu Medienströmen, unter Verwendung der URL Methode rtsp://
• Player sendet eine RTSP146 SETUP Anfrage; Server sendet eine RTSP146 SETUP Antwort
• Player sendet eine RTSP146 PLAY Anfrage; Server sendet eine RTSP146 Antwort
• Medienserver sendet Medienstrom
• Player sendet RTSP146 PAUSE Anfrage; Server sendet RTSP146 PAUSE Antwort
• Player sendet eine RTSP146 TEARDOWN Anfrage; Server sendet RTSP146 TEARDOWN Antwort

2

Motivation für RTSP: Streaming über das Web

Auto PC

Auto PDA_Phone

Auto

RTSP146 dient der verteilten Kontrolle der Medienströme und wird von Streamingapplikationen über das Netz angewendet. Um den Einsatz von RTSP146 zu motivieren, betrachten wir ein typisches Szenario von Medienabspiel und Webserver.
Nehmen wir in einem Webkontext an, dass Audio- und Video Dateien, die über das Internet gesendet werden, auf Webservern abgelegt sind.
Benötigt nun ein Benutzer eine bestimmte Datei, so fragt der Browser des Benutzers mittels einer HTTP63-Anfrage (Hyper Text Transfer Protocol) um diese Datei an. Mittels einer HTTP63-Antwort wird dem Web-Browser vom Webserver die angefragte Datei übertragen. Durch die Angabe des Inhalts-Typs im Header wird die verwendete A/V Kodierung ersichtlich. Der Browser startet nun den Medienplayer und leitet ihm die Datei weiter, welcher die A/V Datei dann abspielt (siehe obige Abbildung).
Das größte Problem bei dieser Form der Übertragung ist, dass der Medienplayer nicht direkt mit dem Server kommuniziert, sondern dass der Web-Browser dazwischengeschalten ist.

Auto PC

Auto PDA_Phone

Auto

Es ist allerdings möglich, diesen Nachteil zu übergehen, und eine direkte Verbindung zwischen Server und Medienplayer aufzubauen. Hier stellt der Web-Browser eine Anfrage für eine bestimmte Datei an den Webserver. Dieser sendet eine Metadatei zurück, welche eine Beschreibung der zu übertragenden Datei beinhaltet. Der Web-Browser liest nun aus dem Header den Inhalts-Typ der Datei aus und startet den entsprechenden Medienplayer. Der Player seinerseits baut eine TCP145-Verbindung mit dem Server auf und sendet eine HTTP63 Anfrage für diese Datei. Der Server überträgt ihm darauf die Datei und der Medienplayer spielt sie ab.

Hierbei stellt sich allerdings das Problem, dass der Medienplayer mit dem Server über HTTP63 kommuniziert. HTTP63 ist allerdings nicht in der Lage, eine VCR-Kontrolle (Pause, Fast Forward, Rewind) anzubieten.

Verwendung von RTSP/RTCP/RTP PC

Auto PC

Auto PDA_Phone

Auto

Mithilfe von RTSP146 (Real-Time Streaming Protocol) ist es möglich kontinuierliche Daten mit VCR-Kontrolle zu übertragen. Schickt der Web-Browser nun eine HTTP63 Anfrage an den Server, so erhält er von diesem eine Präsentationsbeschreibung des gewünschten Mediums. Der Browser ruft nun einen entsprechenden Medienplayer auf, welcher über eine in der Präsentationsbeschreibung beinhaltete RTSP146-Referenz Verbindung zu den benötigten Medienströmen aufnimmt. Die wirkliche Übertragung erfolgt nicht über RTSP146, sondern zum Beispiel über RTP106. RTSP146 hat allein die Aufgabe die Übertragung zu kontrollieren.

Kommen wir nun nach der Motivation zu einer genaueren Erklärung des Aufbaus von RTSP146.

RTSP Grundsätze

Das Echtzeit-Übertragungsprotokol RTSP146 (Real Time Streaming Protocol) wurde ebenso wie RTP106 von IETF258 standardisiert (RCF 2326).
Aufgabe von RTSP146 ist der Aufbau und die Kontrolle der Übertragung von kontinuierlichen Medien, wie z.B. Audio und Video, über einen oder mehrere zeitlich synchronisierte Ströme. Allerdings ist es nicht Aufgabe von RTSP146 die Daten zu übertragen. Die Menge der zu kontrollierenden Ströme ist in der Präsentationsbeschreibung definiert. Somit arbeitet RTSP146 als verteilte Netzwerkkontrolle.

Die von RTSP146 kontrollierten Ströme können z.B. mit RTP106 übertragen werden, aber die Operationen von RTSP146 sind nicht von dem Transportmechanismus, mit dem die kontinuierlichen Daten übertragen werden, abhängig.

RTSP146 unterstützt folgende Operationen:

• Bereitstellung der Medien von einem Server:
  • Ein Benutzer kann die Präsentationsbeschreibung z.B. mittels HTTP63 anfordern. Wenn die Übertragung über Multicast erfolgt, so beinhaltet die Präsentationsbeschreibung die Multicast-Adressen und die Ports welche für die Übertragung der kontinuierlichen Medien benötigt werden.
• Hinzuziehen eines Medien-Servers zu einer Konferenz:
  • Ein Medien-Server kann zu einer existierenden Konferenz hinzugezogen werden. Dies geschieht entweder um Medien in eine Übertragung einzuspielen oder um Medien aufzunehmen. Dieser Modus ist z.B. für verteilte E-Learning-Applikationen nützlich.
• Aufzeichnung der Konferenz

RTSP146 stellt ein textbasiertes Protokoll auf der Applikationsebene dar. Bezüglich der Syntax und des Ablaufes weist RTSP146 einige Ähnlichkeiten mit HTTP63 auf. Allerdings unterscheiden sich diese zwei Protokolle in wichtigen Punkten. Zum einen muss ein RTSP146 Server in der Lage sein seinen Sitzungsstatus beizubehalten. Außerdem können bei diesem Protokoll sowohl der RTSP146-Server als auch der Benutzer Anfragen stellen. Zusätzlich werden die Daten von einem anderen Protokoll band-extern übertragen.

RTSP146 selbst kann über UDP141 oder TCP145 übertragen werden und bietet die Möglichkeit entweder eine Unicast- oder eine Multicastübertragung zu starten.

RTSP beginnt und kontrolliert Übertragung

Auto PC

Auto PDA_Phone

Auto

Will ein Benutzer eine bestimmte Audio- oder Videodatei erhalten, so sendet er wie üblich eine HTTP63 Anfrage an den Webserver. Von diesem erhält er eine Beschreibung der Multimedia-Datei, welche aus verschiedenen Medienströmen bestehen kann. Der Browser ruft nun einen Medienplayer auf, der dem Inhaltstyp in der Präsentationsbeschreibung entspricht (z.B.: SMIL27). Die Präsentationsbeschreibung beinhaltet zusätzlich eine Referenz zu den benötigten Medienströmen (rtsp://). An die angegebene Referenz sendet der Medienplayer zuerst eine RTSP146 SETUP Anfrage und erhält vom Server eine RTSP146 SETUP Antwort. Daraufhin sendet der Player eine RTSP146 PLAY Anfrage. Der Server beginnt nun den Medienstrom zu übertragen. Um die Verbindung wieder zu beenden wird vom Player eine RTSP TEARDOWN Anfrage gesendet und vom Server bestätigt. Durch RTSP146 ist auch die VCR-Kontrolle möglich, der Player kann zum Beispiel eine RTSP146 PAUSE Anforderung an den Server schicken um die Übertragung zeitweilig zu unterbrechen.

3

Referenzen zu RTSP

RTS03

RTS04

RSVP

1

Auto

• RSVP144 ist ein Netzwerkkontroll-Protokoll, das Internet-Applikationen ermöglicht ein spezielles Quality-of-Service für ihre Datenflüsse zu erhalten.
  • Dazu ist im allgemeinen eine Ressource-Reservierung entlang des/der Datenpfade(s) nötig.
  • RSVP144 ist eine Komponente des zukünftigen "Integriertes Services" Internet, welches Best-Effort und Echtzeit-Quality-of-Service anbieten wird.
  • Wenn eine Host-Applikation um ein spezifisches QoS72 für ihren Datenstrom anfragt, wird RSVP144 genutzt um diese Anfrage zu jedem Router entlang des/ der Pfade(s) des Datenstromes zu transportieren und um den Zustand der Router und des Hosts beizubehalten um die angefragten Dienste bieten zu können.
  • Obwohl RSVP144 für Ressourcen-Reservierung entwickelt wurde ist es leicht adaptierbar um andere Arten von Netzwerk-Kontroll-Informationen entlang des Datenflusspfades zu transportieren.
  • RSVP144 IETF258 Standard:
    • RFC 2205, September 1997
    • ftp://ftp.isi.edu/in-notes/rfc2205.txt

RSVP Grundfunktionalität

• RSVP144 bedient heterogene Empfänger.
• RSVP144 ermöglicht es sowohl die Gruppenzugehörigkeit als auch die Routen zu ändern.
  • Für dynamische Adaptierbarkeit und Robustheit hält RSVP einen "Soft-Zustand" in den Routern aufrecht.
• RSVP144 ist kein Routingprotokoll.
  • Der RSVP144 Dämon berät das/die lokalen Routingprotokolle um die Routen einzuhalten.

RSVP Betriebsgrundsätze

• An jedem Knoten wendet RSVP144 eine lokale Entscheidungsprozedur (Zugangskontrolle) auf die QoS72-Anfrage an.
• Jeder Router des Pfades, der zur Ressourcen-Reservierung fähig ist, übergibt die eingehenden Datenpakete einer Paket-Sortiermaschine und einem Paket-Scheduler.

2

Auto

RSVP144 (Resource Reservation Protocol) ist ein Protokoll zur Netzwerkkontrolle. Es ermöglicht Internet-Applikationen ein spezielles Quality of Service für Datenflüsse. In der Hierarchie der Protokolle kommt RSVP144 über IP, RSVP144-Informationen werden also über IP-Pakete übertragen. Daher ist RSVP144 transparent, der Datenfluss kann also nicht-RSVP144-fähige Strecken beinhalten.

Um ein bestimmtes Quality of Service erfüllen zu können, müssen Ressourcen entlang des Übertragungspfades reserviert werden. Die Reservierung kommt in der zeitlichen und damit auch logischen Reihenfolge nach dem Routing. Erst nachdem mit den herkömmlichen IP-Routingmechanismen ein Pfad gefunden wurde, werden per RSVP144 an ihm entlang Ressourcen reserviert.

RSVP144 ist ein Teil des zukünftigen "Integrierten Service" Internet, welches sowohl Best-Effort als auch Echtzeit-Quality of Service anbieten wird.
Wenn nun ein Benutzer um ein bestimmtes Quality of Service für seinen Datenstrom anfragt, so transportiert RSVP144 diese Anfrage zu jedem Router entlang des Übertragungspfades, um die benötigten Ressourcen für den Datenstrom zu reservieren.
RSVP144 wurde zwar für die Reservierung von Ressourcen entwickelt, allerdings kann es durch leichte Adaptierungen auch andere Arten von Netzwerkkontroll-Informationen transportieren.

RSVP Grundfunktionalität

Folgende Grundfunktionalität wird von RSVP144 zur Verfügung gestellt:

RSVP144 kann heterogene Empfänger bedienen:

Verschiedene Empfänger-Hosts des selben Multicast-Übertragungsbaumes können verschiedene Kapazitäten besitzen und dadurch unterschiedliche QoS72 benötigen. Dies geschieht in RSVP144 durch das Merging von Verbindungen. Router erkennen, wenn Dienstgüte-Anforderungen verschiedener Reservierungen verschmolzen werden können. Dies kommt vor allem zum Tragen, wenn mehrere Empfänger den gleichen Sender haben.

RSVP144 ermöglicht es sowohl die Gruppenzugehörigkeit als auch die Routen zu ändern:

Um sicherzustellen, dass Daten auch übertragen werden können, auch wenn eine bestimmte Leitung oder ein Router ausfällt, wurden sogenannte "Soft-Zustände" konzipiert. Ein Router hält eine Verbindung nicht in seiner Routingtabelle, bis sie von einem der Benutzer beendet wird, sondern braucht in einem bestimmten Intervall Bestätigungen, welche von den End-Systemen periodisch verschickt werden, dass die Verbindung noch existiert. Ändert sich nun das Routing, wird eine Verbindung nach Ablauf dieses Intervalls automatisch aus allen Routern genommen, über die sie nicht mehr läuft. Die vom Endpunkt abgeschickte Bestätigung wiederum nimmt automatisch den neuen Pfad.

RSVP144 stellt kein Routingprotokoll dar:

Der RSVP144 Dämon berät ausschließlich die lokalen Routingprotokolle um die Routen einzuhalten. RSVP144 wurde konzipiert um mit existierenden und zukünftigen Unicast- und Multicast-Protokollen zu arbeiten. Der Host sendet IGMP454-Nachrichten um einer Multicast-Gruppe beizutreten, aber er verwendet RSVP144-Nachrichten um die Ressourcen entlang der/des Transportpfade(s) für diese Gruppe zu reservieren.

RSVP Betriebsgrundsätze

Die Betriebsgrundsätze von RSVP144:

Jeder Knoten auf dem Übertragungspfad wird von RSVP144 einer Entscheidungsprozedur (Zugangskontrolle) hinsichtlich der QoS72-Anfrage unterworfen. Diese ermittelt ob ein Knoten genug freistehende Ressourcen zur Verfügung stellen kann um das gewünschte Quality of Service zu liefern. Wenn die Zugangskontrolle Erfolg hat, so werden die Parameter im Klassifizierungs- und Paketscheduler bestimmt um das gewünschte QoS72 zu erreichen. Wenn nur einer der Knoten des Pfades nicht genug Ressourcen zur Verfügung stellen kann, so sendet RSVP144 eine Fehlermeldung an die Applikation.

Zusätzlich bedient sich RSVP144 einer Strategiekontrolle. Diese prüft, ob der Benutzer auch die Erlaubnis hat die angefragten Ressourcen zu reservieren.

Jeder Router des Pfades, der zur Ressourcen-Reservierung fähig ist (also bei dem die vorherigen zwei Kontrollen positiv verlaufen), übergibt die eingehenden Datenpakete einer Paket-Sortiermaschine und einem Paket-Scheduler. Der Paket-Sortierer bestimmt die QoS72-Klasse für jedes Paket und der Scheduler bestimmt die Folge der Paket-Übertragungen um das bestimmte QoS72 für jeden gesendeten Stream zu erlangen.

3

Referenzen zu RSVP

RSV99

RSV04

Bibliographie

2

Allgemeine Referenzen

IRT04