Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

RSVP im Überblick

RSVP im Überblick

Das RSVP-Protokoll wird von Routern verwendet, um QoS-Anforderungen (Quality of Service) an alle Knoten entlang der Datenflusspfade zu stellen und den Status für den angeforderten Service zu erstellen und zu pflegen. RSVP-Anforderungen führen im Allgemeinen zu Ressourcenreservierungen an jedem Knoten entlang des Datenpfads. RSVP hat die folgenden Attribute:

  • Sorgt für Ressourcenreservierungen für unidirektionale Datenflüsse.

  • Ermöglicht dem Empfänger eines Datenflusses, die für diesen Datenfluss verwendete Ressourcenreservierung zu initiieren und zu pflegen, wie in Abbildung 1 gezeigt.

  • Soft State bei Routern und Hosts bei gleichzeitiger Graceful-Unterstützung für dynamische Mitgliedschaftsänderungen und automatische Anpassung an Routingänderungen.

  • Hängt von aktuellen und zukünftigen Routing-Protokollen ab, ist aber selbst kein Routing-Protokoll.

  • Bietet verschiedene Reservierungsmodelle oder -arten für eine Vielzahl von Anwendungen.

  • Unterstützt IPv4- und IPv6-Pakete, die über LSPs mit RSVP-Signalübertragung gesendet werden können.

Abbildung 1: RSVP-Reservierungsanfrage und DatenflussRSVP-Reservierungsanfrage und Datenfluss

RSVP-Betriebsübersicht

RSVP erstellt unabhängige Sitzungen, um jeden Datenfluss zu verarbeiten. Eine Sitzung wird anhand einer Kombination aus der Zieladresse, einem optionalen Zielport und einem Protokoll identifiziert. Innerhalb einer Sitzung kann es einen oder mehrere Absender geben. Jeder Sender wird durch eine Kombination aus Quelladresse und Quellport identifiziert. Ein Out-of-Band-Mechanismus, z. B. ein Sitzungsankündigungsprotokoll oder menschliche Kommunikation, wird verwendet, um die Sitzungskennung mit allen Sendern und Empfängern zu kommunizieren.

Eine typische RSVP-Sitzung umfasst die folgende Folge von Ereignissen:

  1. Ein potenzieller Absender beginnt damit, RSVP-Pfadmeldungen an die Sitzungsadresse zu senden.

  2. Ein Empfänger, der an der Sitzung teilnehmen möchte, registriert sich bei Bedarf selbst. Beispielsweise kann sich ein Empfänger in einer Multicast-Anwendung selbst bei IGMP registrieren.

  3. Der Empfänger empfängt die Pfadmeldungen.

  4. Der Empfänger sendet entsprechende Resv-Nachrichten an den Absender. Diese Nachrichten enthalten eine Flussbeschreibung, die von Routern auf dem Pfad verwendet wird, um Reservierungen in ihren Link-Layer-Medien zu machen.

  5. Der Absender empfängt die Resv-Nachricht und beginnt dann mit dem Senden von Anwendungsdaten.

Diese Folge von Ereignissen wird nicht unbedingt strikt synchronisiert. Empfänger können sich beispielsweise selbst registrieren, bevor sie Pfadmeldungen vom Absender erhalten, und die Anwendungsdaten können gesendet werden, bevor der Absender Resv-Nachrichten empfängt. Anwendungsdaten, die vor der eigentlichen Reservierung in der Resv-Nachricht übermittelt werden, werden in der Regel ohne Garantie als Best-Effort-Datenverkehr ohne Echtzeit-CoS behandelt.

Verständnis des RSVP Signaling Protocol

RSVP ist ein Signalisierungsprotokoll, das die Bandbreitenzuordnung und echtes Traffic-Engineering innerhalb eines netzwerks MPLS übernimmt. Wie LDP nutzt RSVP Erkennungsmeldungen und Werbebotschaften, um LSP-Pfadinformationen zwischen allen Hosts zu austauschen. RSVP enthält jedoch auch eine Reihe von Funktionen, die den Datenverkehrsfluss durch ein MPLS steuern. Während LDP auf die Verwendung des konfigurierten kürzesten Pfads von IGP als Transitpfad durch das Netzwerk beschränkt ist, verwendet RSVP eine Kombination aus CSPF-Algorithmus (Constrained Shortest Path First) und Explicit Route Objects (EROs), um zu bestimmen, wie Datenverkehr über das Netzwerk geroutet wird.

Grundlegende RSVP-Sitzungen werden auf dieselbe Weise eingerichtet wie LDP-Sitzungen. Durch die Konfiguration von MPLS und RSVP an den entsprechenden Transitschnittstellen ermöglichen Sie den Austausch von RSVP-Paketen und die Einrichtung von LSPs. RSVP ermöglicht Ihnen jedoch auch die Konfiguration von Link-Authentifizierung, explicit LSP-Pfaden und Verbindungsfarbe.

Dieses Thema enthält die folgenden Abschnitte:

RSVP-Grundlagen

RSVP nutzt unidirektionale und Simplex-Datenströme durch das Netzwerk zur Ausführung seiner Funktion. Der eingehende Router initiiert eine RSVP-Pfadnachricht und sendet sie downstream an den ausgehenden Router. Die Pfadnachricht enthält Informationen über die Ressourcen, die für die Verbindung benötigt werden. Jeder Router auf dem Pfad beginnt, Informationen zu einer Reservierung zu behalten.

Wenn die Pfadnachricht den ausgehenden Router erreicht, beginnt die Ressourcenreservierung. Der ausgehende Router sendet eine Reservierungsnachricht zurück an den Router zum eingehenden Router. Jeder Router auf dem Pfad empfängt die Reservierungsnachricht und sendet sie auf dem Pfad der ursprünglichen Pfadnachricht an die Upstream-Verbindung. Wenn der Eingehende-Router die Reservierungsnachricht empfängt, wird der unidirektionale Netzwerkpfad eingerichtet.

Der etablierte Pfad bleibt offen, solange die RSVP-Sitzung aktiv ist. Die Sitzung wird durch die Übertragung zusätzlicher Pfad- und Reservierungsmeldungen verwaltet, die alle 30 Sekunden den Sitzungsstatus melden. Wenn ein Router die Wartungsmeldungen nicht 3 Minuten lang erhält, wird die RSVP-Sitzung beendet und der LSP über einen anderen aktiven Router umgeleitet.

Bandbreitenreservierungsanforderung

Wenn eine Bandbreitenreservierung konfiguriert ist, verbreiten Reservierungsmeldungen den Bandbreitenwert über den LSP. Router müssen die für den jeweiligen LSP angegebene Bandbreite reservieren. Wenn die Gesamtbandbreitenreservierung die verfügbare Bandbreite für ein bestimmtes LSP-Segment überschreitet, wird der LSP über eine andere LSR. Wenn keine Segmente die Bandbreitenreservierung unterstützen können, schlägt die LSP-Einrichtung fehl und die RSVP-Sitzung wird nicht festgelegt.

Explicit Route Objects

Explicit Route Objects (EROs) beschränken das LSP-Routing auf eine angegebene Liste von LSRs. Standardmäßig folgen RSVP-Nachrichten einem Pfad, der anhand des kürzesten Pfads des IGP Netzwerks bestimmt wird. In Einem konfigurierten ERO folgen die RSVP-Nachrichten jedoch dem angegebenen Pfad.

ErOs bestehen aus zwei Arten von Anweisungen: Loose Hops und Strict Hops. Wenn ein looser Hop konfiguriert ist, werden ein oder mehrere Transit-LSRs identifiziert, über die der LSP geroutet werden muss. Das Netzwerk ermittelt IGP die genaue Route vom eingehenden Router zum ersten losen Hop oder von einem losen Hop zum nächsten. Der lose Hop gibt nur an, dass ein bestimmter LSR in den LSP einbezogen werden muss.

Wenn ein Strict-Hop konfiguriert ist, wird ein genauer Pfad ermittelt, über den der LSP geroutet werden muss. Strict-Hop-EROs geben die genaue Reihenfolge der Router an, über die die RSVP-Nachrichten gesendet werden.

Sie können Loose-Hop- und Strict-Hop-EROs gleichzeitig konfigurieren. In diesem Fall ermittelt IGP route zwischen Loose Hops, und die Strict-Hop-Konfiguration gibt den genauen Pfad für bestimmte LSP-Pfadsegmente an.

Abbildung 2 zeigt einen typischen LSP mit RSVP-Signal, der EROs verwendet.

Abbildung 2: Typischer RSVP-signalisierter LSP mit EROsTypischer RSVP-signalisierter LSP mit EROs

In der in der Topologie dargestellten Topologie wird der Datenverkehr von Abbildung 2 Host C1 an Host C2 geroutet. Der LSP kann die Router R4 oder Router R7 passieren. Um den LSP zur Verwendung von R4 zu zwingen, können Sie entweder einen Loose-Hop- oder Strict-Hop-ERO einrichten, der R4 als einen Hop im LSP angibt. Konfigurieren Sie einen Strict-Hop-ERO über die drei LSRs, um einen bestimmten Pfad über Router R4, R3 und R6 zu erzwingen.

Eingeschränkte kürzeste Pfad zuerst

Während IGPs den SPF-Algorithmus (Shortest Path First) verwenden, um zu bestimmen, wie Datenverkehr in ein Netzwerk geroutet wird, verwendet RSVP den CSPF-Algorithmus (Constrained Shortest Path First) zur Berechnung von Datenverkehrspfaden, die den folgenden Beschränkungen unterliegen:

  • LSP-Attribute: Administrative Gruppen wie Verbindungsfarbe, Bandbreitenanforderungen und EROs

  • Verbindungsattribute– Farben für eine bestimmte Verbindung und verfügbare Bandbreite

Diese Einschränkungen werden in der Traffic Engineering-Datenbank (TED) aufrechterhalten. Die Datenbank liefert CSPF aktuelle Topologieinformationen, die aktuelle reservierbare Bandbreite der Verbindungen und die Verbindungsfarbe.

Bei der Auswahl des Pfads folgt CSPF diesen Regeln:

  • Berechnet die LSPs nach und nach, und beginnt mit dem LSP mit der höchsten Priorität – der LSPs mit dem geringsten Einrichtungsprioritätswert. Unter den LSPs mit gleichem Priorität beginnt CSPF beijenigen, die die höchste Bandbreitenanforderung haben.

  • Entfernt die Traffic-Engineering-Datenbank von Verbindungen, die nicht Vollduplex sind und nicht über ausreichende reservierbare Bandbreite verfügen.

  • Wenn die LSP-Konfiguration die Anweisung enthält, entfernen Sie alle include Verbindungen, die keine enthaltenen Farben teilen.

  • Wenn die LSP-Konfiguration eine Anweisung enthält, entfernen Sie exclude alle Verbindungen, die ausgeschlossene Farben enthalten. Wenn ein Link keine Farbe hat, wird er akzeptiert.

  • Findet den kürzesten Pfad zum ausgehenden LSP-Router, unter Berücksichtigung beliebiger EROs. Wenn der Pfad beispielsweise Router A passieren muss, werden zwei separate SPF-Algorithmen berechnet: Router A zum Router A zum Router (eingehend) und Router A zum Router (ausgehend).

  • Wenn mehrere Pfade zu gleichen Kosten gehen, wählen Sie den Pfad mit einer Last-Hop-Adresse genauso aus wie das Ziel des LSP.

  • Wenn mehrere Pfade zu gleichen Kosten bestehen, wird der Pfad mit der geringsten Anzahl von Hops ausgewählt.

  • Wenn mehrere Pfade zu gleichen Kosten bestehen, wendet auf den LSP konfigurierte CSPF Load Balancing-Regeln an.

Link-Coloring

RSVP ermöglicht das Konfigurieren administrativer Gruppen für die CSPF-Pfadauswahl. Eine administrative Gruppe wird normalerweise mit einer Farbe benannt, einem numerischen Wert zugewiesen und auf die RSVP-Schnittstelle der entsprechenden Verbindung angewendet. Geringere Zahlen bedeuten eine höhere Priorität.

Nach der Konfiguration der administrativen Gruppe können Sie Links dieser Farbe in der TED entweder ausschließen, einkreisen oder ignorieren:

  • Wenn Sie eine bestimmte Farbe ausschließen, werden alle Segmente mit einer administrativen Gruppe dieser Farbe in der CSPF-Pfadauswahl ausgeschlossen.

  • Wenn Sie eine bestimmte Farbe enthalten, werden nur Segmente mit der entsprechenden Farbe ausgewählt.

  • Wenn Sie die Farbe nicht ausschließen oder die Farbe enthalten, bestimmen die Kennzahlen, die mit den administrativen Gruppen verknüpft und auf die jeweiligen Segmente angewendet werden, die Pfadkosten für dieses Segment.

Der LSP mit den niedrigsten Gesamtpfadkosten wird im TED ausgewählt.

RSVP-TE-Protokollerweiterungen für FRR

Beginnend mit Junos OS Version 16.1 wurden RSVP Traffic Engineering (TE)-Protokollerweiterungen eingeführt, um refresh-interval Independent RSVP (RI-RSVP) definierte RFC 8370 für Fast Reroute (FRR) Facility Protection zu unterstützen, um eine höhere Skalierbarkeit von Label-Switched Paths (LSPs) schnelleren Konvergenzzeiten und einer Verringerung des RSVP-Signaling-Overheads durch regelmäßige Aktualisierungen zu ermöglichen. Junos RSVP-TE läuft standardmäßig im erweiterten FRR-aka RI-RSVP-Modus, der Protokollerweiterungen zur Unterstützung von RI-RSVP für den FrR-Standort-Bypass enthält, der ursprünglich in RFC 4090 angegeben war.

Die in Junos implementierten RI-RSVP-Protokollerweiterungen sind vollständig abwärtskompatibel. In gemischten Umgebungen, in denen eine Untergruppe von LSPs Knoten durchläuft, die diese Funktion nicht enthalten, deaktiviert Junos RSVP-TE, das im erweiterten FRR-Modus ausgeführt wird, automatisch die neuen Protokollerweiterungen in den Signalaustausch mit Knoten, die die neuen Erweiterungen nicht unterstützen.

Im Rahmen des erweiterten FRR-Profils wurden eine Reihe von Änderungen vorgenommen und neue Standardeinstellungen übernommen. Diese finden Sie hier.

  • RSVP-TE führt standardmäßig den "erweiterten" FRR- oder RI-RSVP-Modus aus. Dies umfasst erweiterungsbasierte Erweiterungen für skalierte Szenarien. Diese neuen Protokollerweiterungen können auf einem Router ohne enhanced-frr-bypass-Befehl deaktiviert werden.

  • RSVP Refresh-Reduktionserweiterungen, die in RFC 2961 definiert sind, sind standardmäßig aktiviert. Der Benutzer kann sie mit dem zuverlässigen Befehl deaktivieren (siehe unten).

    Anmerkung:

    Node-ID-basierte Hellos sind standardmäßig aktiviert, da verbesserte FRR- oder RI-RSVP-Erweiterungen den Austausch von Node-ID-basierten Hello-Nachrichten erfordern. Node-ID-basierte Hellos können mit Befehl deaktiviert node-hello werden. Da Refresh-Reduction-Erweiterungen und node-id-basierte Hello-Nachrichten für erweiterte FRR- oder RI-RSVP-Erweiterungen entscheidend sind, wird eine der beiden Knoten automatisch deaktiviert, wenn erweiterte FRR-Erweiterungen auf dem Knoten deaktiviert werden.

  • Die Standardaktualisierungszeit für RSVP-Nachrichten wurde von 30 Sekunden auf 20 Minuten erhöht.

  • Der Standardwert für "Keep-Multiplier"(3) wird auf die neue Standardaktualisierungszeit angewendet.

  • Die lokale Reversion ist standardmäßig deaktiviert. Die vorhandene CLI für Node Hellos ist noch verfügbar, [edit protocols rsvp node-hello] die Aktion ist jedoch redundant. Wenn aktiviert, wird eine Meldung angezeigt, die zeigt, dass die Konfiguration nicht zusammen mit einem erweiterten FRR erforderlich ist.

  • Die vorhandenen Befehle zum Deaktivieren der Nachrichtenzuverlässigkeit werden jetzt verwendet, um die RSVP-Aktualisierungsreduzierung zu deaktivieren. Verwenden Sie die Version der folgenden Befehle, um auf den vorherigen Standard zurück einstellungen, der eine delete Aktualisierungsreduzierung ermöglicht:

    • Set no-reliable auf einer bestimmten Schnittstelle, um FRR-Skalierbarkeitsverbesserungen automatisch für alle LSPs zu deaktivieren, die die Schnittstelle durchlaufen. Wenn RSVP-TE ohne Optimierungen des FRR-Facility-Schutzes ausgeführt wird und die Aktualisierungsreduzierung nicht aktualisiert wird, deaktivieren Sie die Aktualisierungsreduzierung auf jeder Schnittstelle. Verwenden Sie einen der hier dargestellten Befehle:

      • [edit protocols rsvp interface name no-reliable]

      • [edit logical-systems name protocols rsvp interface name no-reliable]

  • Graceful-Restart und Nonstop Active Routing (NSR) werden nicht unterstützt, während der LSP eine lokale Reparatur erfährt oder der LSP während der LSP-Sicherungssignalisierung aktualisiert wird. Diese Einschränkung besteht bereits in der Implementierung, da gr- oder NSR-Switchover während frr-lokaler Reparatur ein Szenario für mehrere Fehler ermöglicht.

  • Die folgenden Betriebsbefehle wurden um neue Informationen zu den neuen Verfahren für RSVP TE Protokollerweiterungen für den FRR-Facility-Schutz aktualisiert.

    • show rsvp version zeigt an, ob verbesserte FRR-Verfahren aktiviert sind.

    • show rsvp neighbor detail zeigt an, ob im Nachbar verbesserte FRR-Verfahren aktiviert sind.

    • show rsvp interface detail zeigt bedingte PathTear-Statistiken an.

    • show rsvp statistics zeigt gesendete und empfangene Statistiken für bedingtes PathTear und andere Statistiken an.

    • show rsvp session extensive zeigt an, ob der Knoten ein Merge-Punkt ist und in diesem Beispiel die PLR-Adresse (Point of Local Repair) zeigt.

  • Die vorherigen CLI Konfigurationsoptionen zum Aktivieren oder Deaktivieren der Nachrichtenbündelung wurden deaktiviert (die vorhandenen Konfigurationen werden akzeptiert, aber in der Show-Konfigurationsausgabe wird eine Warnung angezeigt). Zu diesen Befehlen gehören:

    • [edit protocols rsvp interface name aggregate]

    • [edit logical-systems name protocols rsvp interface name aggregate]

    • [edit protocols rsvp interface name no-aggregate]

    • [edit logical-systems name protocols rsvp interface name no-aggregate]

  • Die folgenden CLI Konfigurationsoptionen wurden durch die aktuellen Änderungen redundant (die vorhandenen Konfigurationen werden akzeptiert, aber in der Show-Konfigurationsausgabe wird eine Warnung angezeigt):

    • [edit protocols rsvp interface name reliable]

    • [edit logical-systems name protocols rsvp interface name reliable]

Junos OS RSVP-Protokollimplementierung

Die Junos-Implementierung von RSVP unterstützt RSVP Version 1. Die Software unterstützt alle Pflichtobjekte und RSVP-Nachrichtentypen und unterstützt die Nachrichtenintegrität und Knotenauthentifizierung über das Integrity-Objekt.

Der Hauptzweck der Junos RSVP-Software ist die Unterstützung dynamischer Signalübertragung innerhalb MPLS Label Switched Paths (LSPs). Das Unterstützen von Ressourcenreservierungen über das Internet ist nur ein Sekundärzweck der Junos OS Implementierung. Da die Unterstützung von Ressourcenreservierungen sekundär ist, unterstützt die Junos RSVP-Software die folgenden Funktionen nicht:

  • IP-Multicasting-Sitzungen.

  • Datenverkehrssteuerung. Die Software kann keine Ressourcenreservierungen für Video- oder Audiositzungen in Echtzeit buchen.

Bezüglich des Protokollmechanismus, der Paketverarbeitung und der unterstützten RSVP-Objekte ist die Junos OS der Software mit anderen RSVP-Implementierungen kompatibel.

RSVP-Authentifizierung

Der Junos OS unterstützt sowohl den in RFC 2747 beschriebenen RSVP-Authentifizierungsstil (mit Multivendor-Kompatibilität) als auch den in Internet draft-ietf-rsvp-md5-03.txt beschriebenen RSVP-Authentifizierungsstil. Der Junos OS verwendet standardmäßig den in Internet draft-ietf-rsvp-md5-08.txt beschriebenen Authentifizierungsstil. Wenn der Router eine RFC 2747-RSVP-Authentifizierung von einem Nachbarn empfängt, wechselt er zu diesem Authentifizierungsstil für diesen Nachbarn. Der RSVP-Authentifizierungsstil für jeden benachbarten Router wird separat ermittelt.

RSVP und IGP Hello Packets und Timers

RSVP überwacht den Status der Nachbarn (IS-IS oder OSPF) des Interior Gateway Protocol (IGP) und vertraut auf die IGP-Protokolle, um zu erkennen, wenn ein Knoten ausfällt. Wenn ein IGP-Protokoll einen Nachbarn herunter erklärt (weil Hello-Pakete nicht mehr empfangen werden), setzt RSVP diesen Nachbarn ebenfalls aus. Bei der Einrichtung eines IGP und RSVP agieren die Protokolle und RSVP jedoch immer noch unabhängig.

In der Junos OS beruht RSVP in der Regel auf eine IGP paketerkennung, um den Knotenausfall zu prüfen. Die Konfiguration von Hello Timern IS-IS von IS-IS OSPF ermöglicht diesen Protokollen, Node-Ausfälle schnell zu erkennen. Wenn der Knoten ausfällt oder ein Knotenausfall erkannt wird, wird eine Pfadfehlernachricht generiert. Und obwohl die RSVP-Sitzung ausfällt, bleiben IGP benachbarte Knoten oben.

RSVP-Hellos können zuverlässig verwendet werden, wenn der IGP einen bestimmten Nachbarn nicht erkennt (z. B. wenn IGP an der Schnittstelle nicht aktiviert ist) oder wenn der IGP RIP (nicht IS-IS oder OSPF). Darüber hinaus kann die Ausrüstung anderer Anbieter zur Überwachung von RSVP-Sitzungen basierend auf RSVP Hello-Paketen konfiguriert werden. Aufgrund des Verlusts von RSVP-Hello-Paketen kann diese Ausrüstung auch eine RSVP-Sitzung beenden.

Wir empfehlen nicht, einen kurzen RSVP Hello Timer zu konfigurieren. Wenn Sie einen fehlerhaften Nachbarn schnell finden möchten, konfigurieren Sie IGP kurze IGP (OSPF oder IS-IS) Hello Timer.

OSPF- IS-IS verfügen über eine Infrastruktur, die das schnelle Senden und Empfangen von Hello-Nachrichten zuverlässig verwaltet, auch wenn die Routingprotokolle oder ein anderer Prozess die Verarbeitungsleistung des Routers belasten. Unter den gleichen Umständen kann es möglich sein, dass RSVP-Hellos plötzlich etwas auszeiten, obwohl der Nachbar normal funktioniert.

RSVP-Meldungstypen

RSVP verwendet die folgenden Nachrichtentypen zum Einrichten und Entfernen von Pfaden für Datenflüsse, Einrichten und Entfernen von Reservierungsinformationen, Bestätigen der Einrichtung von Reservierungen und Melden von Fehlern:

Pfadmeldungen

Jeder Sender-Host übermittelt Pfadmeldungen abwärts entlang der Routen, die von den Unicast- und Multicastrouting-Protokollen bereitgestellt werden. Pfadmeldungen folgen den genauen Pfaden der Anwendungsdaten. So werden Pfadzustände in den Routern entlang des Pfads erstellt, sodass die Router den vorherigen Hop und den Next-Hop-Knoten der Sitzung erlernen können. Pfadmeldungen werden regelmäßig gesendet, um den Pfadzustände zu aktualisieren.

Das Aktualisierungsintervall wird durch eine Variable namens "Timer" gesteuert, d. h. der periodische refresh-time Aktualisierungs-Timer, der in Sekunden ausgedrückt wird. Wenn ein Router keine bestimmte Anzahl von Pfadmeldungen aufeinanderfolgender Daten erhält, wird ein Pfadstatus verdringt. Diese Nummer wird durch eine Variable namens keep-multiplier . Der Pfadzustände wird für ( keep-multiplier + 0,5) x 1,5 x refresh-time ) Sekunden eingehalten.

Resv-Nachrichten

Jeder Empfänger-Host sendet eine Resv-Nachricht (Reservation Request) vorgelagert an Sender und Senderanwendungen. Resv-Nachrichten müssen dem umgekehrten Pfad von Pfadmeldungen folgen. Resv-Nachrichten erstellen und pflegen einen Reservierungsstatus in jedem Router auf dem Weg.

Ihre E-Mail-Nachrichten werden regelmäßig gesendet, um den Reservierungsstand zu aktualisieren. Das Aktualisierungsintervall wird durch dieselbe Aktualisierungszeitvariable gesteuert und die Reservierungszustände werden für Sekunden ( + keep-multiplier 0,5) x 1,5 refresh-time x beibehalten.

PathTear-Nachrichten

PathTear-Nachrichten löschen den Pfadzustände und den von ihnen abhängigen Reservierungszustände in allen Routern auf einem Pfad. PathTear-Nachrichten folgen demselben Pfad wie Pfadmeldungen. Ein PathTear wird in der Regel von einer Absenderanwendung oder einem Router initiiert, wenn der Pfad ausbehnt.

PathTear-Nachrichten werden nicht benötigt, verbessern jedoch die Netzwerkleistung, da sie Netzwerkressourcen schnell frei geben. Wenn PathTear-Nachrichten verloren gehen oder nicht generiert werden, wird der Pfad schließlich in einen Time-out auszeit, wenn sie nicht aktualisiert werden, und die mit dem Pfad verknüpften Ressourcen werden veröffentlicht.

ResvTear-Nachrichten

ResvTear-Nachrichten löschen reservierungszustände auf einem Pfad. Diese Nachrichten werden aufwärts an die Absender der Sitzung gesendet. In dem Sinne sind ResvTear-Nachrichten das Gegenteil von Resv-Nachrichten. ResvTear-Nachrichten werden in der Regel von einer Empfängeranwendung oder einem Router initiiert, wenn der Reservierungsstatus ausbehnt.

Nachrichten zu neuen Nachrichten sind nicht erforderlich, verbessern aber die Netzwerkleistung, da sie Netzwerkressourcen schnell frei geben. Wenn die ResvTear-Nachrichten verloren gehen oder nicht generiert werden, können die Reservierungszustände schließlich auf andere Zeiten auszeit werden, wenn sie nicht aktualisiert werden, und die mit der Reservierung verknüpften Ressourcen werden freigegeben.

PathErr-Nachrichten

Wenn Fehler beim Pfad auftreten (in der Regel aufgrund von Parameterproblemen in einer Pfadnachricht), sendet der Router eine Unicast PathErr-Nachricht an den Absender, der die Pfadnachricht ausgegeben hat. PathErr-Nachrichten sind Beratung, diese Nachrichten verändern nicht den Pfadstatus auf dem Weg.

ResvErr-Nachrichten

Wenn eine Reservierungsanfrage ausfällt, wird eine ResvErr-Fehlermeldung an alle beteiligten Empfänger übermittelt. ResvErr-Nachrichten sind Beratung, diese Nachrichten verändern während des Weges keine Reservierungsstatus.

ResvConbewusstsein-Nachrichten

Empfänger können die Bestätigung einer Reservierungsanfrage anfordern. Diese Bestätigung wird mit einer ResvConverver-Nachricht gesendet. Aufgrund der komplexen REGELN, bei dem der RSVP-Datenfluss zusammengeführt wird, muss eine Bestätigungsnachricht nicht unbedingt die End-to-End-Bestätigung des gesamten Pfads liefern. Daher sind die ResvCon Nutzungsmeldungen kein Anzeichen für einen möglichen Erfolg.

Juniper Networks-Router niemals die Bestätigung mit der ResvCon nutzung der Nachricht anfordern; Ein Router Juniper Networks kann jedoch eine ResvConkonferenz-Nachricht senden, wenn eine Anfrage vom Gerät eines anderen Herstellers empfangen wird.

Verstehen von RSVP Automatic Mesh

Beim Hinzufügen von Standorten zu BGP- und MPLS-VPNs, die RSVP-Signalübertragung nutzen, ist mehr Konfiguration für das Hinzufügen von Provider Edge-Routern (PE)-Routern erforderlich als für das Hinzufügen von Kunden-Edge-Geräten (CE). Die automatische RSVP-Mesh-Konfiguration trägt dazu bei, diese Konfigurationslast zu reduzieren.

Service Provider verwenden häufig BGP- MPLS VPNs, um das Netzwerk effizient zu skalieren und gleichzeitig umsatzgenerierende Services zu bieten. In diesen Umgebungen wird BGP zur Verteilung der VPN-Routinginformationen über das Netzwerk des Dienstanbieters verwendet, während MPLS verwendet wird, um diesen VPN-Datenverkehr von einem VPN-Standort an einen anderen zu weiterleiten. BGP- MPLS-VPNs basieren auf einem Peer-Modell. Um einem vorhandenen VPN ein CE Gerät (Standort) hinzuzufügen, müssen Sie den CE-Router am neuen Standort und den mit dem Router verbundenen PE-Router CE konfigurieren. Sie müssen die Konfiguration aller anderen am VPN beteiligten PE-Router nicht ändern. Die anderen PE-Router lernen automatisch die mit der neuen Site verknüpften Routen, einen Prozess, der als automatische Erkennung (AD) bezeichnet wird.

Die Anforderungen sind etwas anders, wenn Sie dem Netzwerk einen neuen PE-Router hinzufügen müssen. Ein BGP- und MPLS-VPN setzt voraus, dass die BGP-Sitzung über Full-Mesh-Verbindungen mit PE-Router-zu-PE-Router MPLS Label Switched Paths (LSPs) zwischen allen PE-Routern im Netzwerk besteht. Wenn Sie dem Netzwerk einen neuen PE-Router hinzufügen, müssen alle vorhandenen PE-Router neu konfiguriert werden, um mit dem neuen PE-Router Peering zu peeren. Ein Teil des Konfigurationsaufwands kann reduziert werden, wenn Sie BGP Route Reflectors konfigurieren (Entschnunigen der Full-Mesh-Anforderungen für BGP) und wenn Sie (LDP) als Signalisierungsprotokoll für MPLS.

Wenn Sie jedoch einem Netzwerk, das über ein Full-Mesh von RSVP-signalisierten LSPs konfiguriert ist, einen neuen PE-Router hinzufügen müssen, müssen Sie jeden der PE-Router neu konfigurieren, um eine Peer-Beziehung mit dem neuen PE-Router zu haben. Sie können das automatische RSVP-Mesh konfigurieren, um dieses spezielle Betriebsszenario zu verwenden. Wenn Sie rsVP-automatisches Mesh aktivieren, werden RSVP-LSPs dynamisch zwischen einem neuen PE-Router und den vorhandenen PE-Routern erstellt, sodass keine manuelle Neukonfiguration aller PE-Router erforderlich ist. Damit die dynamische LSP-Erstellung ordnungsgemäß funktioniert, BGP für den Austausch von Routen zwischen allen beteiligten PE-Routern konfiguriert werden. Wenn BGP Peers keine Routen austauschen, ist die Konfiguration eines dynamischen LSP zwischen ihnen nicht möglich. Die Routing-Tabelle des lokalen Routers inet.3 muss eine gekennzeichnete Route zu jedem potenziellen IBGP-Next-Hop (zukünftige potenzielle PE-Router oder LSP-Ziele) enthalten.

RSVP umfasst zahlreiche Funktionen, die in LDP nicht verfügbar sind, einschließlich Fast Reroute, End-Point Control und Linkverwaltung. Das automatische RSVP-Mesh hilft bei der Reduzierung der Betriebs- und Wartungsanforderungen für RSVP und ermöglicht die Bereitstellung von RSVP in größeren und komplizierteren Netzwerken.

Jeder PE-Router kann jeden anderen PE-Router im Netzwerk erreichen, da diese Informationen durch das Netzwerk IGP. Ein PE-Router kann einen Point-to-Point RSVP LSP zu jedem anderen PE-Router im Netzwerk einrichten, solange er weiß, dass ein solcher LSP erforderlich ist. Für den Aufbau eines vollen Mesh-Mesh von LSPs zwischen den PE-Routern muss jeder PE-Router wissen, aus welchem der anderen PE-Router das Full-Mesh-Netz macht.

Anmerkung:

In Junos OS Hierarchieebene wird ein automatisches RSVP-Mesh mithilfe der Konfigurationserklärung rsvp-te[edit routing-options dynamic-tunnels dynamic-tunnel-name] konfiguriert. Die rsvp-te Konfigurationserklärung ist auch für die Verwendung in Routinginstanzen als Provider-Tunnel-Option verfügbar. Wird zur Konfiguration der rsvp-te RSVP Point-to-Multipoint-LSPs für Multiprotocol BGP Multicast VPNs verwendet, nicht zur Konfiguration von rsVP-automatischen Mesh-Optionen, wenn diese als Provider-Tunnel-Option implementiert werden.

RSVP-Reservierungsarten

Eine Reservierungsanfrage enthält Optionen zur Angabe des Reservierungsstils. Die Reservierungsarten definieren, wie Reservierungen für verschiedene Absender innerhalb der gleichen Sitzung behandelt und wie Absender ausgewählt werden.

In zwei Optionen wird festgelegt, wie Reservierungen für unterschiedliche Absender innerhalb der gleichen Sitzung behandelt werden:

  • Verschiedene Reservierungen: Jeder Empfänger stellt seine eigene Reservierung bei jedem vorgeschalteten Sender fest.

  • Gemeinsam genutzte Reservierung– Alle Empfänger nehmen eine einzige Reservierung vor, die von vielen Sendern gemeinsam genutzt wird.

Bei zwei Optionen wird festgelegt, wie die Absender ausgewählt werden:

  • Explicit Sender: Listen Sie alle ausgewählten Absender auf.

  • Wildcard-Absender: Alle Sender auswählen, die anschließend an der Sitzung teilnehmen.

Derzeit werden die folgenden Reservierungsstile definiert, die aus einer Kombination dieser vier Optionen entstehen:

  • Fester Filter (FF): Dieser Reservierungsstil besteht aus verschiedenen Reservierungen zwischen expliziten Absendern. Beispiele für Anwendungen, die Reservierungen im fester Filterstil verwenden, sind Videoanwendungen und Unicast-Anwendungen, bei denen für jeden Sender eine separate Reservierung erforderlich ist. Die Reservierungsstil mit festem Filter ist standardmäßig auf RSVP-LSPs aktiviert.

  • Wildcard-Filter (WF): Dieser Reservierungsstil besteht aus gemeinsam genutzten Reservierungen zwischen Wildcard-Absendern. Diese Art von Reservierung reserviert die Bandbreite für alle Sender und verbreitet sich weiter vor allen Sendern und wird automatisch zu neuen Sendern erweitert, sobald sie erscheinen. Eine Beispielanwendung für Wildcard-Filterreservierungen ist eine Audioanwendung, in der jeder Sender einen eigenen Datenstrom überträgt. In der Regel übertragen nur wenige Sender zu einer bestimmten Zeit eine Übertragung. Für einen solchen Datenfluss ist keine separate Reservierung für jeden Sender erforderlich. eine einzige Reservierung reicht aus.

  • Shared Explicit (SE): Dieser Reservierungsstil besteht aus gemeinsam genutzten Reservierungen zwischen expliziten Sendern. Diese Art der Reservierung reserviert die Bandbreite für eine begrenzte Gruppe von Sendern. Eine Beispielanwendung ist eine Audioanwendung, die der Anwendung für Wildcard-Filterreservierungen ähnelt.

RSVP-Aktualisierungsreduzierung

RSVP vertraut auf Soft-State, um den Pfad und die Reservierungsstatus auf jedem Router zu behalten. Wenn die entsprechenden Aktualisierungsmeldungen nicht regelmäßig gesendet werden, werden schließlich time out und Reservierungen gelöscht. RSVP sendet seine Steuerungsmeldungen auch als IP-Datagramme, ohne dass eine Zuverlässigkeit garantiert ist. Er basiert auf regelmäßigen Aktualisierungsmeldungen, um gelegentliche Verluste von Pfad- oder Resv-Nachrichten zu verarbeiten.

Die RSVP-Aktualisierungserweiterung basierend auf RFC 2961 löst die folgenden Probleme, die sich aus regelmäßigen Aktualisierungsmeldungen zur Handhabung von Nachrichtenverlusten ergeben:

  • Skalierbarkeit: Das Skalierungsproblem entsteht aus dem regelmäßigen Übertragungs- und Verarbeitungsaufwand der Aktualisierungsmeldungen. Dieser Anstieg erhöht sich mit der Anzahl von RSVP-Sitzungen.

  • Zuverlässigkeit und Latenz: Das Problem der Zuverlässigkeit und Latenz rührt vom Verlust nicht-refressiger RSVP-Nachrichten oder einmaligen RSVP-Nachrichten wie PathTear oder PathErr ab. Die Zeit bis zur Wiederherstellung nach einem solchen Verlust ist in der Regel an die Aktualisierung des Intervalls und den Keepalive Timer gebunden.

Die RsVP-Aktualisierungsfunktion wird angekündigt, indem die Aktualisierungsreduzierung (RR) -fähiges Bit im gemeinsamen RSVP-Header ermöglicht wird. Dieser Bit ist nur für RSVP-Nachbarn wichtig.

RsVP-Aktualisierungsreduzierung umfasst die folgenden Funktionen:

  • RSVP-Nachrichtenbündelung mit der Bundle-Nachricht

  • RSVP-Nachrichten-ID zur Verringerung des Overheads bei der Nachrichtenverarbeitung

  • Zuverlässige Übermittlung von RSVP-Nachrichten über Nachrichten-ID, Message Ack und Message Nack

  • Zusammenfassende Aktualisierung zur Reduzierung der Informationsmenge, die jedes Aktualisierungsintervall übertragen wird

Mit der RSVP Refresh Reduction-Spezifikation (RFC 2961) können Sie einige oder alle der oben genannten Funktionen auf einem Router aktivieren. Darüber hinaus werden verschiedene Verfahren beschrieben, die ein Router verwenden kann, um die Aktualisierungsreduktionsfunktionen seines Nachbarn zu erkennen.

Der Junos OS unterstützt alle Erweiterungen zur Aktualisierungsreduzierung, von denen einige selektiv aktiviert oder deaktiviert werden können. Der Junos OS unterstützt Nachrichten-ID und kann daher nur für Path- und Resv-Nachrichten eine zuverlässige Nachrichtenzustellung durchführen.

Informationen zur Konfiguration der RSVP-Aktualisierungsreduzierung finden Sie unter Configuring RSVP Refresh Reduction (Konfiguration von RSVP Refresh Reduction).

MTU Signaling in RSVP

Die MTU (MTU) ist das Paket oder den Frame mit der größten Größe in Bytes, die an ein Netzwerk gesendet werden können. Ein MTU ist zu groß und kann zu erneuten Übertragungen führen. Wenn eine zu kleine MTU kann dazu führen, dass der Router relativ mehr Header-Overhead und Bestätigungen sendet und verarbeitet. Es gibt Standardwerte für MTUs, die mit verschiedenen Protokollen verknüpft sind. Sie können auch eine Konfiguration einer MTU einer Schnittstelle explizit konfigurieren.

Wenn ein LSP über eine Reihe von Verbindungen mit unterschiedlichen Größen MTU erstellt wird, weiß der Ingress-Router nicht, MTU sich auf dem LSP-Pfad befindet. Standardmäßig beträgt die MTU für einen LSP 1.500 Bytes.

Wenn diese MTU Größe über dem MTU einer der Zwischenverbindungen liegt, kann der Datenverkehr verworfen werden, weil MPLS nicht fragmentiert sein können. Auch ist dem Router, der einflässig ist, diese Art von Datenverkehrsverlust nicht bekannt, da die Steuerungsebene des LSP immer noch normal funktioniert.

Um diese Art von Paketverlust in Paketübertragungs MPLS LSPs zu verhindern, können Sie signalisieren MTU in RSVP konfigurieren. Diese Funktion wird in RFC 3209 beschrieben. Juniper Networks unterstützt das Integrated Services-Objekt für MTU-Signalübertragung in RSVP. Das Objekt der integrierten Dienste wird in den RFCs 2210 und 2215 beschrieben. MTU in RSVP ist standardmäßig deaktiviert.

Um Paketverluste aufgrund von MTU Mismatch zu vermeiden, muss der Ingress-Router Folgendes tun:

  • Signalisieren der MTU auf dem RSVP-LSP: Um den Paketverlust durch einen MTU-Mismatch zu verhindern, muss der Ingress-Router wissen, welcher MTU-Wert auf dem Pfad des LSP liegt. Sobald dieser MTU erhalten ist, kann der Router ihn dem LSP zuweisen.

  • Fragment-Pakete: Mit dem zugewiesenen MTU-Wert können Pakete, die die Größe des MTU überschreiten, in kleinere Pakete auf dem eingehenden Router fragmentiert werden, bevor sie in MPLS eingekapselt und über den RSVP-signalisierten LSP gesendet werden.

Sobald sowohl MTU Signalübertragung als auch Paketfragmentierung auf einem Ingress-Router aktiviert wurden, verwendet jede Route, die zu einem RSVP LSP auf diesem Router auflöst, den signalisierten Signalwert MTU. Informationen zur Konfiguration dieser Funktion finden Sie unter Konfigurieren MTU- und Signalübertragung in RSVP.

In den folgenden Abschnitten wird beschrieben MTU wie die Signalübertragung in RSVP funktioniert:

Wie die richtige MTU in RSVP signalisiert wird

Wie die MTU Signalübertragung in RSVP variiert, hängt davon ab, ob die Netzwerkgeräte (z. B. Router) eine Signalübertragung in RSVP explizit unterstützen MTU oder nicht.

Wenn die Netzwerkgeräte eine signalisierte MTU in RSVP unterstützen, treten bei aktivierung der signalisierten MTU Folgendes auf:

  • Der MTU wird über das Adspec-Objekt vom Ingress-Router zum Egress-Router signalisiert. Bevor er dieses Objekt weiterleitiert, gibt der Router den Wert MTU der Schnittstelle ein, über die die Pfadnachricht gesendet wird. An jedem Hop im Pfad wird der MTU wert im Adspec-Objekt auf den minimalen Received-Wert und den Wert der ausgehenden Schnittstelle aktualisiert.

  • Der eindringende Router verwendet die Datenverkehrsspezifikation (Tspec)-Objekt, um die Parameter für den Datenverkehr anzugeben, den er senden soll. Der MTU Wert, der für das Tspec-Objekt am Ingress-Router signalisiert wurde, ist der maximale MTU-Wert (9.192 Bytes für M Series- und T-Serie-Router, 9.500 Bytes für Paketübertragungs-Router PTX-Paketübertragungs-Router). Dieser Wert wird auf dem Weg zum Egress-Router nicht geändert.

  • Wenn das Adspec-Objekt am Egress-Router eintrifft, ist der Wert MTU für den Pfad korrekt (d. h. der MTU Wert wird entdeckt. Der Egress-Router vergleicht den MTU Wert im Adspec-Objekt mit dem wert MTU im Tspec-Objekt. Er zeigt die kleinere MTU flowspec-Objekt in der Resv-Nachricht an.

  • Wenn das Resv-Objekt am Ingress-Router eintrifft, wird der MTU Wert in diesem Objekt als MTU für die nächsten Hops verwendet, die den LSP verwenden.

In einem Netzwerk mit Geräten, die die Signalübertragung MTU RSVP nicht unterstützen, kann es folgende Verhaltensweisen geben:

  • Wenn der Ausgangsrouter keine Signalübertragung MTU RSVP unterstützt, wird der MTU standardmäßig auf 1.500 Byte festgelegt.

  • Ein Juniper Networks-Router, der die MTU-Signalübertragung in RSVP nicht unterstützt, legt standardmäßig einen MTU-Wert von 1.500 Bytes im Adspec-Objekt fest.

Festlegen eines ausgehenden MTU Werts

Der ausgehende MTU ist der kleinere Werte, die im Adspec-Objekt empfangen wurden, im Vergleich zum MTU Wert der ausgehenden Schnittstelle. Der MTU Wert der ausgehenden Schnittstelle wird wie folgt ermittelt:

  • Wenn Sie einen Wert MTU Hierarchieebene [family mpls] konfigurieren, wird dieser Wert signalisiert.

  • Wenn Sie eine Konfiguration einer Konfiguration MTU, wird inet MTU signalisiert.

MTU in RSVP-Beschränkungen

Im Folgenden sind Einschränkungen für MTU von Signalübertragung in RSVP:

  • Änderungen am MTU können in folgenden Situationen zu einem vorübergehenden Verlust des Datenverkehrs führen:

    • Zum Verbindungsschutz und Knotenschutz wird die MTU des Bypasss nur bei der aktiv werdenden Bypass-Signalübertragung signalisiert. In der Zeit, in der der neue Pfad MTU verbreitet wird, kann es zu Paketverlusten kommen, wenn ein oder MTU ist.

    • Für die schnelle Umleitung wird MTU Pfad nur nach der Aktivierung der Detour aktualisiert. Dies verursacht eine Verzögerung bei einer Aktualisierung des Pfads MTU des Ingress-Routers. Wenn der MTU nicht aktualisiert wird, kann es zu Paketverlusten kommen, wenn eine MTU auftritt.

      In beiden Fällen gehen nur Pakete verloren, die größer als die Umtour sind oder MTU umgehen.

  • Wenn eine MTU Aktualisiert wird, wird eine Änderung im nächsten Hop ausgelöst. Bei jeder Änderung im nächsten Hop geht die Routenstatistik verloren.

  • Das mindeste MTU für die signalisierte MTU in RSVP 1.488 Byte. Dieser Wert verhindert, dass ein falscher oder falsch konfigurierter Wert verwendet wird.

  • Bei Single-Hop-LSPs ist MTU von den Befehlen ein show RSVP-signalisierter Wert. Dieser Wert MPLS wird jedoch ignoriert und der richtige IP-Wert wird verwendet.

Release-Verlaufstabelle
Release
Beschreibung
16.1
Beginnend mit Junos OS Version 16.1 wurden RSVP Traffic Engineering (TE)-Protokollerweiterungen eingeführt, um refresh-interval Independent RSVP (RI-RSVP) definierte RFC 8370 für Fast Reroute (FRR) Facility Protection zu unterstützen, um eine höhere Skalierbarkeit von Label-Switched Paths (LSPs) schnelleren Konvergenzzeiten und einer Verringerung des RSVP-Signaling-Overheads durch regelmäßige Aktualisierungen zu ermöglichen.