PCEP-Konfiguration

Grundlegendes zu MPLS RSVP-TE

Traffic Engineering (TE) befasst sich mit der Leistungsoptimierung von betrieblichen Netzwerken und bezieht hauptsächlich die Datenverkehrsströme auf eine vorhandene physische Topologie ab. Traffic Engineering bietet die Möglichkeit, den Datenverkehr von dem kürzesten Pfad, der vom Interior Gateway Protocol (IGP) ausgewählt wurde, auf einen potenziell weniger überfüllten physischen Pfad durch ein Netzwerk zu verschieben.

Für das Traffic-Engineering in großen, dichten Netzwerken können MPLS-Funktionen implementiert werden, da sie möglicherweise die meisten der in einem Overlay-Modell verfügbaren Funktionen auf integrierte Weise und zu niedrigeren Kosten als die derzeit konkurrierenden Alternativen bereitstellen. Der Hauptgrund für die Implementierung von MPLS Traffic Engineering ist die Steuerung der Pfade, auf denen der Datenverkehr durch ein Netzwerk fließt. Der Hauptvorteil der Implementierung von MPLS Traffic Engineering besteht darin, dass es eine Kombination aus den Traffic-Engineering-Funktionen von ATM und der Class-of-Service -Differenzierung (CoS) von IP bietet.

In einem MPLS-Netzwerk werden Datenebeneninformationen über Label Switching weitergeleitet. Ein Paket, das auf einem Provider-Edge -Router (PE) vom Kunden-Edge -Router (CE) ankommt, werden mit Denketiketten versehen und dann an den Ausgangs-PE-Router weitergeleitet. Die Label werden am Ausgangsrouter entfernt und dann als IP-Paket an das entsprechende Ziel weitergeleitet. Die Label-Switching-Router (LSRs) in der MPLS-Domäne verwenden Label-Verteilungsprotokolle, um die Bedeutung von Labeln zu kommunizieren, die zur Weiterleitung des Datenverkehrs zwischen und über die LSRs verwendet werden. RSVP-TE ist ein solches Protokoll zur Label-Verteilung, das es einem LSR-Peer ermöglicht, mehr über die Labelzuordnungen anderer Peers zu erfahren.

Wenn sowohl MPLS als auch RSVP auf einem Router aktiviert sind, wird MPLS zu einem Client von RSVP. Der Hauptzweck der Junos OS RSVP-Software besteht darin, dynamische Signalübertragung innerhalb von Label-Switched Paths (LSPs) zu unterstützen. RSVP reserviert Ressourcen, z. B. für IP-Unicast- und Multicast-Datenströme, und fordert Quality-of-Service -Parameter (QoS) für Anwendungen an. Das Protokoll wird im MPLS Traffic Engineering erweitert, damit RSVP LSPs einrichten kann, die für das Traffic-Engineering in MPLS-Netzwerken verwendet werden können.

Wenn MPLS und RSVP kombiniert werden, werden Label mit RSVP-Datenströmen verknüpft. Sobald ein LSP eingerichtet ist, wird der Datenverkehr durch den Pfad durch das Label definiert, das auf den Eingangsknoten des LSP angewendet wird. Die Zuordnung des Etiketts zum Datenverkehr erfolgt nach unterschiedlichen Kriterien. Die Paketmenge, denen von einem bestimmten Knoten derselbe Labelwert zugewiesen wird, gehören derselben FEC (Forwarding Äquivalenzklasse) und definieren effektiv den RSVP-Datenfluss. Wenn der Datenverkehr auf diese Weise auf einem LSP abgebildet wird, wird der LSP als LSP-Tunnel bezeichnet.

LSP-Tunnel sind eine Möglichkeit, unidirektionale Label-Switched-Pfade einzurichten. RSVP-TE baut auf dem RSVP-Core-Protokoll auf, indem neue Objekte definiert und vorhandene Objekte geändert werden, die in den PATH- und RESV-Objekten für die LSP-Einrichtung verwendet werden. Die neuen Objekte – LABEL-REQUEST Object (LRO), RECORD-ROUTE Object (RRO), LABEL Object und EXPLICIT-ROUTE Object (ERO) – sind in Bezug auf das RSVP-Protokoll optional, mit Ausnahme der LRO- und LABEL-Objekte, die beide für den Aufbau von LSP-Tunneln obligatorisch sind.

Im Allgemeinen richtet RSVP-TE einen Label-Switched-Pfad ein, der die Framebereitstellung vom Eingangs- zum Ausgangsrouter gewährleistet. Mit den neuen Traffic-Engineering-Funktionen werden jedoch die folgenden Funktionen in einer MPLS-Domäne unterstützt:

• Möglichkeit, einen Label-Switched-Pfad mit einer vollständigen oder teilweisen expliziten Route einzurichten (RFC 3209).

• Auf Einschränkungen basierende LSP-Einrichtung über Verbindungen, die Anforderungen wie Bandbreite und Verbindungseigenschaften erfüllen.

• Endpunktsteuerung, die mit dem Einrichten und Verwalten von LSP-Tunneln an den Eingangs- und Ausgangsroutern verbunden ist.

• Link-Management, das Linkressourcen verwaltet, um ressourcenorientiertes Routing von Traffic-Engineering-LSPs zu tun und MPLS-Label zu programmieren.

• MPLS Fast Reroute (FRR), das die schutzbedürftigen LSPs verwaltet und diesen LSPs Backup-Tunnelinformationen zuweist.

Aktuelle EINSCHRÄNKUNGEN VON MPLS RSVP-TE

Obwohl die RSVP-Erweiterungen für das Traffic-Engineering eine bessere Netzwerkauslastung ermöglichen und die Anforderungen von Datenverkehrsklassen erfüllen, hat die heutige MPLS RSVP-TE-Protokollsuite mehrere Probleme, die mit ihrer verteilten Natur verbunden sind. Dies verursacht eine Reihe von Problemen während des Streits um die Bisektionskapazität, insbesondere innerhalb einer LSP-Prioritätsklasse, bei der eine Teilmenge von LSPs gemeinsame Setup- und Prioritätswerte hat. Zu den Einschränkungen von RSVP-TE gehören:

• Mangelnde Visibilität der einzelnen Bandbreitenanforderungen pro LSP und pro Gerät: Die Eingangsrouter in einem MPLS-RSVP-TE-Netzwerk stellen LSPs ein, ohne einen globalen Überblick über den Bandbreitenbedarf im Netzwerk zu haben. Informationen zur Netzwerkressourcenauslastung sind nur als insgesamt reservierte Kapazität nach Datenverkehrsklasse auf Schnittstellenbasis verfügbar. Der individuelle LSP-Status ist lokal auf jedem Label Edge Router (LER) nur für seine eigenen LSPs verfügbar. Infolgedessen treten eine Reihe von Problemen im Zusammenhang mit der Nachfragestruktur auf, insbesondere innerhalb einer gemeinsamen Einrichtung und haben Priorität.

• Asynchrone und unabhängige Art der RSVP-Signalübertragung: In RSVP-TE werden die Einschränkungen für die Pfadeinrichtung durch einen Administrator gesteuert. Daher wird die für einen LSP-Tunnel reservierte Bandbreite vom Administrator festgelegt und bedeutet nicht automatisch eine Begrenzung des über den Tunnel gesendeten Datenverkehrs. Daher ist die auf einem Traffic-Engineering-Link verfügbare Bandbreite die für den Link konfigurierte Bandbreite, ohne die Summe aller Reservierungen, die für den Link vorgenommen wurden. Daher führen die nicht signalisierten Anforderungen an einen LSP-Tunnel zu einer Serviceverschlechterung des LSP, der eine übermäßige Bandbreite benötigt, sowie der anderen LSPs, die die Bandbreitenanforderungen der Traffic-Engineering-Verbindung erfüllen.

• LSPs basierend auf dynamischen oder expliziten Pfadoptionen in der reihenfolge der Voreinstellung eingerichtet: Die Eingangsrouter in einem MPLS-RSVP-TE-Netzwerk richten LSPs für Anforderungen basierend auf der Reihenfolge der Ankunft ein. Da die eingehenden Router keinen globalen Überblick über den Bandbreitenbedarf im Netzwerk haben, kann die Verwendung der voreingesetzten Reihenfolge zur Einrichtung von LSPs dazu führen, dass der Datenverkehr unterbrochen wird oder LSPs überhaupt nicht eingerichtet werden, wenn es einen übermäßigen Bandbreitenbedarf gibt.

Abbildung 2 Beispielsweise wird mit MPLS RSVP-TE konfiguriert, in dem A und G die Label Edge Router (LERs) sind. Diese Eingangsrouter richten unabhängig nach der Reihenfolge der Anforderungen LSPs ein und haben keine Kenntnis oder Kontrolle über die LSPs des jeweils anderen. Die Router B, C und D sind Zwischen- oder Transitrouter, die eine Verbindung zu den Ausgangsroutern E und F herstellen.

Abbildung 2: Beispiel MPLS Traffic Engineering

Die Eingangsrouter richten LSPs in der Reihenfolge ein, in der die Anforderungen ankommen. Wenn Router G zwei Anforderungen mit je 5 Kapazität für G-F erhält, dann signalisiert G zwei LSPs – LSP1 und LSP2 – über G-B-D-F. Wenn Router A die dritte Anforderung der Kapazität 10 für A-E empfängt, signalisiert er auch einen LSP, LSP3, über A-B-C-E. Wenn jedoch die Nachfrage an den A-E-LSP von 10 auf 15 steigt, kann Router A LSP3 nicht mit demselben Pfad (A-B-C-E) signalisieren, da der B-C-Link eine geringere Kapazität hat.

Router A sollte die erhöhte Nachfrage an LSP3 über den A-B-D-C-E-Pfad signalisieren. Da LSP1 und LSP2 den B-D-Link basierend auf der Reihenfolge der eingehenden Anforderungen verwendet haben, wird LSP3 nicht signalisiert.

Obwohl für alle LSPs ausreichend Maximale-Flow-Bandbreite verfügbar ist, unterliegt LSP3 möglicherweise längeren Serviceverschlechterungen. Dies liegt an der mangelnden globalen Nachfragetransparenz von Router A und der fehlenden systemischen Koordination bei der Bedarfsplatzierung durch die Eingangsrouter A und G.

Verwendung einer externen Path-Computing-Entität

Als Lösung für die aktuellen Einschränkungen der MPLS-RSVP-TE-Pfadberechnung ist eine externe Pfad-Computing-Entität mit einer globalen Ansicht der nachfrage pro LSP pro Gerät im Netzwerk erforderlich, unabhängig von der verfügbaren Kapazität.

Derzeit wird in einem MPLS RSVP-TE-Netzwerk nur online- und echtzeitbasierte Routing-Pfadberechnungen bereitgestellt. Jeder Router führt unabhängig von den anderen Routern im Netzwerk einschränkungensbasierte Routing-Berechnungen durch. Diese Berechnungen basieren auf derzeit verfügbaren Topologieinformationen – Informationen, die in der Regel aktuell sind, aber nicht vollständig korrekt sind. LSP-Platzierungen werden lokal optimiert, basierend auf dem aktuellen Netzwerkstatus. Die MPLS RSVP-TE-Tunnel werden über die CLI eingerichtet. Ein Betreiber konfiguriert den TE-LSP, der dann vom Eingangsrouter signalisiert wird.

Zusätzlich zu den vorhandenen Traffic-Engineering-Funktionen wird die MPLS RSVP-TE-Funktionalität um eine externe Pfad-Computing-Entität erweitert, die als Path Computation Element (PCE) bezeichnet wird. Der PCE berechnet den Pfad für die TE-LSPs der Eingangsrouter, die für die externe Steuerung konfiguriert wurden. Der Eingangsrouter, der eine Verbindung zu einem PCE herstellt, heißt Path Computation Client (PCC). Das PCC wird mit dem Path Computation Client Protocol (PCEP) konfiguriert, um die externe Pfadverarbeitung durch einen PCE zu ermöglichen.

Weitere Informationen finden Sie unter Komponenten des External Path Computing.

Um das externe Path Computing für die TE-LSPs eines PCC zu ermöglichen, fügen Sie die lsp-external-controller pccd Anweisung auf der Hierarchie- und [edit mpls lsp lsp-name] Hierarchieebene [edit mpls] ein.

Komponenten des External Path Computing

Ein externes Pfad-Computing-System besteht aus folgenden Komponenten:

• Pfadberechnungselement
• Pfadberechnungs-Client
• Path Computation Element Protocol

Interaktion zwischen einem PCE und einem PCC mit PCEP

Abbildung 3 veranschaulicht die Beziehung zwischen PCE, PCC und der Rolle von PCEP im Kontext von MPLS RSVP-TE.

Abbildung 3: PCC und RSVP-TE

Die Kommunikation zwischen PCE und PCC wird durch das TCP-basierte PCEP ermöglicht. Das PCC initiiert die PCEP-Sitzung und bleibt für die Dauer der PCEP-Sitzung mit einem PCE verbunden.

Sobald die PCEP-Sitzung eingerichtet ist, führt der PCC folgende Aufgaben aus:

1. LSP-Zustandssynchronisierung: Der PCC sendet Informationen über alle LSPs (lokal und extern) an alle angeschlossenen PCEs. Für externe LSPs sendet der PCC Informationen über jede Konfigurationsänderung, RRO-Änderung, Zustandsänderung usw. an den PCE.

   Für PCE-initiierte LSPs ist auf dem PCC keine LSP-Konfiguration vorhanden. Der PCE, der den LSP initiiert, sendet die LSP-Parameter an den PCC, der angezeigt hat, dass er PCE-initiierte LSPs unterstützt.

   HINWEIS:

   Unterstützung für PCE-initiierte LSPs wird in Junos OS Version 13.3 und höher bereitgestellt.

2. LSP-Delegierung: Nach der Synchronisierung der LSP-Statusinformationen delegiert das PCC die externen LSPs an einen PCE, den wichtigsten aktiven Status-PCE. Nur der Haupt-PCE kann Parameter für den externen LSP festlegen. Zu den Parametern, die der HAUPT-PCE ändert, gehören Bandbreite, Pfad (ERO) und Priorität (Setup und Halten). Die in der lokalen Konfiguration angegebenen Parameter werden durch die Parameter überschrieben, die vom Haupt-PCE festgelegt werden.

   HINWEIS:

   Wenn die PCEP-Sitzung mit dem Haupt-PCE beendet wird, wählt das PCC einen neuen Haupt-PCE, und alle delegierten LSPs an den zuvor Haupt-PCE werden an das neu verfügbare Haupt-PCE delegiert.

   Im Fall von PCE-initiierten LSPs erstellt der PCC den LSP unter Verwendung der parameter, die vom PCE erhalten wurden. Der PCC weist dem PCE-initiierten LSP eine eindeutige LSP-ID zu und delegiert den LSP automatisch an den PCE. Ein PCC kann die Delegierung der PCE-initiierten LSPs für eine aktive PCEP-Sitzung nicht widerrufen.

   Wenn eine PCEP-Sitzung beendet wird, startet der PCC zwei Timer, ohne die PCE-initiierten LSPs sofort zu löschen – delegation cleanup timeout und lsp cleanup timer – um Eine Unterbrechung der Services zu vermeiden. Während dieser Zeit kann ein aktiver zustandsbehafteter PCE die Kontrolle über die von dem ausgefallenen PCE bereitgestellten LSPs übernehmen, indem eine Create-Anforderung für den LSP gesendet wird.

   Die Kontrolle über PCE-initiierte LSPs wird nach Ablauf von delegation cleanup timeout. Wenn das delegation cleanup timeout Ablaufdatum abläuft und kein anderer PCE die Kontrolle über den LSP von dem ausgefallenen PCE übernommen hat, übernimmt das PCC die lokale Kontrolle über den nicht delegierte PCE-initiierten LSP. Wenn später der ursprüngliche oder ein neuer aktiver Stateful-PCE die Kontrolle über die lokal kontrollierten PCE-initiierten LSPs erlangen möchte, delegiert das PCC diese LSPs an den PCE und der lsp cleanup timer Timer wird angehalten.

   Ein PCE kann die Delegierung des PCE-initiierten LSP an den PCC zurückschicken, um die LSP-Übertragung zwischen PCEs zu ermöglichen. Dies löst für den lsp cleanup timer PCE-initiierten LSP aus. Der PCC wartet, bis der Timer für die LSP-Bereinigung abläuft, bevor die nicht delegierte PCE-initiierten LSPs aus dem ausgefallenen PCE entfernt werden.

   Wenn das lsp cleanup timer Ablaufen abläuft und kein anderer PCE die Kontrolle über die LSPs von dem ausgefallenen PCE übernommen hat, löscht das PCC alle LSPs, die von dem ausgefallenen PCE bereitgestellt wurden.

   HINWEIS:

   In Übereinstimmung mit Draft-ietf-pce-stateful-pce-09 erfolgt das Widerrufen von PCE-initiierten LSP-Delegationen durch einen PCC in einer Make-before-Break-Weise, bevor die LSPs zu einem alternativen PCE neu delegiert werden. Ab Junos OS Version 18.1R1 muss die lsp-cleanup-timer Version größer oder gleich dem delegation-cleanup-timeout des PCC sein, um die LSP-Delegierungen zu widerrufen. Wenn nicht, kann das Timeout-Intervall für die Neulegation für den PCC auf unendlich festgelegt werden, wobei die LSP-Delegierungen an diesen PCE intakt bleiben, bis eine bestimmte Aktion vom PCC zur Änderung der vom PCE festgelegten Parameter durchgeführt wird.

3. LSP-Signalübertragung: Wenn der PCC einen oder mehrere LSP-Parameter vom hauptaktiven Zustandsstatus-PCE empfängt, sendet der PCC den TE-LSP basierend auf dem von PCE bereitgestellten Pfad neu. Wenn der PCC den LSP nicht einrichten kann, benachrichtigt es den PCE über den Setup-Fehler und wartet, bis der Haupt-PCE neue Parameter für diesen LSP bereitstellt, und signalisiert ihn dann erneut.

   Wenn der PCE einen Pfad angibt, der unvollständig ist oder lose Hops hat, bei denen nur die Pfadendpunkte angegeben sind, führt der PCC kein auf Einschränkungen basierendes Routing durch, um den vollständigen Satz von Hops zu ermitteln. Stattdessen stellt der PCC RSVP den PCE-bereitgestellten Pfad für die Signalübertragung bereit, und der Pfad wird mithilfe von IGP Hop-by-Hop-Routing eingerichtet.

Unter Berücksichtigung der in Abbildung 2verwendeten Topologie veranschaulicht Abbildung 4 die partielle clientseitige PCE-Implementierung im MPLS RSVP-TE-fähigen Netzwerk. Die Eingangsrouter A und G sind die PCCs, die so konfiguriert sind, dass sie über eine TCP-Verbindung eine Verbindung mit dem externen Stateful-PCE herstellen.

Der PCE hat einen globalen Überblick über den Bandbreitenbedarf im Netzwerk und führt externe Pfadberechnungen durch, nachdem er die Traffic-Engineering-Datenbank durchgeblickt hat. Der aktive Stateful-PCE ändert dann ein oder mehrere LSP-Attribute und sendet ein Update an den PCC. Der PCC verwendet die Parameter, die es vom PCE empfängt, um den LSP erneut zu signalisieren.

Abbildung 4: Beispiel PCE für MPLS RSVP-TE

Auf diese Weise bietet der Stateful-PCE einen kooperativen Betrieb verteilter Funktionen, die zur Bewältigung spezifischer Herausforderungen einer kürzesten interdomainbeschränkten Pfadberechnung verwendet werden. Es eliminiert Überlastungsszenarien, in denen Datenverkehrsströme ineffizient auf verfügbaren Ressourcen abgebildet werden, was zu einer Überauslastung einiger Teilmengen von Netzwerkressourcen führt, während andere Ressourcen unterbelastet bleiben.

LSP-Verhalten mit externem Computing

• LSP-Typen
• LSP-Steuerungsmodus

Konfigurationsanweisungen, die für externes Computing unterstützt werden

Tabelle 1 listet die MPLS- und vorhandenen LSP-Konfigurationsanweisungen auf, die für einen PCE-gesteuerten LSP gelten.

Die restlichen LSP-Konfigurationsanweisungen sind genauso anwendbar wie für vorhandene LSPs. Bei der Konfiguration einer der oben genannten Konfigurationsanweisungen für einen PCE-gesteuerten LSP wird eine MPLS-Protokollmeldung generiert, die anzeigt, wann die konfigurierten Parameter in Kraft treten.

PCE-gesteuerter LSP-Schutz

Die Schutzpfade, einschließlich Fast Reroute und Bypass-LSPs, werden lokal vom PCC unter Verwendung von einschränkungensbasiertem Routing berechnet. Ein zustandsbehafteter PCE gibt nur den primären Pfad (ERO) an. Ein PCE kann auch einen nicht-Standby-sekundären Pfad auslösen, auch wenn die lokale Konfiguration keinen nicht-Standby-sekundären Pfad zum LSP-Schutz hat.

PCE-gesteuerter LSP-ERO

Für PCE-kontrollierte LSPs (PCC-delegierte LSPs und PCE-initated LSPs) muss nur ein vollständiges Explicit Route Object (ERO)-Objekt vom PCE an das PCC gesendet werden; andernfalls lehnt der PCC die PcUpdate- oder PCCreate-Nachricht für diese PCEP-Sitzung ab.

Ab Junos OS Version 17.2 werden zusätzlich zu external cspfden PCE-gesteuerten LSPs zwei neue Pfadberechnungstypen eingeführt: local cspf und no cspf.

• local cspf—Ein PCC verwendet den local cspf Berechnungstyp nur, wenn der PCE einen Juniper Vendor TLV sendet (Unternehmensnummer: 0x0a4c) des Typs 5.

• no cspf— Weder PCE noch PCC führt eine Berechnung des eingeschränkten Pfads durch. Die Endgeräte und Einschränkungen werden dem RSVP-Modul für die Einrichtung des LSP mit dem IGP-Pfad angegeben.

  Ein PCC verwendet no cspf in den folgenden Fällen den Berechnungstyp:

  • Wenn der PCE TLV sendet local cspf , und wenn die Junos OS-Konfiguration oder entsprechende Vorlage für diesen LSP im PCC-delegierten LSP enthalten ist no-cspf .

  • Wenn der PCE TLV sendet local cspf , und wenn die Junos OS-Konfigurationsvorlage für diesen LSP in den PCE-initiierten LSP enthalten ist no-cspf .

  • Wenn der PCE keine TLV mit einem leeren ERO oder einer losen ERO (mit losem Bit im ERO-Objekt) sendet local cspf .

Mit diesen neuen Berechnungstypen kann ein PCC ein ERO-Objekt entweder als loses ERO oder als leeres ERO akzeptieren. Eine externe Pfad-Computing-Entität, die nicht in der Lage ist, einen Pfad zu berechnen, kann Parameter wie Bandbreite und Farbe basierend auf den Analysen ändern. In solchen Fällen wird ein leeres ERO-Objekt oder ein loses ERO verwendet, deren Pfad vom PCC bestimmt wird.

PCE-gesteuerte Point-to-Multipoint-RSVP-TE-LSPs

Nachdem eine PCEP-Sitzung zwischen einem PCE und einem PCC eingerichtet wurde, meldet der PCC alle LSPs im System an die PCE für die LSP-Zustandssynchronisierung. Dazu gehören PCC-gesteuerte, PCE-delegierte und PCE-initiierte Point-to-Point-LSPs. Ab Junos OS Version 15.1F6 und 16.1R1 wird diese Funktion auch auf Point-to-Multipoint-LSPs erweitert. Bei einem PCE ähnelt der Point-to-Multipoint-LSP dem des RSVP-Point-to-Multipoint-LSP, bei dem der Point-to-Multipoint-LSP als Eine Sammlung von Punkt-zu-Punkt-LSPs behandelt wird, die unter einem Punkt-zu-Multipoint-Bezeichner gruppiert sind.

Standardmäßig wird die PCE-Steuerung von Point-to-Multipoint-LSPs auf einem PCC nicht unterstützt. Um diese Funktion hinzuzufügen, fügen Sie die p2mp-lsp-report-capability Anweisung auf der [edit protocols pcep pce pce-name] Hierarchie- oder [edit protocols pcep pce-group group-id] Hierarchieebene ein. Nachdem die Point-to-Multipoint-Berichtfunktion auf einem PCC konfiguriert ist, kündigt das PCC diese Funktion dem PCE an. Wenn PCE dieselbe Point-to-Multipoint-Berichtsfunktion im Gegenzug ankündigen, meldet der PCC die vollständige Point-to-Multipoint-LSP-Struktur an den PCE für die LSP-Zustandssynchronisierung.

Ein PCC mit der Point-to-Multipoint-TE-LSP-Funktion unterstützt die Berichterstellung von Point-to-Multipoint-TE-LSPs für zustandsbehaftete PCEs, Point-to-Multipoint-Update und LSP-Datenbank, die Point-to-Multipoint-LSP-Namen unterstützt. Die folgenden Funktionen und Funktionen werden für Junos OS Version 15.1F6 und 16.1 jedoch nicht unterstützt:

• Statische Point-to-Multipoint-LSPs

• PCE-delegierte und PCE-initiierte Point-to-Multipoint-LSPs

• Automatische Bandbreite

• TE++

• PCE-Anforderungs- und Antwortnachricht

• Erstellung von Point-to-Multipoint-LSPs mithilfe von Vorlagen

• Konfigurieren des Vorwärtseintrags auf den PCE-initiierten Point-to-Multipoint-LSPs

• Konfigurieren der Weiterleitungseingabe auf dem Router, der auf einen bereitgestellten LSP hinweist.

PCE-initiierte Point-to-Point-LSPs

Ab Junos OS Version 16.1 wird die PCEP-Funktionalität erweitert, um einem Stateful-PCE die Initiierung und Bereitstellung von Traffic-Engineering-LSPs über ein PCC zu ermöglichen. Zuvor wurden die LSPs auf dem PCC konfiguriert und der PCC die Kontrolle über die externen LSPs an einen PCE delegiert. Das Eigentum des LSP-Staates wurde vom PCC gehalten. Mit der Einführung der PCE-initiierten LSPs kann ein PCE einen Point-to-Point-LSP des Datenverkehrs dynamisch initiieren und bereitstellen, ohne dass ein lokal konfigurierter LSP auf dem PCC erforderlich ist. Beim Erhalt einer PCE-Nachricht erstellt das PCC den PCE-initiierten LSP und delegiert den LSP automatisch an den PCE.

Standardmäßig lehnt ein PCC die Anforderung zur Bereitstellung pcE-initiierter Punkt-zu-Punkt-LSPs von einem PCE ab. Um die Unterstützung von PCE-initierten LSPs auf dem PCC zu ermöglichen, fügen Sie die lsp-Provisioning-Anweisung auf der [edit protocols pcep pce pce-id] Hierarchie- oder [edit protocols pcep pce-group group-id] Hierarchieebene ein.

Ein PCC gibt an, dass er PCE-initiierte Point-to-Point-LSPs unterstützt und gleichzeitig die Path Computation Element Protocol (PCEP)-Sitzung mit dem PCE aufbaut. Ein PCE wählt einen PCC mit dieser Funktion aus, um einen LSP zu initiieren. Der PCE stellt dem PCC die PCE-initiierten LSP-Parameter zur Verfügung. Nach dem Erhalt der PCE-initiierten Point-to-Point-LSP-Parameter richtet das PCC den LSP ein, weist eine LSP-ID zu und delegiert den LSP automatisch an den PCE.

Wenn der PCE, der den LSP initiiert, die PCE-initiierten Punkt-zu-Punkt-LSP-Parameter nicht bereitstellt, verwendet der PCC die Standardparameter. Eine optionale LSP-Vorlage kann auch konfiguriert werden, um Werte für den PCE-initiierten Punkt-zu-Punkt-LSP anzugeben, wenn die LSP-Parameter nicht vom PCE bereitgestellt werden. Um eine LSP-Vorlage für PCE-initiierte Punkt-zu-Punkt-LSPs auf dem PCC zu konfigurieren, fügen Sie die Label-switched-path-template-Anweisung auf Hierarchieebene [edit protocols mpls lsp-external-controller lsp-external-controller] ein.

Wenn eine PCEP-Sitzung beendet wird, startet der PCC zwei Timer, ohne die PCE-initiiertenLSPs sofort zu löschen –delegation cleanup timeout und lsp cleanup timer–, um Eine Unterbrechung der Services zu vermeiden. Während dieser Zeit kann ein aktiver zustandsbehafteter PCE die Kontrolle über die von dem ausgefallenen PCE bereitgestellten LSPs erlangen.

Ein PCE kann die Delegierung des PCE-initiierten Point-to-Point-LSP an den PCC zurückschicken, um die LSP-Übertragung zwischen PCEs zu ermöglichen. Die Kontrolle über PCE-initiierte LSPs wird nach Ablauf des Timeouts der Delegationsbereinigung auf das PCC zurückgesetzt. Wenn das Timeout für die Delegierungsbereinigung abläuft und kein anderer PCE die Kontrolle über den LSP von dem ausgefallenen PCE übernommen hat, übernimmt das PCC die lokale Kontrolle über den nicht delegierte PCE-initiierten LSP. Wenn später das ursprüngliche oder ein neuer aktiver Stateful-PCE die Kontrolle über die lokal kontrollierten PCE-initiierten Point-to-Point-LSPs erlangen möchte, delegiert das PCC diese LSPs an das PCE und der LSP-Bereinigungs-Timer wird angehalten.

Das PCC wartet, bis der Timer für die LSP-Bereinigung abläuft, bevor die nicht delegierte PCE-initiierten Punkt-zu-Punkt-LSPs aus dem ausgefallenen PCE gelöscht werden. Wenn der LSP-Bereinigungs-Timer abläuft und kein anderer PCE die Kontrolle über die LSPs aus dem ausgefallenen PCE übernommen hat, löscht das PCC alle LSPs, die vom ausgefallenen PCE bereitgestellt wurden.

Ab Junos OS Version 21.1R1 unterstützen wir Nonstop Active Routing (NSR) für PCE-initiierte RSVP-basierte Point-to-Point- und Point-to-Multipoint-LSPs. Nur die primäre Routing-Engine unterhält die PCEP-Sitzung mit dem Controller. Es synchronisiert alle RSVP-LSPs, die von PCEs initiiert wurden, einschließlich Multicast-Flow-Spezifikationen für alle PCE-initiierten P2MP-LSPs, mit der Backup-Routing-Engine. Während eines Switchovers stürzt die PCEP-Sitzung ab und stellt erneut fest, wenn die Backup-Routing-Engine zur primären Routing-Engine wird. Dies reduziert den Datenverkehrsverlust für den Datenverkehr, der über PCE-initiierte RSVP-LSPs während Routing-Engine-Switchovers übertragen wird. Diese Funktion wird aktiviert, wenn NSR konfiguriert ist.

PCE-initiierter Bypass-LSP

• Grundlegendes zu PCE-initiierten Bypass-LSPs
• Vorteile von PCE-initiierter Bypass-LSP
• Verhalten von PCE-initiierten Bypass-LSPs während eines Ausfalls der PCEP-Sitzung

PCE-initiierte Point-to-Multipoint-LSPs

Mit der Einführung von Point-to-Multipoint-PCE-initiierten LSPs kann ein PCE einen Point-to-Multipoint-LSP dynamisch initiieren und bereitstellen, ohne dass eine lokale LSP-Konfiguration auf dem PCC erforderlich ist. Auf diese Weise kann der PCE den Zeitpunkt und die Reihenfolge der Punkt-zu-Multipoint-Pfadberechnungen innerhalb und über Path Computation Element Protocol (PCEP)-Sitzungen steuern und so ein dynamisches Netzwerk schaffen, das zentral gesteuert und bereitgestellt wird.

Weitere Informationen finden Sie unter Grundlegendes zum Path Computation Element Protocol für MPLS RSVP-TE mit Unterstützung für PCE-initiierte Point-to-Multipoint-LSPs.

SRv6 LSP in PCEP

Segment-Routing kann sowohl auf MPLS- als auch auf IPv6-Weiterleitungsebene angewendet werden. Das Path Computation Element (PCE) berechnet SR-Pfade für MPLS- und IPv6-Weiterleitungsebene. Segment-Routing für PCEP unterstützt SR-LSPs wie PCE-initiierte, lokal erstellte und delegierte SR-LSPs in der IPv6-Weiterleitungsebene.

Vorteile von SRv6-LSPs in PCEP

• Ermöglicht die Erstellung von PCE-initiierten SRv6-LSPs.
• Delegieren der auf dem Router erstellten SRv6-LSPs an den Controller.
• Melden Sie die lokal auf dem Router erstellten LSPs dem Controller.
• Die SRv6-Netzwerkprogrammierung bietet die Flexibilität, Segment-Routing ohne MPLS zu nutzen.

PCEP unterstützt das Erstellen, Updieren und Löschen von PCE initiierten farbigen und unfarbigen SRv6-LSPs. Wenn ein PCE initiierter SRv6-LSP zusammen mit einem statischen SRv6-LSP für dieselbe IP oder farbbasierte IP vorhanden ist, wird die statische SRv6 TE LSP-mitwirkende Route gegenüber der PCE-initiierten SRv6 TE LSP-Mitwirkenden Route bevorzugt.

Um eine PCEP-Sitzung so zu konfigurieren, dass sie SRv6-fähig ist, müssen Sie die srv6-capability Konfigurationsaussage unter [Edit protocols pce pce-id] oder auf [edit protocols pcep pce-group pce-id] Hierarchieebene aktivieren. Wenn die srv6-capability Konfigurationsaussage aktiviert ist, müssen Sie die Srv6-Konfigurationsaussage auch auf der Hierarchieebene [edit protocols source-packet-routing] aktivieren, andernfalls wird während des Commits der Fehler angezeigt.

Um SRv6 für SR-TE zu konfigurieren, müssen Sie die Konfigurationsaussage srv6 auf der Hierarchieebene [Edit protocols Source-Packet-Routing] hinzufügen.

[Weitere Informationen finden Sie unter Understanding SR-TE Policy for SRv6 Tunnel .

Um die maximale Segmentlistentiefe für SRv6-LSP zu konfigurieren, müssen Sie die maximum-srv6-segment-list-depth Konfigurationsaussage auf Hierarchieebene [edit protocols pcep] aktivieren.

Automatischer Bandbreiten- und PCE-gesteuerter LSP

Ab Junos OS Version 14.2R4 wird Unterstützung für automatische Bandbreite für PCE-gesteuerte LSPs bereitgestellt. In früheren Versionen galt die Option für automatische Bandbreite nicht für PCE-gesteuerte LSPs, obwohl LSPs unter der Kontrolle von Auto-Bandwdith und einschränkungensbasiertem Routing mit PCE-gesteuerten LSPs koexistieren konnten. Die Statistikerfassung für die automatische Bandbreite wurde nur wirksam, wenn der Steuerungsmodus eines PCE-gesteuerten LSP von extern auf lokal geändert wurde. Dies geschah in Fällen, wie z. B. keine Verbindung zu einem PCE oder wenn ein PCE die Delegation von LSPs zurück an den PCC zurückschickt.

TCP-MD5-Authentifizierung für PCEP-Sitzungen

Ein Stateful PCE-Server automatisiert die Erstellung von Traffic-Engineering-Pfaden im gesamten Netzwerk, erhöht die Netzwerkauslastung und ermöglicht ein maßgeschneidertes programmierbares Netzwerkerlebnis mit der Verwendung von PCEP-Kommunikation mit einem PCC. Ein PCC sendet LSP-Berichte an einen PCE-Server, und der PCE aktualisiert oder stellt LSPs zurück an den PCC. Die über eine PCEP-Sitzung gesendeten Daten sind für einen PCE-Server entscheidend, um externe Pfadberechnungen durchzuführen. Infolgedessen kann ein Angriff auf die PCEP-Kommunikation Netzwerkservices unterbrechen. Wenn geänderte PCEP-Nachrichten an einen PCC gesendet werden, können unangemessene LSPs eingerichtet werden. Wenn geänderte PCEP-Meldungen an einen PCE gesendet werden, wird vom PCE eine falsche Ansicht des Netzwerks gelernt.

In Anbetracht der Bedeutung der PCEP-Kommunikation zwischen einem PCE und PCC für die effektive Ausführung der PCE-Funktionen bietet Junos OS Version 16.1 die Funktion, eine PCEP-Sitzung mit TCP-MD5-Authentifizierung gemäß RFC 5440 zu sichern. Diese Funktion schützt die Kommunikation zwischen einem PCE und PCC über eine PCEP-Sitzung, die einem Angriff ausgesetzt sein und Netzwerkservices unterbrechen kann.

Um den MD5-Sicherheitsmechanismus für eine PCEP-Sitzung zu aktivieren, wird empfohlen, den MD5-Authentifizierungsschlüssel auf [edit protocols pcep pce pce-id] Hierarchieebene für eine PCEP-Sitzung zu definieren und zu binden. Sie können jedoch auch einen vordefinierten Schlüsselbund aus der [edit security authentication-key-chains key-chain] Hierarchieebene verwenden, um eine PCEP-Sitzung zu sichern. In diesem Fall sollten Sie den vordefinierten Schlüsselbund an die PCEP-Sitzung auf [edit protocols pcep pce pce-id] Hierarchieebene binden.

Die folgende Konfiguration wird auf dem PCC ausgeführt, um eine sichere PCEP-Sitzung mit einem PCE einzurichten:

• Verwendung des MD5-Authentifizierungsschlüssels:

• Verwendung vordefinierter Authentifizierungs-Keychains:

Damit sichere PCEP-Sitzungen erfolgreich eingerichtet werden können, muss die MD5-Authentifizierung mit dem vorab freigegebenen Authentifizierungsschlüssel sowohl auf dem PCE-Server als auch auf dem PCC konfiguriert werden. PCE und PCC verwenden denselben Schlüssel, um die Echtheit jedes Segments zu überprüfen, das über die TCP-Verbindung der PCEP-Sitzung gesendet wird.

Auswirkungen der clientseitigen PCE-Implementierung auf die Netzwerkleistung

Die Pflege einer zustandsbehafteten Datenbank kann nicht trivial sein. In einer einzigen zentralisierten PCE-Umgebung muss ein Zustandsbehafteter PCE lediglich alle TE-LSPs, die vom PCE berechnet wurden, die tatsächlich eingerichteten TE-LSPs (falls dies bekannt sein kann) und an die Zeit, als die TE-LSPs abgerissen wurden, erinnern. Diese Anforderungen verursachen jedoch einen erheblichen Overhead für das Kontrollprotokoll in Bezug auf Zustand, Netzwerknutzung und -verarbeitung sowie die Optimierung von Verbindungen weltweit im gesamten Netzwerk. Daher umfassen die Bedenken einer stateful PCE-Implementierung:

• Jeder zuverlässige Synchronisierungsmechanismus führt zu einem erheblichen Overhead auf der Steuerungsebene. PCEs können den Status synchronisieren, indem sie miteinander kommunizieren, aber wenn TE-LSPs mithilfe einer verteilten Berechnung zwischen mehreren PCEs eingerichtet werden, werden die Probleme bei der Synchronisierung und Vermeidung von Race-Bedingungen größer und komplexer.

• Die Out-of-Band Traffic Engineering-Datenbanksynchronisierung kann komplex sein, wenn mehrere PCEs in einem verteilten PCE-Berechnungsmodell eingerichtet sind, und kann anfällig für Rennensbedingungen, Skalierbarkeitsbedenken usw. sein.

• Pfadberechnungen unter Einbeziehung des Gesamtzustands des Netzwerks sind sehr komplex, selbst wenn der PCE detaillierte Informationen zu allen Pfaden, Prioritäten und Ebenen enthält.

Trotz der oben genannten Bedenken ist die teilweise clientseitige Implementierung des Stateful PCE in großen Traffic-Engineering-Systemen äußerst effektiv. Sie bietet eine schnelle Konvergenz und erhebliche Vorteile in Bezug auf die optimale Ressourcennutzung, indem sie die Anforderungen an globale Visibilität eines TE-LSP-Zustands und eine geordnete Steuerung der Pfadreservierungen über alle Geräte innerhalb des zu kontrollierenden Systems bietet.

Vorteile von PCE-initiierten Point-to-Multipoint-LSPs

Erfüllt die Anforderungen der Point-to-Multipoint-Traffic-Engineering-LSP-Platzierung als Reaktion auf Anwendungsanforderungen durch dynamische Erstellung und Abschaltung von Point-to-Multipoint-LSPs, wodurch ein dynamisches Netzwerk entsteht, das zentral gesteuert und bereitgestellt wird.

Signalisierung von PCE-initiierten Point-to-Multipoint-LSPs

Die Signalisierung von PCE-initiierten Point-to-Multipoint-LSPs ist wie folgt:

• When a new branch is added (Grafting)– Nur der neue Zweigstellen-Sub-LSP wird signalisiert und führt nicht zu einer erneuten Signalübertragung des gesamten Punkt-zu-Multipoint-Baumes.

  Wenn vor der Bereitstellung des neuen Sub-LSP Änderungen in der Topologie aufgetreten sind, berechnet der Path Computation Server (PCS) die gesamte Point-to-Multipoint-Struktur neu und aktualisiert den Point-to-Multipoint-LSP mithilfe einer PC-Updatemeldung.

• When a branch is deleted (Pruning)— Der gelöschte Zweigstellen-Sub-LSP wird heruntergerissen und führt nicht zu einer Erneutübertragung des gesamten Punkt-zu-Mehrpunkt-Baumes.

• When a branch sub-LSP parameter is changed— Änderungen in Sub-LSP-Parametern, wie Explicit Route Object (ERO), Bandbreite oder Priorität, können entweder aufgrund der Optimierung oder auf Benutzeranfrage erfolgen. Wenn es eine Anfrage für eine Sub-LSP gibt, wird die gesamte Point-to-Multipoint-Struktur neu signalisiert, und der Switchover zur neuen Instanz erfolgt, sobald die neuen Instanzen aller Zweigstellen aktiviert sind.

• When a branch sub-LSP path fails– Ein Fehler wird dem PCS für den ausgefallenen Zweigstellen-Sub-LSP gemeldet. Nach dem Erhalt des neuen ERO von den PCS wird die gesamte Point-to-Multipoint-Struktur zusammen mit dem ausgefallenen Zweigstellen-Sub-LSP erneut signalisiert, und der Switchover zur neuen Instanz erfolgt in einer Make-before-Break -Art (MBB).

Verhalten von PCE-initiierten Point-to-Multipoint-LSPs nach pcEP-Sitzungsfehlern

Wenn eine PCEP-Sitzung ausfällt, werden die von PCE initiierten Point-to-Multipoint-LSPs bis zum Ablauf des state timeout Timers verwaist. Nach Ablauf des state timeout Timers werden die PCE-initiierten LSPs bereinigt.

Um die Kontrolle über einen PCE-initiierten Point-to-Multipoint-LSP nach einem PCEP-Sitzungsfehler zu erhalten, sendet der primäre oder sekundäre PCE eine PCInitiate Nachricht, bevor der state timeout Timer abläuft.

Konfigurieren von PCE-initiierten Point-to-Multipoint-LSP-Funktionen

Standardmäßig wird die Erstellung und Bereitstellung von Point-to-Multipoint-LSPs durch einen PCE auf einem PCC nicht unterstützt. Um diese Funktion zu aktivieren, fügen Sie die p2mp-lsp-init-capability Anweisungen und p2mp-lsp-update-capability Anweisungen auf der [edit protocols pcep pce pce-name][edit protocols pcep pce-group group-id] Oder Hierarchieebene ein.

Die p2mp-lsp-init-capability Anweisung bietet die Möglichkeit, Point-to-Multipoint-RSVP-TE-LSPs von einem PCE bereitzustellen. Die p2mp-lsp-update-capability Anweisung bietet die Möglichkeit, Point-to-Multipoint-RSVP-TE LSP-Parameter durch einen PCE zu aktualisieren.

Unterstützte und nicht unterstützte Funktionen für PCE-initiierte Point-to-Multipoint-LSPs

Die folgenden Funktionen werden von PCE-initiierten Point-to-Multipoint-LSPs unterstützt:

• Teilweise Konformität mit dem Internet Draft-ietf-pce-stateful-pce-p2mp (läuft im Oktober 2018 ab), Path Computation Element (PCE) Protocol Extensions für Stateful PCE-Verwendung für Point-to-Multipoint Traffic Engineering Label Switched Paths.

• Ab Junos OS Version 21.1R1 unterstützen wir Nonstop Active Routing (NSR) für PCE-initiierte RSVP-basierte Point-to-Multipoint-LSPs. Nur die primäre Routing-Engine unterhält die PCEP-Sitzung mit dem Controller. Es synchronisiert alle RSVP-LSPs, die von PCEs initiiert wurden, einschließlich Multicast-Flow-Spezifikationen für alle PCE-initiierten P2MP-LSPs, mit der Backup-Routing-Engine. Während eines Switchovers stürzt die PCEP-Sitzung ab und stellt erneut fest, wenn die Backup-Routing-Engine zur primären Routing-Engine wird. Dies reduziert den Datenverkehrsverlust für den Datenverkehr, der über PCE-initiierte RSVP-LSPs während Routing-Engine-Switchovers übertragen wird. Diese Funktion wird aktiviert, wenn NSR konfiguriert ist.

Die folgenden Funktionen werden von PCE-initiierten Point-to-Multipoint-LSPs nicht unterstützt:

• Delegierung von Point-to-Multipoint-LSP.

• LSP-Kontrolldelegation.

• Interior Gateway Protocol (IGP)-Erweiterung für die PCE-Erkennung innerhalb einer IGP-Routing-Domain.

• Anfrage-/Antwort-Messaging.

• Direkte Verlagerung von Zweigstellen-Sub-LSP von einem Punkt-zu-Multipoint-Tree zum anderen.

  Das gleiche kann erreicht werden, indem ein Zweigstellen-Sub-LSP aus der ersten Punkt-zu-Multipoint-Struktur entfernt und erneut zu einer anderen hinzugefügt wird, nachdem die Meldung angibt, dass PCReport LSP vom Gerät entfernt wird.

• IPv6 wird nicht unterstützt.

• SERO-basierte Signalübertragung wird nicht unterstützt.

• Empty-ERO-Funktion wird nicht unterstützt.

• Der Linkschutz wird nicht unterstützt.

Zuordnung von PCE-initiierten Point-to-Multipoint-LSPs zu MVPN

Sie können einen einzelnen oder einen Bereich von MVPN-Multicast-Flows (S,G) einem dynamisch erstellten PCE-initiierten Point-to-Multipoint-Label-Switched Path (LSP) zuordnen. Sie können nur selektive Arten von Datenströmen angeben, für die diese Funktion funktionieren soll. Die Themen umfassen:

• Route Distinguisher (RD), der der MVPN-Routing-Instanz zugeordnet ist.

• (S,G), die die Quelle eines Multicast-Pakets und einer Ziel-Multicast-Gruppenadresse ist. Dies wird verwendet, um eingehenden Datenverkehr zu filtern, um ihn dem Tunnel zuzuordnen.

• Point-to-Multipoint-LSP, der verwendet wird, um Datenverkehr zu senden, der der oben genannten Datenstromspezifikation entspricht.

Weitere Informationen finden Sie im Internet Draft-ietf-pce-pcep-flowspec-05 (läuft ab 16. Februar 2020) PCEP Extension for Flow Specification.

In der aktuellen Implementierung dieser Funktion werden die folgenden Abschnitte des Entwurfs nicht implementiert:

• Abschnitt 3.1.2 — Werbung für PCE-Kapazität in der IGP

• Abschnitt 3.2 – PCReq- und PCRep-Meldung

• Abschnitt 7 – Die meisten Datenstromspezifikationen, außer Route DistinguDie aktuelle Implementierung dieser Funktion wird nicht unterstützt, und IPv4-Multicast-Datenstromspezifikationen werden nicht unterstützt.

So ermöglichen Sie die Zuordnung von PCE-initiierten Point-to-Multipoint-LSPs zu MVPN:

• Fügen Sie die pce_traffic_steering Anweisung auf der [edit protocols pcep pce pce-id] Hierarchieebene ein, um die Unterstützung der Datenstromspezifikationsfunktion (auch Traffic Steering genannt) durch den PCC anzugeben.

• Fügen Sie die external-controller Anweisung auf Hierarchieebene [edit routing-instances routing-instance-name provider-tunnel] ein.

  Das Vorhandensein in external-controller der Provider-Tunnel-Konfiguration für MVPN zeigt an, dass der Point-to-Multipoint-LSP und (S,G) für diese MVPN-Instanz vom externen Controller bereitgestellt werden können. Auf diese Weise kann der externe Controller dynamisch (S,G) und Point-to-Multipoint-LSP für MVPN konfigurieren.

Berücksichtigen Sie folgendes für die Zuordnung von PCE-initiierten Point-to-Multipoint-LSPs zu MVPN:

• Wenn Sie die external-controller pccd Anweisung für eine bestimmte MVPN-Instanz nicht aktivieren, wird der PCCD-Prozess nicht dynamisch konfiguriert (S,G).

• Wenn Sie die Konfiguration über die external-controller pccd CLI deaktivieren, werden die dynamisch erlernten Multicast-Datenflüsse (S,G) für diese bestimmte MVPN-Instanz gelöscht und an den externen Controller gemeldet.

• Wenn (S,G) bereits über die CLI konfiguriert ist, kann das PCC nicht dynamisch (S,G) konfiguriert werden, da die lokale Konfiguration eine höhere Priorität hat.

• Wenn ein bestimmtes (S,G) vom externen Controller dynamisch gelernt wird und Sie dann dasselbe (S,G) für dieselbe MVPN-Instanz konfigurieren, wird das dynamisch gelernte (S,G) gelöscht und dem externen Controller über den PCC gemeldet.

• Wenn der Routingprotokollprozess neu gestartet wird, konfiguriert der PCCD-Prozess alle (S,G) erneut.

• Wenn der PCCD-Prozess neu gestartet wird, meldet MVPN alle konfigurierten PCCD (S,G) an den externen Controller.

• Wenn der Benutzer eine bestimmte MVPN-Instanz aktiviert external-controller pccd , fordert MVPN den PCCD-Prozess an, (S,G) zu konfigurieren, falls vorhanden.

• Wenn größere Konfigurationsänderungen an einer bestimmten MPVN-Instanz vorgenommen werden, fordert MVPN den PCCD-Prozess an, alle (S,G) für diese bestimmte MVPN-Instanz neu zu konfigurieren.

• Alle Datenstromspezifikationen, die mit einem PCE-initiierten Point-to-Multipoint-LSP verknüpft sind, müssen den gleichen RD haben. Während der PC-Initiierung, wenn nicht alle Datenstromspezifikationen über dasselbe RD verfügen, wird die Pc-Initiierungsnachricht mit einem Fehler gelöscht.

• Sie können einen Point-to-Multipoint-LSP nur mit selektiven Datenstromspezifikationen verknüpfen, andernfalls wird die Pc-Initiierungsnachricht mit einem Fehler gelöscht.

• Wenn während der PC-Aktualisierung nicht alle Datenstromspezifikationen aufgrund einer neuen Datenstromspezifikation oder aufgrund einer aktualisierung der Datenstromspezifikationen nicht in allen Datenstromspezifikationen identisch sind, löst der PCC die Update-Meldung aus.

• Wenn während der PC-Aktualisierung nicht alle Datenstromspezifikationen die selektive Bedingung erfüllen, entweder aufgrund des Hinzufügens einer neuen Datenstromspezifikation oder aufgrund einer Aktualisierung der Datenstromspezifikationen, setzt der PCC die Update-Meldung ab.

• Das Verhalten für die Zuordnung von PCE-initiierten Point-to-Multipoint-LSP mit MVPN-Routing-Instanz und zuordnung von statischen (lokal konfigurierten) Point-to-Multipoint-LSP mit MVPN-Instanz ist auf Benutzerebene gleich.

• Eine Datenstromspezifikations-ID kann nur einem Point-to-Multipoint-LSP zugeordnet werden. Um dieselbe RD und (S,G) mehreren Point-to-Multipoint-LSPs zu zuordnen, können Sie mehrere Datenstromspezifikationen mit verschiedenen IDs und derselben RD & (S,G) hinzufügen.

• Für PCEP-mapped dynamic (S,G) ist der Schwellenwert immer der Standardwert von 0.

• Es gibt keine Begrenzung für die Anzahl der Datenstromspezifikationen, die einem einzelnen PCE-initiierten Point-to-Multipoint-LSP zugeordnet sind.

• Die aktuelle Implementierung dieser Funktion unterstützt nicht:

  • Berichterstellung von Weiterleitungsstatus, die dem Point-to-Multipoint-LSP zugeordnet sind.

  • Dynamische Konfiguration eines inklusiven Provider-Tunnels

  • Zuordnung für MVPN-Replikationstunnel

  • Programmierbarer Routing-Protokollprozess (prpd)

  • Berichterstellung von Point-to-Multipoint-LSP mit CLI-Konfiguration, der auf MVPN-Multicast-Datenströme (S,G) abgebildet ist.

Einschränkungen der verteilten CSPF-Berechnung

Segment-Routing-LSP-Pfade werden berechnet, wenn alle konfigurierten Einschränkungen erfüllt sind.

Die verteilte CSPF-Berechnungsfunktion unterstützt die folgenden Teilmenge von Einschränkungen, die im Internet-Entwurf angegeben wurden, draft-ietf-spring-segment-routing-policy-03.txt, Segment-Routing-Richtlinie für das Traffic Engineering:

• Integration und Ausschluss administrativer Gruppen.

• Integration von losen oder strengen Hop-IP-Adressen.

  HINWEIS:

  Sie können nur Router-IDs in den losen oder strengen Hop-Einschränkungen angeben. Label und andere IP-Adressen können in Junos OS Version 19.2R1-S1 nicht als lose oder strenge Hop-Einschränkungen angegeben werden.

• Maximale Anzahl von Segment-IDs (SIDs) in der Segmentliste.

• Maximale Anzahl von Segmentlisten pro Segment-Routingpfad des Kandidaten.

Die verteilte CSPF-Berechnungsfunktion für Segment-Routing-LSPs unterstützt die folgenden Arten von Einschränkungen und Bereitstellungsszenarien nicht:

• IPV6-Adressen.

• Inter Domain Segment Routing Traffic Engineering (SR-TE)-LSPs.

• Schnittstellen ohne Nummer.

• Mehrere Routing-Protokolle wie OSPF, ISIS und BGP-LS gleichzeitig aktiviert.

• Berechnung mit Präfixen oder Anycast-Adressen als Ziel.

• Ein- und Ausschluss von Schnittstellen-IP-Adressen als Einschränkungen.

Verteilter CSPF-Berechnungsalgorithmus

Die verteilte CSPF-Berechnungsfunktion für Segment-Routing-LSPs verwendet den Label-Stack-Kompressionsalgorithmus mit CSPF.

• Label Stack-Kompression aktiviert
• Label Stack-Kompression deaktiviert

Verteilte CSPF-Berechnungsdatenbank

Die für die SR-TE-Berechnung verwendete Datenbank enthält alle Verbindungen, Knoten, Präfixe und deren Merkmale, unabhängig davon, ob Traffic-Engineering in diesen Werbeknoten aktiviert ist. Mit anderen Worten, es ist die Vereinigung der Traffic-Engineering-Datenbank (TED) und der IGP-Link-Zustandsdatenbank aller Domänen, von denen der Computerknoten gelernt hat. Daher müssen Sie die Anweisung auf [edit protocols isis traffic-engineering] Hierarchieebene einschließenigp-topology, damit CSPF funktioniert.

Konfigurieren verteilter CSPF-Berechnungsbeschränkungen

Sie können ein Rechenprofil verwenden, um die Berechnungsbeschränkungen logisch zu gruppieren. Diese Rechenprofile werden durch die Segment-Routing-Pfade für die Berechnung der primären und sekundären Segment-Routing-LSPs referenziert.

Um ein Rechenprofil zu konfigurieren, fügen Sie die Rechenprofil-Anweisung auf Hierarchieebene [edit protocols source-packet-routing] ein.

Die Konfiguration für die unterstützten Recheneinschränkungen umfasst:

• Administrative groups

  Sie können Admin-Gruppen unter der [edit protocols mpls] Hierarchieebene konfigurieren. Junos OS wendet die Konfiguration der administrativen Gruppe auf die SR-TE-Schnittstellen (Segment Routing Traffic-Engineering) an.

  Um die Berechnungsbeschränkungen zu konfigurieren, können Sie drei Kategorien für eine Reihe von administrativen Gruppen angeben. Die Konfiguration der Berechnungsbeschränkungen kann allen Routing-Pfaden für Kandidatensegmente gemeinsam sein oder unter einzelnen Kandidatenpfaden.

  • include-any– Gibt an, dass alle Verbindungen mit mindestens einer der konfigurierten administrativen Gruppen in der Liste für den pfad akzeptabel sind, der durchquert werden soll.

  • include-all– Gibt an, dass jede Verbindung mit allen konfigurierten administrativen Gruppen in der Liste für den zu durchlaufenden Pfad akzeptabel ist.

  • exclude– Gibt an, dass verbindungen, die nicht über eine der konfigurierten administrativen Gruppen in der Liste verfügen, für den Pfad, der durchquert werden soll, akzeptabel sind.

• Explicit path

  Sie können eine Reihe von Router-IDs im Datenverarbeitungsprofil als Einschränkung für die Berechnung der SR-TE-Kandidatenpfade angeben. Jeder Hop muss eine IPv4-Adresse sein und kann vom Typ streng oder lose sein. Wenn der Hoptyp nicht konfiguriert ist, wird strict verwendet. Sie müssen die compute Option unter der Segmentliste-Anweisung einschließen, wenn Sie die Explizite Pfadeinschränkung angeben.

• Maximum number of segment lists (ECMP paths)

  Sie können einen Kandidatenpfad mit einer Reihe von dynamischen Segment-Listen zuordnen. Bei den Pfaden handelt es sich um ECMP-Pfade, bei denen jede Segmentliste in ein Next-Hop-Gateway mit aktiver Gewichtung übersetzt wird. Diese Pfade sind das Ergebnis von Pfadberechnungen mit oder ohne Kompression.

  Sie können dieses Attribut mit der maximum-computed-segment-lists maximum-computed-segment-lists Option unter der Konfigurationsaussage für rechenprofile konfigurieren. Diese Konfiguration bestimmt die maximale Anzahl solcher Segmentlisten, die für einen bestimmten primären und sekundären LSP berechnet werden.

• Maximum segment list depth

  Der Parameter für die maximale Segmentlistentiefe stellt sicher, dass unter den ECMP-Pfaden, die alle anderen Einschränkungen erfüllen, wie z. B. administrative Gruppen, nur Pfade verwendet werden, deren Segmentlisten kleiner oder gleich der maximalen Segmentlistentiefe sind. Wenn Sie diesen Parameter als Einschränkung unter dem Rechenprofil konfigurieren, überschreibt er die maximum-segment-list-depth Konfiguration auf [edit protocols source-packet-routing] Der Hierarchieebene, sofern vorhanden.

  Sie können dieses Attribut mit der maximum-segment-list-depth maximum-segment-list-depth Option unter der Konfigurationsaussage für rechenprofile konfigurieren.

• Protected or unprotected adjacency SIDs

  Sie können geschützte oder ungeschützte Adjacency-SID als Einschränkung unter dem Rechenprofil konfigurieren, um Verbindungen mit dem angegebenen SID-Typ zu vermeiden.

• Metric type

  Sie können den Typ der Metrik für den Link angeben, der für die Berechnung verwendet werden soll. Standardmäßig verwenden SR-TE-LSPs Traffic-Engineering-Metriken der Links für die Berechnung. Die Traffic-Engineering-Metrik für Links wird durch Traffic-Engineering-Erweiterungen von IGP-Protokollen angekündigt. Sie können jedoch auch die IGP-Metrik für die Berechnung verwenden, indem Sie die Metriktypkonfiguration im Rechenprofil verwenden.

  Sie können dieses Attribut mit der metric-type (igp | te) Option unter der Konfigurationsaussage für rechenprofile konfigurieren.

Verteilte CSPF-Berechnung

Die SR-TE-Kandidatenpfade werden lokal berechnet, sodass sie die konfigurierten Einschränkungen erfüllen. Wenn die LabelStack-Kompression deaktiviert ist, ergibt sich bei der CSPF-Berechnung für mehrere Pfade eine Reihe von SID-Stacks mit Adjacency. Wenn die Label-Stack-Kompression aktiviert ist, ergibt sich ein Satz komprimierter Label-Stacks (bestehend aus angrenzenden SIDs und Node-SIDs).

Wenn sekundäre Pfade berechnet werden, werden die Von den primären Pfaden genommenen Verbindungen, Knoten und DIE BACKBONEGs zur Berechnung nicht vermieden. Weitere Informationen zu primären und sekundären Pfaden finden Sie unter Konfigurieren von primären und sekundären LSPs.

Für alle LSPs mit erfolglosem Berechnungsergebnis wird die Berechnung als Änderungen der Traffic-Engineering-Datenbank (TED) erneut durchgeführt.

Interaktion zwischen verteilter CSPF-Berechnung und SR-TE-Funktionen

• Gewichtung im Zusammenhang mit Pfaden einer SR-TE-Richtlinie
• BFD Liveliness Detection
• Inherit-Label-Nexthops
• Automatische Übersetzungsfunktion

Verteilte CSPF-Berechnungs-Beispielkonfigurationen

• Beispiel 1
• Beispiel 2
• Beispiel 3

Vorteile mehrerer Pfade für PCEP SR-TE LSPs

• LSPs können mehrere EROs zu einem Ziel haben

• Bietet Load Balancing-Funktionen durch Konfiguration der Gewichtung für einzelne EROs

• Passt sich mit dem Entwurf für die SR-TE-Architektur zur Definition von Kandidatenpfaden ab

Die folgenden PCEP-Funktionen für mehrere Pfade werden unterstützt:

• Wenn PCEP für mehrere Pfade aktiviert ist (Standard), können Sie mehrere primäre (oder einen sekundären) Pfad in einem PCC-konfigurierten und kontrollierten Kandidatenpfad konfigurieren.

• Wenn PCEP für mehrere Pfade deaktiviert ist, können Sie nur einen primären Pfad in einem Kandidatenpfad konfigurieren. Die Konfiguration des sekundären Pfads ist nicht zulässig.

Wenn Sie PCEP-Multipaths aktivieren, compute-profile können sie jetzt mit einer maximalen Anzahl von Segmentlisten (maximum-computed-segment-lists) von mehr als 1 konfiguriert werden.

Wenn die PCEP-Multipath-Funktion aktiviert ist, ist die sekundäre Pfadkonfiguration für einen nicht delegierten PCC-Kandidatenpfad zulässig. Das für den sekundären Pfad spezifische EXPLICIT-ROUTE-Objekt (EROs) wird an den PCE gesendet, wobei das Backup-Flag für den ERO festgelegt ist. Die primären Pfade enthalten den MULTIPATH-BACKUP-TLV in der PCRpt-Nachricht nicht. Sekundärer Pfad umfasst MULTIPATH-BACKUP-TLV mit Backup-Flag gesetzt.

Die folgenden PCEP-Multipath-Funktionen werden unterstützt:

• Multipath Weight TLV (MULTIPATH-WEIGHT-TLV) im Path-Attribut (PATH-ATTRIB) Objekt

• MULTIPATH-BACKUP TLV in Path Attribut (PATH-ATTRIB) Nur für PCC-gesteuerte SR-TE-LSPs

• MULTIPATH-CAP-TLV im PCEP-LSP-Objekt

• Beschränkt mehrere primäre und sekundäre Pfade im Sr-Kandidatenpfad, wenn DER PCEP-Multipath deaktiviert ist

• Mehrere primäre und sekundäre Pfade im SR-Kandidatenpfad, wenn PCEP-Multipath für PCC-gesteuerte LSPs aktiviert ist

• Maximale Anzahl an berechneten Segmentlisten (max-computed-segment-lists) mehr als 1 im SR-TE-Rechenprofil für delegierte und PCE-initiierte LSPs

• Mehrere EROs für PCE-initiierte Kandidatenpfade in SR-TE und PCCD

• SRv6-LSPs

• SR MPLS (IPv4)

• Dynamische SR MPLS (IPv4)-Tunnel

• Multi-Controller-Unterstützung

• Mehrere ERO-Pfade für PCE-initiierte, PCC-konfigurierte und kontrollierte sowie delegierte farbige und unfarbige Kandidatenpfade

• Abwärtskompatibel mit früheren Versionen von Paragon Pathfinder. Um die Abwärtskompatibilität zu gewährleisten, müssen Sie die Konfigurationsaussage auf Hierarchieebene [edit protocols pcep] konfigurierendisable-multipath-capability.

• Fehlercode-Unterstützung für Fehler bei der Validierung von PCE-initiierten Kandidatenpfaden

  • Die Gesamtanzahl der Pfade für Unterkandidaten pro Kandidatenpfad ist auf 127 begrenzt. Wenn die Anzahl der ERO-Pfade 127 kreuzt, wird für PCE initiierte LSPs von SR-TE ERROR an PCCD ausgegeben (und PCCD sendet PCEP-Fehlermeldung an PCE) und die entsprechenden ERO-Pfade werden abgelehnt.

Folgende PCEP-Fehlermeldungen werden unterstützt:

Einschränkungen

Es gelten die folgenden PCEP-Einschränkungen:

• Die folgenden im Draft-ietf-pce-multipath-06 erwähnten TLVs werden nicht unterstützt:

  • Multipath-Backup-TLV

  • Multipath-Gegenrichtungspfad TLV

  • Zusammengesetzter Kandidatenpfad

• Wenn die Multipath-Funktion in PCEP deaktiviert ist, ist die Konfiguration mehrerer Pfade für Subkandidaten nicht zulässig. Auf Junos-Geräten ohne Multipath-Funktion (Junos OS-Versionen früher als 22.4R1) ist jedoch die Konfiguration mehrerer Pfade für Sub-Kandidaten zulässig. Wenn PCEP-Multisegmente aktiviert ist (standardmäßig), sind für PCC-gesteuerte LSPs zum Zweck der Berichterstattung mehrere primäre Pfade zulässig. Für delegierte Kandidatenpfade wird jedoch nur ein primärer Pfad unterstützt, wenn PCEP-Multisegmente aktiviert ist.

• Admin-Gruppen und andere Einschränkungen werden nicht an PCE für PCC-konfigurierte und kontrollierte SR-MPLS- und SRv6-Kandidatenpfade (mit einzelnen oder mehreren primären Konfigurationen) benachrichtigt. Es gibt keine Auswirkungen auf delegierte und PCE-initiierte Kandidatenpfade.

• Wenn die PCEP-Multipath-Funktion aktiviert ist, ist die sekundäre Pfadkonfiguration für nicht delegierte Kandidatenpfade zulässig. Wenn die PCEP-Multipath-Funktion deaktiviert ist, ist die sekundäre Pfadkonfiguration nicht zulässig.

• Kandidatenpfade können keine Mischung aus PCE-initiierten und delegierten LSPs haben.

• Mehrere Sub-Candidate-Pfade für einen PCE-initiierten farbigen Kandidatenpfad werden nicht unterstützt.

• Delegieren von Funktionen mit mehreren Unterkandidatenpfaden in einem Kandidatenpfad wird nicht unterstützt.

Konfiguration

Fügen Sie die propagate-max-segmentlist Konfigurationsaussage aufedit protocols pcep [] Hierarchieebene ein, um PCCD zu ermöglichen, mehrpfadfähige TLV im LSP-Objekt zu senden, um die maximal berechnete Segmentliste für einen bestimmten Kandidatenpfad zu benachrichtigen. Standardmäßig wird die TLV nicht im LSP-Objekt gesendet.

Um die PCEP-Sitzung mit mehreren Funktionen für alle PCEs zu deaktivieren, fügen Sie die disable-multipath-capability Konfigurationsaussage auf der Hierarchieebene [edit protocols pcep] ein.

Sie können die folgenden Protokoll-Traceoptionen für die Diagnose aktivieren:

• user@host# set protocols pcep traceoptions ...

• user@host# set protocols pcep pce pce1 traceoptions ...

• user@host# set protocols source-packet-routing traceoptions

Sie können die folgenden Show-Befehle verwenden, um den Status von LSPs in PCC anzuzeigen:

• user@host> show path-computation-client lsp— Zeigt den Status der Label-Switched Paths (LSPs) an, die dem Path Computation Client (PCC) bekannt sind.

• user@host> show path-computation-client lsp extensive— Zeigen Sie das umfangreiche Ausgabeniveau zu jedem bekannten LSP an – Punkt-zu-Punkt- und Point-to-Multipoint-LSPs.

• user@host> show path-computation active-pce– Zeigt den Status von Multipath in den Sitzungen an.

• user@host> show spring-traffic-engineering lsp detail—Anzeige der Eingangsdetails des SPRING Traffic Engineering.

Vorteile der Aktivierung von TLS für PCEP-Sitzungen

• Schützt PCEP-Sitzungen vor Angriffen wie Spoofing (PCC- oder PCE-Identitätswechsel), Snooping (Nachrichtenabfangen), Fälschung und Denial of Service.

• Nutzt die Vorteile der TLS-Sicherheit.

Aktivieren von TLS in Path Computation Client (PCC)

Um TLS in PCC zu aktivieren und eine PCEPS-Sitzung einzurichten, legen Sie die tls-strict CLI-Anweisung auf Hierarchieebene [edit protocols pcep] fest.

Nach der Aktivierung der tls-strengen Konfigurationsaussage passieren die folgenden Ereignisse:

1. PCEP-Sitzungsklappen. Jede vorhandene TCP-Verbindung wird beendet und eine erneute Verbindung erfolgt mithilfe von TLS.

2. PCC stellt eine TCP-Verbindung mit dem PCE her.

3. TLS-Prozeduren werden durch die StartTLS Nachricht von PCE an PCC und von PCC zu PCE initiiert. Die StartTLS Nachricht wird von PCC gesendet und der StartTLSWait Timer wird gestartet. Sie können den StartTLSWait Timer konfigurieren, indem Sie die start-tls-wait-timer seconds CLI-Anweisung auf der Hierarchieebene [edit protocols pcep pce pce-id] konfigurieren.

   HINWEIS:

   Der empfohlene Wert für den StartTLSWait Timer beträgt 60 Sekunden und darf nicht niedriger als der OpenWait Timer sein. Der Standard-Timer-Wert OpenWait ist auf 60 Sekunden festgelegt.

   • Wenn die Open-Nachricht von PCC empfangen StartTLS wird, PCErr wird eine Nachricht mit Error-Type auf 1 (PcEP-Sitzungseinrichtung fehlgeschlagen) und Fehlerwert auf 1 (Empfang einer ungültigen Open-Nachricht oder einer nicht-offenen Nachricht) festgelegt, und die TCP-Sitzung wird geschlossen.

   • Wenn StartTLS eine Nachricht nicht von PCE empfangen wird, sendet PCC nach Ablauf des StartTLSWait Timers eine PCErr Nachricht mit dem Wert Error-Type auf 25 (PCEP-FehlerStartTLS) und den Fehlerwert auf 5 (keine Nachricht (nochStartTLS PCErr/Open) vor Ablauf StartTLSWait des Timers), und die TCP-Sitzung wird geschlossen.

4. Aushandlung und Aufbau einer TLS-Verbindung erfolgt.

5. Der Austausch von PCEP-Nachrichten wird gemäß RFC5440 gestartet.

Aktualisieren von Zertifikaten mithilfe der Public Key Infrastructure (PKI)

Die PKI benachrichtigt PCC nicht über den Ablauf des Zertifikats. Sie müssen das Zertifikat manuell mit dem folgenden CLI-Befehl aktualisieren. Bei dieser Methode müssen Sie das Ablaufdatum des Zertifikats im Auge behalten.

Einrichten einer TLS-Verbindung

In den folgenden Schritten wird beschrieben, wie eine TLS-Verbindung (unter Verwendung von TLS v1.2) hergestellt wird:

1. Generieren Sie Zertifikate für die Knoten (Junos OS-Geräte/pce-server). Sie können die Zertifikate mit einer der folgenden Methoden generieren:

   • Method 1— Generieren Sie Schlüsselpaar und CSR auf dem Gerät und senden Sie dieses CSR an die CA, um das Zertifikat zu erhalten. Sobald das Zertifikat ausgestellt ist, wird es in das Kästchen kopiert und installiert.

   • Method 2— Generieren Sie das Schlüsselpaar und das Zertifikat sofort. Sowohl das Zertifikat als auch der private Schlüssel werden auf dem Gerät kopiert und zusammen installiert.

2. Laden Sie die Zertifizierungsstelle (Certification Authority, CA) auf den PCC, damit das PCE-Serverzertifikat anhand der geladenen Zertifizierungsstelle validiert werden kann.

   HINWEIS:

   CAs können in einer flachen Hierarchie als unabhängige Zertifizierungsstelle geladen werden. Wenn eine Zertifizierungsstelle eine Unter-CA einer anderen CA ist, wird die Kette intern von PKI aufgebaut.

   HINWEIS:

   Das Serverzertifikat sollte von einer Zertifizierungsstelle signiert werden. Selbstsignierte Zertifikate sind nicht erlaubt.

3. Aktivieren Sie TLS auf PCC.

4. PCEP-Sitzung wird über TLS mit TLS-Handshake-Mechanismus eingerichtet.

5. PCE-Server überwacht Port 4189 auf eingehende PCC-Verbindungsanfragen über TLS.

6. PCC initiiert die Verbindungsanfrage zum Ziel-Port 4189.

7. Nach Abschluss eines Drei-Wege-Handshakes beginnt der TLS-Handshake mit der Verwendung der Zertifikate und die One-Way-Authentifizierung ist durchgeführt (PCC authentifiziert das Serverzertifikat). Sowohl der Server als auch der Client warten, StartTLSWait bis die StartTLS Nachricht empfangen wird. Sie können den StartTLSWait Timer konfigurieren, indem Sie die start-tls-wait-timer seconds CLI-Anweisung auf der Hierarchieebene [edit protocols pcep pce pce-id] konfigurieren.

   HINWEIS:

   Der empfohlene Wert für den StartTLSWait Timer beträgt 60 Sekunden und darf nicht niedriger als der OpenWait Timer sein. Der Standard-Timer-Wert OpenWait ist auf 60 Sekunden festgelegt.

8. Nach der erfolgreichen TLS-Handshake-Sitzung initiiert PCC und PCE die Einrichtung der PCEP-Sitzung über TLS, während der die Sitzungsparameter ausgehandelt werden.

   • Wenn die Zertifikatsvalidierung fehlschlägt, beendet PCC die TCP-Verbindung.

9. PCEP-Nachricht wird über TLS-Verbindung als Anwendungsdaten gesendet.

10. Die Verschlüsselung und Entschlüsselung erfolgt sowohl auf PCC als auch auf PCE nach einem erfolgreichen TLS-Handshake.

11. Wenn die PCEP-Sitzung geschlossen wird, wird die TLS-Sitzung entfernt.

Grundlegendes zum TLS-Handshake-Mechanismus

Der Handshake ist eine Serie von Nachrichten, die zwischen einem Server und einem Client ausgetauscht werden. Die genauen Schritte im Handshake variieren je nach Schlüsselaustauschalgorithmus, Cipher Suite usw. Im Folgenden werden die grundlegenden Schritte zum TLS-Handshake-Mechanismus beschrieben:

1. Client Hello— Der Client initiiert den Handshake, indem er diese Nachricht sendet. Diese Nachricht enthält TLS-Version, eine Liste der unterstützten Kryptografiealgorithmen oder Cipher Suite und andere Client-Details.

2. Server Hello— Der Server antwortet auf "Client Hello", indem er eine Sever-Hallo-Nachricht sendet. Diese Nachricht enthält Serverzertifikat, ausgewählten Kryptografiealgorithmus, Sitzungs-ID und den öffentlichen Schlüssel des Servers.

3. Authentication— Der Client im Hintergrund überprüft das Serverzertifikat mit einer konfigurierten Zertifizierungsstelle, die das Zertifikat ausgestellt hatte. Bei erfolgreicher Überprüfung bestätigt der Client, dass der Server echt ist und interagiert weiter.

4. Optional Client Certificate— Wenn der Server in der Server Hello-Nachricht ein Zertifikat vom Client angefordert hat, sendet der Client das Client-Zertifikat (nur im Fall von gegenseitigem TLS).

5. Client Key Exchange— Der Client sendet einen geheimen Schlüssel, der mit dem öffentlichen Schlüssel des Servers verschlüsselt ist (in der Nachricht "Server Hallo" erfasst).

6. Decrypt secret key— Der Server entschlüsselt den geheimen Schlüssel mithilfe des privaten Schlüssels.

7. Client Finished— Der Client sendet eine Finish-Nachricht, die mit dem gemeinsam genutzten geheimen Schlüssel verschlüsselt ist, und signalisiert den Handshake "Complete".

8. Server Finished— Der Server antwortet mit einer Endnachricht, die mit dem gemeinsam genutzten geheimen Schlüssel verschlüsselt ist, und signalisiert den Handshake "Complete".

9. Exchange Messages— Die Nachrichten nach dem Handshake-Abschluss werden symmetrisch verschlüsselt.

Diagnose und Validierung von TLS für PCEP-Sitzungen

Verwenden Sie für Diagnosen die folgenden CLI-Anweisungen für Traceoptions:

Aktivieren Sie PKI-Protokolle mit der folgenden Konfiguration und erfassen Sie dieselbe Datei von /var/log/<filename>

Überprüfen Sie das geladene CA-Zertifikat mit dem folgenden Befehl:

Beispielausgabe

Im Folgenden sehen Sie eine Beispielausgabe des show path-computation-client statistics Befehls:

Diese Beispielausgabe bietet die folgenden Informationen:

• TLS ist bei PCC aktiviert.

• PCE ist TLS-fähig.

• TLS-Sitzung eingerichtet. Dies zeigt auch an, dass das PCE-Serverzertifikat gültig ist.

• Der PCEPS-Sitzungsstatus ist einsatzbereit.

Vorteile von Berichtspfadoptimierung und berechneten Metriken in PCEP

• Die Berichterstattung über in PCC konfigurierte Pfadoptimierungsmetriken hilft PCE, sich der Einschränkungen bewusst zu sein, die für die Pfadberechnung verwendet werden.

• Berichterstellung von berechneten Metriken an den PCE. Auf diese Weise kann PCE analysieren, ob der LSP eine weitere Optimierung erfordert.

Verständnis der Optimierungsmetriken

Im folgenden Abschnitt werden die beabsichtigten und tatsächlichen Optimierungsmetriken für RSVP- und SR-TE (SR MPLS)-LSPs in PCEP beschrieben.

• Lokal erstellte RSVP-LSP
• Delegierter RSVP-LSP
• PCE-initiierter RSVP-LSP
• Delegierter SR-TE-LSP
• PCE-initiierter SR-TE LSP
• Senden der Optimierungskennzahl in PCRpt-Nachricht
• Senden einer rechnergestützten Metrik in PCRpt-Nachricht
• Abwärtskompatibilität für Routing-Metrik

Konfigurieren von Optimierungsmetriken für LSPs

Sie können Optimierungsmetriken (IGP, TE und Pfadverzögerung) für RSVP-LSPs und SR-TE LSP konfigurieren.

Um die IGP-, TE- und Pfadverzögerungsoptimierungsmetriken für RSVP-LSPs zu konfigurieren, fügen Sie die metric-type <igp|te|delay|delay minimum> CLI-Anweisung auf der Hierarchieebene [edit protocols mpls label-switched-path <lsp-name>] ein.

Um die IGP-, TE- und Pfadverzögerungsoptimierungsmetriken für SR-TE-LSPs zu konfigurieren, fügen Sie die metric-type <igp|te|delay|delay minimum> CLI-Anweisung auf der Hierarchieebene [edit protocols source-packet-routing compute-profile <compute-profile-name>] ein.

Beispielausgabe

Sie können die show path-computation-client lsp Cli-Befehle verwenden show path-computation-client lsp extensive , um den Status von Label-Switched Paths (LSPs) anzuzeigen, die dem Path Computation Client (PCC) bekannt sind.

Im Folgenden wird eine Beispielausgabe von show path-computation-client lsp extensive:

Die Ausgabe zeigt, dass der LSP mit der Metrik Typ IGP optimiert ist. Der berechnete Wert der IGP-Metrik ist 50. Die in der Routing-Tabelle installierte Route-Metrik ist 50.