RSVP-Übersicht

Das RSVP-Protokoll wird von Routern verwendet, um QoS-Anforderungen (Quality of Service) an alle Knoten entlang der Datenflusspfade zu senden und den Status für den angeforderten Dienst herzustellen und aufrechtzuerhalten. RSVP-Anfragen führen in der Regel zu Ressourcenreservierungen in jedem Knoten entlang des Datenpfads. RSVP hat die folgenden Attribute:

• Nimmt Ressourcenreservierungen für unidirektionale Datenflüsse vor.

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

• Behält einen weichen Zustand in Routern und Hosts bei und bietet elegante 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 -stile für eine Vielzahl von Anwendungen.

• Unterstützt sowohl IPv4- als auch IPv6-Pakete, die über RSVP-signalisierte LSPs gesendet werden können.

Abbildung 1: RSVP-Reservierungsanfrage und Datenfluss

RSVP erstellt unabhängige Sitzungen, um jeden Datenfluss zu verarbeiten. Eine Sitzung wird durch eine Kombination aus der Zieladresse, einem optionalen Zielport und einem Protokoll identifiziert. Innerhalb einer Sitzung kann es einen oder mehrere Absender geben. Jeder Absender 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 an alle Sender und Empfänger zu übermitteln.

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

1. Ein potenzieller Absender beginnt mit dem Senden von RSVP-Pfadnachrichten an die Sitzungsadresse.

2. Ein Empfänger, der an der Sitzung teilnehmen möchte, registriert sich bei Bedarf. Beispielsweise würde sich ein Empfänger in einer Multicastanwendung 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 einen Flussdeskriptor, der von Routern entlang des Pfads verwendet wird, um Reservierungen in ihren Link-Layer-Medien vorzunehmen.

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

Diese Abfolge von Ereignissen ist nicht unbedingt genau synchronisiert. Empfänger können sich z. B. registrieren, bevor sie Pfadnachrichten vom Absender empfangen, und Anwendungsdaten können fließen, bevor der Absender Resv-Nachrichten empfängt. Anwendungsdaten, die vor der eigentlichen Reservierung in der Resv-Nachricht übermittelt werden, werden in der Regel als Best-Effort-Datenverkehr ohne CoS-Garantie behandelt.

RSVP ist ein Signalisierungsprotokoll, das die Bandbreitenzuweisung und echtes Traffic Engineering in einem MPLS-Netzwerk übernimmt. Wie LDP verwendet RSVP Discovery-Nachrichten und Ankündigungen, um LSP-Pfadinformationen zwischen allen Hosts auszutauschen. RSVP enthält jedoch auch eine Reihe von Funktionen, die den Datenverkehrsfluss durch ein MPLS-Netzwerk steuern. Während LDP darauf beschränkt ist, den kürzesten Pfad der konfigurierten IGP als Transitpfad durch das Netzwerk zu verwenden, verwendet RSVP eine Kombination aus dem CSPF-Algorithmus (Constrained Shortest Path First) und Explicit Route Objects (EROs), um zu bestimmen, wie der Datenverkehr durch das Netzwerk geleitet wird.

Grundlegende RSVP-Sitzungen werden auf die gleiche Weise eingerichtet wie LDP-Sitzungen. Indem Sie sowohl MPLS als auch RSVP auf den entsprechenden Transitschnittstellen konfigurieren, ermöglichen Sie den Austausch von RSVP-Paketen und die Einrichtung von LSPs. Mit RSVP können Sie jedoch auch Linkauthentifizierung, explizite LSP-Pfade und Linkfärbung konfigurieren.

Dieses Thema enthält die folgenden Abschnitte:

• RSVP-Grundlagen
• Bandbreitenreservierung erforderlich
• Explizite Routenobjekte
• Eingeschränkter kürzeste Pfad zuerst
• Link-Coloring

Explizite Routenobjekte

Explicit Route Objects (EROs) beschränken das LSP-Routing auf eine bestimmte Liste von LSRs. Standardmäßig folgen RSVP-Nachrichten einem Pfad, der durch den kürzesten Pfad der Netzwerk-IGP bestimmt wird. Wenn jedoch eine konfigurierte ERO vorhanden ist, folgen die RSVP-Nachrichten dem angegebenen Pfad.

EROs bestehen aus zwei Arten von Anweisungen: lockerer Hopfen und strenger Hopfen. Wenn ein loser Hop konfiguriert ist, identifiziert er einen oder mehrere Transit-LSRs, über die der LSP geroutet werden muss. Die Netzwerk-IGP bestimmt 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 aufgenommen werden soll.

Wenn ein strikter Hop konfiguriert ist, identifiziert er einen genauen Pfad, ü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 bestimmt die IGP die Route zwischen losen Hops, und die Strict-Hop-Konfiguration gibt den genauen Pfad für bestimmte LSP-Pfadsegmente an.

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

Abbildung 2: Typischer RSVP-signalisierter LSP mit EROs

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

Ab Junos OS Version 16.1 wurden RSVP Traffic Engineering (TE)-Protokollerweiterungen zur Unterstützung von Refresh-interval Independent RSVP (RI-RSVP) definiertem RFC 8370 für den Schutz von Fast Reroute (FRR)-Einrichtungen eingeführt, um eine größere Skalierbarkeit von Label-Switched Paths (LSPs), schnellere Konvergenzzeiten und einen geringeren RSVP-Signalisierungsnachrichten-Overhead durch regelmäßige Aktualisierungen zu ermöglichen. Junos RSVP-TE wird standardmäßig im erweiterten FRR-Modus, auch bekannt als RI-RSVP-Modus, ausgeführt, der Protokollerweiterungen zur Unterstützung von RI-RSVP für die Umgehung von FRR-Einrichtungen enthält, die ursprünglich in RFC 4090 spezifiziert wurden.

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

Im Rahmen des verbesserten FRR-Profils wurden eine Reihe von Änderungen vorgenommen und neue Standardeinstellungen übernommen. Diese sind hier aufgelistet.

• RSVP-TE führt standardmäßig den "erweiterten" FRR- oder RI-RSVP-Modus aus, der Verbesserungen zur Erleichterung hochskalierter Szenarien enthält. Diese neuen Protokollerweiterungen können auf einem Router mit dem Befehl no-enhanced-frr-bypass deaktiviert werden.

• Die in RFC 2961 definierten Erweiterungen zur Reduzierung der RSVP-Aktualisierung sind standardmäßig aktiviert. Der Benutzer kann sie mit dem Befehl no-reliable deaktivieren (siehe unten).

  HINWEIS:

  Node-ID-basierte Hellos sind standardmäßig aktiviert, da erweiterte FRR- oder RI-RSVP-Erweiterungen den Austausch von Node-ID-basierten Hello-Nachrichten erfordern. Node-ID-basierte Hellos können mit einem Befehl deaktiviert werden.node-hello Da Aktualisierungsreduzierungserweiterungen und Node-ID-basierte Hello-Nachrichten für erweiterte FRR- oder RI-RSVP-Erweiterungen unerlässlich sind, werden durch Deaktivieren einer dieser Erweiterungen automatisch erweiterte FRR-Erweiterungen auf dem Knoten deaktiviert.

• Die standardmäßige Aktualisierungszeit für RSVP-Nachrichten wurde von 30 Sekunden auf 20 Minuten erhöht.

• Der Standardwert für keep-multiplikator, der 3 ist, wird auf die neue Standardaktualisierungszeit angewendet.keep-multiplier

• Die lokale Wiederherstellung ist standardmäßig deaktiviert. Die vorhandene CLI-Konfiguration für den Knoten Hellos, ist weiterhin verfügbar, aber die Aktion ist redundant.[edit protocols rsvp node-hello] Wenn diese Option aktiviert ist, wird eine Meldung angezeigt, die darauf hinweist, dass die Konfiguration in Verbindung mit der erweiterten FRR nicht erforderlich ist.

• Die vorhandenen Befehle zum Deaktivieren der Nachrichtenzuverlässigkeit werden jetzt verwendet, um die RSVP-Aktualisierungsreduzierung zu deaktivieren. Um zur vorherigen Standardeinstellung zurückzukehren, die die Aktualisierungsreduzierung aktiviert, verwenden Sie die Version der folgenden Befehle:delete

  • Wird auf eine bestimmte Schnittstelle festgelegt , um FRR-Skalierbarkeitsverbesserungen automatisch für alle LSPs zu deaktivieren, die die Schnittstelle durchlaufen.no-reliable Wenn Sie RSVP-TE ohne FRR-Facility-Schutzverbesserungen und ohne Aktualisierungsreduzierung ausführen möchten, deaktivieren Sie die Aktualisierungsreduzierung auf jeder Schnittstelle. Verwenden Sie einen der hier gezeigten 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 einer lokalen Reparatur unterzogen wird oder während der LSP-Sicherungssignalisierung aktualisiert wird. Diese Einschränkung besteht bereits in der Implementierung, da die GR- oder NSR-Umschaltung während der lokalen FRR-Reparatur zu mehreren Fehlerszenarien führt.

• Die folgenden Betriebsbefehle wurden aktualisiert, um neue Informationen über die neuen Verfahren aufzunehmen, die für die RSVP-TE-Protokollerweiterungen für den Schutz von FRR-Einrichtungen eingeführt wurden.

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

  • show rsvp neighbor detail zeigt an, ob erweiterte FRR-Prozeduren auf dem Nachbarn aktiviert sind.

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

  • show rsvp statistics zeigt gesendete und empfangene Statistiken für bedingten PathTear zusammen mit anderen Statistiken an.

  • show rsvp session extensive zeigt an, ob es sich bei dem Knoten um einen Zusammenführungspunkt handelt, und wenn ja, zeigt die PLR-Adresse (Point of Local Repair) an.

• Die bisherigen CLI-Konfigurationsoptionen zum Aktivieren oder Deaktivieren der Nachrichtenbündelung sind veraltet (die vorhandenen Konfigurationen werden akzeptiert, aber in der Ausgabe show configuration wird eine Warnung angezeigt). Die folgenden Befehle lauten:

  • [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 überflüssig (die vorhandenen Konfigurationen werden übernommen, aber in der Ausgabe show configuration wird eine Warnung angezeigt):

  • [edit protocols rsvp interface name reliable]

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

Die Junos-Implementierung von RSVP unterstützt RSVP Version 1. Die Software bietet Unterstützung für alle obligatorischen Objekte und RSVP-Nachrichtentypen und unterstützt die Nachrichtenintegrität und Knotenauthentifizierung über das Integrity-Objekt.

Der Hauptzweck der Junos RSVP-Software besteht darin, dynamische Signale innerhalb von MPLS-LSPs (Label-Switched Paths) zu unterstützen. Die Unterstützung von Ressourcenreservierungen über das Internet ist nur ein sekundärer Zweck der Junos OS-Implementierung. Da die Unterstützung von Ressourcenreservierungen zweitrangig ist, unterstützt die Junos RSVP-Software die folgenden Funktionen nicht:

• IP-Multicasting-Sitzungen.

• Steuerung des Datenverkehrs. Die Software kann keine Ressourcenreservierungen für Video- oder Audiositzungen in Echtzeit vornehmen.

In Bezug auf den Protokollmechanismus, die Paketverarbeitung und die unterstützten RSVP-Objekte ist die Junos OS-Implementierung der Software mit anderen RSVP-Implementierungen interoperabel.

Das Junos-Betriebssystem unterstützt sowohl den in RFC 2747 beschriebenen RSVP-Authentifizierungsstil (ermöglicht Kompatibilität mit mehreren Anbietern) als auch den RSVP-Authentifizierungsstil, der in Internetentwurf draft-ietf-rsvp-md5-03.txt beschrieben wird. Das Junos-Betriebssystem verwendet standardmäßig den Authentifizierungsstil, der in Internetentwurf draft-ietf-rsvp-md5-08.txt beschrieben wird. Wenn der Router eine RSVP-Authentifizierung im RFC 2747-Stil von einem Nachbarn empfängt, wechselt er für diesen Nachbarn zu dieser Art der Authentifizierung. Der RSVP-Authentifizierungsstil für jeden benachbarten Router wird separat festgelegt.

RSVP überwacht den Status der Nachbarn des Interior Gateway Protocol (IGP) (IS-IS oder OSPF) und verlässt sich auf die IGP-Protokolle, um zu erkennen, wenn ein Knoten ausfällt. Wenn ein IGP-Protokoll einen Nachbarn für unerreichbar erklärt (weil keine Hello-Pakete mehr empfangen werden), schaltet RSVP auch diesen Nachbarn aus. Die IGP-Protokolle und RSVP agieren jedoch immer noch unabhängig voneinander, wenn ein Nachbar angesprochen wird.

Im Junos-Betriebssystem verlässt sich RSVP in der Regel auf die IGP-Hello-Paketerkennung, um nach Knotenfehlern zu suchen. Wenn Sie eine kurze Zeit für die IS-IS- oder OSPF-Hello-Timer konfigurieren, können diese Protokolle Knotenausfälle schnell erkennen. Wenn der Knoten ausfällt oder ein Knotenfehler erkannt wird, wird eine Pfadfehlermeldung generiert, und obwohl die RSVP-Sitzung ausfällt, bleiben die IGP-Nachbarn aktiv.

Auf RSVP-Hellos kann man sich verlassen, wenn die IGP einen bestimmten Nachbarn nicht erkennt (z. B. wenn IGP auf der Schnittstelle nicht aktiviert ist) oder wenn die IGP RIP ist (nicht IS-IS oder OSPF). Außerdem können die Geräte anderer Anbieter so konfiguriert sein, dass sie RSVP-Sitzungen basierend auf RSVP-Hello-Paketen überwachen. Dieses Gerät kann auch eine RSVP-Sitzung aufgrund eines Verlusts von RSVP-Hello-Paketen unterbrechen.

Es wird nicht empfohlen, einen kurzen RSVP-Hallo-Timer zu konfigurieren. Wenn eine schnelle Erkennung eines ausgefallenen Nachbarn erforderlich ist, konfigurieren Sie kurze IGP-Hello-Timer (OSPF oder IS-IS).

OSPF und IS-IS verfügen über eine Infrastruktur, um das schnelle Senden und Empfangen von Hello-Nachrichten zuverlässig zu verwalten, selbst wenn die Routing-Protokolle oder andere Prozesse die Verarbeitungskapazität des Routers belasten. Unter den gleichen Umständen kann es vorkommen, dass RSVP-Hallos vorzeitig ablaufen, obwohl der Nachbar normal funktioniert.

RSVP verwendet die folgenden Arten von Nachrichten, um Pfade für Datenflüsse einzurichten und zu entfernen, Reservierungsinformationen einzurichten und zu entfernen, die Einrichtung von Reservierungen zu bestätigen und Fehler zu melden:

• Pfad-Meldungen
• Resv-Nachrichten
• PathTear-Meldungen
• ResvTear-Nachrichten
• PathErr-Meldungen
• ResvErr-Nachrichten
• ResvConfirm-Meldungen

Service Provider verwenden häufig BGP- und MPLS-VPNs, um das Netzwerk effizient zu skalieren und gleichzeitig umsatzgenerierende Services bereitzustellen. In diesen Umgebungen wird BGP verwendet, um die VPN-Routing-Informationen über das Netzwerk des Service Providers zu verteilen, während MPLS verwendet wird, um diesen VPN-Datenverkehr von einem VPN-Standort zu einem anderen weiterzuleiten. BGP- und MPLS-VPNs basieren auf einem Peer-Modell. Um ein neues CE-Gerät (Standort) zu einem vorhandenen VPN hinzuzufügen, müssen Sie den CE-Router am neuen Standort und den PE-Router konfigurieren, der mit dem CE-Router verbunden ist. Sie müssen nicht die Konfiguration aller anderen PE-Router ändern, die am VPN teilnehmen. Die anderen PE-Router lernen automatisch die Routen kennen, die mit dem neuen Standort verknüpft sind, ein 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 erfordert, dass die BGP-Sitzung vollständig vermascht ist und dass auch ein vollständiges Netz von PE-Router-zu-PE-Router-MPLS-Label-Switched-Pfaden (LSPs) zwischen allen PE-Routern im Netzwerk vorhanden ist. Wenn Sie dem Netzwerk einen neuen PE-Router hinzufügen, müssen alle vorhandenen PE-Router für die Peering-Verbindung mit dem neuen PE-Router neu konfiguriert werden. Ein Großteil des Konfigurationsaufwands kann reduziert werden, wenn Sie BGP-Routenreflektoren konfigurieren (wodurch die Anforderung des vollen Netzes für BGP verringert wird) und wenn Sie (LDP) als Signalisierungsprotokoll für MPLS konfigurieren.

Wenn Sie jedoch einen neuen PE-Router zu einem Netzwerk hinzufügen müssen, das mit einem vollständigen Netz von RSVP-signalisierten LSPs konfiguriert ist, 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 adressieren. Wenn Sie das automatische RSVP-Mesh aktivieren, werden RSVP-LSPs dynamisch zwischen einem neuen PE-Router und den vorhandenen PE-Routern erstellt, sodass nicht alle PE-Router manuell neu konfiguriert werden müssen. Damit die dynamische LSP-Erstellung ordnungsgemäß funktioniert, muss BGP so konfiguriert sein, dass Routen zwischen allen teilnehmenden PE-Routern ausgetauscht werden. Wenn zwei BGP-Peers keine Routen austauschen, ist es nicht möglich, einen dynamischen LSP zwischen ihnen zu konfigurieren. Die inet.3-Routing-Tabelle des lokalen Routers muss eine beschriftete Route zu jedem potenziellen IBGP-Next-Hop (zukünftige potenzielle PE-Router oder LSP-Ziele) enthalten.

RSVP enthält zahlreiche Funktionen, die in LDP nicht verfügbar sind, darunter schnelle Weiterleitung, Endpunktsteuerung und Verbindungsverwaltung. Das automatische RSVP-Mesh trägt dazu bei, den Betriebs- und Wartungsaufwand für RSVP zu reduzieren, sodass RSVP in größeren und komplizierteren Netzwerken bereitgestellt werden kann.

Jeder PE-Router kann jeden anderen PE-Router im Netzwerk erreichen, da diese Informationen von der IGP verteilt werden. Ein PE-Router kann einen Punkt-zu-Punkt-RSVP-LSP für jeden anderen PE-Router im Netzwerk einrichten, sofern er weiß, dass ein solcher LSP erforderlich ist. Um ein vollständiges Netz von LSPs zwischen den PE-Routern aufzubauen, muss jeder PE-Router wissen, aus welchem der anderen PE-Router das vollständige Mesh besteht.

Eine Reservierungsanfrage enthält Optionen zum Festlegen des Reservierungsstils. Die Reservierungsstile definieren, wie Reservierungen für verschiedene Absender innerhalb derselben Sitzung behandelt werden und wie Absender ausgewählt werden.

Zwei Optionen geben an, wie Reservierungen für verschiedene Absender innerhalb derselben Sitzung behandelt werden:

• Eindeutige Reservierung: Jeder Empfänger richtet seine eigene Reservierung bei jedem Upstream-Absender ein.

• Gemeinsame Reservierung: Alle Empfänger nehmen eine einzelne Reservierung vor, die von vielen Absendern gemeinsam genutzt wird.

Zwei Optionen geben an, wie Absender ausgewählt werden:

• Expliziter Absender: Listet alle ausgewählten Absender auf.

• Platzhalterabsender: Wählen Sie alle Absender aus, die dann an der Sitzung teilnehmen.

Die folgenden Reservierungsstile, die aus einer Kombination dieser vier Optionen bestehen, sind derzeit definiert:

• Fester Filter (FF): Dieser Reservierungsstil besteht aus unterschiedlichen Reservierungen unter expliziten Absendern. Beispiele für Anwendungen, die Reservierungen im Stil eines festen Filters verwenden, sind Videoanwendungen und Unicastanwendungen, für die beide Flows erforderlich sind, die für jeden Absender eine separate Reservierung haben. Der Reservierungsstil mit festem Filter ist für RSVP-LSPs standardmäßig aktiviert.

• Platzhalterfilter (WF): Dieser Reservierungsstil besteht aus gemeinsam genutzten Reservierungen durch Platzhalterabsender. Diese Art der Reservierung reserviert Bandbreite für alle Absender und wird im Upstream an alle Absender weitergegeben, wobei sie automatisch auf neue Absender ausgeweitet wird, sobald diese angezeigt werden. Eine Beispielanwendung für Platzhalterfilterreservierungen ist eine Audioanwendung, bei der jeder Absender einen bestimmten Datenstrom überträgt. In der Regel senden immer nur wenige Absender gleichzeitig. Für einen solchen Ablauf ist nicht für jeden Absender eine separate Reservierung erforderlich. Eine einzige Reservierung ist ausreichend.

• Shared Explicit (SE): Dieser Reservierungsstil besteht aus gemeinsamen Reservierungen zwischen expliziten Absendern. Bei dieser Art der Reservierung wird Bandbreite für eine begrenzte Gruppe von Absendern reserviert. Bei einer Beispielanwendung handelt es sich um eine Audioanwendung, die der für Platzhalterfilterreservierungen beschriebenen Anwendung ähnelt.

RSVP stützt sich auf Soft-State, um den Pfad- und Reservierungsstatus auf jedem Router beizubehalten. Wenn die entsprechenden Aktualisierungsmeldungen nicht regelmäßig gesendet werden, tritt schließlich eine Zeitüberschreitung für die Zustände auf, und Reservierungen werden gelöscht. RSVP sendet seine Steuernachrichten auch als IP-Datagramme ohne Zuverlässigkeitsgarantie. Es stützt sich auf regelmäßige Aktualisierungsmeldungen, um den gelegentlichen Verlust von Path- oder Resv-Nachrichten zu behandeln.

Die auf RFC 2961 basierenden Erweiterungen zur Reduzierung der RSVP-Aktualisierung beheben die folgenden Probleme, die sich aus der Abhängigkeit von regelmäßigen Aktualisierungsmeldungen zur Behandlung von Nachrichtenverlusten ergeben:

• Skalierbarkeit: Das Skalierungsproblem ergibt sich aus dem regelmäßigen Übertragungs- und Verarbeitungsaufwand von Aktualisierungsnachrichten, der mit zunehmender Anzahl der RSVP-Sitzungen zunimmt.

• Zuverlässigkeit und Latenz: Das Zuverlässigkeits- und Latenzproblem ist auf den Verlust von nicht aktualisierten RSVP-Nachrichten oder einmaligen RSVP-Nachrichten wie PathTear oder PathErr zurückzuführen. Die Zeit für die Wiederherstellung nach einem solchen Verlust ist normalerweise an das Aktualisierungsintervall und den Keepalive-Timer gebunden.

Die RSVP-Aktualisierungsreduzierungsfunktion wird durch die Aktivierung des RR-fähigen (Refresh Reduction)-fähigen Bits im allgemeinen RSVP-Header angekündigt. Dieses Bit ist nur zwischen RSVP-Nachbarn von Bedeutung.

Die Reduzierung der RSVP-Aktualisierung umfasst die folgenden Funktionen:

• Bündelung von RSVP-Nachrichten mithilfe der Bundle-Nachricht

• RSVP-Nachrichten-ID zur Reduzierung des Aufwands für die Nachrichtenverarbeitung

• Zuverlässige Zustellung von RSVP-Nachrichten mit Message ID, Message Ack und Message Nack

• Zusammenfassungsaktualisierung, um die Menge der in jedem Aktualisierungsintervall übertragenen Informationen zu reduzieren

Die Spezifikation zur Reduzierung der RSVP-Aktualisierung (RFC 2961) ermöglicht es Ihnen, einige oder alle der oben genannten Funktionen auf einem Router zu aktivieren. Außerdem werden verschiedene Verfahren beschrieben, die ein Router verwenden kann, um die Aktualisierungsreduzierungsfunktionen seines Nachbarn zu erkennen.

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

Informationen zum Konfigurieren der RSVP-Aktualisierungsreduzierung finden Sie unter Konfigurieren der RSVP-Aktualisierungsreduzierung.

Die maximale Übertragungseinheit (Maximum Transmission Unit, MTU) ist das größte Paket oder der größte Frame in Byte, das in einem Netzwerk gesendet werden kann. Eine zu große MTU kann zu erneuten Übertragungen führen. 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 verschiedenen Protokollen zugeordnet sind. Sie können eine MTU auch explizit auf einer Schnittstelle konfigurieren.

Wenn ein LSP über eine Reihe von Links mit unterschiedlichen MTU-Größen erstellt wird, weiß der Eingangsrouter nicht, was die kleinste MTU auf dem LSP-Pfad ist. Standardmäßig beträgt die MTU für einen LSP 1.500 Byte.

Wenn diese MTU größer als die MTU einer der Zwischenverbindungen ist, kann der Datenverkehr verworfen werden, da MPLS-Pakete nicht fragmentiert werden können. Außerdem ist sich der Eingangsrouter dieser Art von Datenverkehrsverlust nicht bewusst, da die Steuerungsebene für den LSP weiterhin normal funktionieren würde.

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

Um Paketverluste aufgrund von MTU-Fehlanpassungen zu vermeiden, muss der Eingangsrouter Folgendes tun:

• Signal the MTU on the RSVP LSP: Um Paketverluste aufgrund einer MTU-Mismatch zu vermeiden, muss der Eingangsrouter wissen, was der kleinste MTU-Wert auf dem vom LSP eingeschlagenen Pfad ist. Sobald dieser MTU-Wert abgerufen wurde, kann der Eingangsrouter ihn dem LSP zuweisen.

• Fragmentpakete: Mithilfe des zugewiesenen MTU-Werts können Pakete, die die Größe der MTU überschreiten, auf dem Eingangsrouter in kleinere Pakete fragmentiert werden, bevor sie in MPLS gekapselt und über den RSVP-signalisierten LSP gesendet werden.

Sobald sowohl die MTU-Signalisierung als auch die Paketfragmentierung auf einem Eingangsrouter aktiviert wurden, verwendet jede Route, die in einen RSVP-LSP auf diesem Router aufgelöst wird, den signalisierten MTU-Wert. Weitere Informationen zum Konfigurieren dieser Funktion finden Sie unter MTU-Signalisierung in RSVP konfigurieren.

In den folgenden Abschnitten wird beschrieben, wie die MTU-Signalisierung in RSVP funktioniert:

• Wie die richtige MTU in RSVP signalisiert wird

• Ermitteln eines ausgehenden MTU-Wertes

• MTU-Signalisierung in RSVP-Einschränkungen

Wie die richtige MTU in RSVP signalisiert wird, hängt davon ab, ob die Netzwerkgeräte (z. B. Router) die MTU-Signalisierung in RSVP explizit unterstützen oder nicht.

Wenn die Netzwerkgeräte die MTU-Signalisierung in RSVP unterstützen, geschieht Folgendes, wenn Sie die MTU-Signalisierung aktivieren:

• Die MTU wird über das Adspec-Objekt vom Eingangsrouter an den Ausgangsrouter signalisiert. Vor der Weiterleitung dieses Objekts gibt der Eingangsrouter den MTU-Wert ein, der der Schnittstelle zugeordnet ist, über die die Pfadnachricht gesendet wird. Bei jedem Hop im Pfad wird der MTU-Wert im Adspec-Objekt auf das Minimum des empfangenen Werts und des Werts der ausgehenden Schnittstelle aktualisiert.

• Der Eingangsrouter verwendet das Datenverkehrsspezifikationsobjekt (Tspec), um die Parameter für den Datenverkehr anzugeben, den er senden wird. Der MTU-Wert, der für das Tspec-Objekt am Eingangsrouter signalisiert wird, ist der maximale MTU-Wert (9192 Byte für Router der M- und T-Serie, 9500 Byte für Paketübertragungsrouter der PTX-Serie). Dieser Wert ändert sich auf dem Weg zum Ausgangsrouter nicht.

• Wenn das Adspec-Objekt am Ausgangsrouter eintrifft, ist der MTU-Wert für den Pfad korrekt (d. h., es handelt sich um den kleinsten erkannten MTU-Wert). Der Ausgangsrouter vergleicht den MTU-Wert im Adspec-Objekt mit dem MTU-Wert im Tspec-Objekt. Es signalisiert die kleinere MTU mithilfe des Flowspec-Objekts in der Resv-Nachricht.

• Wenn das Resv-Objekt am Eingangsrouter 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 MTU-Signalisierung in RSVP nicht unterstützen, können die folgenden Verhaltensweisen auftreten:

• Wenn der Ausgangsrouter die MTU-Signalisierung in RSVP nicht unterstützt, ist die MTU standardmäßig auf 1.500 Byte festgelegt.

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

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

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

• Wenn Sie keine MTU konfigurieren, wird die MTU signalisiert.inet

Im Folgenden sind Einschränkungen für die MTU-Signalisierung in RSVP aufgeführt:

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

  • Für den Link-Schutz und den Knotenschutz wird die MTU des Bypasses erst zu dem Zeitpunkt signalisiert, zu dem der Bypass aktiv wird. Während der Zeit, die benötigt wird, bis die MTU des neuen Pfads weitergegeben wird, kann es aufgrund einer MTU-Nichtübereinstimmung zu Paketverlusten kommen.

  • Bei einer schnellen Umleitung wird die MTU des Pfads erst aktualisiert, nachdem der Umweg aktiv wird, was zu einer Verzögerung bei der Aktualisierung der MTU am Eingangsrouter führt. Bis zur Aktualisierung der MTU kann es zu Paketverlusten kommen, wenn eine MTU-Diskrepanz vorliegt.

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

• Wenn eine MTU aktualisiert wird, löst sie eine Änderung im nächsten Hop aus. Jede Änderung im nächsten Hop führt dazu, dass die Routenstatistik verloren geht.

• Die minimale MTU, die für die MTU-Signalisierung in RSVP unterstützt wird, beträgt 1.488 Byte. Dieser Wert verhindert, dass ein falscher oder falsch konfigurierter Wert verwendet wird.

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