PCEP-Konfiguration

Grundlegendes zu MPLS RSVP-TE

Traffic Engineering (TE) befasst sich mit der Leistungsoptimierung von Betriebsnetzen, wobei der Datenverkehr hauptsächlich auf eine vorhandene physische Topologie abgebildet wird. Traffic Engineering bietet die Möglichkeit, den Datenverkehrsfluss vom kürzesten vom Interior Gateway Protocol (IGP) gewählten Pfad auf einen potenziell weniger überlasteten physischen Pfad in einem Netzwerk zu verlagern.

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

In einem MPLS-Netzwerk werden Informationen auf der Datenebene mithilfe von Label Switching weitergeleitet. Auf ein Paket, das vom Kunden-Edge-Router (CE) auf einem Provider-Edge-Router (PE) eingeht, werden Bezeichnungen angewendet, die dann an den ausgehenden PE-Router weitergeleitet werden. Die Labels 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 Labels zu kommunizieren, die zum Weiterleiten des Datenverkehrs zwischen und durch die LSRs verwendet werden. RSVP-TE ist ein solches Label-Verteilungsprotokoll, das es einem LSR-Peer ermöglicht, mehr über die Label-Zuordnungen 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 Signale innerhalb von Label-Switched-Pfaden (LSPs) zu unterstützen. RSVP reserviert Ressourcen, z. B. für IP-Unicast- und Multicast-Datenströme, und fordert QoS-Parameter (Quality of Service) für Anwendungen an. Das Protokoll wurde in MPLS Traffic Engineering erweitert, damit RSVP LSPs einrichten kann, die für Traffic Engineering in MPLS-Netzwerken verwendet werden können.

Wenn MPLS und RSVP kombiniert werden, werden Bezeichnungen mit RSVP-Flows verknüpft. Sobald ein LSP eingerichtet ist, wird der Datenverkehr durch den Pfad durch die Bezeichnung definiert, die auf den Eingangsknoten des LSP angewendet wird. Die Zuordnung des Labels zum Datenverkehr erfolgt anhand verschiedener Kriterien. Die Gruppe von Paketen, denen von einem bestimmten Knoten derselbe Label-Wert zugewiesen wird, gehört derselben Weiterleitungsäquivalenzklasse (FEC) an und definiert effektiv den RSVP-Fluss. Wenn Datenverkehr auf diese Weise einem LSP zugeordnet 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-Kernprotokoll auf, indem es neue Objekte definiert und vorhandene Objekte modifiziert, die in den PATH- und RESV-Objekten für die LSP-Einrichtung verwendet werden. Die neuen Objekte – LABEL-REQUEST-Objekt (LRO), RECORD-ROUTE-Objekt (RRO), LABEL-Objekt und EXPLICIT-ROUTE-Objekt (ERO) – sind in Bezug auf das RSVP-Protokoll optional, mit Ausnahme der LRO- und LABEL-Objekte, die beide für die Einrichtung von LSP-Tunneln obligatorisch sind.

Im Allgemeinen richtet RSVP-TE einen Label-Switched-Pfad ein, der die Frame-Bereitstellung vom Eingangs- zum Ausgangsrouter sicherstellt. 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 teilweise expliziten Route einzurichten (RFC 3209).

• Constraint-basierte LSP-Einrichtung über Verbindungen, die Anforderungen erfüllen, wie z. B. Bandbreite und Verbindungseigenschaften.

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

• Link-Management, das Link-Ressourcen verwaltet, um ressourcenorientiertes Routing von Traffic-Engineering-LSPs durchzuführen und MPLS-Labels zu programmieren.

• MPLS Fast Reroute (FRR), das die LSPs verwaltet, die geschützt werden müssen, und diesen LSPs Backup-Tunnelinformationen zuweist.

Aktuelle MPLS RSVP-TE-Einschränkungen

Obwohl die RSVP-Erweiterungen für das Traffic Engineering eine bessere Netzwerkauslastung ermöglichen und die Anforderungen der Datenverkehrsklassen erfüllen, weist die heutige MPLS RSVP-TE-Protokollsuite mehrere Probleme auf, die mit ihrer verteilten Natur zusammenhängen. Dies führt zu einer Reihe von Problemen beim Konflikt um die Zweiteilungskapazität, insbesondere innerhalb einer LSP-Prioritätsklasse, in der eine Teilmenge von LSPs gemeinsame Einstellungen und Prioritätswerte aufweist. Zu den Einschränkungen von RSVP-TE gehören:

• Mangelnde Transparenz der individuellen Bandbreitenanforderungen pro LSP und pro Gerät: Die Eingangsrouter in einem MPLS RSVP-TE-Netzwerk richten LSPs ein, ohne einen globalen Überblick über den Bandbreitenbedarf im Netzwerk zu haben. Informationen zur Auslastung von Netzwerkressourcen sind nur als reservierte Gesamtkapazität nach Datenverkehrsklasse pro Schnittstelle 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 dem Nachfragemuster auf, insbesondere innerhalb eines gemeinsamen Setups und einer gemeinsamen Haltepriorität.

• Asynchrone und unabhängige RSVP-Signalisierung: In RSVP-TE werden die Einschränkungen für die Pfadeinrichtung von einem 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 einer Traffic-Engineering-Verbindung verfügbare Bandbreite die für die Verbindung konfigurierte Bandbreite, ohne die Summe aller Reservierungen, die für die Verbindung vorgenommen wurden. Daher führen die nicht signalisierten Anforderungen an einen LSP-Tunnel zu einer Verschlechterung des Dienstes des LSP, der überschüssige Bandbreite benötigt, sowie der anderen LSPs, die die Bandbreitenanforderungen der Traffic-Engineering-Verbindung erfüllen.

• LSPs, die auf der Grundlage dynamischer oder expliziter Pfadoptionen in der Reihenfolge ihrer Präferenz eingerichtet werden: Die Eingangsrouter in einem MPLS RSVP-TE-Netzwerk richten LSPs für Anforderungen basierend auf der Reihenfolge des Eingangs ein. Da die Eingangsrouter keine globale Ansicht des Bandbreitenbedarfs im Netzwerk haben, kann die Verwendung der Präferenzreihenfolge zum Einrichten von LSPs dazu führen, dass Datenverkehr verworfen wird oder LSPs überhaupt nicht eingerichtet werden, wenn ein übermäßiger Bandbreitenbedarf besteht.

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

Abbildung 2: Beispiel MPLS Traffic Engineering

Die Eingangsrouter richten LSPs basierend auf der Reihenfolge ein, in der die Anforderungen eingehen. Wenn Router G zwei Anforderungen von je Kapazität 5 für G-F empfängt, signalisiert G zwei LSPs – LSP1 und LSP2 – über G-B-D-F. Auf die gleiche Weise signalisiert Router A, wenn er die dritte Anforderung von Kapazität 10 für A-E erhält, einen LSP, LSP3, über A-B-C-E. Wenn die Anforderung des A-E LSP jedoch von 10 auf 15 steigt, kann Router A LSP3 nicht über denselben Pfad (A-B-C-E) signalisieren, da die B-C-Verbindung eine geringere Kapazität aufweist.

Router A hätte die erhöhte Nachfrage nach LSP3 über den Pfad A-B-D-C-E signalisieren sollen. Da LSP1 und LSP2 die B-D-Verbindung basierend auf der Reihenfolge der eingegangenen Anforderungen verwendet haben, wird LSP3 nicht signalisiert.

Obwohl also für alle Sprachdienstleister eine ausreichende Bandbreite für den maximalen Datenfluss zur Verfügung steht, ist LSP3 einer potenziell verlängerten Dienstverschlechterung ausgesetzt. Dies ist auf die mangelnde globale Nachfragetransparenz von Router A und die mangelnde systemische Koordination bei der Bedarfsplatzierung durch die Eingangsrouter A und G zurückzuführen.

Verwendung einer externen Path Computing-Entität

Als Lösung für die derzeitigen Einschränkungen bei der MPLS RSVP-TE-Pfadberechnung ist eine externe Pfadberechnungseinheit mit einer globalen Ansicht des Bedarfs pro LSP und pro Gerät im Netzwerk unabhängig von der verfügbaren Kapazität erforderlich.

Derzeit wird in einem MPLS RSVP-TE-Netzwerk nur eine auf Online- und Echtzeiteinschränkungen basierende Routing-Pfadberechnung bereitgestellt. Jeder Router führt einschränkungsbasierte Routingberechnungen unabhängig von den anderen Routern im Netzwerk durch. Diese Berechnungen basieren auf aktuell verfügbaren Topologieinformationen, d. h. Informationen, die in der Regel aktuell, aber nicht vollständig genau sind. LSP-Platzierungen werden basierend auf dem aktuellen Netzwerkstatus lokal optimiert. Die MPLS RSVP-TE-Tunnel werden über die CLI eingerichtet. Ein Bediener 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 Pfadberechnungseinheit erweitert, die als Path Computation Element (PCE) bezeichnet wird. Der PCE berechnet den Pfad für die TE-LSPs von Eingangsroutern, die für die externe Steuerung konfiguriert wurden. Der Eingangsrouter, der eine Verbindung zu einem PCE herstellt, wird als Path Computation Client (PCC) bezeichnet. Der PCC ist mit dem Path Computation Client Protocol (PCEP) konfiguriert, um die externe Pfadberechnung durch einen PCE zu erleichtern.

Weitere Informationen finden Sie unter Komponenten des External Path Computing.

Um die externe Pfadberechnung für die TE-LSPs eines PCC zu aktivieren, schließen Sie die lsp-external-controller pccd Anweisung auf der [edit mpls] Hierarchieebene und [edit mpls lsp lsp-name] ein.

Komponenten des External Path Computing

Die Komponenten, aus denen sich ein externes Pfadcomputersystem zusammensetzt, sind:

• Element "Pfadberechnung"
• Client für die Pfadberechnung
• 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 PCE-zu-PCC-Kommunikation wird durch das TCP-basierte PCEP ermöglicht. Der 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 die folgenden Aufgaben aus:

1. LSP-Statussynchronisierung: Der PCC sendet Informationen über alle LSPs (lokal und extern) an alle verbundenen PCEs. Bei externen Sprachdienstleistern sendet der PCC Informationen über jede Konfigurationsänderung, RRO-Änderung, Zustandsänderung usw. an den PCE.

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

   HINWEIS:

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

2. LSP-Delegierung: Nachdem die LSP-Statusinformationen synchronisiert wurden, delegiert der PCC die externen LSPs an ein PCE, das aktive aktive zustandsbehaftete PCE. Nur das Haupt-PCE kann Parameter für den externen LSP einstellen. Zu den Parametern, die der Haupt-PCE ändert, gehören Bandbreite, Pfad (ERO) und Priorität (Einrichtung und Halten). Die in der lokalen Konfiguration angegebenen Parameter werden durch die Parameter überschrieben, die von der Haupt-PCE festgelegt werden.

   HINWEIS:

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

   Bei PCE-initiierten LSPs erstellt der PCC den LSP mit den Parametern, die er vom PCE erhält. 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 für die 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 Dienste zu vermeiden. Während dieser Zeit kann ein aktiver zustandsbehafteter PCE die Kontrolle über die LSPs übernehmen, die vom ausgefallenen PCE bereitgestellt wurden, indem er eine Erstellungsanforderung für den LSP sendet.

   Die Kontrolle über PCE-initiierte LSPs wird nach Ablauf der delegation cleanup timeout. Wenn der delegation cleanup timeout PCE abläuft und kein anderer PCE die Kontrolle über den LSP vom fehlgeschlagenen PCE übernommen hat, übernimmt der PCC die lokale Kontrolle über den nicht delegierten, von PCE initiierten LSP. Wenn später der ursprüngliche oder ein neuer aktiver zustandsbehafteter PCE die Kontrolle über die lokal gesteuerten PCE-initiierten LSPs übernehmen möchte, delegiert der PCC diese LSPs an den PCE, und der lsp cleanup timer Timer wird gestoppt.

   Ein PCE kann die Delegierung des PCE-initiierten LSP an den PCC zurückgeben, um die LSP-Übertragung zwischen PCEs zu ermöglichen. Dies löst die lsp cleanup timer für den PCE-initiierten LSP aus. Der PCC wartet, bis der LSP-Bereinigungstimer abgelaufen ist, bevor er die nicht delegierten, von PCE initiierten LSPs aus dem fehlgeschlagenen PCE entfernt.

   Wenn der PCE lsp cleanup timer abläuft und kein anderer PCE die Kontrolle über die LSPs aus dem fehlgeschlagenen PCE erlangt hat, löscht der PCC alle LSPs, die vom fehlgeschlagenen PCE bereitgestellt wurden.

   HINWEIS:

   In Übereinstimmung mit draft-ietf-pce-stateful-pce-09erfolgt das Widerrufen von PCE-initiierten LSP-Delegierungen durch einen PCC nach dem Make-before-Break-Verfahren, bevor die LSPs an einen alternativen PCE delegiert werden. Ab Junos OS Version 18.1R1 muss der lsp-cleanup-timer Wert größer oder gleich dem delegation-cleanup-timeout Wert sein, damit der PCC die LSP-Delegierungen widerrufen kann. Ist dies nicht der Fall, kann das Zeitüberschreitungsintervall für die erneute Delegierung für den PCC auf unendlich festgelegt werden, wobei die LSP-Delegierungen an diesen PCE intakt bleiben, bis der PCC bestimmte Maßnahmen ergreift, um die vom PCE festgelegten Parameter zu ändern.

3. LSP-Signalisierung: Beim Empfang eines oder mehrerer LSP-Parameter vom aktiven Stateful-Haupt-PCE signalisiert der PCC den TE-LSP basierend auf dem von PCE bereitgestellten Pfad erneut. Wenn der PCC den LSP nicht einrichten kann, benachrichtigt er 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 aufweist, bei denen nur die Pfadendpunkte angegeben sind, führt der PCC kein lokales, einschränkungsbasiertes Routing durch, um den vollständigen Satz von Hops zu ermitteln. Stattdessen stellt der PCC RSVP den von PCE bereitgestellten Pfad für die Signalisierung zur Verfügung, und der Pfad wird mithilfe des IGP-Hop-by-Hop-Routings eingerichtet.

Unter Berücksichtigung der in Abbildung 2Abbildung 4 verwendeten Topologie wird die partielle clientseitige PCE-Implementierung im MPLS RSVP-TE-fähigen Netzwerk veranschaulicht. 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.

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

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

Auf diese Weise bietet das Stateful PCE einen kooperativen Betrieb verteilter Funktionalität, der verwendet wird, um spezifische Herausforderungen einer kürzesten Interdomain-Constrained-Path-Berechnung zu bewältigen. Es eliminiert Überlastungsszenarien, in denen Datenverkehrsströme ineffizient auf verfügbare Ressourcen abgebildet werden, was zu einer Überauslastung einiger Teilmengen von Netzwerkressourcen führt, während andere Ressourcen nicht ausgelastet sind.

LSP-Verhalten mit externem Computing

• LSP-Typen
• LSP-Steuerungsmodus

Unterstützte Konfigurationsanweisungen für externes Computing

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

Die übrigen LSP-Konfigurationsanweisungen gelten auf die gleiche Weise 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 angibt, wann die konfigurierten Parameter wirksam werden.

PCE-gesteuerter LSP-Schutz

Die Schutzpfade, einschließlich Fast Reroute und Bypass LSPs, werden lokal vom PCC mithilfe von Constraint-basiertem Routing berechnet. Ein zustandsbehafteter PCE gibt nur den primären Pfad (ERO) an. Ein PCE kann auch einen sekundären Nicht-Standby-Pfad auslösen, selbst wenn die lokale Konfiguration nicht über einen sekundären Nicht-Standby-Pfad für den LSP-Schutz verfügt.

PCE-gesteuerter LSP ERO

Für PCE-gesteuerte LSPs (PCC-delegated 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 external cspfzwei neue Pfadberechnungstypen für die PCE-gesteuerten LSPs eingeführt: local cspf und no cspf.

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

• no cspf—Weder die PCE noch die PCC führen eine Berechnung des beschränkten Pfads durch. Die Endpunkte und Einschränkungen werden dem RSVP-Modul zum Einrichten des LSP mit dem IGP-Pfad übergeben.

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

  • Wenn der PCE TLV sendet local cspf und wenn die Junos OS-Konfiguration oder die 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 im PCE-initiierten LSP enthalten ist no-cspf .

  • Wenn der PCE TLV nicht mit einem leeren ERO oder losem ERO sendet local cspf (mit losem Bit, das im ERO-Objekt festgelegt ist).

Mit diesen neuen Berechnungstypen kann ein PCC ein ERO-Objekt entweder als loses ERO oder als leeres ERO akzeptieren. Eine externe Pfadberechnungseinheit, 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 loses ERO verwendet und der einzuschlagende Weg wird vom PCC festgelegt.

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 den PCE zur LSP-Statussynchronisierung. Dazu gehören PCC-gesteuerte, PCE-delegierte und PCE-initiierte Punkt-zu-Punkt-LSPs. Ab Junos OS Version 15.1F6 und 16.1R1 wird diese Funktion auch auf die Berichterstellung von Point-to-Multipoint-LSPs ausgeweitet. Bei einem PCE ähnelt der Punkt-zu-Mehrpunkt-LSP dem von RSVP-Punkt-zu-Multipunkt-LSP, wobei der Punkt-zu-Mehrpunkt-LSP als Sammlung von Punkt-zu-Punkt-LSPs behandelt wird, die unter einem Punkt-zu-Mehrpunkt-Bezeichner gruppiert sind.

Standardmäßig wird die PCE-Steuerung von Punkt-zu-Mehrpunkt-LSPs auf einem PCC nicht unterstützt. Um diese Funktion hinzuzufügen, schließen Sie die p2mp-lsp-report-capability Anweisung auf der [edit protocols pcep pce pce-name] Hierarchieebene oder [edit protocols pcep pce-group group-id] ein. Nachdem die Punkt-zu-Mehrpunkt-Berichtsfunktion auf einem PCC konfiguriert wurde, kündigt der PCC diese Funktion dem PCE an. Wenn der PCE im Gegenzug dieselbe Punkt-zu-Mehrpunkt-Berichtsfunktion ankündigt, meldet der PCC den vollständigen Punkt-zu-Mehrpunkt-LSP-Baum an den PCE zur LSP-Statussynchronisierung.

Ein PCC mit der Point-to-Multipoint-TE-LSP-Funktion unterstützt die Berichterstellung von Point-to-Multipoint-TE-LSPs für zustandsbehaftete PCEs, Punkt-zu-Multipoint-Updates und LSP-Datenbanken, die Point-to-Multipoint-LSP-Namen als Schlüssel unterstützen. Die folgenden Features und Funktionen werden jedoch für Junos OS Version 15.1F6 und 16.1 nicht unterstützt:

• Statische Punkt-zu-Mehrpunkt-Sprachdienstleister

• PCE-delegierte und PCE-initiierte Punkt-zu-Multipoint-LSPs

• Automatische Bandbreite

• TE++

• PCE-Anfrage und Antwortnachricht

• Erstellung von Punkt-zu-Mehrpunkt-Sprachdienstleistern mithilfe von Vorlagen

• Konfigurieren der Vorwärtseingabe auf den PCE-initiierten Punkt-zu-Mehrpunkt-LSPs

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

PCE-initiierte Punkt-zu-Punkt-LSPs

Ab Junos OS Version 16.1 wird die PCEP-Funktionalität erweitert, damit ein Stateful PCE Traffic Engineering-LSPs über einen PCC initiieren und bereitstellen kann. Zuvor wurden die Sprachdienstleister auf dem PCC konfiguriert, und der PCC delegierte die Kontrolle über die externen Sprachdienstleister an einen PCE. Das Eigentum des LSP-Staates wurde von der PCC beibehalten. Mit der Einführung der PCE-initiierten LSPs kann ein PCE einen Punkt-zu-Punkt-LSP für das Traffic Engineering dynamisch initiieren und bereitstellen, ohne dass ein lokal konfigurierter LSP auf dem PCC erforderlich ist. Beim Empfang einer PCCreate-Nachricht von einem PCE erstellt der PCC den PCE-initiierten LSP und delegiert den LSP automatisch an den PCE.

Standardmäßig lehnt ein PCC die Anforderung zur Bereitstellung von PCE-initiierten Punkt-zu-Punkt-LSPs von einem PCE ab. Um die Unterstützung von PCE-initiierten LSPs auf dem PCC zu aktivieren, schließen Sie die lsp-provisioning-Anweisung auf den [edit protocols pcep pce pce-id] Hierarchieebenen or [edit protocols pcep pce-group group-id] ein.

Ein PCC gibt an, dass er PCE-initiierte Punkt-zu-Punkt-LSPs unterstützen kann, während die PCEP-Sitzung (Path Computation Element Protocol) mit dem PCE eingerichtet wird. Ein PCE wählt einen PCC mit dieser Fähigkeit aus, um einen LSP zu initiieren. Der PCE versorgt den PCC mit den PCE-initiierten LSP-Parametern. Nach dem Empfang der PCE-initiierten Punkt-zu-Punkt-LSP-Parameter richtet der 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 der PCC zu konfigurieren, schließen 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-initiierten LSPs sofort zu löschen –delegation cleanup timeout und lsp cleanup timer–, um eine Unterbrechung der Dienste zu vermeiden. Während dieser Zeit kann ein aktiver zustandsbehafteter PCE die Kontrolle über die LSPs übernehmen, die vom ausgefallenen PCE bereitgestellt wurden.

Ein PCE kann die Delegierung des PCE-initiierten Punkt-zu-Punkt-LSP an den PCC zurückgeben, um die LSP-Übertragung zwischen PCEs zu ermöglichen. Die Kontrolle über PCE-initiierte LSPs wird nach Ablauf des Timeouts für die Delegierungsbereinigung auf die PCC zurückgesetzt. Wenn das Timeout für die Delegierungsbereinigung abläuft und kein anderer PCE die Kontrolle über den LSP des fehlgeschlagenen PCE erlangt hat, übernimmt der PCC die lokale Kontrolle über den nicht delegierten, von PCE initiierten LSP. Wenn später der ursprüngliche oder ein neuer aktiver zustandsbehafteter PCE die Kontrolle über die lokal gesteuerten PCE-initiierten Punkt-zu-Punkt-LSPs übernehmen möchte, delegiert der PCC diese LSPs an den PCE, und der LSP-Bereinigungstimer wird gestoppt.

Der PCC wartet, bis der LSP-Bereinigungstimer abgelaufen ist, bevor er die nicht delegierten, von PCE initiierten Punkt-zu-Punkt-LSPs aus dem fehlgeschlagenen PCE löscht. Wenn der LSP-Bereinigungstimer abläuft und kein anderer PCE die Kontrolle über die LSPs aus dem ausgefallenen PCE erlangt hat, löscht der PCC alle LSPs, die vom fehlgeschlagenen PCE bereitgestellt wurden.

Ab Junos OS Version 21.1R1 unterstützen wir Nonstop Active Routing (NSR) für PCE-initiierte RSVP-basierte Punkt-zu-Punkt- und Punkt-zu-Multipunkt-LSPs. Nur die primäre Routing-Engine verwaltet die PCEP-Sitzung mit dem Controller. Es synchronisiert alle RSVP-LSPs, die von PCEs initiiert wurden, einschließlich Multicast-Flussspezifikationen für alle PCE-initiierten P2MP-LSPs, mit der Backup-Routing-Engine. Während eines Switchovers wird die PCEP-Sitzung unterbrochen und wieder hergestellt, wenn die Backup-Routing-Engine zur primären Routing-Engine wird. Dadurch wird der Datenverkehrsverlust für den Datenverkehr reduziert, der über PCE-initiierte RSVP-LSPs während des Routing-Engine-Switchovers übertragen wird. Diese Funktion wird aktiviert, wenn NSR konfiguriert ist.

PCE-initiierte Bypass-LSP

• Grundlegendes zu PCE-initiierten Bypass-LSPs
• Vorteile der PCE-initiierten Bypass-LSP
• Verhalten von PCE-initiierten Bypass-LSPs bei PCEP-Sitzungsfehlern

PCE-initiierte Punkt-zu-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 das Timing und die Reihenfolge der Punkt-zu-Mehrpunkt-Pfadberechnungen innerhalb und zwischen PCEP-Sitzungen (Path Computation Element Protocol) 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 Punkt-zu-Multipunkt-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 sowohl für MPLS- als auch für IPv6-Weiterleitungsebene. Segment-Routing für PCEP unterstützt SR-LSPs wie PCE-initiierte, lokal erstellte und delegierte SR-LSPs in IPv6-Weiterleitungsebene.

Vorteile von SRv6-LSPs in PCEP

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

PCEP unterstützt das Erstellen, Aktualisieren und Löschen von PCE-initiierten farbigen und ungefärbten SRv6-LSPs. Wenn PCE-initiierte SRv6-LSP zusammen mit einer statischen SRv6-LSP für dieselbe IP- oder farbbasierte IP-Adresse existiert, wird die statische SRv6-TE-LSP-Beitragsroute der PCE-initiierten SRv6-TE-LSP-Beitragsroute vorgezogen.

Um eine PCEP-Sitzung so zu konfigurieren, dass sie SRv6-fähig ist, müssen Sie die srv6-capability Konfigurationsanweisung auf den Hierarchieebenen [edit protocols pcep pce pce-id] oder [edit protocols pcep pce-group pce-id] aktivieren. Wenn die Konfigurationsanweisung aktiviert ist, müssen Sie auch die Konfigurationsanweisung srv6 auf der Hierarchieebene [edit protocols source-packet-routing] aktivieren, da sonst während des srv6-capabilityCommits ein Fehler angezeigt wird.

Um SRv6 für SR-TE zu konfigurieren, müssen Sie die Konfigurationsanweisung srv6 auf der Hierarchieebene [edit protocols source-packet-routing] hinzufügen.

[Weitere Informationen finden Sie unter Grundlegendes zur SR-TE-Richtlinie für den SRv6-Tunnel .

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

Automatische Bandbreite und PCE-gesteuerter LSP

Ab Junos OS Version 14.2R4 wird die automatische Bandbreite für PCE-gesteuerte LSPs unterstützt. In früheren Versionen galt die Option für die automatische Bandbreite nicht für PCE-gesteuerte LSPs, obwohl LSPs unter der Kontrolle von Auto-Bandwdith und Constraint-basiertem 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 zu lokal wechselte. Dies geschah z. B. in Fällen, in denen keine Verbindung zu einem PCE bestand oder wenn ein PCE die Delegation von Sprachdienstleistern an den PCC zurückgab.

TCP-MD5-Authentifizierung für PCEP-Sitzungen

Ein zustandsbehafteter PCE-Server automatisiert die Erstellung von Traffic-Engineering-Pfaden über das Netzwerk, erhöht die Netzwerkauslastung und ermöglicht eine benutzerdefinierte programmierbare Netzwerkerfahrung durch die Verwendung der PCEP-Kommunikation mit einem PCC. Ein PCC sendet LSP-Berichte an einen PCE-Server, und der PCE aktualisiert oder stellt LSPs an den PCC zurück. Die Daten, die über eine PCEP-Sitzung gesendet werden, sind für einen PCE-Server von entscheidender Bedeutung, um externe Pfadberechnungen durchzuführen. Infolgedessen kann ein Angriff auf die PCEP-Kommunikation die Netzwerkdienste unterbrechen. Wenn geänderte PCEP-Nachrichten an einen PCC gesendet werden, können ungeeignete LSPs eingerichtet werden. Wenn geänderte PCEP-Nachrichten an einen PCE gesendet werden, lernt der PCE eine falsche Ansicht des Netzwerks.

In Anbetracht der Bedeutung der PCEP-Kommunikation zwischen einem PCE und einem PCC für die effektive Ausführung der PCE-Funktionalitäten führt Junos OS Version 16.1 die Funktion zum Sichern einer PCEP-Sitzung mithilfe der TCP-MD5-Authentifizierung gemäß RFC 5440 ein. Diese Funktion schützt die Kommunikation zwischen einem PCE und einem PCC über eine PCEP-Sitzung, die einem Angriff ausgesetzt sein und Netzwerkdienste unterbrechen kann.

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

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

• Verwenden des MD5-Authentifizierungsschlüssels:

• Verwenden eines vordefinierten Authentifizierungsschlüsselbunds:

Damit sichere PCEP-Sitzungen erfolgreich eingerichtet werden können, sollte 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 Authentizität jedes Segments zu überprüfen, das über die TCP-Verbindung der PCEP-Sitzung gesendet wird.

Auswirkungen der clientseitigen PCE-Implementierung auf die Netzwerkleistung

Die Wartung einer zustandsbehafteten Datenbank kann nicht trivial sein. In einer einzelnen zentralisierten PCE-Umgebung muss sich ein zustandsbehaftetes PCE lediglich alle TE-LSPs merken, die der PCE berechnet hat, die tatsächlich eingerichteten TE-LSPs (sofern dies bekannt ist) und wann die TE-LSPs abgerissen wurden. Diese Anforderungen verursachen jedoch einen erheblichen Overhead der Kontrollprotokolle in Bezug auf Status, Netzwerknutzung und -verarbeitung sowie die globale Optimierung der Verbindungen im gesamten Netzwerk. Zu den Bedenken einer zustandsbehafteten PCE-Implementierung gehören daher:

• Jeder zuverlässige Synchronisationsmechanismus führt zu einem erheblichen Overhead der Steuerungsebene. PCEs können den Zustand synchronisieren, indem sie miteinander kommunizieren, aber wenn TE-LSPs mit verteilten Berechnungen eingerichtet werden, die zwischen mehreren PCEs durchgeführt werden, werden die Probleme der Synchronisierung und der Vermeidung von Race Conditions größer und komplexer.

• Die Out-of-Band-Synchronisierung von Traffic-Engineering-Datenbanken kann komplex sein, da mehrere PCEs in einem verteilten PCE-Berechnungsmodell eingerichtet sind, und kann anfällig für Racebedingungen, Skalierbarkeitsprobleme usw. sein.

• Pfadberechnungen, die den Gesamtstatus des Netzwerks einbeziehen, sind sehr komplex, selbst wenn das PCE detaillierte Informationen zu allen Pfaden, Prioritäten und Layern hat.

Trotz der oben genannten Bedenken ist die teilweise clientseitige Implementierung des Stateful PCE in großen verkehrstechnischen Systemen äußerst effektiv. Es bietet eine schnelle Konvergenz und erhebliche Vorteile im Hinblick auf eine optimale Ressourcennutzung, indem es die Voraussetzungen für die globale Sichtbarkeit eines TE LSP-Status und für eine geordnete Steuerung von Pfadreservierungen für alle Geräte innerhalb des zu steuernden Systems erfüllt.

Vorteile von PCE-initiierten Punkt-zu-Multipunkt-Sprachdienstleistern

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

Signalisierung von PCE-initiierten Punkt-zu-Mehrpunkt-LSPs

Die Signalisierung von PCE-initiierten Punkt-zu-Mehrpunkt-LSPs ist wie folgt:

• When a new branch is added (Grafting)—Nur der neue Branch-Sub-LSP wird signalisiert und führt nicht zu einer erneuten Signalisierung des gesamten Punkt-zu-Mehrpunkt-Baums.

  Wenn vor der Bereitstellung des neuen untergeordneten LSP Änderungen an der Topologie aufgetreten sind, berechnet der Path Computation Server (PCS) die gesamte Punkt-zu-Mehrpunkt-Struktur neu und aktualisiert den Punkt-zu-Mehrpunkt-LSP mithilfe einer PC-Aktualisierungsmeldung.

• When a branch is deleted (Pruning)—Der gelöschte untergeordnete LSP der Verzweigung wird abgerissen und führt nicht zu einer erneuten Signalisierung der gesamten Punkt-zu-Mehrpunkt-Struktur.

• When a branch sub-LSP parameter is changed—Änderungen an Sub-LSP-Parametern, wie z. B. Explicit Route Object (ERO), Bandbreite oder Priorität, können entweder aufgrund der Optimierung oder auf Benutzerwunsch erfolgen. Wenn es eine Re-Signaling-Anforderung für einen Sub-LSP gibt, wird die gesamte Punkt-zu-Multipoint-Struktur erneut signalisiert, und dann erfolgt der Switchover zur neuen Instanz, sobald die neuen Instanzen aller Branches aktiv sind.

• When a branch sub-LSP path fails– Dem PCS wird ein Fehler für den ausgefallenen Branch-Sub-LSP gemeldet. Beim Empfang des neuen ERO vom PCS wird der gesamte Punkt-zu-Mehrpunkt-Baum zusammen mit dem ausgefallenen Branch-Sub-LSP erneut signalisiert, und der Wechsel zur neuen Instanz erfolgt nach dem Prinzip "Make-before-Break" (MBB).

Verhalten von PCE-initiierten Punkt-zu-Multipoint-LSPs nach einem PCEP-Sitzungsfehler

Wenn eine PCEP-Sitzung fehlschlägt, sind die PCE-initiierten Punkt-zu-Multipunkt-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 Punkt-zu-Multipunkt-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 der PCE-initiierten Punkt-zu-Multipoint-LSP-Funktion

Standardmäßig wird die Erstellung und Bereitstellung von Punkt-zu-Mehrpunkt-LSPs durch einen PCE auf einem PCC nicht unterstützt. Um diese Funktion zu aktivieren, schließen Sie die p2mp-lsp-init-capability and-Anweisungen p2mp-lsp-update-capability auf den [edit protocols pcep pce pce-name] Hierarchieebenen or [edit protocols pcep pce-group group-id] ein.

Die p2mp-lsp-init-capability Anweisung bietet die Möglichkeit, Punkt-zu-Mehrpunkt-RSVP-TE-LSPs durch einen PCE bereitzustellen. Die p2mp-lsp-update-capability Anweisung bietet die Möglichkeit, Punkt-zu-Mehrpunkt-RSVP-TE LSP-Parameter durch eine PCE zu aktualisieren.

Unterstützte und nicht unterstützte Funktionen für PCE-initiierte Punkt-zu-Multipunkt-LSPs

Die folgenden Funktionen werden von PCE-initiierten Punkt-zu-Mehrpunkt-LSPs unterstützt:

• Teilweise Übereinstimmung mit dem Internet-Entwurf draft-ietf-pce-stateful-pce-p2mp (läuft im Oktober 2018 ab), Path Computation Element (PCE) Protocol Extensions for Stateful PCE usage for 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 Punkt-zu-Multipoint-LSPs. Nur die primäre Routing-Engine verwaltet die PCEP-Sitzung mit dem Controller. Es synchronisiert alle RSVP-LSPs, die von PCEs initiiert wurden, einschließlich Multicast-Flussspezifikationen für alle PCE-initiierten P2MP-LSPs, mit der Backup-Routing-Engine. Während eines Switchovers wird die PCEP-Sitzung unterbrochen und wieder hergestellt, wenn die Backup-Routing-Engine zur primären Routing-Engine wird. Dadurch wird der Datenverkehrsverlust für den Datenverkehr reduziert, der über PCE-initiierte RSVP-LSPs während des Routing-Engine-Switchovers übertragen wird. Diese Funktion wird aktiviert, wenn NSR konfiguriert ist.

Die folgenden Funktionen werden von PCE-initiierten Punkt-zu-Multipunkt-LSPs nicht unterstützt:

• Delegierung von lokal gesteuerten Punkt-zu-Mehrpunkt-LSPs.

• Delegierung der LSP-Steuerung.

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

• Request/Response-Nachrichten.

• Direktes Verschieben von Branch-Sub-LSP von einem Punkt-zu-Mehrpunkt-Baum in einen anderen.

  Dasselbe kann erreicht werden, indem ein untergeordneter Verzweigungs-LSP aus der ersten Punkt-zu-Mehrpunkt-Struktur gelöscht und einer anderen erneut hinzugefügt wird, nachdem die PCReport Meldung das Entfernen des LSP vom Gerät angezeigt hat.

• IPv6 wird nicht unterstützt.

• SERO-basierte Signalisierung wird nicht unterstützt.

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

• Der Linkschutz wird nicht unterstützt.

Zuordnen von PCE-initiierten Punkt-zu-Multipoint-LSPs zu MVPN

Sie können einen einzelnen oder einen Bereich von MVPN-Multicast-Flows (S,G) einem dynamisch erstellten, PCE-initiierten Punkt-zu-Multipoint-Label-Switched-Pfad (LSP) zuordnen. Sie können nur ausgewählte Typen von Schemata angeben, damit diese Funktion funktioniert. Dies beinhaltet:

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

• (S,G), d. h. die Quelle eines Multicast-Pakets und die Adresse der Ziel-Multicast-Gruppe. Dies wird verwendet, um eingehenden Datenverkehr zu filtern und ihn dem Tunnel zuzuordnen.

• Punkt-zu-Mehrpunkt-LSP, der zum Senden von Datenverkehr verwendet wird, der der oben genannten Datenstromspezifikation entspricht.

Weitere Informationen finden Sie unter Internet draft draft-ietf-pce-pcep-flowspec-05 (gültig bis 16. Februar 2020) PCEP Extension for Flow Specification.

Die aktuelle Implementierung dieser Funktion implementiert die folgenden Abschnitte des Entwurfs nicht:

• Abschnitt 3.1.2 – Werbung für PCE-Fähigkeiten in IGP

• Abschnitt 3.2 – PCReq- und PCRep-Nachricht

• Abschnitt 7 – Die meisten Datenstromspezifikationen, mit Ausnahme der RoutenunterscheidungDie aktuelle Implementierung dieser Funktion unterstützt keine IPv4-Multicast-Datenflussspezifikationen werden nicht unterstützt.

So aktivieren Sie die Zuordnung von PCE-initiierten Punkt-zu-Mehrpunkt-LSPs zu MVPN:

• Fügen Sie die pce_traffic_steering Anweisung auf Hierarchieebene [edit protocols pcep pce pce-id] ein, um die Unterstützung für die Datenflussspezifikationsfunktion (auch als Datenverkehrssteuerung bezeichnet) durch den PCC anzugeben.

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

  Das Vorhandensein von external-controller in der Provider-Tunnel-Konfiguration für MVPN gibt an, dass der Punkt-zu-Multipoint-LSP und (S,G) für diese MVPN-Instanz vom externen Controller bereitgestellt werden können. Dadurch kann der externe Controller dynamisch (S,G) und Punkt-zu-Mehrpunkt-LSP für MVPN konfigurieren.

Bei der Zuordnung von PCE-initiierten Punkt-zu-Multipunkt-LSPs zu MVPN ist Folgendes zu berücksichtigen:

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

• Wenn Sie die external-controller pccd Konfiguration über die CLI deaktivieren, werden die dynamisch erlernten Multicast-Flows (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 der PCC (S,G) nicht dynamisch konfigurieren, da die lokale Konfiguration eine höhere Priorität hat.

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

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

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

• Wenn der Benutzer für eine bestimmte MVPN-Instanz aktiviert external-controller pccd , fordert MVPN den PCCD-Prozess zur Konfiguration (S,G) an, falls vorhanden.

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

• Alle Flow-Spezifikationen, die einem PCE-initiierten Punkt-zu-Multipoint-LSP zugeordnet sind, müssen dieselbe RD aufweisen. Wenn während der PC-Initiierung nicht alle Flow-Spezifikationen die gleiche RD haben, wird die PC-Initiierungsnachricht mit einem Fehler gelöscht.

• Sie können einen Punkt-zu-Mehrpunkt-LSP nur mit selektiven Datenflussspezifikationen verknüpfen, andernfalls wird die PC-Initiierungsnachricht mit einem Fehler verworfen.

• Wenn während der PC-Aktualisierung nicht alle Flow-Spezifikationen den gleichen RD haben, entweder aufgrund einer neuen Flow-Spezifikation oder aufgrund einer vorhandenen Flow-Spezifikations-Aktualisierung, dann löscht der PCC die Update-Meldung.

• Wenn während der PC-Aktualisierung alle Flow-Spezifikationen die selektive Bedingung nicht erfüllen, entweder aufgrund einer neuen Flow-Spezifikation oder aufgrund einer Aktualisierung vorhandener Flow-Spezifikationen, verwirft der PCC die Update-Meldung.

• Das Verhalten für die Zuordnung von PCE-initiierten Punkt-zu-Multipoint-LSPs zu MVPN-Routing-Instanzen und die Zuordnung von statischen (lokal konfigurierten) Punkt-zu-Multipoint-LSPs zu MVPN-Instanzen ist auf Benutzerebene identisch.

• Eine Datenflussspezifikations-ID kann nur einem Punkt-zu-Mehrpunkt-LSP zugeordnet werden. Um dieselben RD und (S,G) mehreren Punkt-zu-Mehrpunkt-LSPs zuzuordnen, können Sie mehrere Flow-Spezifikationen mit unterschiedlichen IDs und derselben RD & (S,G) hinzufügen.

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

• Es gibt keine Begrenzung für die Anzahl der Datenflussspezifikationen, die einem einzelnen PCE-initiierten Punkt-zu-Mehrpunkt-LSP zugeordnet werden.

• Die aktuelle Implementierung dieser Funktion unterstützt Folgendes nicht:

  • Melden von Weiterleitungszuständen, die dem Punkt-zu-Mehrpunkt-LSP zugeordnet sind.

  • Inklusive dynamischer Konfiguration des Provider-Tunnels

  • Zuordnung für MVPN-Eingangsreplikationstunnel

  • Programmierbarer Routing-Protokoll-Prozess (PRPD)

  • Berichterstellung für CLI-konfigurierte Punkt-zu-Multipunkt-LSPs, die MVPN-Multicast-Flows (S,G) zugeordnet sind.

Verteilte CSPF-Berechnungseinschränkungen

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

Die verteilte CSPF-Berechnungsfunktion unterstützt die folgende Teilmenge von Einschränkungen, die im Internet-Entwurf, draft-ietf-spring-segment-routing-policy-03.txt, Segment Routing Policy for Traffic Engineeringangegeben sind:

• Ein- und Ausschluss administrativer Gruppen.

• Einbeziehung von Loose- oder Strict-Hop-IP-Adressen.

  HINWEIS:

  Sie können nur Router-IDs in den lockeren oder strikten Hop-Einschränkungen angeben. Bezeichnungen und andere IP-Adressen können in Junos OS Version 19.2R1-S1 nicht als lockere oder strikte Hop-Einschränkungen angegeben werden.

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

• Maximale Anzahl von Segmentlisten pro Kandidatensegment-Routing-Pfad.

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

• IPV6-Adressen.

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

• Nicht nummerierte Schnittstellen.

• Routing-Protokolle für mehrere Protokolle wie OSPF, ISIS und BGP-LS sind gleichzeitig aktiviert.

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

• Ein- und Ausschließen von Schnittstellen-IP-Adressen als Einschränkungen.

Verteilter CSPF-Berechnungsalgorithmus

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

• Aktivierte Etikettenstapelkomprimierung
• Label-Stack-Komprimierung deaktiviert

Verteilte CSPF-Berechnungsdatenbank

Die Datenbank, die für die SR-TE-Berechnung verwendet wird, enthält alle Links, Knoten, Präfixe und deren Merkmale, unabhängig davon, ob in diesen Werbeknoten Traffic-Engineering aktiviert ist. Mit anderen Worten, es ist die Vereinigung der Traffic-Engineering-Datenbank (TED) und der IGP-Link-State-Datenbank aller Domänen, aus denen der Rechenknoten gelernt hat. Damit CSPF funktioniert, müssen Sie die igp-topology Anweisung daher auf Hierarchieebene [edit protocols isis traffic-engineering] einschließen.

Konfigurieren verteilter CSPF-Berechnungseinschränkungen

Sie können ein Computeprofil verwenden, um die Berechnungseinschränkungen logisch zu gruppieren. Auf diese Computeprofile wird von den Segmentroutingpfaden für die Berechnung der primären und sekundären Segmentrouting-LSPs verwiesen.

Um ein Computeprofil zu konfigurieren, schließen Sie die compute-profile-Anweisung auf Hierarchieebene [edit protocols source-packet-routing] ein.

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

• Administrative groups

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

  Um die Berechnungseinschränkungen zu konfigurieren, können Sie drei Kategorien für eine Gruppe von administrativen Gruppen angeben. Die Konfiguration der Berechnungseinschränkung kann für alle Routingpfade für Kandidatensegmente oder unter einzelnen Kandidatenpfaden gelten.

  • include-any– Gibt an, dass jede Verknüpfung mit mindestens einer der konfigurierten administrativen Gruppen in der Liste für den zu durchlaufenden Pfad akzeptabel ist.

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

  • exclude– Gibt an, dass jeder Link, der keine der konfigurierten administrativen Gruppen in der Liste enthält, für den zu durchlaufenden Pfad akzeptabel ist.

• Explicit path

  Sie können eine Reihe von Router-IDs im Computeprofil als Einschränkung für die Berechnung der SR-TE-Kandidatenpfade angeben. Jeder Hop muss eine IPv4-Adresse sein und kann vom Typ strict oder loose sein. Wenn der Typ eines Hops nicht konfiguriert ist, wird strict verwendet. Sie müssen die compute Option unter der segment-list-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 dynamischer Segmentlisten verknüpfen. 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 der Pfadberechnung mit oder ohne Komprimierung.

  Sie können dieses Attribut mit der maximum-computed-segment-lists maximum-computed-segment-lists Option unter der Konfigurationsanweisung compute-profile 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 Berechnung der maximalen Segmentlistentiefe stellt sicher, dass unter den ECMP-Pfaden, die alle anderen Einschränkungen wie die administrative Gruppe erfüllen, nur die Pfade verwendet werden, deren Segmentlisten kleiner oder gleich der maximalen Segmentlistentiefe sind. Wenn Sie diesen Parameter als Einschränkung unter dem Computeprofil konfigurieren, überschreibt er die maximum-segment-list-depth Konfiguration auf der Hierarchieebene [edit protocols source-packet-routing] , sofern vorhanden.

  Sie können dieses Attribut mit der maximum-segment-list-depth maximum-segment-list-depth Option unter der Konfigurationsanweisung compute-profile konfigurieren.

• Protected or unprotected adjacency SIDs

  Sie können geschützte oder ungeschützte Nachbarschafts-SID als Einschränkung unter dem Computeprofil konfigurieren, um Verknüpfungen mit dem angegebenen SID-Typ zu vermeiden.

• Metric type

  Sie können den Typ der Metrik auf dem Link angeben, der für die Berechnung verwendet werden soll. Standardmäßig verwenden SR-TE-Sprachdienstleister für die Berechnung Traffic-Engineering-Metriken der Verbindungen. 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 Konfiguration vom Typ "metric" im Computeprofil verwenden.

  Sie können dieses Attribut mit der metric-type (igp | te) Option unter der Konfigurationsanweisung compute-profile konfigurieren.

Verteilte CSPF-Berechnung

Die SR-TE-Kandidatenpfade werden lokal so berechnet, dass sie die konfigurierten Einschränkungen erfüllen. Wenn die Label-Stack-Komprimierung deaktiviert ist, ist das Ergebnis der Multi-Path-CSPF-Berechnung ein Satz von Adjacency-SID-Stacks. Wenn die Label-Stack-Komprimierung aktiviert ist, ist das Ergebnis ein Satz komprimierter Label-Stacks (bestehend aus benachbarten SIDs und Knoten-SIDs).

Wenn sekundäre Pfade berechnet werden, werden die Verbindungen, Knoten und SRLGs, die von den primären Pfaden verwendet werden, für die 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 Sprachdienstleister mit erfolglosem Berechnungsergebnis wird die Berechnung als TED-Änderungen (Traffic Engineering Database) wiederholt.

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

• Gewichtungen, die mit Pfaden einer SR-TE-Richtlinie verknüpft sind
• BFD-Lebendigkeitserkennung
• inherit-label-nexthops
• Automatische Übersetzungsfunktion

Beispielkonfigurationen für verteilte CSPF-Berechnungen

• Beispiel 1
• Beispiel 2
• Beispiel 3

Vorteile mehrerer Pfade für PCEP SR-TE LSPs

• Sprachdienstleister können mehrere Sätze von EROs für ein Ziel haben

• Bietet Load-Balancing-Funktionen durch Konfiguration von Gewichtungen für einzelne EROs

• Entspricht dem SR-TE-Architekturentwurf zur Definition von Kandidatenpfaden

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 gesteuerten Kandidatenpfad konfigurieren.

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

Wenn Sie PCEP-Multipaths aktivieren, compute-profile kann jetzt die maximale Anzahl von Segmentlisten (maximum-computed-segment-lists) größer als 1 konfiguriert werden.

Wenn die PCEP-Multipath-Funktion aktiviert ist, ist die Konfiguration des sekundären Pfads 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. Primäre Pfade enthalten die MULTIPATH-BACKUP-TLV nicht in der PCRpt-Nachricht. Der sekundäre Pfad enthält MULTIPATH-BACKUP-TLV mit gesetztem Backup-Flag.

Die folgenden PCEP-Multipath-Funktionalitäten werden unterstützt:

• Mehrwegegewichtung TLV (MULTIPATH-WEIGHT-TLV) im Pfadattributobjekt (PATH-ATTRIB)

• MULTIPATH-BACKUP TLV im Pfadattributobjekt (PATH-ATTRIB) nur für PCC-gesteuerte SR-TE LSPs

• MULTIPATH-CAP TLV im PCEP LSP-Objekt

• Schränkt mehrere primäre und sekundäre Pfade im SR-Kandidatenpfad ein, wenn PCEP-Multipath deaktiviert ist

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

• Maximal berechnete Segmentlisten (max-computed-segment-lists) größer als 1 im SR-TE-Computeprofil für delegierte und PCE-initiierte LSPs

• Mehrere EROs für den PCE-initiierten Kandidatenpfad in SR-TE und in PCCD

• SRv6-Sprachdienstleister

• SR MPLS (IPv4)

• Dynamische Tunnel SR MPLS (IPv4)

• Multi-Controller-Unterstützung

• Mehrere ERO-Pfade für PCE-initiierte, PCC-konfigurierte und gesteuerte sowie delegierte farbige und ungefärbte Kandidatenpfade

• Abwärtskompatibel mit früheren Versionen von Paragon Pathfinder. Aus Gründen der Abwärtskompatibilität müssen Sie die Konfigurationsanweisung auf der Hierarchieebene [edit protocols pcep] konfigurierendisable-multipath-capability.

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

  • Die Gesamtzahl der Unterkandidatenpfade pro Kandidatenpfad ist auf 127 begrenzt. Wenn bei PCE-initiierten LSPs die Anzahl der ERO-Pfade 127 überschreitet, löst SR-TE ERROR an PCCD aus (und PCCD sendet eine PCEP-Fehlermeldung an PCE), und die entsprechenden ERO-Pfade werden zurückgewiesen.

Die folgenden PCEP-Fehlermeldungen werden unterstützt:

Begrenzungen

Es gelten die folgenden PCEP-Einschränkungen:

• Die folgenden TLVs, die im draft-ietf-pce-multipath-06 erwähnt werden, werden nicht unterstützt:

  • Multipath-Backup-TLV

  • Multipath-Pfad in entgegengesetzter Richtung TLV

  • Zusammengesetzter Kandidatenpfad

• Wenn die Multipath-Funktion in PCEP deaktiviert ist, ist die Konfiguration mehrerer Unterkandidatenpfade nicht zulässig. Auf Junos-Geräten ohne Multipath-Funktion (Junos OS-Versionen vor 22.4R1) ist jedoch die Konfiguration mehrerer Unterkandidatenpfade zulässig. Wenn PCEP Multi-Segment (standardmäßig) aktiviert ist, sind mehrere primäre Pfade für PCC-gesteuerte LSPs zum Zwecke der Berichterstellung zulässig. Es wird jedoch nur ein primärer Pfad für den delegierten Kandidatenpfad unterstützt, wenn PCEP Multi-Segment aktiviert ist.

• Admin-Gruppen und andere Einschränkungen werden PCE nicht für PCC-konfigurierte und kontrollierte SR-MPLS- und SRv6-Kandidatenpfade (mit einer 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 Konfiguration des sekundären Pfads nicht zulässig.

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

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

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

Konfiguration

Damit PCCD Multipath-Funktions-TLV im LSP-Objekt senden kann, um die Liste der maximal berechneten Segmente für einen bestimmten Kandidatenpfad zu benachrichtigen, schließen Sie die propagate-max-segmentlist Konfigurationsanweisung auf der Hierarchieebene [edit protocols pcep] ein. 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 Konfigurationsanweisung auf der Hierarchieebene [edit protocols pcep] ein.

Sie können die folgenden Protokoll-Trace-Optionen 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 von Label-Switched-Pfaden (LSPs) an, die dem Path Computation Client (PCC) bekannt sind.

• user@host> show path-computation-client lsp extensive: Zeigt umfangreiche Ausgabepegel zu jedem bekannten LSP an – Punkt-zu-Punkt- und Punkt-zu-Mehrpunkt-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: Zeigt Eingangsdetails des SPRING-Traffic-Engineerings an.

Vorteile der Aktivierung von TLS für PCEP-Sitzungen

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

• Nutzt TLS-Sicherheitsvorteile.

Aktivieren von TLS im Path Computation Client (PCC)

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

Nach der Aktivierung der Konfigurationsanweisung tls-strict treten die folgenden Ereignisse auf:

1. PCEP-Session-Klappen. Jede vorhandene TCP-Verbindung wird beendet und die Verbindung wird mithilfe von TLS wiederhergestellt.

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

3. TLS-Vorgänge werden durch die StartTLS Nachricht von PCE zu PCC und von PCC zu PCE initiiert. Die StartTLS Nachricht wird von PCC gesendet und der StartTLSWait Timer 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 kleiner als der OpenWait Timer sein. Der Standardwert OpenWait für den Timer ist auf 60 Sekunden festgelegt.

   • Wenn PCC die Nachricht "Offen" anstelle der StartTLS Nachricht empfängt, PCErr wird die Nachricht mit dem Fehlertyp auf 1 (Fehler beim Aufbau der PCEP-Sitzung) und dem Fehlerwert auf 1 (Empfang einer ungültigen offenen Nachricht oder einer nicht offenen Nachricht) festgelegt, und die TCP-Sitzung wird geschlossen.

   • Wenn StartTLS keine Nachricht von PCE empfangen wird, sendet PCC nach Ablauf des Timers eine PCErr Nachricht, bei der StartTLSWaitder Fehlertyp auf 25 (PCEP-Fehler StartTLS ) und der Fehlerwert auf 5 (keine StartTLS Nachricht (noch PCErr/Open) vor StartTLSWait Ablauf des Zeitgebers festgelegt ist), und die TCP-Sitzung wird geschlossen.

4. Die Aushandlung und der Aufbau der 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 nachverfolgen.

TLS-Verbindung herstellen

Die folgenden Schritte beschreiben, wie eine TLS-Verbindung (mit 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 ein Schlüsselpaar und CSR auf dem Gerät, und senden Sie diese CSR an die Zertifizierungsstelle, um das Zertifikat zu erhalten. Sobald das Zertifikat ausgestellt wurde, wird es auf die Box kopiert und installiert.

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

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

   HINWEIS:

   Zertifizierungsstellen können in flacher Hierarchie als unabhängige Zertifizierungsstelle geladen werden. Wenn es sich bei einer Zertifizierungsstelle um eine untergeordnete Zertifizierungsstelle einer anderen Zertifizierungsstelle handelt, wird die Kette intern von PKI erstellt.

   HINWEIS:

   Das Serverzertifikat sollte von einer Zertifizierungsstelle signiert sein. Selbstsignierte Zertifikate sind nicht zulässig.

3. Aktivieren Sie TLS auf PCC.

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

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

6. PCC initiiert die Verbindungsanforderung an den Zielport 4189.

7. Nach Abschluss eines Drei-Wege-Handshakes beginnt der TLS-Handshake mit der Verwendung der Zertifikate, und die unidirektionale Authentifizierung wird durchgeführt (PCC authentifiziert das Serverzertifikat). Sowohl der Server als auch der Client warten StartTLSWait auf die Zeit, 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 kleiner als der OpenWait Timer sein. Der Standardwert OpenWait für den Timer ist auf 60 Sekunden festgelegt.

8. Nach der erfolgreichen TLS-Handshake-Sitzung initiieren PCC und PCE den Aufbau einer PCEP-Sitzung über TLS, bei der die Sitzungsparameter ausgehandelt werden.

   • Wenn die Zertifikatsüberprüfung fehlschlägt, beendet PCC die TCP-Verbindung.

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

10. Die Ver- 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 Reihe von Nachrichten, die zwischen einem Server und einem Client ausgetauscht werden. Die genauen Schritte des Handshakes variieren je nach Schlüsselaustauschalgorithmus, Verschlüsselungssammlung usw. Im Folgenden sind die grundlegenden Schritte des TLS-Handshake-Mechanismus aufgeführt:

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

2. Server Hello– Der Server antwortet auf Client Hello, indem er die Sever Hello-Nachricht sendet. Diese Nachricht enthält das Serverzertifikat, den ausgewählten kryptografischen Algorithmus, die Sitzungs-ID und den öffentlichen Schlüssel des Servers.

3. Authentication– Der Client überprüft im Hintergrund das Zertifikat des Servers mit der konfigurierten Zertifizierungsstelle, die das Zertifikat ausgestellt hat. Nach erfolgreicher Überprüfung bestätigt der Client, dass der Server echt ist, und fährt mit der Interaktion fort.

4. Optional Client Certificate– Wenn der Server ein Zertifikat vom Client in der Server-Hallo-Nachricht angefordert hat, sendet der Client das Client-Zertifikat (nur bei gegenseitigem TLS).

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

6. Decrypt secret key– Der Server entschlüsselt den geheimen Schlüssel mit dem privaten Schlüssel.

7. Client Finished– Der Client sendet eine Finish-Nachricht, die mit dem gemeinsamen geheimen Schlüssel verschlüsselt ist und signalisiert, dass der Handshake abgeschlossen ist.

8. Server Finished– Der Server antwortet mit einer Ende-Nachricht, die mit dem gemeinsamen geheimen Schlüssel verschlüsselt ist und signalisiert, dass der Handshake abgeschlossen ist.

9. Exchange Messages—Die Nachrichten nach Abschluss des Handshakes werden symmetrisch verschlüsselt.

Diagnostizieren und Validieren von TLS für PCEP-Sitzungen

Verwenden Sie für die Diagnose die folgenden traceoptions CLI-Anweisungen:

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

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

Beispielausgabe

Im Folgenden finden Sie ein Beispiel für eine Ausgabe des show path-computation-client statistics Befehls:

Diese Beispielausgabe enthält die folgenden Informationen:

• TLS ist bei PCC aktiviert.

• PCE ist TLS-fähig.

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

• Der Status der PCEPS-Sitzung ist "Aktiv und wird ausgeführt".

Vorteile der Berichtspfadoptimierung und der berechneten Metriken in PCEP

• Die Berichterstellung von in PCC konfigurierten Pfadoptimierungsmetriken hilft PCE, die Einschränkungen zu kennen, die für die Pfadberechnung verwendet werden.

• Reporting der berechneten Metriken an die PCE. Dies hilft PCE zu analysieren, ob der LSP weiter optimiert werden muss.

Grundlegendes zu 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
• Delegierte RSVP LSP
• PCE-initiierte RSVP LSP
• Delegierter SR-TE LSP
• PCE-initiierter SR-TE LSP
• Senden einer Optimierungsmetrik in einer PCRpt-Nachricht
• Senden einer berechneten Metrik in einer PCRpt-Nachricht
• Abwärtsinkompatibilität für Routenmetrik

Konfigurieren von Optimierungsmetriken für Sprachdienstleister

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 Befehle und show path-computation-client lsp extensive CLI verwenden, um den Status von Label-Switched-Pfaden (LSPs) anzuzeigen, die dem Path Computation Client (PCC) bekannt sind.

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

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

Vorteile von SRv6-TE-Tunneln mit Unterstützung von Micro-SIDs in PCEP

• Verbessern Sie das Traffic-Engineering, indem Sie dem PCE ermöglichen, SRv6-TE-Tunnel mit Micro-SIDs zu erstellen und zu verwalten, um die Netzwerkleistung und Ressourcennutzung zu optimieren.

• Sorgen Sie für eine bessere Netzwerkkontrolle und Visibilität durch die Berichterstattung und Delegierung von statischen SRv6-TE-Tunneln mit Micro-SID-Konfigurationen an die PCE.

Überblick

Durch die Integration von SRv6-TE-Tunneln mit Unterstützung für Micro-SIDs in PCEP können Sie die Traffic-Engineering-Funktionen Ihres Netzwerks erheblich verbessern. Mit dieser Funktion können Sie SRv6-TE-Tunnel mit Micro-SIDs melden, delegieren und erstellen, wobei Sie das Path Computation Element (PCE) für eine bessere Netzwerkoptimierung und -verwaltung nutzen. Wenn Sie statische SRv6-TE-Tunnel mit Micro-SID-Konfigurationen an die PCE melden, enthält dies umfassende Details wie die SID-Struktur und das Endpunktverhalten, sodass die PCE diese Tunnel effektiv verwalten kann.

Die Delegation von SRv6-TE-Tunneln mit Micro-SIDs an die PCE ermöglicht eine verbesserte Kontrolle, da die PCE die Tunnelkonfigurationen verwalten und Routing-Pfade dynamisch optimieren kann. Diese Delegierung kann so konfiguriert werden, dass sie nach der Erstellung erfolgt, oder Sie können sie so einrichten, dass Erstellung und Delegierung in einem einzigen Commit kombiniert werden, wodurch Ihr Konfigurationsprozess optimiert wird. Darüber hinaus kann das PCE SRv6-TE-Tunnel mit Micro-SIDs initiieren und so sicherstellen, dass die ordnungsgemäße Überprüfung der SID-Struktur und des Endpunktverhaltens durchgeführt wird, wodurch die Integrität und Leistung Ihres Netzwerk-Routings erhalten bleibt.

Sie können die folgenden show-Befehle verwenden, um SRv6-TE-Tunnel zu überwachen:

Mit diesen Befehlen erhalten Sie detaillierte Einblicke in den Status und die Konfiguration Ihrer SRv6-TE-Tunnel, sodass Sie bei Bedarf Fehler beheben und optimieren können. Sie können die erweiterten Funktionen von SRv6-TE-Tunneln mit Unterstützung für Micro-SIDs in PCEP in vollem Umfang nutzen.