Zusammenfassung

  • Ein XRO gilt für den gesamten Pfad; ein EXRS begrenzt einen Abschnitt innerhalb eines ERO. Beide entfernen Optionen, wählen aber nicht die übrig gebliebene Route.
  • Ein gelöschtes L-Bit bedeutet MUST exclude; ein gesetztes L-Bit bedeutet SHOULD avoid. Die zweite Vorgabe kann nach lokaler Policy dennoch zur Nutzung führen.
  • Vielfalt ist ein zu verifizierendes Ergebnis von Route, Topologie und Ressourcen, keine Zusage, die ein Flag allein transportiert.

Die Mechanik

RFC 3209 definiert das Explicit Route Object für einzuschließende abstrakte Knoten. RFC 4874 ergänzt Signalisierung für explizite Ausschlüsse, wenn der vollständige Weg nicht am Eingang berechnet werden muss. Ein XRO kann IPv4- oder IPv6-Präfixe, unnummerierte Schnittstellen, autonome Systeme und Shared Risk Link Groups benennen; Präfix- und Schnittstellenformen können zwischen Schnittstellen-, Knoten- und SRLG-Eigenschaften unterscheiden. Ein EXRS liegt dagegen als Subobject in einem ERO und gilt für einen abgegrenzten Abschnitt.

Beim nächsten Hop oder beim Auflösen einer losen ERO-Angabe muss der Berechnungsknoten verbindlich ausgeschlossene Ressourcen entfernen und nur zu vermeidende Ressourcen möglichst minimieren.

Widerspricht ein verbindlicher XRO-Eintrag einer Aufnahme im ERO, hat der Ausschluss Vorrang. Die Path-Nachricht ist abzulehnen und der definierte Routing-Problem-Fehler zurückzugeben. Bleibt nach Anwendung der Ausschlüsse keine Weiterleitungsmöglichkeit, soll ein PathErr melden, dass die Route durch den Exclude Route blockiert wurde. Ist der XRO für Implementierung oder Policy zu komplex, kann ebenfalls ein spezifischer PathErr folgen. Das ist ein Setup-Fehler, nicht die automatische Auswahl eines Ersatzpfads.

Ein Knoten ohne XRO-Unterstützung darf das Objekt aufgrund seiner Klassennummer weiterleiten, ohne es zu prüfen. Nicht unterstützte Subobjects oder Attribute können ignoriert werden. Deshalb ist End-to-End-Unterstützung nicht vorauszusetzen: Record Route muss von den Berechnungsknoten ausgewertet werden, um Verletzungen zu erkennen und, sofern möglich, neu zu berechnen. Grenzübergänge, Sicherheitsregeln zum Entfernen gewöhnlicher ERO-Informationen und unterschiedliche Implementierungsfähigkeiten bestimmen, welche Teile der Einschränkung tatsächlich weiterwirken.

Ausschluss ist kein Pfadentwurf

XRO eignet sich für die Berechnung nicht überlappender Schutz-LSPs: Ein erster Weg wird aufgezeichnet, anschließend werden seine Knoten oder Risiken für den zweiten ausgeschlossen. Das liefert aber weder den zweiten Weg noch den Nachweis, dass er vorhanden oder physisch getrennt ist. Ausschlüsse können in einer anderen Berechnungsdomäne irrelevant werden, wenn deren Ressourcen nicht betroffen sind; sie können bei einer Neuberechnung ergänzt oder entfernt werden. Originator, Berechnungsknoten und nachgelagerte Implementierungsinstanz müssen daher klären, wer den Ausschluss erhält, auflöst und kontrolliert.

RFC 6001 aktualisiert RFC 4874 für mehrschichtige und multiregionale GMPLS-Netze. Es ergänzt XRO-Subobjects für Switching Capability und Labels und behält die Unterscheidung zwischen verbindlichem Ausschluss und bloßer Vermeidung. RFC 8390 ergänzt Diversity-XRO- und Diversity-EXRS-Subobjects. Ihr Verweis kann auf eine von Client, PCE oder Netzwerk vergebene Kennung einer Referenz-LSP oder eines Referenzpfads zeigen, auch wenn der Anforderer deren Detailressourcen nicht kennt. Das kann Topologieoffenlegung und Wissensbedarf reduzieren, verlagert aber die Korrektheit auf die Stelle, die die Kennung auflöst und den Referenzpfad prüft.

Mandatory und advisory diversity, Fehler bei inkonsistenten oder nicht unterstützten Kennungen sowie der vorgeschriebene Erhalt der Diversity-Subobjects über eine Grenze hinweg bleiben maßgeblich, selbst wenn gewöhnliche ERO-Daten aus Sicherheitsgründen entfernt werden.

Macht, Nutzen und Kosten

Der Originator erhält ein Vetorecht über benannte Ressourcen. Der Berechnungsknoten behält die Autorität darüber, welche verbleibende Route gewählt wird oder ob keine existiert. Begünstigt werden Dienste, die Link-, Knoten-, SRLG- oder Referenzpfadvielfalt benötigen. Die Kosten sind eine kleinere zulässige Menge, zusätzlicher Signalisierungszustand, mögliche Topologieoffenlegung sowie Abhängigkeit von Unterstützung an allen Knoten und Grenzen. Ohne Ausschluss kann ein berechneter Weg die unerwünschte Ressource wiederverwenden. Mit zu vielen verbindlichen Ausschlüssen scheitert die Einrichtung.

Bei advisory avoidance bleibt Verfügbarkeit höher, aber lokale Policy kann die unerwünschte Ressource akzeptieren.

Analyse von Elias Ward: Ein verbindlicher Ausschluss macht aus einer Präferenz eine fail-closed-Bedingung. Das schützt Trennung, kann aber die Einrichtung verhindern. Die Quellen belegen keine konkreten Betreiber, Hersteller, Deployments, Vorfälle, Messwerte, Kundenfolgen, Pfadqualität, Setup-Latenz oder Fehlerquoten. Sie belegen auch keine aktuell machbare Route in einer realen Topologie. Es gibt in diesem Briefing keine Allegation. Unbekannt bleibt insbesondere, ob ein signalisiertes Diversity-Erfordernis in der Live-Topologie tatsächlich physische Verschiedenheit erzeugt.

Konkrete Prüf-Fixtures

  1. Grundfall: Baue zwei mögliche nächste Hops und schließe eine Schnittstelle mit gelöschtem L-Bit aus. Prüfe die tatsächliche Auswahl gegen XRO; behaupte nicht, der Ausschluss habe den verbleibenden Hop gewählt.
  2. ERO-Konflikt: Nimm dieselbe Ressource in ERO auf und schließe sie verbindlich im XRO aus. Erwartet werden Ablehnung und Routing Problem.
  3. Alles blockiert: Schließe sämtliche Weiterleitungsoptionen aus. Erwartet wird PathErr mit dem Hinweis auf Blockierung durch Exclude Route.
  4. Überkomplexität: Sende einen XRO, der Implementierung oder Policy überfordert, und prüfe den spezifischen PathErr.
  5. L-Semantik: Wiederhole den Fall mit gesetztem L-Bit. Dokumentiere SHOULD avoid und akzeptiere eine lokale Durchquerung als möglich, nicht als Verstoß gegen MUST.
  6. Unterstützungsgrenze: Leite XRO durch einen nicht unterstützenden Knoten oder mit nicht unterstütztem Subobject; prüfe Record Route auf eine Verletzung und die Möglichkeit einer Neuberechnung.
  7. Mehrschichttest: Schließe Switching Capability und Label nach RFC 6001 in mehreren GMPLS-Schichten aus; prüfe beide L-Semantiken.
  8. Referenztest: Verwende eine Client-, PCE- oder Netzwerkkennung nach RFC 8390, teste eine inkonsistente und eine nicht unterstützte Kennung und prüfe ihre Retention über die Grenze.
  9. Diversitätsnachweis: Vergleiche Record Route mit Topologiedaten und realen Ressourcen. Ein erfolgreich signalisiertes LSP ist allein kein Beleg physischer Diversität.

Bedienerentscheidung

Bestimme zuerst den Begünstigten und den räumlichen Geltungsbereich. Verwende MUST, wenn erneute Ressourcennutzung schlechter ist als ein Setup-Fehler; verwende SHOULD, wenn Verfügbarkeit Vorrang hat. Prüfe Unterstützung pro Domäne und Grenze für XRO, EXRS, RFC 6001 und RFC 8390. Lege fest, welche PathErr eine Eskalation auslösen. Nach dem Setup: Record Route, Referenzkennung und Topologie abgleichen. Fehlt die Übereinstimmung, ist Vielfalt nicht nachgewiesen.

Quellen