Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Pop-and-Forward-LSP-Konfiguration

Pop-and-Forward-LSPs führt das Konzept der vorinstallierten Pop-Labels pro Traffic Engineering-Link ein, die von RSVP-TE-LSPs gemeinsam genutzt werden, die diese Links durchlaufen und den erforderlichen Status der Weiterleitungsebene erheblich reduzieren. Ein Transit-Label-Switching-Router (LSR) weist jeder Traffic-Engineering-Verbindung ein eindeutiges Pop-Label mit einer Weiterleitungsaktion zu, um das Label aufzulösen und das Paket über diese Traffic-Engineering-Verbindung weiterzuleiten, falls das Label oben im Paket angezeigt wird. Diese Pop-Labels werden in der RESV-Nachricht des LSP bei jedem LSR zurückgesendet und im Record Route Object (RRO) weiter aufgezeichnet. Der Label-Stack wird aus den aufgezeichneten Labels im RRO erstellt und vom Ingress-Label-Edge-Router (LER) gepusht, während jeder Transit-Hop eine Pop-and-Forward-Aktion auf seinem Label ausführt. Die Pop-and-Forward-Tunnel erweitern die Funktionsvorteile der RSVP-TE-Steuerungsebene durch die Einfachheit der gemeinsam genutzten MPLS-Weiterleitungsebene.

Vorteile von RSVP-TE Pop-and-Forward-LSP-Tunneln

  • Scaling advantage of RSVP-TE—Es wird verhindert, dass eine plattformspezifische Begrenzung des Beschriftungsbereichs auf einem LSR eine Einschränkung für die Skalierung der Steuerungsebene auf dieser Schnittstelle darstellt.

  • Reduced forwarding plane state—Die Transit-Labels auf einer Traffic-Engineering-Verbindung werden von RSVP-TE-Tunneln, die die Verbindung durchqueren, gemeinsam genutzt und unabhängig von den Eingangs- und Ausgangsgeräten der LSPs verwendet, wodurch der erforderliche Status der Weiterleitungsebene erheblich reduziert wird.

  • Reduced transit data plane state—Da die Pop-Labels pro Traffic-Engineering-Link zugewiesen und von LSPs gemeinsam genutzt werden, wird der gesamte Label-Status in der Weiterleitungsebene auf eine Funktion der Anzahl der RSVP-Nachbarn auf dieser Schnittstelle reduziert.

  • Faster LSP setup time—Der Status der Weiterleitungsebene wird während des LSP-Setups und -Abbaus nicht programmiert. Daher muss die Steuerungsebene nicht nacheinander bei jedem Hop warten, bis die Weiterleitungsebene programmiert wird, bevor das Label in der RESV-Nachricht stromaufwärts gesendet wird, was zu einer kürzeren LSP-Einrichtungszeit führt.

  • Backward compatibility—Dies ermöglicht die Abwärtskompatibilität mit Transit-LSRs, die reguläre Bezeichnungen in RESV-Nachrichten bereitstellen. Labels können über Transithops hinweg in einem einzigen MPLS RSVP-TE LSP gemischt werden. Bestimmte LSRs können Traffic Engineering-Link-Labels verwenden, andere können reguläre Labels verwenden. Der Eingang kann einen entsprechenden Label-Stack erstellen, je nachdem, welche Art von Label von jedem Transit-LSR aufgezeichnet wird.

Pop-and-Forward-LSP-Tunnel-Terminologie

Die folgende Terminologie wird bei der Implementierung von RSVP-TE POP-AND-FORWARD-LSP-Tunneln verwendet:

  • Pop label– Ein eingehendes Label an einem LSR, das über eine bestimmte Traffic-Engineering-Verbindung an einen Nachbarn weitergeleitet wird.

  • Swap label– Ein eingehendes Label an einem LSR, das gegen ein ausgehendes Label ausgetauscht und über eine bestimmte nachgelagerte Traffic-Engineering-Verbindung weitergeleitet wird.

  • Delegation label– Ein eingehendes Etikett an einem LSR, das gepoppt wird. Ein neuer Satz von Labels wird übertragen, bevor das Paket weitergeleitet wird.

  • Delegation hop– Ein Transit-Hop, der eine Delegierungsbezeichnung zuweist.

  • Application label depth (AppLD)– Maximale Anzahl von Anwendungs- oder Dienstbezeichnungen (z. B. VPN-, LDP- oder IPv6-Bezeichnungen mit expliziten NULL-Bezeichnungen), die sich unter den RSVP-Transportbezeichnungen befinden können. Er wird für jeden Knoten konfiguriert und gilt für alle Sprachdienstleister gleichermaßen. Er wird weder signalisiert noch angekündigt.

  • Outbound label depth (OutLD)- Maximale Anzahl von Labels, die vor der Weiterleitung eines Pakets übertragen werden können. Dies ist für den Knoten lokal und wird weder signalisiert noch angekündigt.

  • Additional transport label depth (AddTLD): Maximale Anzahl anderer Transportbeschriftungen, die hinzugefügt werden können (z. B. Umgehungsbeschriftung). Hierbei handelt es sich um einen Parameter pro LSP, der weder signalisiert noch angekündigt wird. Der Wert wird ermittelt, indem geprüft wird, ob der LSP mit Linkschutz (AddTLD=1) oder ohne Linkschutz (AddTLD=0) signalisiert wurde.

  • Effective transport label depth (ETLD)— Anzahl der Transportbezeichnungen, die der LSP-Hop potenziell an seinen Downstream-Hop senden kann. Dieser Wert wird pro LSP im Unterobjekt Hop-Attribute signalisiert. Das Unterobjekt hop attributes wird dem Datensatzroutenobjekt (RRO) in der Pfadnachricht hinzugefügt.

Pop-and-Forward-LSP-Tunnellabel und Signalisierung

Jeder Traffic-Engineering-Verbindung wird ein Pop-Label zugewiesen, das in der mpls.0-Routing-Tabelle installiert ist, mit einer Weiterleitungsaktion, um das Label aufzurufen und das Paket über die Traffic-Engineering-Verbindung an den nachgeschalteten Nachbarn des RSVP-TE-Tunnels weiterzuleiten.

Bei Pop-and-Forward-LSP-Tunneln wird die Pop-Bezeichnung für die Traffic-Engineering-Verbindung zugewiesen, wenn die erste RESV-Nachricht für eine Pop-and-Forward-Transit-LSP über diese Traffic-Engineering-Verbindung eintrifft. Dies geschieht, um die Vorabzuweisung von Pop-Labels und deren Installation in Netzwerken zu vermeiden, in denen Pop-and-Forward-LSPs nicht konfiguriert sind.

HINWEIS:

Damit die Pop-and-Forward-LSP-Tunnel effektiv funktionieren, wird empfohlen, die Anweisung auf allen Schnittstellen im RSVP-TE-Netzwerk zu konfigurieren.maximum-labels

Abbildung 1 Zeigt Pop-Labels an allen Schnittstellen für benachbarte Geräte an.

Abbildung 1: Pop-and-Forward-LSP-TunnelbeschriftungenPop-and-Forward-LSP-Tunnelbeschriftungen

Es gibt zwei Pop-and-Forward-LSP-Tunnel: T1 und T2. Tunnel T1 verläuft von Gerät A zu Gerät E auf dem Pfad A-B-C-D-E. Tunnel T2 verläuft von Gerät F zu Gerät E auf dem Pfad F-B-C-D-E. Beide Tunnel, T1 und T2, teilen sich die gleichen verkehrstechnischen Verbindungen B-C, C-D und D-E.

Wenn RSVP-TE die Einrichtung des Pop-and-Forward-Tunnels T1 signalisiert, empfängt der LSR D die RESV-Nachricht vom Ausgang E. Gerät D überprüft die Next-Hop-Traffic-Engineering-Verbindung (D-E) und stellt das Pop-Label (250) in der RESV-Nachricht für den Tunnel bereit. Die Beschriftung wird im Label-Objekt gesendet und auch im Label-Unterobjekt (mit gesetztem Pop-Label-Bit) aufgezeichnet, das in der RRO enthalten ist. In ähnlicher Weise stellt Gerät C die Pop-Bezeichnung (200) für die Next-Hop-Traffic-Engineering-Verbindung C-D und Gerät B die Pop-Bezeichnung (150) für die Next-Hop-Traffic-Engineering-Verbindung B-C bereit. Für den Tunnel T2 stellen die Transit-LSRs die gleichen Pop-Labels bereit wie für Tunnel T1 beschrieben.

Sowohl die Label-Edge-Router (LERs), Gerät A als auch Gerät F, übertragen denselben Stapel von Labels [150(oben), 200, 250] für die Tunnel T1 bzw. T2. Die aufgezeichneten Labels im RRO werden von der Eingangs-LER verwendet, um einen Stapel von Labels zu erstellen.

Die Pop-and-Forward-LSP-Tunnelbezeichnungen sind mit Transitschnittstellen kompatibel, die Auslagerungsbezeichnungen verwenden. Labels können über Transithops in einem einzigen MPLS RSVP-TE LSP gemischt werden, wobei bestimmte LSRs Pop-Labels und andere Swap-Labels verwenden können. Das Eingangsgerät erstellt den entsprechenden Etikettenstapel basierend auf dem Etikettentyp, der von jedem Transit-LSR aufgezeichnet wird.

Pop-and-Forward-LSP-Tunnel-Label-Stacking

Aufbau des Etikettenstapels am Eingang

Der Eingangs-LER überprüft den Typ der Bezeichnung, die von jedem Transithop empfangen wurde, wie im RRO in der RESV-Nachricht aufgezeichnet, und generiert den entsprechenden Bezeichnungsstapel, der für den Pop-and-Forward-Tunnel verwendet werden soll.

Die folgende Logik wird von der Eingangs-LER beim Erstellen des Bezeichnungsstapels verwendet:

  • Jedes RRO-Label-Unterobjekt wird beginnend mit dem Label-Unterobjekt aus dem ersten Downstream-Hop verarbeitet.

  • Jede Bezeichnung, die vom ersten nachgeschalteten Hop bereitgestellt wird, wird immer auf dem Bezeichnungsstapel abgelegt. Wenn es sich bei dem Bezeichnungstyp um ein Pop-Label handelt, wird jedes Label aus dem nachfolgenden Downstream-Hop ebenfalls auf den erstellten Labelstapel verschoben.

  • Wenn es sich bei dem Bezeichnungstyp um eine Auslagerungsbezeichnung handelt, wird keine Bezeichnung aus dem nachfolgenden Downstream-Hop auf den erstellten Bezeichnungsstapel übertragen.

Automatische Delegierung des Etikettenstapels

Das Eingangsgerät führt den CSPF (Constrained Shortest Path First) aus, um den Pfad zu berechnen, und wenn die Hop-Länge größer als der ist, kann das Eingangsgerät nicht den gesamten Bezeichnungsstapel aufzwingen, um das Ausgangsgerät zu erreichen.OutLD-AppLD-AddTLD

Wenn RSVP-TE aufgefordert wird, den Pfad zu signalisieren, fordert das Eingangsgerät immer die automatische Delegierung für den LSP an, wobei sich ein oder mehrere Transit-Hops automatisch als Delegierungs-Hops auswählen, um den Label-Stack zum nächsten Delegierungs-Hop zu pushen. Junos OS verwendet einen Algorithmus, der auf der empfangenen Effective Transport Label-Stack Depth (ETLD) basiert und die jeder Transit ausführt, um zu entscheiden, ob er sich automatisch als Delegierungs-Hop auswählen soll. Dieser Algorithmus basiert auf dem Abschnitt über ETLD im Internet-Entwurf draft-ietf-mpls-rsvp-shared-labels-00.txt (läuft am 11. September 2017 ab), Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane.

Der vom Eingangsgerät vorgegebene Label-Stack übermittelt das Paket bis zum ersten Delegierungs-Hop. Der Bezeichnungsstapel jedes Delegierungshops enthält auch die Delegierungsbezeichnung des nächsten DelegierungspHops am unteren Rand des Stapels.

zeigt Bezeichnungen an jeder Geräteschnittstelle an, wobei Gerät D und Gerät I Delegierungshops, P die Pop-Bezeichnung und D die Delegierungsbezeichnung ist.Abbildung 2[Label][Label] Der RSVP-TE Pop-and-Forward-LSP-Tunnel ist A-B-C-D-E-F-G-H-I-J-K-L. Die Delegierungsbezeichnung 1250 steht für (300, 350, 400, 450, 1500); Die Delegierungsbezeichnung 1500 steht für (550, 600).

Abbildung 2: Pop-and-Forward-LSP-Tunnel-Pop- und DelegierungsbezeichnungenPop-and-Forward-LSP-Tunnel-Pop- und Delegierungsbezeichnungen

Bei diesem Ansatz drückt für den Tunnel das eingehende LER-Gerät A (150, 200, 1250). Bei LSR-Gerät D wird das Delegierungslabel 1250 gepoppt und die Labels 300, 350, 400, 450 und 1500 werden übertragen. Bei LSR-Gerät I wird das Delegierungslabel 1500 geplatzt und der verbleibende Satz von Labels (550, 600) wird übertragen. In Junos OS erfolgt die Pop-and-Push-Aktion als Auslagerung zur untersten Bezeichnung des ausgehenden Stapels und Push der verbleibenden Bezeichnungen.

Eine Delegierungsbezeichnung und das LSP-Segment, das sie abdeckt, können von mehreren Pop-and-Forward-LSPs gemeinsam genutzt werden. Ein LSP-Delegierungssegment besteht aus einem geordneten Satz von Hops (IP-Adressen und Labels), wie sie im RESV RRO zu sehen sind. Die Delegierungsbezeichnung (und das Segment, das sie abdeckt) ist nicht im Besitz eines bestimmten LSP, kann aber freigegeben werden. Wenn alle Sprachdienstleister, die eine Delegierungsbezeichnung verwenden, gelöscht werden, wird die Delegierungsbezeichnung (und die Route) gelöscht.

Pop-and-Forward-Schutz für LSP-Tunnelverbindungen

Um den Verbindungsschutz an einem Point of Local Repair (PLR) mit einer Pop-and-Forward-Datenebene bereitzustellen, weist der LSR ein separates Pop-Label für die Traffic-Engineering-Verbindung zu, die für die RSVP-TE-Tunnel verwendet wird, die den Verbindungsschutz vom Eingangsgerät anfordern. Es sind keine Signalisierungserweiterungen erforderlich, um den Verbindungsschutz für die RSVP-TE-Tunnel über die Pop-and-Forward-Datenebene zu unterstützen.

Abbildung 3 zeigt Pop-Labels an jeder Geräteschnittstelle an; Labels, die mit P markiert sind, sind Pop-Labels, die Link-Schutz für den Traffic-Engineering-Link bieten.

Abbildung 3: Pop-and-Forward-LSP-TunnelverbindungsschutzPop-and-Forward-LSP-Tunnelverbindungsschutz

An jedem LSR können für jede Traffic-Engineering-Verbindung verbindungsgeschützte Pop-Labels zugewiesen werden, und zum Schutz der Traffic-Engineering-Verbindung kann ein Link-Schutzeinrichtungs-Bypass-LSP erstellt werden (bei dem es sich nicht um ein Pop-and-Forward-LSP, sondern um ein normales Bypass-LSP handelt). Diese Labels können in der RESV-Nachricht vom LSR an LSPs gesendet werden, die den Verbindungsschutz über die spezifische Traffic-Engineering-Verbindung anfordern. Da die Umgehung der Einrichtung am nächsten Hop (Zusammenführungspunkt) endet, entspricht das eingehende Pop-Label auf dem Paket im PLR dem, was der Zusammenführungspunkt erwartet.

Beispielsweise kann die LSR-Vorrichtung B eine Umgehungs-LSP für das Link-geschützte Pop-Label 151 installieren. Wenn die Traffic-Engineering-Verbindung B-C verfügbar ist, gibt LSR-Gerät B die Nummer 151 aus und sendet das Paket an C. Wenn die Traffic-Engineering-Verbindung B-C ausgefallen ist, kann der LSR 151 knallen und das Paket über die Sicherung der Einrichtung an Gerät C senden.

RSVP-TE Pop-and-Forward LSP-Tunnel – Unterstützte und nicht unterstützte Funktionen

Junos OS unterstützt die folgenden Funktionen mit RSVP-TE Pop-and-Forward-LSP-Tunneln:

  • Pop-Labels pro RSVP-Nachbar für ungeschützte LSPs.

  • Pop-Labels pro RSVP-Nachbar für LSPs, die den Link-Schutz mithilfe der Umgehung der Einrichtung anfordern

  • Automatische Delegierung des LSP-Segments.

  • Mixed-Label-Modus, bei dem bestimmte Transit-LSRs keine Pop-and-Forward-LSP-Tunnel unterstützen

  • LSP-Ping und Traceroute

  • Alle vorhandenen CSPF-Einschränkungen.

  • Lastenausgleich des Datenverkehrs zwischen Pop-and-Forward-LSPs und regulären Punkt-zu-Punkt-RSVP-TE-LSP.

  • Automatische Bandbreite, LDP-Tunneling und TE++-Container-LSP.

  • Aggregierte Ethernet-Schnittstelle.

  • Unterstützung virtueller Plattformen, wie z. B. der virtuelle vMX-Router von Juniper Networks.

  • 64-Bit-Unterstützung

  • Logische Systeme

Junos OS unterstützt die folgenden Funktionen für RSVP-TE Pop-and-Forward-LSP-Tunnel nicht:

  • Schutz von Knotenverbindungen

  • Umleitungsschutz für MPLS-Schnellumleitung

  • Punkt-zu-Multipunkt-LSPs.

  • Switch-away LSP.

  • Generalized MPLS (GMPLS) LSPs (einschließlich bidirektionaler LSPs, zugehöriger LSPs, VLAN-Benutzer-zu-Netzwerk-Schnittstelle [UNI] usw.)

  • IP Flow Information Export (protocol) (IPFIX) Inline-Flow-Sampling für MPLS-Vorlage

  • RFC 3813, Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)

  • IPv4 Explicit-null (Das Einfügen der Bezeichnung 0 am unteren Rand des Beschriftungsstapels wird nicht unterstützt. Wenn sich unter dem RSVP-TE-Pop-and-Forward-Label-Stack Service-Labels befinden, weil der vorletzte Hop für den LSP den EXP-Wert in die Service-Bezeichnung kopiert, kann dies die Kontinuität der Class of Service (CoS) über die MPLS-Weiterleitungsebene hinweg ermöglichen.

  • Ultimate-Hop-Popping (UHP)

  • Graceful Routing Engine Switchover (GRES)

  • Nonstop Active Routing (NSR)