Zusammenfassung

  • RFC 5152 ermöglicht die abschnittsweise Berechnung eines domänenübergreifenden TE-LSP, wenn der Head End den vollständigen Pfad weder kennt noch signalisieren kann.
  • Eine Domäne kann ein AS, ein IGP-Bereich, eine Overlay-Struktur oder ein rekursiv unterteilter Berechnungsraum sein.
  • Der jeweilige Boundary LSR berechnet den nächsten Abschnitt mit lokaler TE-Sicht, lokaler Erreichbarkeit und lokalen Richtlinien.
  • Ein ERO darf strikte und lose Hops mischen; frühe strikte Entscheidungen verbrauchen Wahlfreiheit, lose Hops delegieren sie an spätere Grenzen.
  • Ein Exit kann statisch, über IGP oder BGP oder durch Policy bestimmt werden; Erreichbarkeit beweist jedoch keine günstige Ressourcenaufteilung für ein Pfadpaar.
  • Bei nachgelagertem Scheitern liefert PathErr einen Fehler zurück, und Crankback kann einen anderen Egress versuchen.
  • Wiederholung, Egress-Wechsel und Lockerung einer Bedingung prüfen jeweils eine andere Hypothese und bilden keinen vollständigen Suchnachweis.
  • RFC 5152 sagt ausdrücklich, dass domänenweise Berechnung keinen optimalen domänenübergreifenden Pfad garantiert.
  • Im Trapping-Beispiel blockiert A-B-C-D einen zweiten diversen Pfad, obwohl A-C-D und A-B-D gemeinsam ein diverses Paar bilden.
  • Die erste Reservierung kann daher kombinatorisch wertvolle Links binden, ohne dass ihre Einzelmetriken auffällig schlecht sein müssen.
  • Lokale Reoptimierung kann jeden Domänenabschnitt verbessern und trotzdem dieselbe ungeeignete Folge von Boundary LSRs beibehalten.
  • Wer Diversität verkauft, muss das Paar als gemeinsame Ressourcenzuteilung beauftragen und Suchmethode, Datenstand, Exits, Ausschlüsse und verbrauchte Ressourcen belegen.

Gestrandete Redundanz ist kein bloßer Kapazitätsmangel

Bei Redundanz wird häufig in Summen gedacht: Wie viel Bandbreite ist noch frei, wie viele Links sind verfügbar, wie viele alternative Übergänge gibt es? Für ein diverses Paar reicht diese Bestandsaufnahme nicht. Entscheidend ist, ob die freien Ressourcen noch in zwei Kombinationen angeordnet werden können, die die verlangten Risiken nicht teilen.

Genau diese kombinatorische Eigenschaft macht das Trapping-Beispiel aus RFC 5152 so wichtig. Zwischen A und D sind die Pfade A-C-D und A-B-D als diverses Paar möglich. Wird zuerst A-B-C-D gewählt, ist dieser Pfad für sich genommen zulässig. Danach gibt es aber keinen zweiten Pfad, der zu ihm divers ist. Die erste Auswahl hat auf beiden Seiten jene Bausteine belegt, die getrennt auf zwei Pfade hätten verteilt werden müssen.

Das Netz ist dadurch nicht plötzlich ärmer geworden. Die Ressourcen wurden nur in einer Form gebunden, in der sie die vertragliche Funktion nicht mehr erfüllen. Das ist gestrandete Redundanz: technische Reserve, die bilanziell vorhanden ist, aber wegen einer vorherigen Entscheidung nicht als zusammenhängende Schutzleistung eingesetzt werden kann.

Domänenweise Berechnung optimiert unter getrennten Büchern

RFC 5152 adressiert eine reale Organisationsgrenze. Der Ingress LSR besitzt oft keine vollständige Sicht über mehrere IGP-Bereiche oder autonome Systeme. Er signalisiert die bekannte Route beziehungsweise das Ziel bis zu einem Boundary LSR. Dieser berechnet den nächsten Abschnitt aus seiner Traffic-Engineering-Datenbank, den erreichbaren Nachbardomänen, den unterstützten Verfahren und der eigenen Policy.

Die verantwortlichen Berechnungsknoten liegen dabei selbst auf dem entstehenden LSP. Ein AS kann zudem intern aus weiteren Bereichen oder Sub-AS bestehen, sodass dasselbe Muster rekursiv auftritt. Jeder Schritt führt eine lokale Bilanz: Ist der Abschnitt machbar, ist der nächste Grenzknoten erreichbar, dürfen die angeforderten Ressourcen eingesetzt werden?

Was fehlt, ist nicht notwendigerweise Information über einen einzelnen Link. Es kann die gemeinsame Bilanz des Pfadpaares fehlen. Eine Grenze sieht, dass ihr bevorzugter Egress für Pfad eins passt. Sie sieht womöglich nicht, dass genau dieser Egress später die einzige disjunkte Kombination für Pfad zwei zerstört. Lokale Zulässigkeit und globale Opportunitätskosten werden in verschiedenen Büchern geführt.

Strikte Hops fixieren Ressourcen, lose Hops fixieren Verantwortungsübergänge

Das Explicit Route Object kann vollständig strikt sein, zunächst einen strikten Quellbereich beschreiben und danach Boundary LSRs aufführen, mehrere Domänenkennungen enthalten oder nur die gegenwärtige Grenze und das endgültige Ziel vorgeben. Strikte und lose Hops dürfen kombiniert werden.

Ein strikter nächster Knoten wird nach den üblichen RSVP-TE-Regeln verarbeitet. Ein loser Hop oder ein abstrakter Hop über mehrere LSRs muss lokal expandiert werden. Damit kann der Head End dort präzise sein, wo er Wissen besitzt, und die unbekannten Abschnitte delegieren.

Der erfolgreiche ERO ist jedoch lediglich die Quittung für die gewählte Zusammensetzung. Er zeigt nicht, welche Exit-Kandidaten verworfen wurden, welche Shared-Risk-Gruppen die Algorithmen kannten, wie sich eine erste Reservierung auf die zweite Suche auswirkte oder ob überhaupt ein Paarproblem berechnet wurde. Aus einem installierten Pfad lässt sich die verlorene Wahlfreiheit nicht rückwärts zuverlässig ablesen.

Erreichbarer Egress und ressourcenschonender Egress sind verschiedene Aussagen

Ein Domänenausgang kann vorkonfiguriert sein oder aus IGP-, BGP- oder Policy-Informationen abgeleitet werden. Liegt ein nächster Hop außerhalb der lokalen TE-Datenbank, prüft die Grenze, ob er tatsächlich außerhalb der Domäne liegt, ob die Voraussetzungen für Packet Switching und In-Band-Control gelten und ob IP-Erreichbarkeit besteht.

Ist der Hop nicht erreichbar, folgt ein Routing-Problem-PathErr. Fehlt sowohl ein Erkennungsverfahren als auch eine alternative Exit-Vorgabe, scheitert die Berechnung. Diese Regeln begrenzen Fehler und ermöglichen Fortschritt ohne vollständigen Topologieaustausch.

Erreichbarkeit ist aber ein Fortsetzungsnachweis, kein Kapazitätsportfolio. Ein Egress kann für Pfad eins erreichbar, reservierbar und kostengünstig sein und zugleich jene Linkkombination beanspruchen, die dem zweiten Pfad als einzige risikoseparierte Route dienen könnte. Wer nur die Einzelkosten des ersten Pfads bewertet, kann die teuerste Entscheidung gerade als billigste verbuchen.

Crankback ist ein Reparaturmechanismus, keine Inventur aller Alternativen

Findet ein nachgelagerter ASBR keinen zulässigen Abschnitt, sendet er PathErr zur vorherigen Grenze. Wenn Crankback erlaubt und konfiguriert ist, kann diese einen anderen Egress wählen. Ohne Crankback wird der Fehler zum Head End zurückgegeben. Dort kann eine andere Folge loser Hops hinterlegt sein.

Der Head End kann denselben Versuch auch wiederholen, wenn eine veraltete IGP-TE-Sicht in einer späteren Domäne vermutet wird. Oder er lockert Bandbreite, Priorität beziehungsweise eine andere Bedingung. Diese Handlungen sind operativ sinnvoll, dürfen aber nicht in eine einzige Erfolgskategorie fallen.

Ein anderer Egress untersucht einen weiteren lokalen Ast. Eine spätere Wiederholung prüft einen neuen Netzzustand. Eine Lockerung beschafft eine andere Dienstleistung. Keine dieser Handlungen beweist allein, dass für die ursprünglichen Bedingungen alle globalen Paarungen durchsucht wurden. Auch zehn fehlgeschlagene lokale Varianten sind kein Unmöglichkeitsbeweis, wenn die erste Ressourcenbindung unangetastet bleibt.

Die zweite Suche erbt die Opportunitätskosten der ersten

Für einen einzelnen LSP ist eine Reservierung vor allem ein erfolgreicher Zustand. Für das Pfadpaar ist sie zusätzlich eine irreversible beziehungsweise nur kostspielig reversible Vorentscheidung. Die zweite Berechnung startet nicht im ursprünglichen Netz. Sie startet in dem Netz, das Pfad eins hinterlassen hat, und soll außerdem die von ihm berührten Risiken meiden.

Darum ist die Meldung „kein diverser Pfad gefunden“ unvollständig, wenn sie keinen Fingerabdruck des ersten Pfads enthält. Sie muss auch den Datenstand, die Diversity-Definition, die bereits belegten Ressourcen, die geordneten Exit-Entscheidungen und den Suchalgorithmus nennen. Ohne diese Angaben wird aus einer bedingten Aussage über den Restbestand eine angebliche Aussage über die Topologie.

Die wirtschaftliche Folge ist erheblich. Unternehmen können in physische Redundanz investieren und trotzdem nur serielle Feasibility erhalten. Das Kapital steckt dann in Leitungen und Übergängen, die technisch funktionieren, sich aber nach der ersten Zuweisung nicht mehr zum versprochenen Schutzprodukt kombinieren lassen.

Reoptimierung kann das falsche Grenzgerüst effizienter machen

Bei einem zusammenhängenden LSP kann eine nachgelagerte Domäne dem Head End einen besseren Pfad melden; Make-before-break bleibt unter dessen Kontrolle. Bei verschachtelten oder gestitchten Konstruktionen kann eine Domäne ihr H-LSP oder S-LSP lokal und weitgehend transparent reoptimieren. Metriken, Zeitpunkte und Bandbreitenregeln dürfen sich je Domäne unterscheiden.

Das verbessert Auslastung oder Kosten im Inneren. Wenn die Boundary LSRs als lose Anker erhalten bleiben, wird jedoch nicht zwingend die Domänenfolge neu gewählt. Alle lokalen Abschnitte können nach ihren eigenen Maßstäben besser werden, während das Paarproblem weiterhin an derselben Grenzkombination scheitert.

Ein belastbares Änderungsprotokoll muss deshalb ausweisen, ob lediglich interne Hops, ein Egress oder die gesamte interdomänale Zusammensetzung geändert wurden. Das Wort Reoptimierung sagt sonst mehr, als die Maßnahme geleistet hat.

Vertraulichkeit schützt Topologien, aber nicht vor falscher Ressourcenlogik

Das Verfahren vergrößert laut RFC 5152 nicht den Topologieaustausch zwischen autonomen Systemen. Jede Domäne behält ihre detaillierte Karte und gibt nur weiter, was für Signalisierung und Fehlerbehandlung erforderlich ist. Das ist ein legitimer Architekturvorteil.

Die begrenzte Sicht verlangt jedoch eine präzise Grenze für globale Aussagen. RFC 5152 erlaubt dem Provider, das Berechnungsverfahren je LSP auszuwählen, und verweist für end-to-end Constraint-Pfade oder diverse Mengen auf PCE-basierte Ansätze. Daraus folgt keine universelle Garantie: Auch ein PCE kann unvollständige Daten, veraltete Zustände oder eine ungeeignete Risikoabstraktion besitzen.

Boundary-Berechnung erweitert außerdem die Angriffsfläche. Erforderlich sind Richtlinien für autorisierte ERO-Expansion, Filter für Bandbreite und Priorität, Begrenzung von Setup- und Fehlerraten, Kontrolle ausgehender Nachrichten sowie abgestimmte RSVP-Authentifizierung. Diese Maßnahmen schützen Ressourcen vor Missbrauch. Sie ersetzen nicht den Nachweis, dass Ressourcen für das beauftragte Paar gemeinsam disponiert wurden.

Quellen

  1. RFC 5152, HTML
  2. RFC 5152, Text
  3. RFC-Editor-Eintrag
  4. IETF-Datatracker-Eintrag
  5. Versionsgeschichte von RFC 5152
  6. Referenzen von RFC 5152
  7. Errata zu RFC 5152
  8. RFC 3209
  9. RFC 3473
  10. RFC 5151
  11. RFC 5150
  12. RFC 4920
  13. RFC 4655
  14. RFC 4726
  15. RFC 4105
  16. RFC 4216
  17. RFC 4736
  18. RFC 2747
  19. RFC 3097
  20. RFC 3630
  21. RFC 4203
  22. RFC 4205
  23. RFC 6805
  24. RFC 8694
  25. Minimum Initial Specification
  26. On Reality Layers
  27. Running-Code Primacy