Ressourcenreservierungsprotokoll - Resource Reservation Protocol

Das Resource Reservation Protocol ( RSVP ) ist ein Protokoll der Transportschicht, das entwickelt wurde, um Ressourcen über ein Netzwerk unter Verwendung des Modells integrierter Dienste zu reservieren . RSVP arbeitet über IPv4 oder IPv6 und bietet eine vom Empfänger initiierte Einrichtung von Ressourcenreservierungen für Multicast- oder Unicast -Datenflüsse. Es transportiert keine Anwendungsdaten, ähnelt aber einem Kontrollprotokoll wie dem Internet Control Message Protocol (ICMP) oder dem Internet Group Management Protocol (IGMP). RSVP ist in RFC  2205 beschrieben .

RSVP kann verwendet werden , Hosts und Router auf Anfrage oder liefern , bestimmte Stufen von Quality of Service (QoS) für die Anwendung von Datenströmen . RSVP definiert, wie Anwendungen Reservierungen platzieren und wie sie die reservierten Ressourcen aufgeben können, wenn sie nicht mehr benötigt werden. RSVP-Operationen führen im Allgemeinen dazu, dass Ressourcen in jedem Knoten entlang eines Pfads reserviert werden. RSVP ist kein Routing-Protokoll, sondern wurde entwickelt, um mit aktuellen und zukünftigen Routing-Protokollen zusammenzuarbeiten.

RSVP selbst wird selten in Telekommunikationsnetzen eingesetzt. Im Jahr 2003 wurde der Entwicklungsaufwand von RSVP auf RSVP-TE für Teletraffic Engineering verlagert . Next Steps in Signaling (NSIS) war ein vorgeschlagener Ersatz für RSVP.

Internetprotokoll-Suite
Anwendungsschicht
Transportschicht
Internetschicht
Verbindungsschicht

Hauptattribute

  1. RSVP fordert Ressourcen für Simplexflüsse an : einen Verkehrsstrom in nur einer Richtung vom Sender zu einem oder mehreren Empfängern.
  2. RSVP ist kein Routing-Protokoll, funktioniert aber mit aktuellen und zukünftigen Routing-Protokollen.
  3. RSVP ist insofern empfängerorientiert, als der Empfänger eines Datenflusses die Ressourcenreservierung für diesen Fluss initiiert und aufrechterhält.
  4. RSVP behält den weichen Zustand (die Reservierung an jedem Knoten erfordert eine periodische Auffrischung) der Ressourcenreservierungen des Hosts und des Routers bei, wodurch eine dynamische automatische Anpassung an Netzwerkänderungen unterstützt wird.
  5. RSVP bietet mehrere Reservierungsstile (eine Reihe von Reservierungsoptionen) und ermöglicht das Hinzufügen zukünftiger Stile in Protokollrevisionen, um unterschiedlichen Anwendungen gerecht zu werden.
  6. RSVP transportiert und verwaltet Verkehrs- und Richtliniensteuerungsparameter, die für RSVP undurchsichtig sind.

Geschichte und verwandte Normen

Die grundlegenden Konzepte von RSVP wurden ursprünglich 1993 vorgeschlagen.

RSVP wird in einer Reihe von RFC-Dokumenten der IETF beschrieben:

  • RFC  2205 : Die funktionale Spezifikation der Version 1 wurde in RFC 2205 (Sept. 1997) von IETF beschrieben . Version 1 beschreibt die Schnittstelle zur Zugangs-(Verkehrs-)Steuerung, die "nur" auf Ressourcenverfügbarkeit basiert. Später erweiterte RFC2750 die Unterstützung der Zugangskontrolle .
  • RFC  2210 definiert die Verwendung von RSVP mit Controlled Load RFC 2211 und garantierten RFC 2212 QoS-Kontrolldiensten. Weitere Informationen finden Sie unter Integrierte Dienste . Definiert auch die Verwendung und das Datenformat der Datenobjekte (die Informationen zur Ressourcenreservierung enthalten), die von RSVP in RFC 2205 definiert sind.
  • RFC  2211 spezifiziert das Netzwerkelementverhalten, das für die Bereitstellung von Controlled-Load-Diensten erforderlich ist.
  • RFC  2212 spezifiziert das Netzwerkelementverhalten, das erforderlich ist, um garantierte QoS-Dienste bereitzustellen.
  • RFC  2750 beschreibt eine vorgeschlagene Erweiterung für generische Unterstützung richtlinienbasierte Zulassungssteuerung in RSVP. Die Erweiterung umfasste eine Spezifikation von Richtlinienobjekten und eine Beschreibung zum Umgang mit Richtlinienereignissen. (Januar 2000).
  • RFC  3209 , "RSVP-TE: Erweiterungen zu RSVP für LSP-Tunnel" (Dezember 2001).
  • RFC  3473 , "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource Reserve Protocol-Traffic Engineering (RSVP-TE) Extensions" (Januar 2003).
  • RFC  3936 , "Verfahren zur Veränderung der R esource re S er V ation P rotokoll (RSVP)" (Oktober 2004), beschreibt aktuelle Best Practices und legt Verfahren für RSVP zu modifizieren.
  • RFC  4495 , "A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow" (Mai 2006), erweitert RSVP, um die Bandbreite einer bestehenden Reservierung zu reduzieren, anstatt die Reservierung abzubauen.
  • RFC  4558 , "Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement" (Juni 2006).

Schlüssel Konzepte

Die beiden Schlüsselkonzepte des RSVP-Reservierungsmodells sind flowspec und filterspec .

Flowspec

RSVP reserviert Ressourcen für einen Flow. Ein Fluss wird durch die Zieladresse, die Protokollkennung und optional den Zielport identifiziert. Beim Multiprotokoll-Label-Switching (MPLS) wird ein Fluss als Label-Switched-Path (LSP) definiert. Für jeden Fluss identifiziert RSVP auch die spezielle Dienstgüte (QoS), die von dem Fluss benötigt wird. Diese QoS-Informationen werden als Flussspezifikationen bezeichnet und RSVP leitet die Flussspezifikationen von der Anwendung an die Hosts und Router entlang des Pfads weiter. Diese Systeme analysieren dann die Flussspezifikation , um die Ressourcen zu akzeptieren und zu reservieren. Eine Flowspec besteht aus:

  1. Serviceklasse
  2. Reservierungsspezifikation - definiert die QoS
  3. Verkehrsspezifikation - beschreibt den Datenfluss

Filterspezifikation

Die Filterspezifikation definiert die Menge von Paketen, die von einer Flussspezifikation beeinflusst werden sollen (dh die Datenpakete, die die durch die Flussspezifikation definierte QoS empfangen). Eine Filterspezifikation wählt typischerweise eine Teilmenge aller von einem Knoten verarbeiteten Pakete aus. Die Auswahl kann von einem beliebigen Attribut eines Pakets abhängen (zB der Absender-IP-Adresse und dem Port).

Die derzeit definierten RSVP-Reservierungsstile sind:

  1. Fester Filter - reserviert Ressourcen für einen bestimmten Flow.
  2. Explizit geteilt – reserviert Ressourcen für mehrere Flows und alle teilen sich die Ressourcen
  3. Platzhalterfilter – reserviert Ressourcen für einen allgemeinen Flow-Typ, ohne den Flow anzugeben; alle Ströme teilen sich die Ressourcen

Eine RSVP-Reservierungsanfrage besteht aus einer Flussspezifikation und einer Filterspezifikation, und das Paar wird Flussdeskriptor genannt . Die Flussspezifikation setzt die Parameter des Paketplaners an einem Knoten und die Filterspezifikation setzt die Parameter am Paketklassifikator .

Mitteilungen

Es gibt zwei Haupttypen von Nachrichten:

  • Pfadnachrichten ( Pfad )
Die Pfad - Nachricht wird von der Sender - Host an dem Datenweg und speichert der gesendete Pfadzustand in jedem Knoten entlang des Pfades.
Der Pfadstatus enthält die IP-Adresse des vorherigen Knotens und einige Datenobjekte:
  1. Absendervorlage zur Beschreibung des Formats der Absenderdaten in Form einer Filterspec
  2. sender tspec zur Beschreibung der Verkehrseigenschaften des Datenflusses
  3. Adspec , die Werbedaten enthält (siehe RFC 2210 für weitere Details).
  • Reservierungsnachrichten ( resv )
Die resv- Nachricht wird vom Empfänger über den umgekehrten Datenpfad an den Sender-Host gesendet. An jedem Knoten ändert sich die IP-Zieladresse der resv- Nachricht auf die Adresse des nächsten Knotens auf dem Rückwärtspfad und die IP-Quelladresse auf die Adresse der vorherigen Knotenadresse auf dem Rückwärtspfad.
Die resv- Nachricht enthält das flowspec- Datenobjekt, das die Ressourcen identifiziert, die der Flow benötigt.

Die Datenobjekte auf RSVP-Nachrichten können in beliebiger Reihenfolge übertragen werden. Die vollständige Liste der RSVP-Nachrichten und Datenobjekte finden Sie in RFC 2205.

Betrieb

Eine RSVP - Host , dass Bedarf ein Datum mit spezifischen QoS fließen senden wird eine RSVP übertragen Pfad Nachricht alle 30 Sekunden , die entlang der Unicast oder Multicast - Routen im Voraus festgelegt durch das Arbeits Routing - Protokoll reisen. Wenn der Pfad ankommt Nachricht an einem Router, der nicht RSVP nicht versteht, dass die Router leitet die Nachricht , ohne den Inhalt der Nachricht zu interpretieren und wird nicht Reserve Ressourcen für den Fluss.

Wer sie anhören möchte, schickt eine entsprechende resv- Nachricht (kurz für Reserve ) die dann den Weg zum Absender zurückverfolgt. Die resv- Nachricht enthält eine flowspec . Die resv- Nachricht hat auch ein Filterspec- Objekt; es definiert die Pakete, die die angeforderte QoS erhalten, die in der Flussspezifikation definiert ist. Eine einfache Filterspezifikation könnte nur die IP-Adresse des Absenders und optional sein UDP- oder TCP-Port sein. Wenn ein Router die RSVP- Resv- Nachricht empfängt , wird er:

  1. Machen Sie eine Reservierung basierend auf den Anfrageparametern. Die Zulassungssteuerung verarbeitet die Anforderungsparameter und kann entweder den Paketklassifizierer anweisen, die ausgewählte Teilmenge von Datenpaketen korrekt zu behandeln, oder mit der oberen Schicht verhandeln, wie die Paketbehandlung durchgeführt werden soll. Wenn das nicht unterstützt werden kann, wird eine Ablehnungsnachricht gesendet, um den Hörer darüber zu informieren.
  2. Leiten Sie die Anfrage stromaufwärts (in Richtung des Absenders) weiter. An jedem Knoten kann die Flussspezifikation in der resv- Nachricht durch einen weiterleitenden Knoten geändert werden (zB im Fall einer Multicast-Flussreservierung können die Reservierungsanfragen zusammengeführt werden).
  3. Die Router speichern dann die Art des Flusses und richten optional die Überwachung gemäß der Flussspezifikation dafür ein.

Wenn für eine bestimmte Zeit nichts gehört wird, wird die Reservierung abgebrochen und storniert. Dies löst das Problem, wenn entweder der Sender oder der Empfänger abstürzt oder heruntergefahren wird, ohne vorher die Reservierung zu stornieren.

Andere Eigenschaften

Integrität
RSVP-Nachrichten werden mit einem Nachrichten-Digest angehängt, der durch Kombinieren des Nachrichteninhalts und eines gemeinsamen Schlüssels unter Verwendung eines Nachrichten-Digest-Algorithmus (üblicherweise MD5 ) erzeugt wird. Der Schlüssel kann unter Verwendung von zwei Nachrichtentypen verteilt und bestätigt werden: Integritäts-Challenge-Anfrage und Integritäts-Challenge-Antwort .
Fehler melden
Wenn ein Knoten einen Fehler erkennt, wird eine Fehlermeldung mit einem Fehlercode generiert und stromaufwärts auf dem Rückwärtspfad zum Sender propagiert.
Informationen zum RSVP-Flow
Zwei Arten von Diagnosenachrichten ermöglichen es einem Netzbetreiber, die RSVP-Statusinformationen zu einem bestimmten Fluss anzufordern.
Diagnoseeinrichtung
Eine Erweiterung des Standards, die es einem Benutzer ermöglicht, Informationen über den RSVP-Status entlang eines Pfads zu sammeln.

RFCs

Verweise

  • John Evans; Clarence Filsfils (2007). Bereitstellung von IP- und MPLS-QoS für Multiservice-Netzwerke: Theorie und Praxis . Morgan Kaufmann. ISBN 978-0-12-370549-5.

Externe Links